There is a common theme that we have seen when discussing innovative projects. It goes something like “We don’t need an MVP, we know what we want from our existing solutions”. There is a variation on this which goes “We need an MVP and the budget is well beyond £100k”.

Typically, in the background, there is a significant pressure to build the solution – from a commercial and operational basis, and due to general frustrations in the business. Sometimes, there are one (or more) well connected software business development teams working their sales process, and adding to the organisational pressure to ‘get going’ on the new project.

So, what is it?

In this context, the requirements for the system have either been documented, or will be documented from the experience of the Product Manager or CEO - depending on the size of the business. Frequently, the business will point at a number of existing applications and explain that the solution will be a single, simpler version of what they use currently, and it’s these solutions that drive the written requirements.

It is these requirements that are then used to progress the tendering process (if the innovation is to be developed by a 3rd party), or to scope the size of the team (if to be developed internally).

Basing innovation projects on written requirements (alone) is a significant risk

Given most innovative projects are delivered by teams who know the perils of waterfall, but that understand the frustrations of the ‘looseness’ of agile, a sort of hybrid solution is creeping in. In particular, where there is a need to engage a 3rd party and defined a project budget. In these cases, functional specs, or a variation of them, are used to describe requirements. Sometimes storyboards are collated as an alternative to specify the working solution.

Once developed, the work is tendered (or an internal team is built) to deliver this solution.

The challenge of this approach is that it leads to inefficiency, cost-overuns and frustrations. This can be tracked back to the requirements documents which have a number of challenges:

• The documents are rarely read, reviewed, and understood by everyone that needs to read them
• You don’t what you want until you see the solution
• The requirements are incomplete – and lose the interconnectedness of ideas

The documents are rarely read, reviewed, and understood by everyone that needs to read them

The purpose of the requirements document is to create a shared understanding of what’s required, why and how it’s to work (from a business context). This makes for a complex document that requires time to understand and review. Given the lack of resource in most companies and the competing demands for attention, there is a risk that requirements documents get 'speed-read', rather than reviewed. As a consequence, they don't tell the full story.

If storyboarding has been fully completed, and the storyboards have been developed with the right team, and do include visual elements as well as written requirements, then some of the risks can be reduced. However, if this isn’t the case, or storyboards are carried out as an initial phase of the project, they come too late - once budgets have been agreed, contracts have been awarded, and costs of change are high.

You don’t what you want until you see the solution

As highlighted in our piece (“How hard can it be”), you won’t know what all of what you want until you see it. It is very rare for a solution to be a direct replica of an existing system. There will be improvements that have been identified and this new solution may well combine the functionality of several existing systems.

The user flows will be different and when these flows are built and tested, opportunities will be identified that change the requirements.

Interconnectedness of ideas

In Amazon, Jeff Bezos is famous for his hatred of PowerPoint slides. In his original email about this ( see Ram Charan and Julia Yang’s book – The Amazon Management System) he says:

“Well-structured, narrative text is what we’re after, rather than just text. If someone builds a list of bullet points in Word, that would be just as bad as PowerPoint… PowerPoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.”

In digital projects, the stories (or features) are the equivalent of the bullets in a PowerPoint presentation – they’re not wrong or bad, they’re just not the full story. They are not good at articulating how the different features fit together, nor what opportunities the solution might generate when several stories are put together.

The MVP is your insurance policy

The original objective of the MVP is to enable an innovation find product market fit. It’s developed to get a full and detailed understanding of customer wants and provides the solutions that lead to further sales.

We think that an MVP still applies to these larger / more mature innovation projects. The objective is to build a working version of the intended solution that captures the functional requirements of a bigger build. In the diagram below, we have highlighted the typical failure reasons of software projects that can be mitigated with the MVP.

Forbes council analysis : An MVP can help with the areas highlighted (our annotations).

The cost of the MVP will be significantly lower than the bigger implementation, and has a number of benefits:

• It allows for more accurate pricing than requirements documents alone
• It will reduce the number of iterations required of the subsequent (high budget) scale project
• Changes in the MVP development are far quicker to deliver than changes on a large project.
• It will reduce more expensive ‘day rate’ 3rd party charges that occur on bigger projects
• It will provide stakeholders much earlier visibility of the solution – enabling improved buy-in
• It will improve cash flow (deferring the larger investment)

There are situations where the majority of the big budget development is on handling non-functional requirements (including performance, security, capacity, reliability). In these cases, an MVP may not be required.

There are technical benefits of an MVP

There are a number of technical decisions that need to be made in the development of the solution. These decisions tend to have significant downstream impacts to the flexibility and cost of change over time.

For example, the MVP allows for the data model design to be developed and tested in a live environment. Equally, it allows for the user journey to be understood, and the core architecture to be developed and assessed.

Much of this learning (if correctly developed) can be passed into the bigger build solution development. If re-factoring is required, it will be much simple and less expensive to address this at the start of the solution of the scale implementation.

Conclusion

In summary, a typical MVP should be under £50k investment. There will be exceptions depending on the solution requirements, however for many innovation projects that require a scale implementation, this cost will be more than covered from reduced cost overruns and reduced delays in developing the solution.

Take aways

Here are a set of questions to help trigger your thinking about whether you need an MVP ahead of a larger spend implementation:

• Are there any new features, flows that you want that don't currently exist?
• How much of the big build budget will be spent on redefining your requirements during the project discovery phase?
• What proportion of work effort will be invested on non-functional requirements?
• Would you investors gain confidence if they could see the MVP iteration of the bigger project?
• Will developing the MVP increase total project length?