Wedges and Control Points in Product Strategy

7 min read Original article ↗

Several years ago, a CEO asked me a simple question after I demoed our product:

“This is interesting, very useful.
But tell me—what do you own?”

I didn’t have a good answer. I was leading product, and I couldn’t clearly articulate what position we occupied—what part of the value chain we actually controlled.

That moment stuck with me. Over time, I’ve come to see it as the difference between wedges and control points.

But the harder truth was this: I had made a major career decision without ever asking that question of myself.

A wedge is a focused, narrow product—fast to build, easy to understand. Most successful products start here. A control point is what customers come to depend on: a position in the value chain that’s hard to displace, often because it sits at a critical integration, data layer, or workflow chokepoint.

The transition between them is where most companies stall. It’s easy to double down on what’s working. It’s harder to ask what the market will structurally rely on—and build toward that.

Durable companies aren’t defined by what they build next, but by what they come to own.

Today, AI is compressing the wedge lifecycle. If discovery and delivery are both getting faster, a narrow useful product has less time before it’s commoditized or copied. That makes the question of control points more urgent—not less.

A control point is not a feature, a product, or even a category.

It is a position in a value chain that others must depend on to create, deliver, or capture value.

If you disappeared, other companies’ workflows would break.

Control only exists in the context of a value chain—a sequence of how value is created and delivered. Control points can sit anywhere in that chain. What matters is whether others must go through you.

A company doesn’t become powerful by being useful. It becomes powerful by becoming difficult to route around.

Wedges help you enter a value chain. Control points determine whether you can shape it.

There’s a common trap: if we build something useful enough, we’ll eventually own the market. But usefulness is not the same as structural position.

Five misconceptions worth naming explicitly:

Being in the architecture is not a control point. Components can be swapped. Control comes from governing how the system operates, not just participating in it.

Contractual lock-in is not a control point. Real power is voluntary. If customers stay only because switching is painful, your position disappears the moment they have a real choice. That’s friction, not authority.

A large customer base is not a control point. Reach is distribution. It is not structural position in a value chain.

“Land and expand” is not a control point. You can scale a wedge across an entire enterprise, but simply growing the footprint of a replaceable utility does not grant you power.

A system of intelligence is not a control point. Insight is valuable—but if the system only provides ad hoc reports, and doesn’t govern actions, it can be bypassed.

This generalizes: the system type doesn’t determine your position. A system of record can be a passive repository. A system of action can be a dumb pipe. What makes any of them a control point is whether others must pass through it to operate—not what type of system it is.

Control is not about being present. It’s about being unavoidable.

Consider a simple value chain:

Data Origin → Access / Connectivity → Application / Experience → End User

Mint and Plaid both operated in this chain—but at very different layers, with very different outcomes.

Mint built a beautiful consumer product that showed users exactly how they spent their money. I still miss Mint.com. But it remained a destination: useful, yet dependent on underlying systems it didn’t control.

Plaid took a different path. Its early attempts at downstream applications were less successful—but that work exposed a deeper issue: the real bottleneck wasn’t user experience, it was data access. So Plaid moved into the middle of the chain, owning connectivity and solving the messy bank integrations no one else wanted to touch.

Mint provided the report. Plaid provided the pipe.

Plaid’s control point is not unassailable, but it illustrates the dynamic clearly. Products compete for attention. Control points become embedded in how the system works. One requires winning customers repeatedly. The other compounds.

You see this pattern across industries:

  • The hypervisor didn’t just virtualize compute—it became the layer that allowed companies to define entire data centers in software.

  • Identity systems didn’t just manage access—they became the enforcement layer across applications.

  • Payments APIs didn’t just move money—they became the default foundation for new financial products.

  • Agricultural platforms aren’t just collecting farm data—they’re becoming the layer that governs how inputs like seed, fertilizer, and water get applied.

In each case, the company started with a wedge—a focused, useful product—and then moved to own a layer others depended on. The control point then did the heavy lifting: new products launched with less friction, adoption came faster, and competition became structurally harder.

A wedge requires a new battle for every customer. A control point becomes a launchpad.

A control point is not a permanent position—it’s a durable one. Value chains evolve, and the layer you own today can be commoditized by a shift in architecture, infrastructure, or buyer behavior. VMware held the hypervisor layer for years before cloud reshaped the chain around it. Earning a control point buys leverage and time. Holding it requires watching what the chain is doing.

At this level, control point strategy and business strategy are the same thing.

The hardest part of this isn’t identifying a control point—it’s investing in one when the wedge is still producing results.

The wedge produces the eggs. The control point is the goose.

The wedge drives near-term results. The control point builds the underlying asset. Those are often in tension:

  • Focus only on the wedge: you maximize short-term output but risk starving the system that creates it. A useful product without a control point becomes a commodity.

  • Invest in the control point: you step back from immediate wins to build interoperability, governance, and structural position—foundations that make future growth compounding rather than linear.

This is also a bet. Control points are constrained by what’s technically feasible, what your organization can deliver, and what customers are willing to trust you with. You’re not just investing—you’re making a directional call under uncertainty.

That’s what makes this a leadership question, not just a product question.

To test your position, ask:

If a competitor launched a product that was 2x better at half the price tomorrow, would a significant portion of your customer base actually move—or only at the margins?

  • If yes: you have wedge advantage. You are competing on utility.

  • If no: you have control point advantage. Leaving would require customers to change how they operate.

In the wedge phase, you compete on features. In the control point phase, you compete on gravity.

Here’s what makes this hard operationally: these two states aren’t sequential—they’re parallel.

Teams will always be shipping features. That work doesn’t stop. But leadership has to operate at a different altitude simultaneously—asking not whether each feature is strategic, but whether the company’s aggregate momentum is moving toward a position in the value chain it can own.

Most product organizations are disciplined about the first question. Very few are disciplined about the second.

Product strategy isn’t just about what you build next. It’s about what position you are moving toward—and whether the decisions you’re making are bringing you closer to owning it.

Wedges get you in. Only control points determine whether you ever win.

Now that we’ve defined what a control point is conceptually, the next questions are: what types of control points actually exist in modern tech value chains, and how do you maneuver yourself there? That is what I’m working on next.

If you’ve seen this dynamic play out—at a company you’ve built, invested in, or competed against—I’d like to hear how it looked from the inside.

Discussion about this post

Ready for more?