When we talk about building an MVP, we understand that MVP means “a very, very simple product”.
For example – without 3G, Appstore, MMS, etc, the iPhone 1G was a very, very simple product.
It doesn’t mean that the quality of the product is intentionally lowered, though. The quality in this case is measured by how much this MVP reflects the final vision of the creator.
“A very simple product” might mean that only a very little set of features exists in the product. For example, if we build a first car, it might not have LED headlights, heated seats, and event seatbelts! But it should still have a motor that runs and moves the body of the vehicle together with the driver and passengers risk-free. If the first cars would explode, nobody would use them today. If the first zeppelins wouldn’t catch on fire, there is a high chance we would use them today.
So, you should understand what would make a simple first version of the product, and still build it with a highly technical team. A good technical solution will not be a competitive advantage, it never is, you should remember that! A good technical solution gives you a better impression on the first customers, they are not distracted by technical problems, and instead tell you the details of the problem they need to solve.
So, good build quality of the MVP is important if you want to gather only relevant feedback.
What time period should be taken for building an MVP? It depends on if you have a full-software product, or it has some hardware part.
For a full-software product, the right amount of time for building the first MVP is 2-3 weeks. The first week might be completely spent on writing the spec, so it’s only 1-2 weeks for building. Is it very little? Indeed! Does it make you think hard on what’s really important? Of course!
The best part here would be to consult with a technical expert and separate the tasks into 3 categories – hard/medium/easy. A hard task would take one developer the full development cycle, a medium would take 1-2 days, and easy can be done multiple a day. After a few such sessions, you will get a feeling of what can be done quickly and brings huge value, and what can’t be done quickly and bring low value. One sweet thing is that hard tasks can be decomposed into an easy and a hard task, and the easy part might have that high value. So the planning process is really, really important.
For a hardware product, it’s usually almost impossible to have a quick first MVP. For the first Tesla model it took a few years. So in this case investment is a very important part. Try to gather a team that can land an investment without having any real product, just theoretical explanation of what and how should be achieved. Pay attention to educational background and extensive in-field experience when you gather teammates.