Incremental development
Minimum Viable Product (MVP)
This is a definition made popular by Eric Ries on his book "The Lean Startup" — a great read for anyone involved in creating new products. His own definition is as follows.
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Despite the name, it's not exactly about creating the smallest product possible but rather about building the minimum amount of functionality, using the least amount of iterations, that will allow us to validate what fit the people that will use it.
Planning for and building an MVP adds some overhead and one might be tempted to ignore this step. In reality, there are a number of good reasons for not implementing an MVP — the main one being that the product is already simple by design. However, in most cases, the learnings that can be obtained from a well planned MVP will definitely be helpful when expanding the product later on.
Building an MVP isn't exactly the same as building a product using small iterations.
Building Incremental Software
While building an MVP, one wants to make sure that every decision is informed. It's pointless to keep progressing towards a result that might be void of value. To tackle this challenge, efficient teams have been leveraging build-measure-learn feedback loops.
The Build-Measure-Learn feedback loop is a technique that helps you to realise when you've got things wrong, before it's too late to turn initial failure into eventual success. In practice, the model involves a cycle of creating and testing hypotheses by building something small for potential users to try, measuring their reactions, and learning from the results. The aim is to continuously improve your offering so that you eventually deliver precisely what those that will use your product want.
Plan — Obviously, before you can build anything, you need to plan for it. This is the moment when initial hypothesis are formulated, based on a more or less informed discovery phase.
Build — Once the hypothesis is formulated, the team can start creating the MVP.
Measure — By adopting an iterative approach, you create several opportunities to test the initial assumptions and understand if they are being successful.
Learn — With each iteration, there's a new opportunity to learn if the product has acceptance, proving its success. If you find that it doesn't, it's time to try to understand why and pivot in a different direction.
The lesson learned may come in different sizes, from small pivots to having to completely toss a few features. This shouldn't deter the team from moving forward and keep trying to find what will work. Evidently, the greatest cap to this process is the available runway — timeline, funds or both. You have to learn to adapt your cycles to the available runway.
Planning for the available timeline
People often start a new challenge trying to estimate how much time it will take. This approach, while innevitable when it comes to assess what resources are needed, has the potential to push a team away from practicing an iterative attitude towards the problem.
A better approach is to understand how much time is available for development. Knowing this, you should scope your solution towards that reality, setting the necessary deadlines along the way so that one epic doesn't take the whole timeline. Doing this allows the team to more easily understand progress and forces them to keep making decisions along the journey that will shape the product into what reality allows.
As a consequence, if the team is able to work efficiently and the timeline allows, you can expect to deliver a complete product in a timely fashion. On the other hand, if unexpected delays happen or if the team finds out that the initial goal was too optimistic, then you can rest assured knowing that the best decisions were made so that the team delivers the best possible, most relevant result.
Last updated
Was this helpful?