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/

1. LEAN AND MEAN
Recipes for Managing Successful Products

2. Disclaimer
This presentation is focused on creating high
growth b2c/SaaS software products

3. Wix.com - Real WYSIYG Web Editing
One Design Template. Endless User Designs.
3

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. 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. The Fundamentals
Team building
Product life cycle
Early stage
On going management
Tech choices
Becoming methodical

7. TEAM BUILDING
It’s not business, it’s personal

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. 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. 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. 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. 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. 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. 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. 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. 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. Problem Indicators
• Long emails
• Long specs
• Bullshit ideological conflicts
• People talk in us and them
• Meetings

18. PRODUCT LIFE CYCLE - EARLY STAGE
Be open to failure

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. 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. 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. 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. 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. 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. 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. 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. 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. PRODUCT LIFE CYCLE - ONGOING PRODUCT
Managing focus

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. 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. 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. Product road map
Facilitating discussion and alignment
• All the lists
• Inspirations
• Key assumptions
• Goals
• Resource allocation and shortages
• Critical action items

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. 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. 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. 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. 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. CHOOSING THE TECH
Keep It Simple Stupid

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. 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. 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. 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. 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. 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. 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. 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. Architecture Sample
User
User
Site
Site
Doc
Doc
Header
Header
DB
DB
CDN
CDN
Static
Static
Storage
Storage
BI
BI
Logger
Logger

48. BECOMING METHODICAL
It is the corner stone for growth