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.

1. SERGEY SUNDUKOVSKIY PH.D.
From Prototype To MVP
1

2. Introduction
2

3. Background
3

4. Agenda
MVP Considerations
Debt Avoidance
Technical Debt
Organizational Debt
Process Debt
Infrastructure Debt
4

5. Product Lifecycle
5

6. MVP Core Functionality
Ideal MVP
6

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. 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. 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. Defining MVP
10

11. Defining an MVP
MVP vs. Prototype
11

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. MVP vs. Prototype
Who Builds It?
13

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. Beta vs. MVP
15

16. Roger’s Adoption Curve
Who is MVP for?
16

17. MVP Targeting
Prototype Targets Innovators
MVP Targets Early Adopters
Early Adopter Groups
 Educators
 Influencers
 Opinion Makers
 Social Connectors
17

18. MVP Features
Less is truly more
18

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. Irreducible Complexity
Simplest mousetrap
20

21. Path To Intent
Straightforward path to intent
21

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. Product Spec
Target Customer
Wireframes
Mockups
Flow Diagrams
User Stories
Business rules
23

24. Example Company
24

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. Prototype Wireframes
26

27. Prototype Wireframes (cont.)
27

28. Prototype Wireframes (cont.)
28

29. Prototype Wireframes (cont.)
29

30. Prototype Mockup
30

31. Mind Map
31

32. “Nirvana” Features
 Admin
 Installation
 Analytics
 Account Management
 Help Management
 Walk Through Management
 Tutorial Management
 Video Management
 App Management
32

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. 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. 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. 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. 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. 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. Technical Debt
Things slow down
39

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. Debt (Leverageable)
41

42. Debt Story
I have not seen organs like this
42

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. 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. 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. Broken Window Theory
One broken window leads to ruin
46

47. Broken Window Theory
Do sweat the small stuff
47

48. Debt Tipping Point
48
Product Death
Year 2
Year 1
Tipping Point

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. Decision Stack
Reverse funnel
50

51. Frameworks
51

52. Language Selection
Programming language is irrelevant. It only matters in terms
of resource and starter product availability
52

53. Organizational Debt
You can’t outsource what you do not understand
53

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. Offshore Development
Do it for Right Reasons
55

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. Right Reasons
57
Right Expectations
 Somewhat Easier to Find Talent
 24 h Dev/QA Cycle
 Improved Ramp Up/Ramp Down Cycles
 Specific Expertise

58. 90% Done Problem
What Do They Mean by That?
58

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. Buddy Program
Do it Right
60

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. Congruent Culture
Pick a Congruent Culture
62

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. Team Structure
Big Rocks First
64

65. Separate Development Teams
65
Rapid development vs. core
VS.

66. Process Debt
How Do They Know?
66

67. Process Complication
Do Not Make It Complicated
67

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. Planned vs. Agile
69
VS

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. Agile Umbrella
71

72. Agile Process Phases
72

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. False Agile
Just because you call it agile it does not mean it is
74

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. Infrastructures Debt
Avoiding infrastructure debt
76

77. IaaS + PaaS
Use as much of the stack as you can
77

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. PaaS
79

80. IaaS
80