Download - From Prototype to MVP (case study)
SERGEY SUNDUKOVSKIY PH.D.
From Prototype To MVP1
Introduction2
Background3
Agenda
MVP ConsiderationsDebt AvoidanceTechnical DebtOrganizational DebtProcess DebtInfrastructure Debt
4
Product Lifecycle5
MVP Core Functionality
Ideal MVP
6
Ideal MVP
Mini-Me is an Ideal MVPCore Functionality
Identical “DNA” Same Major Features Same Major Functionality Same Usability Not Up To Scale Not As Pretty
7
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.”
MinimalProduct nobody
wants to use
ViableProduct built
by companiesthat have no
financial limitations
MVP
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
Defining MVP10
Defining an MVP
MVP vs. Prototype
11
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
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 Usually Throwaway in Its Development
14
Beta vs. MVP15
Roger’s Adoption Curve
Who is MVP for?
16
MVP Targeting
Prototype Targets InnovatorsMVP Targets Early AdoptersEarly Adopter Groups
Educators Influencers Opinion Makers Social Connectors
17
MVP Features
Less is truly more
18
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
Irreducible Complexity
Simplest mousetrap
20
Path To Intent
Straightforward path to intent
21
Product Don’ts
Do Not Complicate ThingsDo Not Make Users ThinkDo Not Make Users WorkDo Not Defy User’s ExpectationsDo Not Confuse Yourself With UsersDo Not Assume You Know Everything
22
Product Spec
Target CustomerWireframesMockupsFlow DiagramsUser StoriesBusiness rules
23
Example Company24
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
Prototype Wireframes26
Prototype Wireframes (cont.)27
Prototype Wireframes (cont.)28
Prototype Wireframes (cont.)29
Prototype Mockup30
Mind Map31
“Nirvana” Features
Admin Installation Analytics Account Management Help Management Walk Through Management Tutorial Management Video Management App Management
32
“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
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
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
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
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
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
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 Refactor Later
Debt Misconceptions All Debt is Bad No Debt is Great Taking on Debt Always Gets You There Faster
40
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 New Team They Are Not Productive Either Must Have Chosen Wrong I Fired Them All SAVE ME
43
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
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
Broken Window Theory
One broken window leads to ruin
46
Broken Window Theory
Do sweat the small stuff
47
Debt Tipping Point48
Product Death
Year 2
Year 1
Tipping Point
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
Decision Stack
Reverse funnel
50
Frameworks51
Language Selection
Programming language is irrelevant. It only matters in terms of resource and starter product availability
52
Organizational Debt
You can’t outsource what you do not understand
53
MVT54
Minimal Viable Team Designer/UX/UI (part-time) Mobile/HTML5/Javascript SysAdmin/DBA/DevOPS Lead Developer 2 Engineers
MVT = 5.5 peopleCan We Afford It?Who is My Product Guy?
Offshore Development
Do it for Right Reasons
55
All The Wrong Reasons56
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)
Right Reasons57
Right Expectations Somewhat Easier to Find Talent 24 h Dev/QA Cycle Improved Ramp Up/Ramp Down Cycles Specific Expertise
90% Done Problem
What Do They Mean by That?
58
90% Done Problem59
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
Buddy Program
Do it Right
60
Buddy Paring61
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)
Congruent Culture
Pick a Congruent Culture
62
Offshore Team Picking63
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)
Team Structure
Big Rocks First
64
Separate Development Teams65
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 Followed Complicated = Edge Case Centric Complicated ! = Useful Complicated = Unintended Consequences
68
Planned vs. Agile69
VS
Planned vs. Agile
Planned Process Exhaustive Planning (plan until you are exhausted) Prescriptive Document Centric
Agile Process Iterative Planning Non-prescriptive Practice Centric
70
Agile Umbrella71
Agile Process Phases72
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
False Agile
Just because you call it agile it does not mean it is
74
You Are Not Agile If
Requirement FrontloadingQA BackloadingYou Move Dates Instead of Feature NegotiatingYou Extend Sprints/IterationsYou Are Not Producing Code by Third Week of the ProjectYou Have No Business RepresentationYou Are Not Tracking RequirementsYou Do Not Keep Track of Velocity/Drumbeat
75
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 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
PaaS 79
IaaS 80