What’s in an MVP and why do I need one?

The earliest stages of a tech-focused startup involve a seemingly maddening number of vicious-circle requirements. The specifics vary from sector to sector but whatever sector you’re operating in, it’s likely that you will very early on encounter one or more of the following “chicken before egg before chicken” conundrums:

• We need to build our Product so we can raise money, but we need to raise money first to build our Product
• We need to build our Product to get feedback, to find out what needs to be in our Product when we’ve built it

It’s also probable that these other, related thoughts will occur to you around the same time:

• If we need to build our Product before we can measure Product Market Fit, won’t it be a bit late to change it?
• We need to build our Product quickly and simply, but it also needs to be future-proof

It’s easy to see then that the prevalent mindset of “you need to build an MVP” won’t resolve these circular arguments at all; in fact, it just adds stress to the whole thing.

You need a way to see a series of ever-maturing versions of your Product, starting RIGHT NOW. These will of course be small and flimsy in the first couple of weeks, but growing and blossoming with each week that passes.

It’ll start with an app just in the hands of the founders; then close friends; then trusted associates, and so on. As the weeks unfold you will gain more confidence in the perfection of what you’re building and start to share it more widely..

This cycle of Continuous Delivery is at the very heart of how MCBH Cloud Software approaches all product development.

At each stage - every week - you get the chance to see and feel the product and - as a result - to make adjustments, and to consider pivots or course-corrections. After a few months of this, you will have achieved the elusive alchemy of having a true Minimum Viable Product and along the way you have been able to learn, react and adapt. All as part of the MVP delivery process.

This seemingly magical promise is the very core of the principles of Agile. NO, not sprint planning, points, arguments about velocity - that’s not Agile. That’s a mechanical, unthinking automaton approach to Scrum (which is like a toolkit to try and be Agile).

No, we are talking Core Agile Principles which include:

• Accept that the best way is to deliver a series of bankable value additions week on week, and use these to get REAL feedback on your product
• Get your Founding Team thinking about the Product as a consistent series of incremental releases, and NOT a big-bang “6 months of waiting” project
• Identify and call out the biggest baddest assumptions early on and getting proof that you can handle them like you think you can (tech USPs, tricky API integrations, etc)
• Position your Product person as the warm organic core of the project, responsible for continual transition of features between what we know we’re working on and what we expect to work on; a truly navigational mindset

Of course, if you want to deliver your product in this way - and you really do - then you will need not only your strategic and product founding team to be willing to work in this way (and once they have, they won’t want to work any other way), but you also need a Tech Team that is able to seamlessly mesh with this thinking and, indeed, views their entire raison d’être as the delivery of Agile Product, in incremental releases (“iterations”).

Too often you will find that Tech Leadership - managerial or architectural - will be over-focused on Big Picture Architecture and long-term project goals from the outset. This will not only frustrate your attempts to deliver Continually Deliver value, it will very likely completely derail them.

That is why with MCBH Cloud Software all our engineering work is informed purely by Product Needs and focuses itself exclusively on the Value being delivered in the current week. No over-engineering or pre-engineering. Just Lean, Agile tech. In your hands. Week after week.

The processes and standards which we put in place will carry your enterprise forward past MVP, past Beta, into Full Launch and beyond. We will also put in place the culture and a team (if we are hiring for you) which will ensure this ethos not only survives but comes to define Product Practice in your organisation.

Conclusion

To answer the questions in this blog’s title: What’s in an MVP, and why do I need one?

What’s in an MVP?

So what is in a Minimum Viable Product? Naturally each project is unique and your product is unique, so the literal list of items is in your own hands. It’s also beyond the scope of this level of document but you can find more info on how to Prep Your Backlog to set up the project for success early on.

But in general, our Products in your MVP will be there to achieve the following aims:

• Things which prove to you and to possible investors that you’ve identified and tackled the hard questions
• Proofs of Concepts for the most critical USPs in your offering, again for your own benefit and that of potential investors
• Demonstrably smart technical decisions which show that your tech leadership is both capable of prudent engineering decisions and ready for future scalability requirements

Why do I need one?

There are many reasons why you need an MVP, but foremost in your mind should be to:

• Establish credibility and feasibility as a technical product
• Focus efforts on getting something even slightly usable into the hands of actual users as soon as possible, so that you can gather vital feedback
• Show that your founding team can operate together to produce a plausible product that’s true to the vision of the organisation..
• ..and therefore to attract investment and interest at the earliest possible stages
• Get automation and continuous delivery in place as early as possible

MCBH Cloud Software’s unique blend of Agile, Product and Tech skills will take you there. Please get in touch to find out more: contact@mcbh.co.uk.

About the Author

I’m Mark Henwood, a skilled and experienced technology leader with an extensive Agile delivery background who has personally led many complex software projects to timely and successful outcomes across sectors including early startups, scale-ups, global household names and central UK government. Please feel free to reach out to me on LinkedIn.