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