Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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

One Design Template. Endless User Designs.

3
Wix.com – Growing beyond design
Registered Users

Premium Subscriptions

Collections

36 million 1H’13
2010-12 CAGR: 108%
...
Gig Kaplan
Entrepreneur and innovator. Age 43. born and based in Israel.
WIX – Co-Founder & CTO

•
•

Managed HR, R&D, Sys...
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
• K...
Recruitment Process
Smart, Fun people that can Execute

•
•
•
•
•

Test people for real deliverables
Make the interview pe...
Open culture is the key
•
•
•
•
•
•
•

Open doors if any
Goals and results are in the open
BI is open to all employees
Eve...
Indicators of a Healthy Culture

•
•
•
•
•

People recruit their friends

•

Do not give prizes

People meet after hours
P...
Human Architecture
•
•
•

Software architecture creates divides

•

Client, Server, System

Different roles creates divide...
Product Management
is not a role it is skills

•
•

Passion, Focus, Eye for details
The 6 skills - no one has them all

•
...
Developers are product people too
•

Good developers need to be engaged with the road map, users and the
creative process,...
QA & Support
•
•
•

Doubt your need for QA & Support

•

Use a good test driven methodology and
monitoring instead

Produc...
Good Practices
•
•
•
•

Product and R & D people should be in the same room

•
•
•
•

Feature assessment time should be sl...
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...
Identifying the minimal features set

•
•
•
•

Define your basic assumptions
Always start with testing your assumption
Ide...
Getting to the market early
The don’ts
•
•

Ignore things your team can not do
Ignore good problems

•
•
•
•

Ignore scala...
Getting to the market early
The do’s
•
•

Focus on the differentiator
Keep design simple

•
•

•
•
•

Copy simple design f...
Launching your product
•
•

Minimal assumption on your users

•
•
•

Buy some advertising

Communicate with bloggers, foru...
Measure Early
A/B Testing, Logs, Analytics & Monitoring

•
•

A company culture cornerstone
Feature testing methodology is...
User Feedback
•
•
•
•
•

More important then testing
Become the user - Use you own product
Talk to your users, they love i...
Assessment - Failure
It is better to close early then a slow death
IF launch successful
Great
IF not
Did you get reaction ...
Assessment - Success
Understand why users use your product

•
•

This is your most important task
It can be:

•
•
•
•
•

a...
PRODUCT LIFE CYCLE - ONGOING PRODUCT

Managing focus
Product Deliverables
•
•
•
•
•

Must be simple - no one has attention
Lists - manage knowledge
Road maps - manage focus
Sp...
Managing the Product
On Going dual effort

•
•

Optimizations are driven by lists

•

Bug fixes, feature improvement, user...
Lists, Lists, Lists
Managing the feedback loop
goals

feature

status

owner

priority

source

wow

animations

p. ready
...
Product road map
Facilitating discussion and alignment

• All the lists
• Inspirations
• Key assumptions
• Goals
• Resourc...
Managing Focus
• 3-6 month roadmaps
• half time work plans (1-3 months)
• 4 levels
• Can not fail
• Very important
• Oppor...
Work plan
actual 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...
Commit to Plans
•
•
•
•
•

Once you have a plan commit and execute
Do not double guess
If derailed stop to reassess

•

Su...
Plan Early
• Use the Garbage time
• Post major release energy drop
• Stuff in Qa/Support/v1.1Phase
• Best time to plan
• G...
Pit falls
•
•
•
•
•

Not enough time for effort estimation
Long tasks - not broken to smaller bits
Over Design
Developers ...
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 s...
Do not focus on scalability
Unless you have to :)

•

Scalability is a syndrome which happens to successful
companies

•
•...
Focus on manageability
Tests, Logs, Monitor, BI

•

The earlier you can intro testing, logs, bi & monitor them the
better
...
Don’t choose the stack
Choose the developers
•

It doesn’t matter

•
•

php/ruby/java/python/.net - they all suck :)

Peop...
Clouds - are not 99.99
but your code has more errors

•
•
•

Delay creating a “system” as much as you can
For most product...
Storage is cheap
abuse it

•
•

Make sure information is replicated and redundant

•

you will screw up

Do not bother to ...
CDN is magic
abuse it

• Anything which can be delivered from a
CDN is scalable

• We CDN media, queries, page parts
• Use...
Data Bases are dumb
so keep it simple

• Offload to client if you have one
• If not, offload to app server
• Do not transa...
Architecture Sample
User
User
Site
Site

Doc
Doc
Header
Header
DB
DB

CDN
CDN
Static
Static
Storage
Storage

BI
BI

Logger...
BECOMING METHODICAL

It is the corner stone for growth
Upcoming SlideShare
Loading in …5
×

IDCEE 2013: Lean scalability: product, HR and technology for rapid growth - Giora Kaplan (Co-founder & CTO @ WIX)

2,156 views

Published on

http://idcee.org/p/giora-kaplan/

