Product Diversification

At some point, single-product companies start saying the same sentence: “We depend too much on one product.” It is a legitimate worry. The second sentence is where things go wrong: “So let's build something new.”

Diversification is mostly justified as risk reduction, and in practice it raises risk instead. Team and attention are fixed. A new product splits the thin attention the main product already had.

When you need it

The signals show up on the customer side first. Your customers do a job right next to your product, one you do not serve, using another tool or a spreadsheet. The same missing piece keeps appearing in support tickets and sales calls. Expansion revenue in your base has plateaued: price increases and extra seats no longer produce meaningful growth. The main product's market is structurally bounded, meaning that even in the best case growth ends when you have filled your share.

It is too early when the main product still struggles with activation and retention. Diversification does not fix those problems, it hides them. A new product looks bright in its first months because it has no history to compare against. The team drifts toward it, and the main product's problems grow a little more.

What most teams miss

Diversification is not “selling other things.” It is solving the same customer's next problem. The difference is whether you have to build distribution from zero for the new product.

Proximity is not a side effect of diversification, it is the requirement: either the new product's customer or its channel must already be yours today.

The well-known framework here, the Ansoff matrix, shows it: selling a new product to an existing customer is far less risky than selling a new product to a new customer. In one you have one unknown, in the other two. If the new product needs a new customer and a new channel, you are actually founding a second company.

A familiar example from a large company: Amazon opening its internal infrastructure to outside customers, which, in Amazon's own telling, became AWS. It is more accurate to see that as externalizing a capability it was already good at than as diversification in the loose sense. Proximity came from competence. That is a common pattern in successful diversifications: the new product is something the company already does well, opened to a new customer.

The second thing teams miss is the fear of cannibalization. They worry the new product will weaken the main one. In some cases it should, because if you do not do it, a competitor will. What matters is separating controlled cannibalization from plain loss.

The playbook

1. Map the workflow around your product

Talk to twenty customers and ask: what do you do right before and right after using us, and with which tools? Those two directions are your list of adjacent jobs. These conversations are not for collecting ideas, they are for tying ideas to evidence.

2. Screen candidates with three filters

For each candidate ask: does the customer spend money and time on this problem today? Can it be sold through our current channel? Does it lean on something our team already knows? Candidates that pass all three go on the shortlist. An idea with two “no” answers is out, however attractive.

3. Sell the offer before the product

Before writing code, take a pre-registration, a pilot or a paid early version to a slice of your base. Paid intent is far more valuable data than “that would be interesting.” Set the threshold in advance: for example, do not start building until a set number of customers agree to pay.

4. Launch with a small, separate team

Do not shift capacity from the main product team. Build a team of two or three with clear ownership and its own goal. Protecting the main roadmap matters as much as investing in the new product. Without that separation the new product loses to the main one every sprint, and nobody ever made that a decision.

5. Design packaging and price up front

Will the new product be sold separately, bundled, or added to a tier of the main product? The answer shapes its fate. Selling separately means a new purchase decision and friction. Bundling raises adoption but makes its revenue harder to see. Whichever you pick, write down how you will measure it beforehand.

6. Tie the scale or shut-down decision to a date

Decide in advance what number at six months means you continue and what means you close. Shutting down a failing side product is harder than launching it in most companies.

What to measure

• Adoption among existing customers. Shows whether the proximity assumption holds.
• Revenue and product count per customer. Tells you whether cross-sell really lifts ARPA.
• Change in main-product retention. The critical lagging indicator of whether the new product is hurting the old one.
• The new product's own purchase intent and conversion. A leading indicator, visible before development cost.

Pitfalls

Diversifying to spread risk. If the risk is dependence on one customer segment or channel, a second product sold to the same segment does not solve it. Name where the risk really sits.

Starting with too many products, too early. Every new product means support, documentation, pricing and sales training. If the team half-knows each product, customers end up unhappy with all of them.

Covering main-product problems with a new one. A launch while retention is weak feels like growth, but it is like filling a leaky bucket.

Launching without a price. “Let them use it first, we'll look at money later” hides for months whether the product creates value at all.

Start this week

1. Book half-hour calls with five customers and ask: “What do you do right before and right after using us?”
2. Score the adjacent jobs you hear on proximity, willingness to pay and channel fit, and pick a single candidate.
3. Write a one-page offer and a price for that candidate, and take it to your ten closest customers as a pre-registration or pilot.