Consider the following scenario, you run a small software company and a potential customer is willing to put a deposit down on a purchase which will be completed when the team builds a specific feature. Most would say that this is an obvious “yes.” Getting people to pay for your software is a notoriously hard problem.
In reality, the answer is not so obvious. Every product decision must weigh the relative value between the potential customers that would find the feature appealing versus those that would prefer the product function differently. While this customer may be willing to pay today, adding the feature could shut the door on dozens of customers willing to pay tomorrow.
While counterintuitive at first, the idea follows logically. At the beginning, before the first line of code, customer discovery meetings, and hires, there is nothing but a clean slate. Every human on the planet, every api, and every interconnected device is a potential customer of whatever idea is created. As soon as the first product decision is made, such as “we’re going to solve this problem,” or “we’re going to build a mobile app,” the size of the potential market shrinks by an order of magnitude.
While this is clearly the case when it comes to the major decisions like the high-level solution and delivery mechanism it also applies to the smaller day to day decisions. One concrete example is whether an application should integrate with another system and how easy the configuration should be. There are plenty of customers who would appreciate a one-click connection to their CRM, calendar, bug tracker, or other system of record. However, there are also many customers that are against the idea of their data being at risk in multiple places. Before making a decision, both sets of customers are addressable, yet after the choice is make one set of the market is lost.
These two graphs illustrate the principle. The graph on the left shows the impact over time of 10 product iterations. While only minimal progress is made, the size of the potential market shrinks rapidly. The graph on the left zooms in on the final 4 iterations, showing that even at smaller numbers the risk is still there.
Inevitably, the product owner has to make a decision and pick which part of the potential market to address. Products that do not have features are unable to solve problems and are inherently useless. The real focus of any product team should be the addressable market, which for a long period of time will remain significantly smaller than the potential market. Nor is a small potential market a critical problem, as many small markets have the post passionate and loyal customer bases.
However for a nascent product it is still necessary to consider the impact of the potential market especially when juxtaposed versus an immediate revenue opportunity. Prematurely putting a small cap on the market size in order to service one good looking contract has sunk more than a few products and companies. To avoid this trap, it is imperative to understand this trade.