Gig is a web visionary with extensive experience in product management and technological invention. Together with his co-founders, Gig has managed to revolutionize the web by developing the technology allowing everyone to easily create a professional and striking web presence.

Gig has been involved in web publishing since the early 90s. His personal vision is to make web technologies accessible to all, and this has made him instrumental in shaping Wix’ platform. He is bored by and hates “me too” and copy-cat ideas.

Gig’s experience focuses in the consumer internet and digital publishing fields, most notable of which is Optimedia Ltd which provides cutting edge internet & digital publishing technology to global publishing houses. In all his companies, one of Gig’s top priorities is the work environment and it’s important for him to provide a fun, creative and inspiring place to work.

On a day off you can catch him scuba diving, surfing or cooking.

Pic's are here: http://www.flickr.com/photos/idcee/sets/

More @ http://idcee.org

Follow us on:
YouTube: http://www.youtube.com/user/OfficialIDCEEChannel
Facebook: https://www.facebook.com/IDCEE
Linkedin: http://www.linkedin.com/groups/IDCEE-3940138
Twitter: https://twitter.com/idcee_eu
Google+: http://gplus.to/idcee
Flickr: http://www.flickr.com/photos/idcee/collections/

Published in: Business, Technology
  • Be the first to comment

IDCEE 2013: Lean scalability: product, HR and technology for rapid growth - Giora Kaplan (Co-founder & CTO @ WIX)

  1. 1. LEAN AND MEAN Recipes for Managing Successful Products
  2. 2. Disclaimer This presentation is focused on creating high growth b2c/SaaS software products
  3. 3. Wix.com - Real WYSIYG Web Editing One Design Template. Endless User Designs. 3
  4. 4. Wix.com – Growing beyond design Registered Users Premium Subscriptions Collections 36 million 1H’13 2010-12 CAGR: 108% 626,000 1H’13 2010-12 CAGR: 78% $72 million LTM 2010-12 CAGR: 93% 2008 2009 2012 2012 2013 Flash Ecommerce HTML5 App Market Mobile 4
  5. 5. 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 • • • • • Started coding at 12, My last line of code was 2003. Focus - Product Road maps and specific products and HR architecture CV 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
  6. 6. The Fundamentals Team building Product life cycle Early stage On going management Tech choices Becoming methodical
  7. 7. TEAM BUILDING It’s not business, it’s personal
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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 :)
  14. 14. 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 • • • Become architects instead of coders Developers must be given time to engage with the product • • • Develop technology instead of 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
  15. 15. QA & Support • • • Doubt your need for QA & Support • Use a good test driven methodology and monitoring instead Product & Dev should be engaged in both Small & testable features should not be QA’d but released
  16. 16. Good Practices • • • • Product and R & D people should be in the same room • • • • Feature assessment time should be slotted 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 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
  17. 17. Problem Indicators • Long emails • Long specs • Bullshit ideological conflicts • People talk in us and them • Meetings
  18. 18. PRODUCT LIFE CYCLE - EARLY STAGE Be open to failure
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. Launching your product • • Minimal assumption on your users • • • Buy some advertising Communicate with bloggers, forums, opinion leaders Multiple launch is easy - Try this Provide feedback format
  24. 24. Measure Early A/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
  25. 25. 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
  26. 26. Assessment - Failure It 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
  27. 27. Assessment - Success Understand why users use your product • • This is your most important task It can be: • • • • • a Specific feature Combination Packaging Price Point …
  28. 28. PRODUCT LIFE CYCLE - ONGOING PRODUCT Managing focus
  29. 29. 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
  30. 30. 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
  31. 31. Lists, Lists, Lists Managing the feedback loop goals feature status owner priority source wow animations p. ready wow rotation R&D research cash billing brazil research CFO operation CDN monitor tbd CTO users Vision/ideas, User feedback, complaints, successes, Bi, logs, monitoring, Operational needs (billing, system), Competitors gap
  32. 32. Product road map Facilitating discussion and alignment • All the lists • Inspirations • Key assumptions • Goals • Resource allocation and shortages • Critical action items
  33. 33. Managing Focus • 3-6 month roadmaps • half time work plans (1-3 months) • 4 levels • Can not fail • Very important • Opportunistic • Maintenance/ongoing
  34. 34. Work plan actual 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 5 Maintenance Maintenance Maintenance Know your real resources How many do you really have Allocate around the can not fail & maintenance ....
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. CHOOSING THE TECH Keep It Simple Stupid
  39. 39. 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
  40. 40. 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
  41. 41. Focus on manageability Tests, 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
  42. 42. 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
  43. 43. Clouds - are not 99.99 but 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
  44. 44. Storage is cheap abuse 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
  45. 45. CDN is magic abuse it • Anything which can be delivered from a CDN is scalable • We CDN media, queries, page parts • Use version variables instead of flushing
  46. 46. 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
  47. 47. Architecture Sample User User Site Site Doc Doc Header Header DB DB CDN CDN Static Static Storage Storage BI BI Logger Logger
  48. 48. BECOMING METHODICAL It is the corner stone for growth

×