From an idea to an MVP: a guide for startups
•Download as PPTX, PDF•
5 likes•762 views
The Minimum Viable product and why it is critical for a startup. How to get from an idea to an MVP through a prototype. How to speed up your software prototyping process. Techniques to help you experiment and capture feedback. As a founder, It is very important to deeply understand the notion of the MVP. You need to use it as part of a method or a framework to help you make better product decisions – and mitigate or avoid known risks. So this definition by Eric Ries, defines the MVP as ‘ …a product with just enough features to satisfy early customers, and to provide feedback’. Your MVP must solve the problem for your customers; your users should get value out of it; your MVP should be good enough so the users engage with it and potentially pay for it; Your early customers should be so happy with your product to act as promoters – to recommend it to others and publicly share positive feedback. https://www.theinnovationmode.com/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to From an idea to an MVP: a guide for startups
Similar to From an idea to an MVP: a guide for startups (20)
More from George Krasadakis
More from George Krasadakis (20)
Recently uploaded
Recently uploaded (17)
From an idea to an MVP: a guide for startups
- 1. From an IDEA to an Explained in just 40 slides George Krasadakis Feb 2019
- 2. The structure of this session Background The MVP and why it is critical for a startup1 From an idea to an MVP Steps to follow to properly define your MVP2 Rapid prototyping Techniques to help you experiment and capture feedback3
- 3. From a problem to an MVP Problem Idea(s) Concept(s) Prototype(s) MVP A learning process via prototyping, experimentation & feedback loops Problem statement Users & Personas Stakeholders Market & competition Failed attempts Ideas in a structured form State-of-the-art Technology trends Solutions, Epics, Wireframes Users and personas Product Architecture Technology Architecture Feasibility & cost -- quick estimates Realistic UX Technical description Exit criteria Feedback summary, user insights, market signals Product Backlog Product Roadmap Tech architecture Market strategy Feedback mechanisms Defined experiments
- 4. The product management function Problem Ideas Concepts Product Management Function Prototype MVP MVP +1 MVP +n Product Backlog … Targets Planning Insights KPIs User Feedback Priorities Ideas Inflow: User feedback, telemetry Outflow: New releases, new features
- 5. Product Management is critical for startups 75 percent of venture-backed startups fail1 1 FastCompany, "Why Most Venture Backed Companies Fail," Harvard Business School -Shikhar Ghosh. 1. Startups have extremely limited resources 2. They are ‘driven by passion’ 3. They have little or no structure The product risk: To build something nobody wants or poorly build a product with great demand
- 6. Source: https://www.cbinsights.com/research/startup-failure-reasons-top/ Why do Startups fail? It’s the product!
- 7. Why do Startups fail? My own list of failure reasons 1. Over-engineered products Even if the MVP is properly defined, the engineering work become far more sophisticated than needed; this leads to waste of energy and resources – with huge opportunity cost. Engineering-heavy teams need to be aware of this risk and follow a lean, agile approach. 2. Ignore or mis-interpret user feedback Startups may ignore the signals from their userbase; or confirmation bias may responsible for reading only the ‘compatible’ patterns; this is where predefined Success criteria – specific metrics and KPIs could make a difference. 3. Limited understanding of the MVP They don’t deeply understand the notion of the MVP and, as a result, they fail to focus and set the right priorities
- 8. Why do Startups fail? It’s the product! Make sure you have the right product management skills in your team!
- 9. The MVP 1. The definition of the MVP 2. Popular misconceptions regarding the MVP 3. Why a good MVP is critical for startups 4. Characteristics of a good MVP 5. Signs of a poor MVP 1
- 10. But what is an MVP anyway? “In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product Ries, Eric (August 3, 2009)
- 11. But what is an MVP anyway? “In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product Ries, Eric (August 3, 2009)
- 12. But what is an MVP anyway? “In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product Ries, Eric (August 3, 2009)
- 13. But what is an MVP anyway? “In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product Ries, Eric (August 3, 2009)
- 14. Frequent misconceptions about MVP People confuse the MVP with the Prototype People confuse the MVP with the Proof of Concept People think of the MVP as ‘just something to start with’ People think of the MVP as a ‘quick and dirty’ product
- 15. With a proper MVP you will be able to: Think Big, but start small, iterate fast Build your product with less Test your product with real users, faster Go to market faster Pivot, earlier
- 16. A good MVP … Focuses on the user Reflects tested user needs Has great feedback loops Solves the core problem
- 17. A bad MVP … Is over-engineered or not engineered :) Is not aligned with user needs Does not enable user feedback loops Is over-complicated or oversimplified
- 19. The Problem Statement Make sure you don’t solve the wrong problem Describe the problem you are solving with a solid problem statement: ”… a concise description of an issue to be addressed or a condition to be improved upon. It identifies the gap between the current (problem) state and desired (goal) state of a process or product https://en.wikipedia.org/wiki/Problem_statement
- 20. Validate the Problem Is it really a problem worth solving? 1. Who are the key-users – the ones impacted by this problem? 2. What are the pain-points you are trying to eliminate? 3. Did you validate your problem statement with your team, your stakeholders and selected users – does it reflect the real problem?
- 21. Articulate your solution Describe in a single page: 1. The context – the situation 2. How your product solves the problem? 3. Start describing your personas 4. How you address the major pain points for your users? 5. Think big at this stage – describe your product vision 6. State your assumptions
- 22. Identify your users Who are you solving for? 1. List all different classes of users –who will benefit from your solution? 2. Document your users, their needs, their pain points 3. Describe the ideal scenarios/ experience for each class of users 4. Collect metadata for your users – anything that could be correlated with needs, expectations, point of view 5. Define named personas
- 23. Understand your users Who the users are vs what the users need 1. Construct user profiles and personas; use empathy 2. Interview users – capture signals, pain points, expectations 3. Analyse available studies and metadata – public domain 4. Validate your problem with selected users 5. Validate your solution with selected users
- 24. Define your product Think as a user: define your product with user stories 1. Describe product features <as a user> 2. Apply empathy – use what you know for your users/ personas and try to express their needs and the desired user experience 3. Think Big – write Epic user stories 4. Think Small – its OK to write user stories at the lowest level of detail 5. Don’t bother about feasibility and priorities at this stage
- 25. Define your MVP Post-process your user stories; rank them; get your MVP 1. Your product backlog should have all the user stories/ product features you can think of 2. Process each user story to estimate [a] its expected value for the user/ its importance in solving the problem and [b] its feasibility 3. For each story, you can combine these estimates into a single score 4. When all your stories have a score, rank them to reflect the priority
- 26. Define Success You need a solid definition of success … to get there 1. At this point you have a prioritized product backlog; you need to describe what ‘success will look like’ 2. Identify the key metrics which will be used to measure success 3. Combine the metrics to the right KPIs 4. Prepare your data capturing mechanisms to support your metrics 5. Design a single ‘product performance dashboard’ as your source of truth
- 27. Problem Ideas Concepts Product Management Function Prototype MVP MVP +1 MVP +n Product Backlog … Targets Planning Insights KPIs User Feedback Priorities Ideas You are here How can you get there… faster?
- 29. The Prototype Defined Types of prototypes 1. Static prototypes – wireframes could serve the purpose in certain cases 2. Clickable prototypes – approximating the experience but with no real back-end and data services 3. Functional prototypes – but under numerous assumptions and conventions; they can look realistic enough to support real user interaction scenarios
- 30. Rapid prototyping techniques Why build a prototype? 1. To get a realistic, functional instance of your product, really fast 2. Expose it to selected users and capture feedback 3. Test certain aspects of your product – the ones which have high uncertainty and/ or implementation cost 4. Test certain technologies or experiences which might be new to end- users – for example voice-driven interactions
- 31. Prototype ≠ MVP MVP 1. Minimum but Production ready and real product 2. Secure and Reliable 3. Accessible by all users 4. Integrated with real data services Prototype 1. Does not address production requirements 2. Security/ Reliability not concerns (static/ limited security risks) 3. Accessible by limited number of users only 4. Reusing existing components and artificial data and static content vs
- 32. How to speed up your prototyping Build only what needs to be tested 1. Set the right focus – do not build ‘conventional features’ 2. Find the features with increased uncertainty 3. Define an overall experience by combine all ‘static’ features and those built for the prototype
- 33. How to speed up your prototyping Use static data; reuse existing components 1. Don’t spend time building real data models and data stores; 2. Quickly design your key entities as static JSON files 3. Expose them via a simple APIs and you have a realistic integration scenario
- 34. How to speed up your prototyping Use existing, 3rd party services 1. Even for advanced AI scenarios there are ready to use commercial APIs to quickly integrate and use 2. Even if you plan to build your own AI algorithm, you should be able to approximate your results with existing commercial services 3. For all of your key scenarios – search what is already out there in terms of APIs and use it!
- 35. How to speed up your prototyping Use prototyping tools 1. There are great prototyping tools out there – especially for designing UI/UX for web and mobile devices 2. There are great prototyping tools even for VR/AR experiences 3. Scan the market, select the right tools for you and use them for quick, static or clickable prototypes
- 36. How to speed up your prototyping Make assumptions, move fast! 1. When prototyping you have to deal with uncertainty, fast! 2. When you do not have all the answers, just make assumptions; just make sure you will go back to validate them as you learn about the problem and your users 3. Maintain simple, to-the-point documentation on the objectives, assumptions and success criteria of the rapid prototyping effort; share it with your team and your key stakeholders
- 37. How to speed up your prototyping Rethink Quality 1. Quality is great – but you have to put it in the right context 2. You are not building a production system – even if the prototype is hugely successful, chances are that you will through away the code 3. Focus on the user experience; back end processes could be hard-coded, based on static, artificial data and the overall experience supported by just a script
- 38. How to speed up your prototyping Define exit criteria 1. A prototype is a kind of experiment/ test, to enable you to validate a concept and learn 2. You need to define the key questions and the specific points your are ‘testing’. 3. Document the definition of success and exit criteria; and what you are hoping to get out of the prototype, upfront.
- 39. How to speed up your prototyping Build, capture feedback, iterate fast! 1. Build a basic UX – wireframes or real UI 2. Connect static data to make it realistic 3. Present it in the right context with a story – the right flow 4. Capture feedback 5. Iterated as needed; but fast!
- 40. How to speed up your prototyping Use UI libraries & templates 1. There are great resources online – from web page templates, mobile apps, images and videos – even public data sets which could make sense in your scenario; use them! 2. If you plan to prototype frequently, build your own, internal library of resources 3. If you have UI/UX experts in your team, consider setting up a set of reusable UI elements and resources to speed up UI/UX development
- 41. How to speed up your prototyping Use DevOps, Automation, Monitoring 1. Normally you need to host your prototype – so get ready in terms of hosting scenarios and DevOps 2. Assuming a large group of users to expose your prototype to, you need an effective way to capture feedback – via the prototype and/or with online tools 3. You might need to setup monitoring processes to summarize user engagement and interaction, during the prototyping phase
- 42. How to speed up your prototyping Set the right expectations 1. Make sure that your key-stakeholders understand what a prototype is and have the right expectations 2. Make sure your users get the full context when they are asked to interact with the prototype 3. Make sure that you get honest, objective feedback from your users and stakeholders; summarize and communicate appropriately the feedback and insights
- 43. Talking about feedback … Did you find this useful? I would appreciate your feedback and thoughts! Use this link https://goo.gl/j8L7uw to submit your thoughts, questions or suggestions. 20’ video version: https://www.youtube.com/watch?v=xCapgWMvCCI
- 44. Related resources Startups and the Importance of Agile Product Development Rapid Prototyping practices for Software Engineering teams How to run a successful Design Sprint How to lead innovation and drive change in engineering teams How (and Why) to Write Great User Stories How to become a great Product Manager Is this a prototype or an MVP? Well actually, it’s a proof of concept. How to setup and lead a great product development team Technology Innovation — Trends and Opportunities in 2018 20’ video version: How to go from an Idea to an MVP - explained in just 20'
- 45. George Krasadakis Building data-driven and AI-powered products; leading technology innovation programmes; 17+ patents on Artificial Intelligence, Analytics and IoT • 20 years of digital product development – from concept to launch • 80+ innovative, data- driven projects • 10 multinational corporations • 3 technology startups • Founder of ‘Datamine decision support systems’ https://www.linkedin.com/in/gkrasadakis/ https://medium.com/@gkrasadakis
Editor's Notes
- Hello there, My name is George Krasadakis and I am very happy to host this MVP webinar for you. The objective of the webinnar is to help you with your product development efforts – by explaining the notion of the MVP – Minimum Viable Product, and the reasons why it is sooo important for a startup I will present how to define it and how to actually build it – all in the context of a startup. So lets start with an introduction.
- In the next 45' or so I will be covering the following: 1. A quick introduction to the notion of the MVP – what an MVP is, why you need, and why it is a critical success factor for startups 2. The process – how to move from an idea to a properly defined MVP - steps, activity and best practices 3. Advice on what to do and what to avoid in the context of product development for startups
- Problem: A clear, solid definition of the problem statement; a deep understanding of your market, your users, the competitive landscape Idea One pager of the idea Concept Epic User stories, wireframes, high-level architecture Prototype Epic User stories, wireframes, high-level architecture MVP Epic User stories, wireframes, high-level architecture The Feedback loops A learning process
- Describe a potential roadmap Describe the build> release> learn loop
- Additional reasons based on my personal experience: over engineered product; lack of commercial aspect
- The purpose of this chapter is to define the MVP and explain its importance for startups; we will also cover the characteristics of a good MVP versus a poorly defined one.
- As a startuper or founder, It is very important to deeply understand the notion of the MVP and use it as part of a method or a framework to help you make better product decisions – and mitigate or avoid known risks. Let's start. MVP was coinned by '' and then popuraized by the book 'Lean startup' by Eric Ries There are three key components in this definition:
- MVP was coinned by '' and then popuraized by the book 'Lean startup' by Eric Ries There are three key components in this definition: Just enough features --- Minimum … but how? You need to identify the best subset of features which are both valuable, good enough for the user – while at the same time inexpensive to build and operate
- 2. Satisfying early customers Your MVP must solve the problem for your customers; your users should get value out of it; your MVP should be good enough so the users engage with it and potentially pay for it; your early customers should be so happy with your product to act as promoters – to recommend it to others
- 3. Enabling feedback for future development This is critical: you need to be able to deeply understand what your users want and reflect it to your product strategy You need the right mechanisms and processes to capture the level of user engagement and measure how your users use the product and how they interact with it across platforms, channels and markets; In many cases, you need to collect qualitative feedback in several forms; you may need to run focus groups, surveys, analyse complaints etc. all focusing on understanding how you are delivereing value to the users and what is missing. You should definitely consider integrating customer satisfaction mechanisms such as the NPS – Net promoter score Having these insights, you will be able make informed decisions about your product development and investment areas
- The thing is that, although the notion of the MVP is a great idea, in practice it is now used in the right way: For instance, MVP is frequently used to denote a quick implementation, a draft, a prototype or something to start with. Although that these might be relevant at some extend, an MVP is much more powerful notion.
- 1. You will empowered to thing BIG – and this is very important: you need to have a product vision – this will help you not only with your strategy but also with execution: having a clear vision about your product will allow you to easily set the priorities, timelines and roadmap. The process of defining your MVP will force you to think clearly about priorities, constraints, users, the value you bring and how to solve the real problem. Thiking about your MVP will help to also thing of iterations towards your ultimate goal: your product vision. 2. You will be able to build your product with less: the MVP is about identifying the absolutely necessery functionality that keeps users active/ engaged; while generating insightful feedback to support your decisions; this allows you to minimize your development and operational costs by de-prrioritizing those features which are considered to be lower priority and 'can wait' for another iteration. Properly defined and executed the MVP will save you money; and help you manage risks. 3. This is a major thing: the MVP should provide streams of feedback in a number of ways – directly or indirectly. For instance, a properly build MVP should capture all user interactions and append the data into a historical user interaction database (be aware of GDPR here). Proper reporting and data analysis could unveil patterns to validate or invalidate your assumptions; or to indicate different paths or opportunities to pivot. Qualitative feedbck – via embedded forms or online questionnaires or focus groups with real users on their experience with the MVP – could also empower your product development team/ with signals, requests, or insights you might have never thought of. 4. As explained, you will build faster, but you will also have to enter the mode of 'continous deployment'. Understanding the notion of the MVP, means that you accept that there are constraints in order to go to market faster: you will release only what you have identified to be the minimum (and not necessarily all the fancy, cool and super techy ideas you have). That's the tradeoff here. In general, thinking in terms of MVP and iterations will dramaticaly improve your agility and product development performance. Just make sure you keep 'listening' to your users and considering the insights in your feature prioritization decisions! 5. Pivot earlier: in general, the MVP approach also help you minimize the risks. You have the users engaged from the beginning, you capture feedback and use it in every single product development iteration. Your are more connected to your user base and you have the flexibility to respond and adjust your priorities and product roadmap, just in time.
- Describe poorly defined MVPs, common mistakes and things to avoid
- Don’t apply constraints at this point/ you will be able to prioritize your MVP at later stage The Minimum in the MVP implies that you already have the big picture, you have the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and the big picture. Set the context — think of the problem, the situation and the opportunity. Think of what is already available in the market dealing with the same problem.
- Identify and name the types of users involved and how they interact. Document your users, their needs, the problems they are experiencing, their expectations, and the best-possible experience they could have in your context. Define Success criteria for each class of users
- Having listed your users, doesn’t mean that you also understand them Although qualitative only – it could provide significant signals – do not generalize though/ be aware of confirmation bias here
- Having the big picture you need to apply a process to identify the smallest subset of functionality that serves a very specific goal. The goal is to satisfy your users. You also want to enable critical user insights and feedback. This feedback can improve the next iteration in your product development plan. The big picture is the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of epic stories. Then iterate across all identified users and try to define user stories covering their needs and expected benefit/ gains. Use a compact format as the one proposed in Scrum: as a <user> I want to <be able to perform an activity> so that <describe the gain>. You don’t have to worry about priorities at this stage. A good idea would be to name each story/ assign a compact title for easier classification and organization. JUST APPEND EVERYTHING TO A LIST/ OR A SYSTEM – YOU WILL POST PROCESS THE STORIES TO SET THE RIGHT ORDER ETC.
- For simplicity, you can skip the scoring model and apply business sense in assigning priorities directly; then you just rank with the priority
- You haven’t gone that far yet – although this is the fundamental – the basis – the core –
- The ultimate goal of a rapid prototyping project, is to build a realistic functional instance of the concept, in order to capture feedback and signals from real users; you need to think ‘as a user’ and summarize the scope with clarity — ideally as a short list of well-defined epic user stories. For example voice interaction – users might not feel comfortable to interact with a machine via voice
- When in rapid prototyping mode, it doesn’t make sense to waste resources in building non-critical components and features — for example authentication mechanisms, a login UX or a new ‘visual language’ from scratch. Do not try to prototype your entire product or even your entire MVP. Instead, set the focus and minimize the development time using the following: Identify the non-important features of your product (in terms of uncertainty and learning opportunity). For example, why build a real login mechanism or a user profile page or a dynamic landing page? You could reuse existing components/ or use static data to approximate the experience, while focusing on the components which are the real unknowns
- Quality can be redefined in the context of your prototype, with a bias for UX rather than optimized code or other technical aspects. In general, for a prototype, it should be OK to hard-code and use static data as needed in order to move faster. For instance, as soon as you define your object model, you could generate static JSON objects, to be consumed by your client apps via regular APIs calls; as you move on with your development and where it makes sense, you can take advantage of this abstraction layer and plug in real data connectors, dynamically instantiating your objects and serving them via the same APIs with the same JSON serialization — with no further changes.
- A prototype is a kind of an experiment to help you make product development decisions; you need to set the framework on how to process the feddback from users and what are the signals/ metrics which will allow you to make wise product development decisions
- During a rapid prototyping project, it is critical to iterate fast: prepare your data, build a first version of the UI, integrate APIs, offer a basic end-to-end experience and present to stakeholders; process feedback, make sure the focus is right and iterate towards a realistic implementation of the original idea.
- Having a great collection of UI elements and controls to draft your User Interfaces is of critical importance. You need a rich set of reusable, configurable UI elements and frameworks along with tools and platforms enabling sketching and wireframing. Depending on the case, special UI components such as data visualizers, dashboard patterns, interactive charts etc. could also prove to be very helpful.
- Releasing, hosting and managing your prototype throughout its lifecycle, should also be fast and efficient. This requires the right tools and processes to automate certain tasks, control access and manage the code repositories. If you are systematically producing prototypes, you need a repository for the prototypes themselves — to enable discoverability, analysis of usage patterns, feedback and a range of metadata.
- The culture
- So, a few words about my self… I am a Product Architect for nearly 20 years – which means that I have been defining and building digital products for ever. My background is based on a combination of software engineering and statistical science – always in a product development context. Up to now, I have designed and built a number of data-driven software products for large multinational corpporations – such as Microsoft and Accenture – but also for a number of startups – including Datamine Decision Support systems. I have also designed the Innovation frameworks for (Microsoft, Accenture) and the technology layers to support innovation functions such as ideation, experimentation, rapid prototyping, gamification and more. So, hopefully I will provide some useful insights and guidance on how to define and build your MVP. Enough about me. Let's start with the our agenda. ----------- In a typical case, I start from an idea, I design the architecture of the product, and then then manage its execution and the launch.