From an idea to a Minimum Viable Product

In a startup context
George Krasadakis
Feb 2019
Photo by Hal Gatewood on Unsplash

View Slide

The structure of this session
Background
The MVP and why it is critical for a startup
1
From an idea to an MVP
Steps to follow to properly define your MVP
2
Rapid prototyping
Techniques to help you experiment and capture feedback
3

View Slide

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 involved
Stakeholders
Market scan
Possible competitors
Failed attempts
Ideas – one pagers
State-of-the-art
Competition
Solutions – one pagers
Wireframes
Users and personas
Product Architecture
Technology Architecture
Feasibility & cost estimates
Realistic UX
Technical description
Exit criteria
Feedback summary
Product Backlog
Product Roadmap
Tech architecture
Market strategy
Feedback mechanisms
Experiments

View Slide

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

View Slide

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

View Slide

Source: https://www.cbinsights.com/research/startup-failure-reasons-top/
Why do
Startups fail?
It’s the product!

View Slide

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. MVP – they just don’t get it
They don’t get the notion of the MVP and, as a result, they fail to focus and set the right priorities

View Slide

Why do Startups fail?
It’s the product!
Make sure you have the right product
management skills in your team!

View Slide

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

View Slide

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)

View Slide

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

View Slide

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

View Slide

A good MVP …
Focuses on the user
Reflects tested user needs
Has great feedback loops
Solves the core problem

View Slide

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

View Slide

View Slide

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

View Slide

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?

View Slide

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

View Slide

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

View Slide

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

View Slide

Define your product
Think as a user: define your product with user stories
1. Describe product features
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

View Slide

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

View Slide

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

View Slide

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?

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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 higher uncertainty
3. Define an overall experience by combine all ‘static’ features and those
built for the prototype

View Slide

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

View Slide

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!

View Slide

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

View Slide

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

View Slide

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

View Slide

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.

View Slide

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!

View Slide

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

View Slide

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

View Slide

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

View Slide

Talking about feedback …
Did you find this useful?
I would appreciate your feedback and thoughts!
Scan the QR code or use this link https://goo.gl/j8L7uw to submit your
thoughts, questions or suggestions.
Video version: https://www.youtube.com/watch?v=Buy8Ki-P0T8

View Slide

Building data-driven and AI-powered products;
leading technology innovation programmes;
17+ US 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’
[email protected]
https://medium.com/@gkrasadakis

View Slide

From an idea to a Minimum Viable Product

From an idea to a Minimum Viable Product

George krasadakis

More Decks by George krasadakis

Other Decks in Technology

Featured

Transcript