When MVPs aren't the most valuable: how to approach markets with few early adopters
Exploring early adopters and initial use cases in industrial software
Coined by Geoffrey Moore in a book by the same name, “Crossing the Chasm” is a popular startup trope. The act of crossing the chasm refers to a startup’s ability to sell to customers beyond early adopters.
Early adopters (green in the left chart above) are eager users of new products. They are less risk averse, less price sensitive, and quicker to adopt. Many times, they'll use a product before it's finalized.
On the other hand, the majority (orange in the chart above) is more cautious. They prefer complete and reliable products. They move slower and need to see clear benefits before adopting.
Startups must acquire customers in the majority to achieve meaningful market share (right chart above). Failing to do so limits a startup's opportunity size.
Moore's framework is based on the technology adoption lifecycle. A normal distribution (bell curve) illustrates user adoption across a market.
Market risk tolerance impacts early-adopter population size
In a “normal” market, early adopters represent ~16% of the market (one standard deviation). For example, in a market of 1,000 participants, 160 will be eager to adopt. Selling to the rest becomes much harder. See the middle chart below: normal market/zero skew.
If you have an abnormal market full of experimenters, there may be more like 200 or 300 early adopters. See the left chart below: risk-tolerant market/positive skew.
One example of this behavior is marketing. Marketers will adopt new tools that give them a leg up on the competition without a second thought. With such a large early adopter population, startups can iterate on product and go-to-market. As a result, they can move quickly in the early days. However, finding true product-market fit can be harder. I wrote about this in What happens when you over-index on momentum early
Other markets are risk-averse and have few early adopters. In the example of 1,000 participants, there might be only 10 or 20. This number of early adopters is not enough to experiment with the product and go to market. Building and selling get tough quickly. See the right chart below: risk-averse markets/negative skew.
I spend most of my time in these negative skewed markets as I invest in industrial tech. Think manufacturing, supply chain, construction.
Startups building in these markets must cross the chasm early in their lifecycle. Though it is hard for startups to serve these markets in early days, it becomes much easier for them to scale. In these markets, false negatives in product-market fit are frequent. (In positive-skew markets, false-positives for product-market fit are more frequent.)
The approach to building and scaling is different for positive-skew and negative-skew markets.
MVPs are for early adopters; everyone else wants a developed product
Another common startup term is “MVP” or minimum viable product. An MVP includes only the features necessary to meet the needs of early adopters. MVPs are only relevant in markets with enough early adopters to buy and use the product. Namely, in zero-skew or positive-skew markets.
However, in negative-skew markets, you may not have the chance to sell an MVP. At most, you may have a handful of development customers to help refine product vision.
In these cases, startups invest in building a full product from the start. Many times, startups build a single feature or product that solves a defined need. Eventually, they stack features until they have a full platform offering.
Introducing the use case chasm
Markets with early adopters must cross the chasm to capture market share. In markets with few early adopters, this chasm becomes irrelevant. Instead, markets with few early adopters cross the “product” chasm; from limited product scope to platform.
The user adoption curve compares user profiles to potential market penetration. The product adoption curve compares use-case profiles to available technology solutions.
The x-axis describes the frequency and criticality of any use cases.
The y-axis describes how likely someone go to the market and buy a product that will address their use case.
If a use case is standard, 90%+ of the use case can likely be facilitated by off-the-shelf software. However, if a use case is highly custom, only 10% of the requirements might be met by off-the-shelf software. In those cases, users might execute the tasks manually or choose to build their own software.
My first job out of school started with a project working on an ERP system for a large utility. The company use Oracle for most of its back-office functions. It's a robust platform but it can't do everything. For example:
We build infrequent and nonstandard use cases in-house. The utility had to track NERC training at a corporate level. Of all Oracle's customers, only a small percentage have this requirement. It wasn't worth their time to build it into the ERP. It wasn't a big enough market for another company to build a tracking system either. As a result, the utility did not buy a solution but rather built it in-house.
We use off-the-shelf software for frequent and standard use cases. The utility had a corporate HQ. Employees badged in and out of the building. When new employees joined, they needed badge access. This is a use case many companies have. The utility was able to use off-the-shelf software and integrations to manage this.
When functionality is too frequent and critical, we are skeptical of outsourcing. This utility had a unique set of rules for paying their people. Some of it was because of unions, some of it because of policies related to storms or overtime. Of course, paying people accurately is critically important. Accordingly, the company chose to build a process to calculate pay in-house. A vendor might be able to configure this process but the company did not want to “risk it.”
This dynamic is supply and demand related. If a use case is widespread and standardized, it presents a big market to any vendor. Technology providers are more likely to build for these large markets. And, companies are more likely to buy these good solutions versus build them.
If a use case exists for only one company or industry, the market might be less interesting to vendors. Depending on the complexity and frequency, companies may build in-house.
This is one of the reasons vertical SaaS is coming into its own these days. The thick middle of use cases (ERP, CRMs, other horizontal SaaS) are mature and competitive.
Preparing to cross use case chasm for negative-skewed markets
What a mouthful.
To review.
Negative skewing markets, like industrial tech, have limited early adopters. The user chasm doesn't apply.
Instead, they must cross the product chasm. Startups enter a market with a single product or feature and expand.
There are four approaches to crossing the product chasm. Especially for those with limited access to capital, it is important to choose the correct approach. Otherwise, founders can burn through capital making different attempts at the market. Or they can get stuck as a feature and never realize full market potential.
There are four approaches to market are disrupt, duplicate, extend, and expand.
Disrupt.
Startups begin with less functional, worse versions of current products. As the product matures meeting more customer expectations, the company moves up market. Clayton Christensen identified this strategy as disruptive innovation.
Duplicate.
When incumbents stop innovating, the market opens to new entrants. Startups build "2.0" solutions that are improvements on legacy solutions. The best time for duplication is during platform shifts. For example, the introduction of mobile.
Extend.
When a new platform reaches a sufficient market penetration, another market opportunity appears. Startups build on top of recently adopted technology to extend capabilities. For example, widespread smartphone usage allows for geo-fenced time tracking on construction sites. Accurate time tracking enables better project accounting and optimizations.
Expand.
Other startups go after the long tail of use cases. These products would otherwise fall into the "build" or "neither" category in a "build" v. "buy" decision. They benefit from limited competition. However, they face two major challenges. First, there must be a good reason to change behavior. Second, after the initial use case, the product must expand to reach any interesting scale. For example, any Excel app replaced by a workflow that “lands and expands” to become a system of record.
Of all the approaches, I find expansion is the most interesting but also the most risky.
Market shocks favor expansionary platforms
Expansionary startups must have a great answer to “Why now?”
For industrials and other negatively skewed markets, this answer must be perfect.
Otherwise, the gravity of the status quo will be too strong for these risk-averse buyers.
Three situations create conditions for new product adoption. The first two include changes in supply. In this case, supply is anything that completes a task. It could be anything from talent or internal tech capacity. The third relates to abrupt increases in demand.
Supply reduced.
The most prevalent example here is the retirement of skilled labor. When there are fewer workers either output goes down or knowledge lost. Assuming demand remains the same, the willingness to pay for output goes up.
In markets with highly-trained labor, the ability to hire more workers is limited. Instead, organizations turn to technology to increase workforce efficiency or to supplement it.
For example, none as abrupt as air traffic controllers. The FAA had to hire 7,200 controllers over the last five years in a total workforce of 11,000. (3,000 positions remain vacant.) The shortage of labor was a forcing function to upgrade safety and traffic systems. The FAA awarded a $350M contract to Lockheed Martin.
Supply expanded.
Sometimes a technical breakthrough happens and drives down the cost of a product. Or, the breakthrough allows the same tech to do a lot more. In both cases, the cost of a product relative to its value goes down and drives new adoption.
For example, utilities have become avid adopters of drone applications. In the first wave of adoption, drones replaced manual inspections of utility equipment. Using drones and imaging tech is safer, better, and cheaper (faster) than sending humans up a pole. Now, new capabilities such as BLOS or beyond-line-of-sight are increasingly approved. This increases drone use cases and tips the cost/benefit tradeoff further. Drones can do what small helicopters can, for example.
(We are seeing some examples of this today with creative uses of ChatGPT on an individual task level.)
Demand rises.
On some occasions, we experience dramatic rises in demand that leave companies in a pinch. In those cases, they are desperate for a solution, any solution that solves their problem. Sometimes that means turning to a new and unproven entrant. Other times they are willing to pay more, and in doing so create a margin buffer that attracts new entrants.
Beware, this shift is the riskiest to bet on as the market opening ends to exist for a limited period of time.
If elevated demand persists, fast followers may flood the market driving prices down. If the elevated demand does not persist, new entrants may lose the business they won in peak times.
To avoid getting caught in the whiplash, the new entrant must do two things well:
Create a business model sustainable in the best of times AND the worst
Create complimentary offerings that curry favor and stickiness with customers AND increase revenue/margins
If a new entrant does those things well, they will have lowered their cost of entry materially.
For example, when this doesn’t work, it looks like the freight tech market over the last few years.
When it does, it looks like Trusted Health. Trusted started as a marketplace matching nursing staff to augment demand. In parallel, they built a VMS (vendor management system) that became widely adopted and loved.
Startups can use market shifts to jumpstart product adoption and customer acquisition. However, they need to move beyond the initial use case to achieve scale and sustainability.
In essence, they need to cross the product chasm.
TL;DR
This framework applies to a subset of startups, primarily those:
Serving risk-averse “left-skew” markets (versus those with plentiful early adopters)
Focusing on crossing the product chasm (versus acquiring the early majority)
Choosing a disrupt, duplicate, extend, or expand approach to the market
Identifying market dislocations that provide an opportunity for unusual adoption
If this describes you*, the questions you should ask yourself include:
Are the conditions right?
What market transitions are providing tailwinds for platform adoption? Is it new regulations? Shifts in buyer demand or supply? Technology advancements?
Have I identified the best control point?
What is the best entry point to the market? What is my customers’ most acute unsolved pain point? Can I align my incentives with theirs to make adoption easy? Am I building on a product that enables me to own workflows or core data?
Do I have the capabilities to capture demand and build resiliency?
If my control point sets me up for market entry, what must I do to build on that advantage? How do I scale quickly, efficiently, and defensibly? What durability am I building into my product? Can I become the industry standard?
Companies borne of volatile market conditions are challenged with taking advantage of it. If they enter the market with the right control point, they will experience lower customer acquisition costs. If they have capabilities that enable them to cross the product chasm, they will create real scale.
Missing the mark on any of these vectors relegates one to a subscale existence.
But with great fundamentals here, the juice is worth the squeeze.
If you are working on an expansionary platform serving industrials, I would love to chat.
Great read. Thanks.
This was a fantastic read, Jackie. You covered so much so very well. Thank you.
We’re in a negative skew, highly risk-averse market (construction materials).
We Extend your ERP, but we’re primarily an Expansionary use case.
If you’re big enough, and CX matters… You’ve already built this for yourself.
If, on the other hand… you’re locked into legacy systems and don’t have the in-house IT to build it… We’ve got you covered.
SUCH a narrow use case (but don’t tell my founder 🤫)
Great, great read. Thanks again 🙏🏼