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