Part 4 in the series started in Partnership with Auxilia Global to explore the various steps entailed in product development in going from idea to product to launch. Last week, we explored how to ideate with your team and think of various different solutions to your problem statement. This week, we will be exploring how to take all these ideas to help you define, prototype and test your MVP.
You can find the previous articles below:
- I have an idea for a product, what now?
- Part 2: Making sense of early problem discovery conversations
- Part 3: Ideating and getting ready to define an MVP
Defining your MVP
You’ve equipped yourself with many solutions, and this is awesome, but it’s time to bring your personas back into your thinking. Pull out the personas you’ve defined and start thinking how the solutions would be applicable to them. Imagine them using each one of them. How are they feeling? What frustrates them? How would this fit around their lifestyle? Would it make them tick?
This will help you narrow down the solutions available to the ones that would most appeal to your personas. If you are still left with too many, think of any more boundaries that may make sense or use your gut feeling and experience. You want to choose a solution that offers the most value with the least effort (both from your side but also the persona side).
Bring it down to 2–3 solutions and sketch them out. How would they work, what would the interaction look like? It’s a great time to build some wireframes to bring them to life. As you build your wireframes you need to keep in mind that this is still about defining your MVP. That means:
Minimum: the smallest number of capabilities, features, and packaging that…
Viable: deliver enough value that customers are willing to spend money (or another currency such as personal information)…
Product: on something they can use today… not just invest in a future concept, promise, or offer. (source)
You can design 2–3 solutions and build a dummy interactive prototype. I usually use Figma to create the designs and InVision to bring these screens to life (you can build interactions on the designs to make it a responsive prototype). At this stage you don’t need any coding, only some basic design skills. You want to be able to validate the solution before it’s even built.
Testing your dummy prototype and gathering feedback
Take your dummy prototype (or even better 2 of them) back to your personas, give it to them and let them talk out loud as they experience it for the first time. Don’t tell them what the product is or how it works, if you’ve done a great job they will quickly figure it out. Any question they ask, take a note of, it means something is confusing. Watch where they spent their time on, what excites them and what frustrates them. Listen to their feedback.
Some tips on sharing a dummy prototype with a potential customer:
- Remind yourself that you should be obsessing with problems, not solutions, don’t get too attached to any solution. You may have to redesign the whole thing more than once.
- Let them know you are looking for honest, candid feedback.
- As they go through it, encourage them to share their thoughts out loud.
- Keep your poker face and show genuine interest on what they share as frustrations, try to understand why it is frustrating. Is it a usability problem or is it just not seemingly solving the problem?
- Let them know, if they feel frustrated, that this is a problem of the solution, rather than them.
- Ask them how valuable they found it and whether they used somthing similar in the past. Explore their experience with similar products.
- Ask them if they would expect to use it (take the answers with a pinch of salt, people are inclined to say yes, but you need to go back and think how are they solving the problem today and whether this is complimentary to their lifestyle rather than disrupting it).
- Their reactions are worth a lot more than what they actually answer to the above question. Pay attention to how they interact with the prototype and the comments they make as they go through it, don’t keep notes, observe.
Test the solutions with 10–15 people who represent your personas. Testing with friends or family is a good way to start and perhaps catch some usability issues, but your personas will tell you whether the solution is valuable to them or not.
Redefining your MVP and keep testing
Go through the feedback, recognise common themes and create a new non-working prototype. This step is one you may have to repeat a few times until you get it right. You are looking to see this “aha” moments that make your personas tick as they experience your product, then you know you’re on a good way to making a valuable product.
You may have exceptional insights to your personas (based on your early problem research and experience) and be lucky enough to have created the best prototype ever, but also be prepared to redefine it a few times until you get it right. Defining an MVP is not a one-time thing, it is a repetitive process informed by your personas, your insights, your experiences and gut feeling.
Recruiting beta testers
As you are going through this feedback loop, you should also be “recruiting” your beta testers. These could be friends and family, but you need to make sure that your beta testers include a big percentage of your personas. You want to recruit people who will give you candid feedback and would be assumed as early adopters. Think again of the places you could find these personas and approach them, asking if they would be happy to be the first to test your product and provide feedback. This is a lengthy exercise but one of the most important ones that will help you shape your MVP and build your roadmap, ready for launch.
Next week, I will come back to explore how to gather feedback on your MVP, build and inform your product roadmap and prepare for launch (not billboard type launch that is, more like a quiet, but public one)!
Have a wonderful week and let me know your thoughts and feedback!
