Preparing for the upside

By Aakash Dharmadhikari

The introduction of the Minimum Viable Product or MVP was a reaction to a cognitive bias commonly seen in startups: Our tendency to disproportionately anticipate success.

In the past, most early stage products would prepare for success by:

• Building some features for each definition of success (speculate breadth first)
• Cherry-picking one definition of success and build all possible features for it (speculate depth first)

This would typically result in slow execution, poor product market fit and high experimentation costs, often leading to failure.

Minimal is not necessarily Viable

In the process of avoiding the trap of speculation, the MVP has inadvertently created an equal and opposite trap: One of failing to consider what the product needs in order to grow fast when it hits early product-market fit.

All too often, defining an MVP becomes exclusively about minimising the number of features. While this is a necessary goal, it is not a sufficient goal because it ignores the true goal of iteration — success.

Because most MVPs fail, most conversations on the topic revolve around managing and iterating through these failures. But that does not mean we ignore the possibility of success entirely. The point of an MVP, being data driven and iterating continuously is, after all, finding success.

Going lean and then losing the game because of unexpected success would be… ironic.

For most classes of tech products, there are a common set of levers that we pull to increase scale post early traction. While one shouldn’t implement any of these upfront, in the event of success, your product should be primed to do so cheaply and quickly.

Here are some of the most commonly discussed ones:

• add channels to increase addressable market size
• scale digital marketing while constantly optimizing CAC
• try different pricing strategies
• A/B tests to optimise the product experience
• for a mobile product, move existing users to the latest version of the app to test response to a feature

To caveat, these examples are merely illustrative. Every class of product will share a well understood set of common growth levers, so please substitute as needed.

Change Without Change

Let’s talk about a simple framework to keep a product primed for rapid scaling while also keeping it minimal.

There are only two ways to prepare a system for change without actually changing it.

• Configurable: A predefined set of parameters whose values when changed, change the behavior of the system.
• Pluggable: A predefined set of contracts that allows subsystems to be added or replaced, without any change to the overall system.

The cost of creating configurable systems is lower than that of a pluggable system and so is the flexibility. Also, different classes of systems can use one or both of these approaches to create flexibility cheaply. Let’s take few examples:

Pricing Rules for an app based transport system (configurable & pluggable):

• Minimal: completely hardcoded pricing rules and rule picking logic that requires code changes and deployments for any change.
• Configurable: Pricing rules are fixed. Criteria to pick a pricing rule for a booking (location on time of day, for example) are fixed. Parameters influencing calculations within a rule are configurable without any code change or deployment.
• Pluggable: Pricing rules have a standard contract, allowing them to be added or replaced with a minimal code change (via, say, an internal library or a pricing micro-service). Criteria to pick a pricing rule for a booking remain fixed. A side-effect is the overall system should not need a deployment, only the subsystem in question.
• Future Ready: Both rules and rule picking criteria are fluid, typically implemented via a rules engine or machine learning.

Integrating analytics and attribution systems (pluggable):

• Minimal: Uses a single analytics system and adding anything else will require code changes across the codebase.
• Configurable: Not Applicable
• Pluggable: Analytics integration is abstracted out into a separate subsystem which supports adapters. Adding a new analytics library requires code change only in a single place (adding a new adapter), making it easy to add Crashlytics, AppsFlyer, FB App events SDK or any other analytics tool as needed.

Driving mobile app updation (configurable):

• Minimal: Apps have to depend on users updating from the app store at their leisure.
• Configurable: Add a feature that allows users to be targeted by app versions, OS versions or user ids to send notifications containing incentives to upgrade. Keep the reason and reward for update configurable, so it can be used in case of security issues, new product launches or just performance improvements.
• Pluggable: Not Applicable

There is a whole spectrum of how configurable or pluggable we want our systems to be. That’s a subjective call that you need to take based on your business and the cost of creating that flexibility. YMMV.