Minimum Viable Product

Understanding the MVP

How To Specify an MVP

Igale are recognised as one of the best Agile software companies in London. Our team has worked with clients over the past 30 years to build minimum viable products (MVPs) as quickly as possible, allowing the earliest deployment of new offerings.

For many years Igale and our staff have practiced iterative development, the approach has changed names over the years, however over the past 10-15 years the term Agile development has become widely adopted and accepted.

Typically at the conception stages of a custom software development project, the formulation of the detailed requirements can be a burdensome and often time consuming exercise. To fully analyse, scope, obtain agreement and deliver a full specification can lead to high costs and at the point of conception is not always possible.

One of Igale’s key principles is working to understand the smallest piece of functionality that will provide value to an end user and enable the team to gain feedback to shape further development. What will form the MVP will be unique to each product but getting something to market early enables clients to get important feedback and iterate towards a solid product that’s more complete in its vision.

Chair Tall

What Is Absolutely Necessary?

Chair 2

By thinking about the required features or use cases that are absolutely essential for the product to function, we can start to shape the key features of the MVP. A common mistake at this point is forgetting that the product still needs to be valuable, meaning that it should be usable, understandable, and meet a need of the market. I.e. it should be a minimum valuable product as well as a minimum viable product.

Our London based development team has all the skillsets required to bring a product from conception to reality, and with 3 SaaS businesses founded by the team, we’re able to advise and guide on what is really needed to get to market quickly.

Our team challenges clients to cut the scope vertically (number of features) and horizontally (complexity of features) whilst ensuring that the business remains viable.

Conversely, understanding the broader scope of what the product will need to do, and what the future vision for it is will enable our solution architects to ensure that the underlying technology will adapt to this vision as time and budgets permit. Knowing where a product is going to encounter bottlenecks in the technology stack is a crucial exercise when defining the MVP!

Planning the MVP is critical, and Igale work with our clients throughout the Sprint 0 process to do just this. As the project moves into development sprints we work with the product owner to support their decision making, again focusing on delivering valuable functionality as quickly as possible.

The MVP Buzzword

The whole Igale delivery process is centred around delivering tested and working products that meet their test criteria and adhere to the agreed definition of done. With some client projects we have had an MVP ready for market in as few as three sprints.

The challenge that many people face when defining the MVP is that it’s one of those buzzwords that anyone and everyone can make their own definition of. There is inherent risk in defining the MVP, getting it wrong early can cost time and some capital, however delaying getting the product to market and getting feedback can cost a lot more!

Our experience in building MVPs that have gone on to become full bespoke solutions and are business critical for our clients has enabled us to iterate and refine our process with a fail fast mentality. This ensures that our clients get maximum value for money and feedback on their idea from the people that will use it as quickly as possible!

To find out more about how Igale can help you with developing your next MVP contact us today.

Stool