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 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
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building Debt Free MVP - Deep Dive

  1. 1. SERGEY SUNDUKOVSKIY PH.D.Building Debt Free MVP1
  2. 2. Introduction2
  3. 3. Background3
  4. 4. AgendaMVP ConsiderationsDebt AvoidanceTechnical DebtOrganizational DebtProcess DebtInfrastructure Debt4
  5. 5. MVP Core FunctionalityIdeal MVP5
  6. 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. 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. 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. 9. Defining MVP9
  10. 10. Defining an MVPMVP vs. Prototype10
  11. 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. 12. MVP vs. PrototypeWho Builds It?12
  13. 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. 14. Roger’s Adoption CurveWho is MVP for?14
  15. 15. MVP TargetingPrototype Targets InnovatorsMVP Targets Early AdoptersEarly Adopter Groups Educators Influencers Opinion Makers Social Connectors15
  16. 16. MVP FeaturesLess Is Truly More16
  17. 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. 18. Irreducible ComplexitySimplest Mousetrap18
  19. 19. Path To IntentStraightforward Path To Intent19
  20. 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. 21. Survey BiasPeople Say One Thing and Do Another21
  22. 22. CrowdsourcingRise of the Crowds22
  23. 23. Mechanical TurkMicrotasking Crowdsourcing Platform23
  24. 24. Usability Study Setup (cont.)25
  25. 25. Usability Study Results26
  26. 26. Was not surewhat to do
  27. 27. Usability Study Results28
  28. 28. FeedbackIt Is All About Uncensored Feedback29
  29. 29. Feedback (cont.)30
  30. 30. Usability Testing Tools31
  31. 31. Technical DebtThings Slow Down32
  32. 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. 33. Debt (Leverageable)34
  34. 34. Debt StoryI Have not Seen Organs Like This35
  35. 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. 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. 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. 38. Broken Window TheoryOne Broken Window Leads to Ruin39
  39. 39. Broken Window TheoryDo Sweat the Small Stuff40
  40. 40. Debt Tipping Point41Product DeathYear 2Year 1Tipping Point
  41. 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. 42. Decision StackReverse Funnel43
  43. 43. Frameworks44
  44. 44. Language SelectionProgramming Language Is Irrelevant. It Only Matters inTerms of Resource and Starter Product Availability45
  45. 45. Organizational DebtYou Can’t Outsource What You Do Not Understand46
  46. 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. 47. Offshore DevelopmentDo it for Right Reasons48
  48. 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. 49. Right Reasons50Right Expectations Somewhat Easier to Find Talent 24 h Dev/QA Cycle Improved Ramp Up/Ramp Down Cycles Specific Expertise
  50. 50. 90% Done ProblemWhat Do They Mean by That?51
  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. 52. Buddy ProgramDo it Right53
  53. 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. 54. Congruent CulturePick a Congruent Culture55
  55. 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. 56. Team StructureBig Rocks First57
  57. 57. Separate Development Teams58Rapid Development vs. CoreVS.
  58. 58. Process DebtHow Do They Know?59
  59. 59. Process ComplicationDo Not Make It Complicated60
  60. 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. 61. Planned vs. Agile62VS
  62. 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. 63. Agile Umbrella64
  64. 64. Agile Process Phases65
  65. 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. 66. False AgileJust Because You Call It Agile It Does Not Mean It Is67
  67. 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. 68. Infrastructures DebtAvoiding Infrastructure Debt69
  69. 69. IaaS + PaaSUse As Much of the Stack as You Can70
  70. 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. 71. PaaS72
  72. 72. IaaS73