I approach MVPs using the scientific method. Create a disprovable hypothesis, test the hypothesis with experiments, and use the resulting data as feedback.
An experiment is not necessarily created with code.
A disproved hypothesis informs whether the business needs to pivot.
Clearly Identify the Problem you are Solving (Hypothesis)
The first step to a successful MVP is a successfully identified problem.
It is a disprovable hypothesis (or set of hypotheses).
Working Backwards
When you have identified a problem, a user pain, a job to do, then you can work backwards from that point to choose the right technology.
You are not your User
A very common problem in MVP development involves building the product for yourself, instead of for your users.
A Designer is Important
By Designer, I mean a UX Designer that understands qualitative, quantitative, and contextual data.
Their goal is to produce as much data to prove/disprove the Hypothesis as possible without code, and to be critical input to an Engineering team.
They are NOT solely focused on producing wireframes and picking colors, fonts, etc.
Create Experiments
Experiments involve anything that sufficiently and accurately solicits feedback from users to prove/disprove the Hypothesis.
Experiments don't have to be Working Software
If you can solicit effective feedback using a picture drawn on a napkin, a PowerPoint presentation that was setup to behave like an App, or any other tool that delivers quick and effective feedback, use it.
Do not spend thousands of dollars on code unless that was the 'Minimum' needed to produce data.
Explore Risk
Use the time spent building your experiments to explore the risk in the project.
Risk involves:
- Unknowns
- Learning curves for new tools (team isn't experienced with the tool)
- Anything that could derail the product and idea
Measure the Experiment (Data)
Measurements include quantitative, qualitative, and contextual data acquired during the experiment.
Iterate
Each experiment and subsequent data produced is a chance to iterate on your Hypotheses.
Don't attach yourself to a Hypothesis
You should be willing to let go of a hypothesis if the data proves it wrong.
Pivot if Necessary
Be ready for the possibility of needing to pivot. The chances are high that change may need to happen in these early stages.
It is easier to Choose the best performing Prototype, than to Guess
If you created 10 prototypes, and one of those prototypes had clear signals from actual users indicating it could be successful, the chances are much higher you will actually succeed.
Compare this to building something from only your understanding, which is effectively guessing.