In Three Market Expansions, the Product Was Never the Hard Part

I have worked on multiple market expansion opportunities, and over the past couple of years I have had a number of conversations with product leaders planning one. Expansion tends to get discussed as though it were a single kind of decision, and usually as a decision about what to build. In my experience it is not. In at least three of mine the product could do the job. What blocked each one, and what had to change for it to work, was different every time.

That matters, because most expansion reviews start by asking what needs to be built. In practice that is the last question worth asking, and asking it first sends the team off to add capability nobody was waiting for.

Here is what actually stood in the way and what worked, three times.

The product sits in the middle and is rarely the thing that blocks an expansion. What blocks it is somewhere around it: the cost to a customer of switching, a story the seller was never equipped with, or an overlap with something the company already sells.

One: the customer had defined the product differently than we had

I worked at a company that sold communications equipment to service providers. Our modular platform was deployed widely across customer networks, successful by any measure, installed in large numbers.

We decided to build the next generation product. Newer technology, genuinely better capability, and a completely different form factor. It was positioned as the successor to the existing product. We put a good amount of resources into building it from scratch, and there was real excitement come launch day. The customers liked what it could do for them, but commercially it did poorly. Not because it was worse, but because of what adopting it required.

Customers had deployed the existing platform at scale. Taking the new product meant physically pulling out equipment that was working, and then solving for a footprint that did not fit where the old one sat. We had framed the decision as an upgrade. The customer experienced it as a rip and replace, funded by them, to solve a problem they did not have.

The question customers kept asking was not whether the new capability was good. It was why they could not simply have that capability on the platform they already owned.

So we built it that way. The new generation’s capability went into a module that fit the existing platform. That was harder than it sounds, and the constraint was physics rather than software: the module had to run newer, heavier functionality inside the power envelope an older platform was designed to supply. It worked. Adoption became adding capability to equipment the customer already had, rather than replacing infrastructure.

The lesson: we had defined the product as the box. The customer had defined it as the installed base. Their switching cost, not our build cost, was the number that decided the outcome, and nobody had put that number on a slide.

Two: the product was ready and the story was not

I worked on an enterprise product sold to security buyers. The narrative and collateral were built for that audience, and that motion worked.

We also had another buyer motion available, through sellers who spent more time with infrastructure teams, often inside the very same accounts. That team carried the product too, with an almost identical story. The second route produced very little, and for a while the read internally was that those buyers did not want it.

That was not the problem. The problem was that an infrastructure-oriented seller had been handed a security story to tell an infrastructure-oriented buyer. The seller could not tell it credibly, because it was not their language and not their quota, and the buyer had no reason to care about it framed that way. The product was not failing in the second market. It had never actually been offered there in terms that market used.

What we changed had nothing to do with the code. We built an infrastructure storyline for it, repositioned the collateral against the broader operational environment the buyer already owned, and designed sales training for that seller rather than adapting it from the security track.

To be precise about what this was not, because it is easy to overclaim: it was not a new route to market. The route existed, the sales force existed, and they already carried the product. What was new was that we finally equipped it. After that, one product served two audiences, and both could scale.

A route you have named but not equipped is not a route. It is a line on an org chart.

Three: the market had already decided, and the obstacle was internal

I worked on a site-level security product inside a larger portfolio. The industry was converging on an idea: at smaller sites, security and connectivity could live in the same appliance. Some competitors were already shipping their products that way. Customers could see the appeal of one box instead of two. Traffic patterns had shifted toward SaaS and cloud services, which made the combination sensible rather than merely convenient.

The product already had most of what was needed. The build work was real but bounded: bring the capabilities together, and design the experience an administrator would actually use to run both jobs from one place.

The genuine obstacle was not in the market. It was that we had a separate connectivity portfolio of our own. Shipping the security product into that job meant competing with ourselves, and that is the kind of conflict that quietly kills a proposal without anyone having to argue against it on the merits.

What made it resolvable was that the market had already made the call. Once you accept that customers are going to buy a converged edge device from someone, the internal question changes shape. It stops being whether to allow the overlap and becomes how to rationalize the portfolio so both businesses capture share instead of one blocking the other.

The answer we landed on ran in both directions. Security capability went into the connectivity product, and connectivity capability went into the security product. The management experience stayed consistent across both, so a customer’s choice of appliance did not change how their team worked day to day.

The expansion was a portfolio decision wearing a product decision’s clothes.

Telling which one you are facing

In these three expansions, there were three binding constraints: the customer’s switching cost, the story and enablement around a route, and a portfolio boundary inside the company. Product capability was not the limiting factor in any of them, though in all three it would have been the easiest thing to go and work on.

If you are looking at an adjacent market now, these are the questions worth asking before anyone opens a roadmap.

Does the adjacent market already run something of yours at scale? If so, look at switching cost before you look at features. Form factor, footprint, migration path, and what has to be removed to make room. A better product that requires an expensive change is a worse offer, and customers price it that way even when they cannot articulate why.

Do you have a second sales motion that is underperforming? Before concluding the market is soft, check whether that motion was equipped or merely assigned. Different story, different collateral, different training, built for the seller who has to carry it. If none of that exists, you have not tested the market yet.

Is the category converging? If the market is already coalescing around a combined product, your real work is probably internal. Find the portfolio overlap and rationalize it deliberately, because if you do not, the market will resolve it for you, and it will resolve it in favor of whoever shipped.

And the one worth asking in all three cases: what would have to be true for this to fail? In every one of these, the answer was known to somebody in the building before the work started. It just was not the person writing the plan.

The pattern

The product is rarely the constraint. What has to change around the product almost always is, and it shows up in a different place each time: in the shape of what you ship, in the story you equip a seller with, or in the boundary between two things you already sell.

An expansion plan that starts with what to build has usually skipped the diagnosis. It is worth spending the first two weeks working out which of these three you are actually in, because the answer determines whether this is an engineering project, a go-to-market project, or a portfolio conversation with your own leadership.

Previous post: The AI Cost Stack Nobody Maps, on the recurring costs an AI roadmap commits you to and the three decisions they force.