Building Debt Free MVP - Deep Dive
Download as PPT, PDF5 likes1,454 views
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.
Building Debt Free MVP - Deep Dive
- 1. SERGEY SUNDUKOVSKIY PH.D. Building Debt Free MVP 1
- 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
- 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
- 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
- 27. Was not sure what to do
- 29. Feedback It Is All About Uncensored Feedback 29
- 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
- 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
- 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
- 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
- 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