Part 5 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 define your MVP and build a dummy one. This week, we will be exploring how to build your MVP and create a continuous feedback loop with your customers.
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
- Part 4: Define an MVP, build a dummy one and test, test, test
Building your MVP
You have done your research, nailed the problem statement, built a user base and defined your MVP. Now, it is time to build it. The below will apply best to digital products but parallels could be drawn for non-digital ones as well.
- There are various no-code methods out there to help you get started.
- It is usually easier to build something on the web rather than a mobile app, however, you need to keep in mind your personas and when/how are they expected to experience your product. You want to avoid compromising your MVP’s performance, just because you chose the wrong platform to build it.
- If you are looking to build an app, think, are your personas more likely to be using an iPhone or an Android phone?
I’d suggest choosing the most appropriate one and build for it first. There are exceptional resources out there when it comes to what coding languages to use, if you decide the no code solutions are not suitable. Inform your decision by spending some time going through the options, thinking your personas, the problem and your vision for this product, researching the various ways you can build your MVP and consulting with people you trust.
You may include some data analytics for understanding how your users are using the MVP, but it is ok if you don’t. You should be in constant communication with them at this stage and hearing this data firsthand!
Share your MVP with your BETA users
You’ve built your MVP, now it’s time to share it with your BETA users. Let them know this is your first variation and you would like their feedback to help you make it more valuable for them. Encourage them to use it and share their thoughts and feelings.
- What would they like to be different?
- What would they like to see next?
- What do they love about it?
- When are they using it and how?
- What stops them from using it?
Gather as much feedback as you possibly can and keep going back for more!
It is also helpful to set a dedicated email address, or communications channel where they can reach you. You should make it as easy as possible for them to reach out to you. Welcome the feedback and be quick to respond to frustrations that may occur due to technical issues, like difficulty signing in or app crashing. Be helpful, respond with empathy and try to reply to all communications.
Build a way to track the feedback you are receiving to help you generate insights and recognise patterns. I use Airtable, as I love the way I can connect the feedback to the user and the persona, all while creating graphs that quickly highlight the biggest pain points or most common feature requests.
The qualitative data you are gathering from your BETA users are the most valuable data you can have, any quantitative data at this stage, wouldn’t make much sense.
I have however, created one metric that I think is very helpful, called feedback retention. I defined this metric by counting how many times a specific customer or user was coming back to give us feedback. This helped me recognise who might be our early adopters that I would be able to reach out to easier when I wanted some quick feedback before a new feature, but also recognise which personas I was missing feedback from.
Build your product roadmap
Your product roadmap is a living and breathing thing. It could consist of:
- 10% bug fixes
- 60% feedback-based feature development
- 30% cool features
These may be features you think will be super cool and bring value to your customers, but they don’t know it yet! This is your space to innovate and test ideas.
The above percentages will probably change from time to time and as your product matures you’ll have to keep a percentage for security, privacy and any tech related development, to maintain and improve the performance of your product.
You should also be reviewing and prioritising the feedback you are receiving on a daily basis. If you feel you don’t have to do this every other day, you are probably not receiving enough feedback!
There are many ways you can prioritise your product roadmap as well, but at this early stage it is probably about:
- Fix any bugs that affect people using the product
- Develop the features that will bring the most value to the most users (these will most likely be the most frequent feature requests that you are receiving)
- Allow for some time to be building your cool features on the side (~20% of your development efforts)
Create your feedback loop
Whatever I mentioned above is not a linear process that happens once. This is a continuous loop. Gather feedback (learn) → Define/design a solution → Build the solution → Test it → Gather more feedback
Your goal is to get things out as quickly as possible (avoiding bugs!) to test them and receive feedback to improve them. Features don’t have to be huge, they could be simple ones. Imagine a navigation app, a feature could be sorting the results after somebody input an address, by ranking first the ones that are in the same country as the user.
It is all about building features that bring more value to your amazing customers and getting it out there quickly. There’s no one better to tell you if delivered something valuable than your customers themselves!
I got quite excited about connecting with your BETA users and building a feedback loop that I didn’t get to cover the preparation for launch this week, but I will dedicate next week’s blog post on just that. Stay tuned!
Let me know your thoughts and feedback in the comments.
