From Prototype to MVP (case study)
Upcoming SlideShare
Loading in...5
×
 

From Prototype to MVP (case study)

on

  • 339 views

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.

Statistics

Views

Total Views
339
Views on SlideShare
336
Embed Views
3

Actions

Likes
3
Downloads
14
Comments
0

1 Embed 3

http://www.slideee.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

From Prototype to MVP (case study) From Prototype to MVP (case study) Presentation Transcript

  • SERGEY SUNDUKOVSKIY PH.D. From Prototype To MVP 1
  • Introduction 2
  • Background 3
  • Agenda MVP Considerations Debt Avoidance Technical Debt Organizational Debt Process Debt Infrastructure Debt 4
  • Product Lifecycle 5
  • MVP Core Functionality Ideal MVP 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 7
  • 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
  • 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
  • Defining MVP 10
  • Defining an MVP MVP vs. Prototype 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 12
  • MVP vs. Prototype Who Builds It? 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 14
  • Beta vs. MVP 15
  • Roger’s Adoption Curve Who is MVP for? 16
  • MVP Targeting Prototype Targets Innovators MVP Targets Early Adopters Early Adopter Groups  Educators  Influencers  Opinion Makers  Social Connectors 17
  • MVP Features Less is truly more 18
  • 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
  • Irreducible Complexity Simplest mousetrap 20
  • Path To Intent Straightforward path to intent 21
  • 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
  • Product Spec Target Customer Wireframes Mockups Flow Diagrams User Stories Business rules 23
  • Example Company 24
  • 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
  • Prototype Wireframes 26
  • Prototype Wireframes (cont.) 27
  • Prototype Wireframes (cont.) 28
  • Prototype Wireframes (cont.) 29
  • Prototype Mockup 30
  • Mind Map 31
  • “Nirvana” Features  Admin  Installation  Analytics  Account Management  Help Management  Walk Through Management  Tutorial Management  Video Management  App Management 32
  • “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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Technical Debt Things slow down 39
  • 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
  • Debt (Leverageable) 41
  • Debt Story I have not seen organs like this 42
  • 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
  • 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
  • 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
  • Broken Window Theory One broken window leads to ruin 46
  • Broken Window Theory Do sweat the small stuff 47
  • Debt Tipping Point 48 Product Death Year 2 Year 1 Tipping Point
  • 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
  • Decision Stack Reverse funnel 50
  • Frameworks 51
  • Language Selection Programming language is irrelevant. It only matters in terms of resource and starter product availability 52
  • Organizational Debt You can’t outsource what you do not understand 53
  • 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?
  • Offshore Development Do it for Right Reasons 55
  • 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)
  • Right Reasons 57 Right Expectations  Somewhat Easier to Find Talent  24 h Dev/QA Cycle  Improved Ramp Up/Ramp Down Cycles  Specific Expertise
  • 90% Done Problem What Do They Mean by That? 58
  • 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
  • Buddy Program Do it Right 60
  • 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)
  • Congruent Culture Pick a Congruent Culture 62
  • 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)
  • Team Structure Big Rocks First 64
  • Separate Development Teams 65 Rapid development vs. core VS.
  • Process Debt How Do They Know? 66
  • Process Complication Do Not Make It Complicated 67
  • Process Complication  Do Not Make It Complicated  Complicated = Bad  Complicated = Unsustainable  Complicated = Not Followed  Complicated = Edge Case Centric  Complicated ! = Useful  Complicated = Unintended Consequences 68
  • Planned vs. Agile 69 VS
  • Planned vs. Agile  Planned Process  Exhaustive Planning (plan until you are exhausted)  Prescriptive  Document Centric Agile Process  Iterative Planning  Non-prescriptive  Practice Centric 70
  • Agile Umbrella 71
  • Agile Process Phases 72
  • 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
  • False Agile Just because you call it agile it does not mean it is 74
  • 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
  • Infrastructures Debt Avoiding infrastructure debt 76
  • IaaS + PaaS Use as much of the stack as you can 77
  • 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
  • PaaS 79
  • IaaS 80