Your SlideShare is downloading. ×

Building Debt Free MVP - Deep Dive


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 …

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.

Published in: Technology, Economy & Finance
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. SERGEY SUNDUKOVSKIY PH.D.Building Debt Free MVP1
  • 2. Introduction2
  • 3. Background3
  • 4. AgendaMVP ConsiderationsDebt AvoidanceTechnical DebtOrganizational DebtProcess DebtInfrastructure Debt4
  • 5. MVP Core FunctionalityIdeal MVP5
  • 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 Pretty6
  • 7. Viable For What?7Eric Ries defines MVP as “…that version of a new productwhich allows a team to collect the maximum amount ofvalidated learning about customers with the least effort.”MinimalProduct nobodywants to useViableProduct builtby companiesthat have nofinancial limitationsMVP
  • 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 Half8
  • 9. Defining MVP9
  • 10. Defining an MVPMVP vs. Prototype10
  • 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 Money11
  • 12. MVP vs. PrototypeWho 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 Development13
  • 14. Roger’s Adoption CurveWho is MVP for?14
  • 15. MVP TargetingPrototype Targets InnovatorsMVP Targets Early AdoptersEarly Adopter Groups Educators Influencers Opinion Makers Social Connectors15
  • 16. MVP FeaturesLess Is Truly More16
  • 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 Wins17
  • 18. Irreducible ComplexitySimplest Mousetrap18
  • 19. Path To IntentStraightforward Path To Intent19
  • 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 Everything20
  • 21. Survey BiasPeople Say One Thing and Do Another21
  • 22. CrowdsourcingRise of the Crowds22
  • 23. Mechanical TurkMicrotasking Crowdsourcing Platform23
  • 24. Usability Study Setup (cont.)25
  • 25. Usability Study Results26
  • 26. Was not surewhat to do
  • 27. Usability Study Results28
  • 28. FeedbackIt Is All About Uncensored Feedback29
  • 29. Feedback (cont.)30
  • 30. Usability Testing Tools31
  • 31. Technical DebtThings Slow Down32
  • 32. 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 Faster33
  • 33. Debt (Leverageable)34
  • 34. Debt StoryI Have not Seen Organs Like This35
  • 35. 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 ME36
  • 36. 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 These37
  • 37. Support to Innovation RatioYou Are in the Support Business38Support(15%)Innovation(85%)Support(50%)Innovation(50%)Support(85%)Innovation(15%)Year 1Year 2Year 3
  • 38. Broken Window TheoryOne Broken Window Leads to Ruin39
  • 39. Broken Window TheoryDo Sweat the Small Stuff40
  • 40. Debt Tipping Point41Product DeathYear 2Year 1Tipping Point
  • 41. 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 Recipes42
  • 42. Decision StackReverse Funnel43
  • 43. Frameworks44
  • 44. Language SelectionProgramming Language Is Irrelevant. It Only Matters inTerms of Resource and Starter Product Availability45
  • 45. Organizational DebtYou Can’t Outsource What You Do Not Understand46
  • 46. MVT47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?
  • 47. Offshore DevelopmentDo it for Right Reasons48
  • 48. All The Wrong Reasons49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)
  • 49. Right Reasons50Right Expectations Somewhat Easier to Find Talent 24 h Dev/QA Cycle Improved Ramp Up/Ramp Down Cycles Specific Expertise
  • 50. 90% Done ProblemWhat Do They Mean by That?51
  • 51. 90% Done Problem52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
  • 52. Buddy ProgramDo it Right53
  • 53. Buddy Paring54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)
  • 54. Congruent CulturePick a Congruent Culture55
  • 55. Offshore Team Picking56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)
  • 56. Team StructureBig Rocks First57
  • 57. Separate Development Teams58Rapid Development vs. CoreVS.
  • 58. Process DebtHow Do They Know?59
  • 59. Process ComplicationDo Not Make It Complicated60
  • 60. Process Complication Do Not Make It Complicated Complicated = Bad Complicated = Unsustainable Complicated = Not Followed Complicated = Edge Case Centric Complicated ! = Useful Complicated = Unintended Consequences61
  • 61. Planned vs. Agile62VS
  • 62. Planned vs. Agile Planned Process Exhaustive Planning (plan until you are exhausted) Prescriptive Document CentricAgile Process Iterative Planning Non-prescriptive Practice Centric63
  • 63. Agile Umbrella64
  • 64. Agile Process Phases65
  • 65. 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 Busters66
  • 66. False AgileJust Because You Call It Agile It Does Not Mean It Is67
  • 67. 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 theProjectYou Have No Business RepresentationYou Are Not Tracking RequirementsYou Do Not Keep Track of Velocity/Drumbeat68
  • 68. Infrastructures DebtAvoiding Infrastructure Debt69
  • 69. IaaS + PaaSUse As Much of the Stack as You Can70
  • 70. 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 Control71
  • 71. PaaS72
  • 72. IaaS73