As I worked in startups I know the challenge to stay focused while being bombarded by featured requests, ideas and technical challenges way before the MVP has been properly set and evaluated.
As an engineer or technical person it is a common trap to immediately start solving a problem with the toolsets at your disposal. These common mistakes come to mind as dangerous in this phase:
- You a very biased to turn to the technical side of a problem too early (being an technical person). So think hard if a technical prototype is actually the real MVP!
- You are very likely to prioritize the wrong technical features and you might be tempted to implement Nice-To-Have features although there is no demand for them in that development-stage.
- You might use and choose an old habit toolset over a newer approach that would reduce development time out of pure convenience or even worse ignorance.
- You might be tempted to implement non essential parts of the idea opposed to outsourcing them. One needs to keep working on the MVP and not re-inventing the wheel. So make sure to always evaluate using common third-party-solutions rather then reimplementing basic building blocks.
- Keep things simple and add features only if essential to the MVP.
I found a great article outlining (my own experience) about the minimal viable product by Steve Blank @ Medium.
Minimum viable product
A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.Gathering insights from an MVP is often less expensive than developing a product with more features, which increases costs and risk if the product fails, for example, due to incorrect assumptions. The term was coined and defined in 2001 by Frank Robinson and then popularized by Steve Blank and Eric Ries.
It may also involve carrying out market analysis beforehand.
Definition from Wikipedia – Minimum viable product