LEAN AND MEAN
Recipes for Managing Successful Products
Disclaimer
This presentation is focused on creating high growth b2c/SaaS software products
Wix.com - Real WYSIYG Web Editing
3
One Design Template. Endless User Designs.
Wix.com – Growing beyond design
4
Registered Users
36 million 1H’132010-12 CAGR: 108%
Premium Subscriptions
626,000 1H’132010-12 CAGR: 78%
Collections
$72 million LTM2010-12 CAGR: 93%
2008 2012 2013
Flash MobileApp MarketHTML5
20122009
Ecommerce
Gig Kaplan Entrepreneur and innovator. Age 43. born and based in Israel.
WIX – Co-Founder & CTO
• Managed HR, R&D, System & Product for the 1st 4 years
• Focus - Product Road maps and specific products and HR architecture
CV
• Started coding at 12, My last line of code was 2003.
• 3 years army - Developer and Sys Admin
• Co - Founded 6 software and internet start-ups, 1st one at 15
• Involved in kick starting another 7 start-ups, 1 dance group, 1 nonprofit
• Studied – Psychology, Philosophy, Yoga, Dance
The Fundamentals
Team building
Product life cycle
Early stage
On going management
Tech choices
Becoming methodical
TEAM BUILDING
It’s not business, it’s personal
Success is a team effort
People are your main asset
•Teams can have multiple leaders
•Good teams are skill balanced
•Keep teams small and personal
•Aggressive is good, Mean is bad
•Teams should allow individuality
Recruitment Process
Smart, Fun people that can Execute
• Test people for real deliverables
• Make the interview personal – do you like the person
• Hire skills not knowledge
• Go into details of a previous work experience
• Check recommendations
Open culture is the key
• Open doors if any
• Goals and results are in the open
• BI is open to all employees
• Everyone can provide feedback
• It is ok to fail, just don't be dumb about it
• Problems are humored not hidden
• People subscribe to reports
Indicators of a Healthy Culture
• People recruit their friends
• Do not give prizes
• People meet after hours
• People can be angry but are not mean
• Few formal meetings
• People meet and talk organically
• People approach management
Human Architecture
• Software architecture creates divides
• Client, Server, System
• Different roles creates divides
• Product, Marketing, R & D, QA, Support
• Work on breaking those divides
• People should be able to influence out side of their scope
• Create opportunities for interaction
Product Management is not a role it is skills
• Passion, Focus, Eye for details
• The 6 skills - no one has them all
• Product marketing - Road map & Commercialization
• Product analysis - Use cases
• Product UX - Screens
• Product packaging - Design, Text
• Project management - Get it done, Organization
• Technical knowhow - It should work :)
Developers are product people too
• Good developers need to be engaged with the road map, users and the creative process, otherwise they will kill the product
• Develop technology instead of product
• Become architects instead of coders
• Developers must be given time to engage with the product
• Brain storm, work on products, support users, meet users, access to bi
• Developers must offload from PM
• Technology is a product too
• APIs, System architecture, DB, etc... are all products and should be treated as such
QA & Support
•Doubt your need for QA & Support
•Product & Dev should be engaged in both
•Small & testable features should not be QA’d but released
•Use a good test driven methodology and monitoring instead
Good Practices• Product and R & D people should be in the same room
• All should be aware of road map, support issues, BI, etc...
• All should be aware of everybody's work, and allowed to contribute
• Go over the list of potential features and try to find the cheapest ways for implementation - look for quick wins
• Feature assessment time should be slotted
• Developers should be able to deploy there own features to be tested
• Management should meet with team and not with pm to discuss road map
• Get drunk together
Problem Indicators
•Long emails
•Long specs
•Bullshit ideological conflicts
•People talk in us and them
•Meetings
PRODUCT LIFE CYCLE - EARLY STAGE
Be open to failure
Early Stage Recipe• Get a great team
• Get started - minimal feature set
• Get to the market early, Get users
• Launch
• Constantly test & get feedback
• Measure (logs, analytics, support calls,..)
• Focus on the bottom line - conversion, usage, retention = $
• Talk to users, see what they do with the product
• Asses
Identifying the minimal features set
• Define your basic assumptions
• Always start with testing your assumption
• Identify the minimal feature which would test this assumption
• my favorite tool
• Imagine yourself releasing without the feature
Getting to the market early
The don’ts
• Ignore things your team can not do
• Ignore good problems
• Ignore scalability
• Ignore architecture
• Ignore future features
• Ignore business model
Getting to the market early
The do’s• Focus on the differentiator
• Keep design simple
• Copy simple design from somewhere
• Text should explain the value
• Focus on the empty screen and the first steps
• Provide a place for users to interact with you
• Analytics and logs are a must
Launching your product
•Minimal assumption on your users
•Communicate with bloggers, forums, opinion leaders
•Buy some advertising
•Multiple launch is easy - Try this
•Provide feedback format
Measure EarlyA/B Testing, Logs, Analytics &
Monitoring
• A company culture cornerstone
• Feature testing methodology is key to acceleration
• Makes sure you didn't break things
• Reduces lengthy discussions
• Reduces over design
• Sometimes even acknowledges success
• Allows everybody to release their features
User Feedback• More important then testing
• Become the user - Use you own product
• Talk to your users, they love it
• Look at what they do
• Provide feedback mechanism
• Contacts, Chat, Forum, Wish list,...
• Everybody should interact with users
Assessment - FailureIt is better to close early then a slow
death
IF launch successful
Great
IF not
Did you get reaction from users
Improve
IF not
RETHINK
Assessment - SuccessUnderstand why users use your product
• This is your most important task
• It can be:
• a Specific feature
• Combination
• Packaging
• Price Point
• …
PRODUCT LIFE CYCLE - ONGOING PRODUCT
Managing focus
Product Deliverables
• Must be simple - no one has attention
• Lists - manage knowledge
• Road maps - manage focus
• Spec = Screens & Use Cases
• Focus on the empty screen - 1st time user experience
Managing the Product
On Going dual effort•Optimizations are driven by lists
•Bug fixes, feature improvement, user requested, competitors, performance..
•Leaps are driven by road maps
•Good optimization effort can be a leap
•Managed similarly to new product
goals feature status owner priority source
wow animations p. ready users
wow rotationR&D
research
cash billing brazil research CFO
operation CDN monitor tbd CTO
Lists, Lists, ListsManaging the feedback loop
Vision/ideas, User feedback, complaints, successes, Bi, logs, monitoring, Operational
needs (billing, system), Competitors gap
Product road mapFacilitating discussion and
alignment •All the lists
•Inspirations
•Key assumptions
•Goals
•Resource allocation and shortages
•Critical action items
Managing Focus•3-6 month roadmaps
•half time work plans (1-3 months)
•4 levels
•Can not fail
•Very important
•Opportunistic
•Maintenance/ongoing
Work planactual planning
resource week 1 week 2 week 3 ....
dev 1 C. F 1 C.F 1 C.F 1
dev 2 C.F 2 C.F 2 C.F 2
dev 3 List vacation List
dev 4 List List List
Dev 5Maintenanc
eMaintenanc
eMaintenanc
e
Know your real resources How many do you really haveAllocate around the can not fail & maintenance
Commit to Plans
• Once you have a plan commit and execute
• Do not double guess
• If derailed stop to reassess
• Suicide mode doesn’t work
• Drop the non critical
• Do not drop the ongoing
Plan Early
•Use the Garbage time
•Post major release energy drop
•Stuff in Qa/Support/v1.1Phase
•Best time to plan
•Get the developers involved
Pit falls
•Not enough time for effort estimation
•Long tasks - not broken to smaller bits
•Over Design
•Developers methodology overshadowing
•Not enough value in a work plan
CHOOSING THE TECH
Keep It Simple Stupid
Architecture is overrated
Use common sense instead
• Assume you will rewrite your product at least twice
• Keep it simple, keep it modular
• Modeling before you know the domain rarely works
• Patterns are overrated
Do not focus on scalability
Unless you have to :)
• Scalability is a syndrome which happens to successful companies
• Succeed first - Focus on product and marketing
• If you have to:
• Cloud => CDN => Write/read asymmetric => Shard
• SOA: Use carefully
Focus on manageabilityTests, Logs, Monitor, BI
• The earlier you can intro testing, logs, bi & monitor them the better
• Use logs & Analytics from day 1
• Start simple and evolve
• Introduce a/b testing mechanism as early as possible
Don’t choose the stack
Choose the developers• It doesn’t matter
• php/ruby/java/python/.net - they all suck :)
• People matter
• Choose the technology that your people know best or that you have access to hands on expert
• Create methodology and teach it to people
• A great developer can work in any environment
• A mediocre developer you can not afford
Clouds - are not 99.99but your code has more errors
• Delay creating a “system” as much as you can
• For most product a cloud is the right choice
• Do not own the machines - it costs more
Storage is cheapabuse it
• Make sure information is replicated and redundant
• you will screw up
• Do not bother to delete
• Fragments disks
• Very hard to recover from bugs
CDN is magicabuse it
•Anything which can be delivered from a CDN is scalable
•We CDN media, queries, page parts
•Use version variables instead of flushing
Data Bases are dumb
so keep it simple•Offload to client if you have one
•If not, offload to app server
•Do not transact in the DB
•Use GUID instead of Id
•Duplicate data per index is not a sin
Architecture Sample
Doc Header
DB
Doc Header
DBUserSiteUserSite
CDNStatic
Storage
CDNStatic
Storage
BIBI LoggerLogger
BECOMING METHODICAL
It is the corner stone for growth