Build to last… or build to trash: Technical decisions for MVPs

The question that businesses should be asking whenever they start on a new digital product  is, “How much time and effort do we put into building the various components of our product?” The answer to this depends on how certain you are that what you are building will do what you want it to and reach the objectives you have for it. For this article, I want to focus on the decisions around how to build a minimum viable product and how these decisions are different from those you would make in mature product. The MVP development cycle has two phases, each of which is essential to creating a successful product:

• Build to trash

• Build to last

The first is  the MVP itself. The second is what is needed once the hypothesis has been proven. Both are essential in the development of successful digital product, but both have very different foci and require different attitudes in the product and development teams.

Build to trash

As Tim Bichara discussed in his article, The critical things you need to know about building an MVP Part 1,an MVP is designed to test a hypothesis, such as pension fund managers want to see side-by-side performance data for hedge funds. By its nature, the hypothesis is a guess. It may fail, or it may succeed beyond our wildest dreams, we just don’t know. As a result, the focus in an MVP is on how to get the product in front of customers in order to see if:

• They even want your great idea

• They will use your product the way you think they will

• The features you thought were important are what the customer thinks are important

Because of the focus here is on getting the product out for users to test, developers need to find the easiest and fastest way to put together the necessary functionality. Of course, that means what is built is not the best it can be, in terms of scalability, maintainability or security.

The focus of a MVP is not to build a good product, it is to build the minimum needed to gather enough data so that the team can prove or disprove the hypothesis. This leads to a technical preference for:

• Reuse, not bespoke build: Using already existing tools, code and skills to save time and cost

• Immediate need, not future-proofing: Build the functionality to a point where it can be tested, not for the success we hope it will have

• Simplicity over bells-and-whistles: Build the basic functionality, test it, then use the feedback to determine what else to add

Because the MVP is a test, sometimes the test fails and everything that has been done has to be dumped. As a result, there is no point in investing too much time and money in coding the product to perfection. Technical decisions need to be made with one eye firmly on the budget. “How much will we burn on this round of development?” The idea is to go through the MVP process a few times to find the product fit. As a result, each round needs to be cheap enough to ensure there can be a next round.

This means that the business and the technical teams need to be in a constant dialog, each checking that the decisions about what to build for the MVP, and how to build it, are in line with the aim of the MVP: get a product out to test a hypothesis. The focus is to find the product that will resonate with customers and be successful, not to build this product.

Build to last… at least for a while

One of the rather unappreciated aspects of development, and of human nature, is the concept of inertia. With digital products, it comes in, not when the MVP fails, but when it succeeds. Your hypothesis is correct and there are eager customers out there. You start rolling out the product backlog, getting traction and preparing for your IPO… all on the code base of the MVP.

The product is not scalable. It can’t be refactored because no one documented anything and, anyway, there is no time to stop and rewrite everything. As a result, technical debt piles upon technical debt. Here, technical debt is the shortcuts and compromises that the developers made to get the MVP to market. This debt is acceptable when the focus is on testing a hypothesis. Once the hypothesis is proven, however, these compromises can cripple the product.

What is needed is the next phase of product development, consolidation. Customers want the features we thought they did and more want them then we expected. The technical part of the product then has to be re-examined. Is it sustainable? Can it support the number of users we have and project we will have? Is the code and environment secure? The team can now start looking to the future… but not too far. If there are too many unvalidated assumptions made, time and money will be wasted on unnecessary development. Even at this stage, we are still faced with uncertainty, which leads us back into the test and consolidate cycle.

Share: