A lot has been written about the benefits of using MVPs, even right here on this blog. Perhaps it’s time to consider when an MVP seems to be particularly useful and in what circumstances its implementation works best.
Does at least one of these needs arise?
- I need a minimum product which will be loved by users (and which will leave the competition in the dust, of course).
- I need a minimum product which will confirm my hypothesis regarding the fate of the project.
- I need a minimum product to find out if my idea is good.
- I need a minimum product to check what the cooperation with the outsourced development team is going to look like.
- I need a minimum product to test a new contractor.
- I need a minimum product because I want users to start using what I’ve already developed.
- I need a minimum product to see if I’m not taking too much of a risk by opting for a Time and Material accounting model.
How one prioritizes those needs will naturally depend on the type or character of the company that’s starting out with the MVP.
At the earliest stage of a start-up’s growth, the main issue – above all others – is to gain knowledge about the market and the quality of the idea. In this case, the MVP can be as simple as an explanatory video or a landing page.
An equally important issue, perhaps, is that the delivered feature would allow for not only gleaning market knowledge (which is obvious), but reap some real benefits. It’ll be a working piece of software that’s ready to be developed.
And finally, this will be an excellent way to test your technical partner.
The context is slightly different for companies that already have products but who want to:
- develop the existing products with new features,
- start off a new project
It’s likely that the most important issue in this case will be to choose the right contractor and technology. In both cases, the MVP is a reasonable start, as it allows mutual trust to be built.
Who to trust?
My professional opinion is that an ideal future tech partner should possess certain key attributes. Ideally, the partner should:
- offer consulting services, and not only software development (i.e. offers workshops to define the IT project),
- offer to collaborate on defining the scope of the MVP,
- offer a safe accounting/contract model,
- put emphasis on the use of prototypes,
- be actively interested in your business,
- ask questions, suggest changes and – quite simply – have an opinion.
The advisory nature of such a company at the stage of MVP is difficult to overestimate.
Any questions, shoot!