SERGEY SUNDUKOVSKIY PH.D.
From Prototype To MVP
1
Introduction
2
Background
3
Agenda
MVP Considerations
Debt Avoidance
Technical Debt
Organizational Debt
Process Debt
Infrastructure Debt
4
Product Lifecycle
5
MVP Core Functionality
Ideal MVP
6
Ideal MVP
Mini-Me is an Ideal MVP
Core Functionality
 Identical “DNA”
 Same Major Features
 Same Major Functionality
...
Viable For What?
8
Eric Ries defines MVP as “…that version of a new product
which allows a team to collect the maximum amo...
Difficult Determinations
Prototype vs. MVP
 How Do I Distinguish?
MVP vs. Product
 At What Point Do I Stop?
Intent Ma...
Defining MVP
10
Defining an MVP
MVP vs. Prototype
11
MVP vs. Prototype
 MVP
 Test Product Viability
 Test Assumptions
 Test the Market
 Test Product Usability
 Get User ...
MVP vs. Prototype
Who Builds It?
13
MVP vs. Prototype
 MVP
 Built by a Minimal Viable Team
 Evolutionary in Its Development
Prototype
 Built by One Guy
...
Beta vs. MVP
15
Roger’s Adoption Curve
Who is MVP for?
16
MVP Targeting
Prototype Targets Innovators
MVP Targets Early Adopters
Early Adopter Groups
 Educators
 Influencers
 ...
MVP Features
Less is truly more
18
MVP Features
Intelligent Design and Evolutionary Concepts
 Aim For Adjacent Possible
Irreducible Complexity
 Can’t Tak...
Irreducible Complexity
Simplest mousetrap
20
Path To Intent
Straightforward path to intent
21
Product Don’ts
Do Not Complicate Things
Do Not Make Users Think
Do Not Make Users Work
Do Not Defy User’s Expectations...
Product Spec
Target Customer
Wireframes
Mockups
Flow Diagrams
User Stories
Business rules
23
Example Company
24
Target Customer
Target Customer – GuidedFlow is a B-B-C solution
targeted to an early stage SaaS Platform Startups
 Size...
Prototype Wireframes
26
Prototype Wireframes (cont.)
27
Prototype Wireframes (cont.)
28
Prototype Wireframes (cont.)
29
Prototype Mockup
30
Mind Map
31
“Nirvana” Features
 Admin
 Installation
 Analytics
 Account Management
 Help Management
 Walk Through Management
 T...
“Nirvana” Drilldown
 Account Management – Allows user to manage accounts
and account related activities in the system
 M...
Core Functionality = MVP
 Account Management – Allows user to manage accounts
and account related activities in the syste...
GA
 Account Management – Allows user to manage accounts
and account related activities in the system
 Manage User Accoun...
Beta
 Account Management – Allows user to manage accounts
and account related activities in the system
 Manage Account S...
User Story
User Story – As “Who” I want “What” and “Why”
 As a “end-user” I want to be able to “click on help button” so...
Business Rule
Business Rule – Non Trivial Rules
 Subscription plan upgrades are effective immediately
 Subscription pla...
Technical Debt
Things slow down
39
Debt
Everything you want to do “Later” is DEBT
 Let’s Document Later
 Let’s Test Later
 Let’s Architect Later
 Let’s ...
Debt (Leverageable)
41
Debt Story
I have not seen organs like this
42
Common Story
CEOs Tale
 We Were Very Productive
 We Kicked Ass
 We Became Complacent
 I Fired Them All
 I Hired a Ne...
Common Story
CTOs Tale
 We Were Very Productive Through Debt Accumulation
 We Kicked Ass But Burned Out
 We Slowed Dow...
