The percentage of software projects that are not finished on time, or not finished at all, is enormous compared to other fields of engineering. How can delivery-oriented product management change that? How can we create working methods and organizations that will lead us to the safe shores of production? How do we in Wix confront these challenges and how can we maintain ongoing product delivery cycles? This lecture is relevant to any entrepreneur, product manager, software engineer or anyone interested in delivering successful internet and software products.

1. DeliveryOriented Product Management
David Schwartz, June 2015

2. A Little About Me
 From TLV, Israel
 VP Product Management, Boost and e
commerce at Wix.com
 Founder- PeerApp, Jogli
2

3. A Little About Wix
3
Power to Create
Documents
Presentation
Blogs
Online Presence

4. A Little About Wix
 70 Million users
 1.4 Million new users each month
 ~50% subscription from free traffic sources
 190 countries with Wix Users
 0 sales People
 Nasdaq:WIX As of November 2013
 1000 employees in TLV, B7, NY, SF, Vilnius, and Dnipropetrovsk
4

5. A Little About Wix
 Our Business Model
5
Marketing Premium
Subscription
Apps
User
Recommendations
Free
Website

6. The Software Crisis Challenge

7. Imagine they never finished 90%
of the buildings
 About 90% (!!!) of software projects are
never finished
 Nearly 100% of software projects are
never finished in time…
7

8. The Software Crisis
 About 90% (!!!) of software projects are
never finished
 Nearly 100% of software projects are
never finished in time
 Think that would have been the case in
another engineering field…
8

9. Delivery Oriented Product
Management
The “no man” approach
Why do we need this project?
Is this project really needed
We have this, this this
We are simpler, cleaner
What extra features do you need?
What features would you take out?
The core- create MVP and put it out there!
Budget / HR / Time / Scope / Quality
Quality, Budget HR and Time should be fixed!!
9

10. Product Life Cycle
 Research
 Wireframes
 Design
 Pre development
 Development
 Launch
 Post Launch
 Next Phase
10

11. Research – are we doing this?
 No man- Do we really need this? A product
needs measurable justification
 Look at other products around
 Two approaches
 I am like…
 I am different from
 Talk to colleagues, users
 Don’t guess! Put a dummy button…
11

12. Wireframes
 What is it? Means of communication!
 Who do you talk to: Users, Other Product
Managers, Developers, UX, Management
 Your MVP screens
 In context
 In details and scale
 Represent all use cases
 New
 Full
 Something went wrong
12

13. 13

14. The right order
 Wireframes - Designs – Development
 1 hour of wire frame = 10 hours of design
= 100 hours of dev
 And yet, I’ve seen people do it otherwise
14

15. Wireframes – guidelines
 MVP- the no man approach
 Its better to have half the features, and a product
that kick ass, then double the features and half
ass product!
 More features- longer learning curve
 Its hard to create, its very hard to maintain
 Wireframes are not a dictatorship but rather
a way Product Managers, Developers,
Designers, Marketing and Management can
talk on product rather then blurb
15

16. Wireframes – guidelines
 sanity check
 If people don’t understand your wireframes they wont understand your product
 Get as many reviews as you can
 Must- Users, Colleagues
 You are the owner (yet- you can be sent to the drawing table)
 If you hear valuable feedback- fix it- and go back to get another review
 If your wireframes are done in scale you know if you have room for all the things you
think you must do (and in German!)
 What is:
 Crucial? Make sure it’s the most noticeable CTA
 Very important things? Clear, but don’t draw attention from crucial
 Just important- TAKE OUT OF MVP!
 Nice to have – Ahh?
 Do we really need all this? What can we take out?
16

17. before
17

18. after
18

19. Wireframes, make decisions
 Let the users choose (Android Approach)
 Lots of options- nice
 Overwhelming settings
 You are afraid to decide so you let the users decide
 Every user is different (well – 80/20 rule)
 Choose for the users (Iphone approach)
 Make decisions
 Simpler product, less overwhelming
 Less dev, faster launch, easier maintenance
 If life or death- add it second phase
19

20. Wireframes- alternatives
 Specs
 Pros
 Easier to create check lists (?)
 Make sure you cover it all (?)
 Cons
 No clear
 No sanity check
 Less info in more time
 Harder to change
 Designed screens
 Pros
 Saves work phase
 You see the product as you design it
 Cons
 Changes take more time
 Esthetic consideration influence functionality
 Partial Wire frames (not is scale, without context, etc.)
 Pros
 Take less time
 Cons
 In good case- you loose the sanity check
 In bad case- you will drag mistake to UX design, development and production
20

21. UX Design
 UX designers three main purposes:
 Wireframes review and changes
 Take things out
 Verify functionality and quality
 Astonishing design
 Final gate keeper – “the eye”
21

22. Pre - Development
 Define AB tests
 Define BI
 Define Monitoring
22

23. Development
 MVP! MVP! MVP!
 Developers are great product tippers –
make them help you drop features
 In QA- define show stoppers and things
you can live with
 Get UX designer gate keeping- “the eye”
23

24. Launch
 Party time!
 Use it yourself!!!!
24

25. Post Launch
 Use it again (and again, and again, and again)
 Check AB and BI
 Check support
 Look at users, ask them what they don’t use and what
distracts them
 Talk to Other Product Managers, Developers, UX,
Management
 Learn what you really need and don’t do auto 2nd
phase…
25

26. Questions?
 TX!!!
26