Is it true that you should feel shame for your MVP?
Starting to work on your idea and getting to the first results is a difficult time – you have to convince your team, investors and even sometimes yourself also that the idea you are working on is worth time and money that you invest in it. But when the time frames are pretty tight and you work on complicated solutionIts, one day you will face the dilemma – what exactly you should cut off to get the MVP in time and how can you avoid painful mistakes. A well-known joke among Product Managers says that you should feel a kind of shame for your MVP, but is it really so and how exactly you can minimize this feeling during your demo days?
We won’t write here the stuff like “you should plan everything before”, “time planning save your product” or “good backlog of the tasks is your saver” because reality is so complicated thing, that a lot of different factors can affect the success of your MVP and the more complicated your product is, the more possibilities arise that in the research and development phases something will be discovered, and this SOMETHING will significantly change your backlog, or even will make your think about rapid pivot in your idea.
Let’s assume that you already have some troubles in your development line and you have not so much time before the demo. You have to decide which of the functionality you should sacrifice to get the minimum level of the negative feedback from the testers and make your MVP good enough for them to want your product in the future. There is no strict advice about the way you should behave in this difficult situation, but looking logically at the goals of your product, you can understand the maximum amount of the final features that you can sacrifice.
For instance, when you are working with the A-HA product that needs to make a great impression from the first seconds of usage, it’s not a good way to sacrifice your UX and design for the broader functionality. Even if in the first version of your product specification you have mentioned that you want your product to be multi-functional, when time counts too fast you have to reduce the amount of the functionality in your product but to deliver the best possible design for your testers. In this case, limitation of the different dashboard options will be not so crucial as the poor view of the dashboard and absence of the colorful and intuitive elements.
The other situation is when you are working with a high-functional product that needs to solve the urgent need of the customers so they can sacrifice the poor design and more concentrate on speed and the effectiveness of your product. You can’t give customers a good looking tool but with the absence of the basic functionality that they wait for, so you’d better save some time and effort with the basic design (even if it looks too simple for you), but concentrate on the best available quality of the services and the high speed of the product. And yes, a small disclaimer on your front page about the idea that right now the user is on the MVP of the product and thus the design is still on the construction, can give you some additional points as your teatster will be aware of the fact that soon they will get not only a perfect functionality, but also a beautiful design of your solution.
As you can see, it’s not the case to make your solution feel and runs perfectly from the first stages, but it’s quite achievable to make it feel good for your first customers. Gaining insights from your auditory is the crucial step for your product’s future development, some of the feedback might be a little bit disappointing and you can feel not so comfortable with your MVP. But it’s quite okay, “no pain-no gain”, just try to make your best in understanding your customer needs, tailor your MVP to test your assumptions and be ready to move further after the testing results inspired and proud that you have learned how to make your solution even better.
1
Previous