Support to Innovation Ratio
You are in the support business
45
Support
(15%)
Innovation
(85%)
Support
(50%)
Innovation
(50...
Broken Window Theory
One broken window leads to ruin
46
Broken Window Theory
Do sweat the small stuff
47
Debt Tipping Point
48
Product Death
Year 2
Year 1
Tipping Point
Technical Debt Elements
Technical Debt Elements
 Lack of Architectural Blueprint
 Lack of Unit Testing
 Lack of Integr...
Decision Stack
Reverse funnel
50
Frameworks
51
Language Selection
Programming language is irrelevant. It only matters in terms
of resource and starter product availabili...
Organizational Debt
You can’t outsource what you do not understand
53
MVT
54
Minimal Viable Team
 Designer/UX/UI (part-time)
 Mobile/HTML5/Javascript
 SysAdmin/DBA/DevOPS
 Lead Developer
...
Offshore Development
Do it for Right Reasons
55
All The Wrong Reasons
56
Wrong Expectations
 Solution to Ignorance (outsourcing what you do not understand)
 It Will Be...
Right Reasons
57
Right Expectations
 Somewhat Easier to Find Talent
 24 h Dev/QA Cycle
 Improved Ramp Up/Ramp Down Cyc...
90% Done Problem
What Do They Mean by That?
58
90% Done Problem
59
90 Done
 Offshore Team Did All the Work
 90% of the Money is Spent
 No Business Documentation
 No...
Buddy Program
Do it Right
60
Buddy Paring
61
Not Your Grandfather’s Pair Programming
 Get paired (your counterpart)
 Truman Show (my life on tv)
 4...
Congruent Culture
Pick a Congruent Culture
62
Offshore Team Picking
63
Congruent Culture (challenge authority)
Working Hours Overlap (4+)
Right Size (30+ large enoug...
Team Structure
Big Rocks First
64
Separate Development Teams
65
Rapid development vs. core
VS.
Process Debt
How Do They Know?
66
Process Complication
Do Not Make It Complicated
67
Process Complication
 Do Not Make It Complicated
 Complicated = Bad
 Complicated = Unsustainable
 Complicated = Not Fo...
Planned vs. Agile
69
VS
Planned vs. Agile
 Planned Process
 Exhaustive Planning (plan until you are exhausted)
 Prescriptive
 Document Centric...
Agile Umbrella
71
Agile Process Phases
72
Process Debt Elements
Process Debt Elements
 Lack of Articulated Process
 Lack of Process Documentation
 Lack of Repea...
False Agile
Just because you call it agile it does not mean it is
74
You Are Not Agile If
Requirement Frontloading
QA Backloading
You Move Dates Instead of Feature Negotiating
You Extend ...
Infrastructures Debt
Avoiding infrastructure debt
76
IaaS + PaaS
Use as much of the stack as you can
77
Infrastructure Debt Elements
 Infrastructure Debt Elements
 No Utilizing IaaS/Pass
 Lack of Monitoring
 Lack of Redund...
PaaS
79
IaaS
80
Upcoming SlideShare
Loading in...5
×

From Prototype to MVP (case study)

1,239

Published on

Are you ready to build an MVP? Where do you start? How do you know what features to build? How do you know how many people you need to build it? How do you know that they are building a right thing in a right way? This presentation and conversation will explore strategies for assembling effective teams for building and deploying an MVP while incurring minimal Product and Technical Debt. We will also discuss implementing an effective process to make sure that your MVP will be built on time and on target.

From Prototype to MVP (case study)

  1. 1. SERGEY SUNDUKOVSKIY PH.D. From Prototype To MVP 1
  2. 2. Introduction 2
  3. 3. Background 3
  4. 4. Agenda MVP Considerations Debt Avoidance Technical Debt Organizational Debt Process Debt Infrastructure Debt 4
  5. 5. Product Lifecycle 5
  6. 6. MVP Core Functionality Ideal MVP 6
  7. 7. Ideal MVP Mini-Me is an Ideal MVP Core Functionality  Identical “DNA”  Same Major Features  Same Major Functionality  Same Usability  Not Up To Scale  Not As Pretty 7
  8. 8. Viable For What? 8 Eric Ries defines MVP as “…that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” Minimal Product nobody wants to use Viable Product built by companies that have no financial limitations MVP
  9. 9. Difficult Determinations Prototype vs. MVP  How Do I Distinguish? MVP vs. Product  At What Point Do I Stop? Intent Matters  You Will Get What You Are Aiming For Do Not Make A Mermaid  You Will Always Get a Wrong Half 9
  10. 10. Defining MVP 10
  11. 11. Defining an MVP MVP vs. Prototype 11
  12. 12. MVP vs. Prototype  MVP  Test Product Viability  Test Assumptions  Test the Market  Test Product Usability  Get User Feedback Prototype  Demonstrate the Concept  Convince Others That You Are Serious  Get Seed Money 12
  13. 13. MVP vs. Prototype Who Builds It? 13
  14. 14. MVP vs. Prototype  MVP  Built by a Minimal Viable Team  Evolutionary in Its Development Prototype  Built by One Guy  Usually Throwaway in Its Development 14
  15. 15. Beta vs. MVP 15
  16. 16. Roger’s Adoption Curve Who is MVP for? 16
  17. 17. MVP Targeting Prototype Targets Innovators MVP Targets Early Adopters Early Adopter Groups  Educators  Influencers  Opinion Makers  Social Connectors 17
  18. 18. MVP Features Less is truly more 18
  19. 19. MVP Features Intelligent Design and Evolutionary Concepts  Aim For Adjacent Possible Irreducible Complexity  Can’t Take Anything Away  Can’t Be Simpler Most Efficient For What It Does  Most Efficient Wins 19
  20. 20. Irreducible Complexity Simplest mousetrap 20
  21. 21. Path To Intent Straightforward path to intent 21
  22. 22. Product Don’ts Do Not Complicate Things Do Not Make Users Think Do Not Make Users Work Do Not Defy User’s Expectations Do Not Confuse Yourself With Users Do Not Assume You Know Everything 22
  23. 23. Product Spec Target Customer Wireframes Mockups Flow Diagrams User Stories Business rules 23
  24. 24. Example Company 24
  25. 25. Target Customer Target Customer – GuidedFlow is a B-B-C solution targeted to an early stage SaaS Platform Startups  Size – 1-10 Employees  Revenue – None - 500K  Solution Type – SaaS Platforms  Industry – Marketing 25
  26. 26. Prototype Wireframes 26
  27. 27. Prototype Wireframes (cont.) 27
  28. 28. Prototype Wireframes (cont.) 28
  29. 29. Prototype Wireframes (cont.) 29
  30. 30. Prototype Mockup 30
  31. 31. Mind Map 31
  32. 32. “Nirvana” Features  Admin  Installation  Analytics  Account Management  Help Management  Walk Through Management  Tutorial Management  Video Management  App Management 32
  33. 33. “Nirvana” Drilldown  Account Management – Allows user to manage accounts and account related activities in the system  Manage User Accounts (create, update, delete)  Manage Master Account (update)  Manage User Permissions (author, update, publish)  Manage Account Subscription (upgrade, downgrade, cancel)  Manage Payments (credit card info) 33
  34. 34. Core Functionality = MVP  Account Management – Allows user to manage accounts and account related activities in the system  Reset Password – Allows account users to reset credentials 34
  35. 35. GA  Account Management – Allows user to manage accounts and account related activities in the system  Manage User Accounts (create, update, delete)  Manage Master Account (update)  Manage User Permissions (author, update, publish) 35
  36. 36. Beta  Account Management – Allows user to manage accounts and account related activities in the system  Manage Account Subscription (upgrade, downgrade, cancel)  Manage Payments (credit card info) 36
  37. 37. User Story User Story – As “Who” I want “What” and “Why”  As a “end-user” I want to be able to “click on help button” so I can “get help messages”  As a “end-user” I want to be able to “click on tour button” so I can “get a guided tour”  As an “admin” I want to be able to “define” help messages for help screens  As an “admin” I want to be able to “create” credit card information so I “can manage Payments”  As a “system user” I want to be able to “reset password” so I can log into the system 37
  38. 38. Business Rule Business Rule – Non Trivial Rules  Subscription plan upgrades are effective immediately  Subscription plan downgrades are effective as of new billing cycle  In case of credit card rejection system will repeat billing attempts three times two days apart. Upon third rejection customer will be downgraded to a “Free” Subscription Plan 38
  39. 39. Technical Debt Things slow down 39
  40. 40. Debt Everything you want to do “Later” is DEBT  Let’s Document Later  Let’s Test Later  Let’s Architect Later  Let’s Refactor Later Debt Misconceptions  All Debt is Bad  No Debt is Great  Taking on Debt Always Gets You There Faster 40
  41. 41. Debt (Leverageable) 41
  42. 42. Debt Story I have not seen organs like this 42
  43. 43. Common Story CEOs Tale  We Were Very Productive  We Kicked Ass  We Became Complacent  I Fired Them All  I Hired a New Team  They Are Not Productive Either  Must Have Chosen Wrong  I Fired Them All  SAVE ME 43
  44. 44. Common Story CTOs Tale  We Were Very Productive Through Debt Accumulation  We Kicked Ass But Burned Out  We Slowed Down Due to Debt  We Got Fired  New Team Got Hired  It Does Not Know Where Skeletons Are Buried  We Got Fired As Well  I have Not Seem Organs Like These 44
  45. 45. Support to Innovation Ratio You are in the support business 45 Support (15%) Innovation (85%) Support (50%) Innovation (50%) Support (85%) Innovation (15%) Year 1 Year 2 Year 3
  46. 46. Broken Window Theory One broken window leads to ruin 46
  47. 47. Broken Window Theory Do sweat the small stuff 47
  48. 48. Debt Tipping Point 48 Product Death Year 2 Year 1 Tipping Point
  49. 49. Technical Debt Elements Technical Debt Elements  Lack of Architectural Blueprint  Lack of Unit Testing  Lack of Integration Testing  Lack of Code Reviews  Lack of Starting Platform  Lack of Starting Framework  Lack of Technical Design  Lack of Development Recipes 49
  50. 50. Decision Stack Reverse funnel 50
  51. 51. Frameworks 51
  52. 52. Language Selection Programming language is irrelevant. It only matters in terms of resource and starter product availability 52
  53. 53. Organizational Debt You can’t outsource what you do not understand 53
  54. 54. MVT 54 Minimal Viable Team  Designer/UX/UI (part-time)  Mobile/HTML5/Javascript  SysAdmin/DBA/DevOPS  Lead Developer  2 Engineers MVT = 5.5 people Can We Afford It? Who is My Product Guy?
  55. 55. Offshore Development Do it for Right Reasons 55
  56. 56. All The Wrong Reasons 56 Wrong Expectations  Solution to Ignorance (outsourcing what you do not understand)  It Will Be Cheaper (min 30% overhead)  We Can Achieve Instant Scalability (it takes time to hire)  Poaching Is not a Problem (no difference)  We Can Minimize Office Distractions (hallway magic)
  57. 57. Right Reasons 57 Right Expectations  Somewhat Easier to Find Talent  24 h Dev/QA Cycle  Improved Ramp Up/Ramp Down Cycles  Specific Expertise
  58. 58. 90% Done Problem What Do They Mean by That? 58
  59. 59. 90% Done Problem 59 90 Done  Offshore Team Did All the Work  90% of the Money is Spent  No Business Documentation  No Technical Documentation  No Repeatable Process  No Unit Tests  Lead Developer Instead of CTO  Performance Problems Right out of the Gate
  60. 60. Buddy Program Do it Right 60
  61. 61. Buddy Paring 61 Not Your Grandfather’s Pair Programming  Get paired (your counterpart)  Truman Show (my life on tv)  4 + 4 (overlap time + alone time)  Joined work assignment (we are a unit)  Circle of influence (product manager, project manager, qa, development buddy)
  62. 62. Congruent Culture Pick a Congruent Culture 62
  63. 63. Offshore Team Picking 63 Congruent Culture (challenge authority) Working Hours Overlap (4+) Right Size (30+ large enough to have a bench) Right Size (100- small enough to care) Right Focus (we do everything) Do Not Let It Grow (micro-teams)
  64. 64. Team Structure Big Rocks First 64
  65. 65. Separate Development Teams 65 Rapid development vs. core VS.
  66. 66. Process Debt How Do They Know? 66
  67. 67. Process Complication Do Not Make It Complicated 67
  68. 68. Process Complication  Do Not Make It Complicated  Complicated = Bad  Complicated = Unsustainable  Complicated = Not Followed  Complicated = Edge Case Centric  Complicated ! = Useful  Complicated = Unintended Consequences 68
  69. 69. Planned vs. Agile 69 VS
  70. 70. Planned vs. Agile  Planned Process  Exhaustive Planning (plan until you are exhausted)  Prescriptive  Document Centric Agile Process  Iterative Planning  Non-prescriptive  Practice Centric 70
  71. 71. Agile Umbrella 71
  72. 72. Agile Process Phases 72
  73. 73. Process Debt Elements Process Debt Elements  Lack of Articulated Process  Lack of Process Documentation  Lack of Repeatability  Lack of Clear Process Identification  Presence of Numerous Process Exceptions  Process Busters 73
  74. 74. False Agile Just because you call it agile it does not mean it is 74
  75. 75. You Are Not Agile If Requirement Frontloading QA Backloading You Move Dates Instead of Feature Negotiating You Extend Sprints/Iterations You Are Not Producing Code by Third Week of the Project You Have No Business Representation You Are Not Tracking Requirements You Do Not Keep Track of Velocity/Drumbeat 75
  76. 76. Infrastructures Debt Avoiding infrastructure debt 76
  77. 77. IaaS + PaaS Use as much of the stack as you can 77
  78. 78. Infrastructure Debt Elements  Infrastructure Debt Elements  No Utilizing IaaS/Pass  Lack of Monitoring  Lack of Redundancy  Lack of Disaster Recovery  Lack of Environment Separation Dev Ops Debt Elements  Lack of Deployment Framework  Lack of Continuous Integration  Lack of Effective Source Control 78
  79. 79. PaaS 79
  80. 80. IaaS 80
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×