Audience Overlap Is Not a Product Expansion Strategy

A company can understand its users very well and still have no right to serve their next need.

That distinction matters as more companies widen their ambitions. A dating app considers becoming an everything app for its community. Chip companies push their advantage beyond the chip itself. Car manufacturers look at robots as another source of future profit. Industrial companies apply lessons from automating physical environments to AI deployment.

These moves can look similar on a strategy slide. They are not. Some are based mainly on audience overlap: we already have these users, so perhaps we can sell them more things. Others are based on a capability that transfers: we already know how to solve a difficult class of problem, so perhaps that knowledge gives us an advantage elsewhere.

I trust the second argument far more than the first.

The same customer can have two needs that require completely different products, trust models, distribution methods and support operations. A person using a dating product may also want events, travel services or financial products. That does not mean the company is equipped to provide any of them. Access to an audience lowers the cost of asking for attention. It does not automatically lower the cost of delivering value.

A transferable capability is more concrete. A company experienced in automating mines has learned something about introducing technology into safety-critical, messy physical operations. A hardware company that controls important parts of its technical stack may be able to extend into adjacent infrastructure. The new market is still uncertain, but the company brings something more useful than a mailing list.

In product reviews, I would therefore challenge expansion proposals with three questions. What do we do unusually well today? Which part of the proposed product becomes meaningfully easier because of that capability? What evidence would show that customers value the resulting advantage rather than merely trying the new feature?

The second question is the one teams often skip. They can describe customer demand and market size, then jump straight to a delivery plan. The missing connection is why this company should win. If the answer is brand recognition, an existing login or the ability to place a banner in the current product, the case is weak. Those advantages can generate initial traffic while hiding poor retention and expensive operations.

This is also why I prefer small tests in the real operating environment over polished expansion narratives. Recent product discussions have returned to experiments in actual restaurants, outcome-first engineering and the risk of moving complexity towards the customer-facing part of the system. The shared lesson is that an adjacent product should be tested where the difficult work happens, not where the presentation looks strongest.

For a software company entering services, that might mean manually fulfilling a narrow version of the service before building the platform around it. For an AI feature entering a complex workflow, it might mean testing whether the team can handle exceptions reliably, not just whether the normal path produces a good result. For a community product adding transactions, it means learning whether users trust the company with the transaction itself, not counting clicks on an announcement.

The measurement should remain narrow. Expansion already creates organisational noise: more teams, more dependencies and more reasons to add metrics. A large dashboard can make a weak proposition look busy. I would rather choose one behavioural outcome that proves the new product solves a repeated problem, then add operational measures that expose the cost of doing so.

There is nothing inherently wrong with becoming a broader company. But breadth should be earned through demonstrated capability, not inferred from the number of users already inside the building. Knowing who someone is does not mean you are qualified to solve everything they need.