The document discusses the importance of building a debt-free Minimum Viable Product (MVP), which focuses on maximizing validated learning with minimal resources. It distinguishes between MVP and prototype, emphasizing the significance of understanding target audiences and avoiding various forms of debt—technical, organizational, and process-related—while maintaining efficient design and development practices. Additionally, it outlines the roles and expectations for teams involved in the MVP process and cautions against misconceptions about outsourcing and the dangers of complexity in development.

1. SERGEY SUNDUKOVSKIY PH.D.
Building Debt Free MVP
1

2. Introduction
2

3. Background
3

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

5. MVP Core Functionality
Ideal MVP
5

6. 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
6

7. Viable For What?
7
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

8. 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
8

9. Defining MVP
9

10. Defining an MVP
MVP vs. Prototype
10

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
11

12. MVP vs. Prototype
Who Builds It?
12

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
13

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

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

16. MVP Features
Less Is Truly More
16

17. 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
17

18. Irreducible Complexity
Simplest Mousetrap
18

19. Path To Intent
Straightforward Path To Intent
19

20. 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
20

21. Survey Bias
People Say One Thing and Do Another
21

22. Crowdsourcing
Rise of the Crowds
22

23. Mechanical Turk
Microtasking Crowdsourcing Platform
23

25. Usability Study Setup (cont.)
25

26. Usability Study Results
26

27. Was not sure
what to do

28. Usability Study Results
28

29. Feedback
It Is All About Uncensored Feedback
29

30. Feedback (cont.)
30

31. Usability Testing Tools
31

32. Technical Debt
Things Slow Down
32

33. 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
33

34. Debt (Leverageable)
34

35. Debt Story
I Have not Seen Organs Like This
35

36. 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
36

37. 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
37

38. Support to Innovation Ratio
You Are in the Support Business
38
Support
(15%)
Innovation
(85%)
Support
(50%)
Innovation
(50%)
Support
(85%)
Innovation
(15%)
Year 1
Year 2
Year 3

39. Broken Window Theory
One Broken Window Leads to Ruin
39

40. Broken Window Theory
Do Sweat the Small Stuff
40

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

42. 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
42

43. Decision Stack
Reverse Funnel
43

44. Frameworks
44

45. Language Selection
Programming Language Is Irrelevant. It Only Matters in
Terms of Resource and Starter Product Availability
45

46. Organizational Debt
You Can’t Outsource What You Do Not Understand
46

47. MVT
47
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?

48. Offshore Development
Do it for Right Reasons
48

49. All The Wrong Reasons
49
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)

50. Right Reasons
50
Right Expectations
 Somewhat Easier to Find Talent
 24 h Dev/QA Cycle
 Improved Ramp Up/Ramp Down Cycles
 Specific Expertise

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

52. 90% Done Problem
52
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

53. Buddy Program
Do it Right
53

54. Buddy Paring
54
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)

55. Congruent Culture
Pick a Congruent Culture
55

56. Offshore Team Picking
56
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)

57. Team Structure
Big Rocks First
57

58. Separate Development Teams
58
Rapid Development vs. Core
VS.

59. Process Debt
How Do They Know?
59

60. Process Complication
Do Not Make It Complicated
60

61. Process Complication
 Do Not Make It Complicated
 Complicated = Bad
 Complicated = Unsustainable
 Complicated = Not Followed
 Complicated = Edge Case Centric
 Complicated ! = Useful
 Complicated = Unintended Consequences
61

62. Planned vs. Agile
62
VS

63. Planned vs. Agile
 Planned Process
 Exhaustive Planning (plan until you are exhausted)
 Prescriptive
 Document Centric
Agile Process
 Iterative Planning
 Non-prescriptive
 Practice Centric
63

64. Agile Umbrella
64

65. Agile Process Phases
65

66. 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
66

67. False Agile
Just Because You Call It Agile It Does Not Mean It Is
67

68. 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
68

69. Infrastructures Debt
Avoiding Infrastructure Debt
69

70. IaaS + PaaS
Use As Much of the Stack as You Can
70

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

72. PaaS
72

73. IaaS
73