You Fixed Delivery. You Didn’t Fix Direction.
Two earlier pieces in this series made connected arguments. The first, Product Ops is Necessary but Insufficient on Its Own, argued that improving delivery execution rarely fixes a value realization problem on its own, because the real constraint is usually upstream: in the operating model, and specifically in how the business allocates capital and accountability. The second, Decision Friction is a System Design Problem, argued that even the right operating model will seize without governance: the deliberately designed system of decision rights, evidence flows, and shared visibility that connects strategy to execution.
Both are necessary. Neither, on its own, is sufficient. There is a third layer that neither piece addresses. It sits above the delivery system, above the governance, above the operating model itself. This piece is about that layer.
One note on timing. If your delivery system is still unpredictable, slow, or structurally unreliable, fixing it is the right priority, and the arguments in the earlier pieces apply directly. This piece is for a different inflection point: organizations where delivery is working, governance has tightened, and value realization still isn’t moving in proportion to the investment made in transformation.
The Diagnostic Gap
At some point in this version of the problem, a difficult conversation happens that nobody quite knows how to have.
Your transformation has taken hold. Teams are shipping consistently. The operating model has been redesigned around stable product teams with clearer ownership. Governance is more deliberate. By most available measures, the hard work is done.
Value realization still isn’t moving.
The temptation is to return to the delivery system: tune the cadence, clarify decision rights, improve feedback loops. This is the wrong diagnosis. The constraint isn’t inside any of those systems. It sits upstream of all of them, in a question the transformation was never designed to answer: which capabilities should this business be building, and why?
That question is harder than it sounds, particularly in large enterprises. Many operate in B2B markets or at one remove from the end customer, where products have been in maintenance for years. Capability investment has long been driven by feature requests, client commitments, or internal efficiency agendas rather than systematic inquiry into where the market is actually moving. In many of these organizations, researchers, designers, and product managers believe it is their job to answer this question. Their work is not integrated into the investment decisions the business is actually making. Customer evidence sits in product teams. Capability priorities are set at the portfolio level. And the two rarely meet in a way that materially changes where capital flows.
This is a structural condition, not a capability gap. Designing the integration is the fix. Hiring better researchers or running more discovery sprints won’t close it.
What the Delivery System Presupposes
Teresa Torres makes an argument I find compelling: that Discovery and Delivery are co-equal disciplines. Delivery asks whether we can build something and sustain it. Discovery asks whether we should, and whether it will create value.
Enterprise transformation has, rightly, invested heavily in Delivery. Not from ignorance of this duality, but from necessity. The delivery system in most large organizations is genuinely broken: unpredictable, expensive, and slow to surface what isn’t working. The predictability gains from fixing it are real, and the operating model changes that enable reliable delivery are worth making on their own terms.
But the systemic implication of Torres’s framing is that organizations haven’t yet accounted for the other side of that duality with anything close to the same rigor. Organizations have invested in building the thing right without matching that investment in building the right thing. That asymmetry isn’t incidental. It’s the structural condition that produces the value realization gap.
And the consequences become visible in competitive markets. Smaller companies and startups, unburdened by the delivery complexity that large organizations have spent years trying to solve, are often closer to the market precisely because they can’t afford not to be. They don’t have the luxury of a capability brief that was written two years ago and never revisited. They build, observe, and adjust, and in doing so they compound capability advantage in the segments where the large enterprise has stopped looking closely. By the time the enterprise notices the gap, the startup has the differentiation and the customer relationship. The delivery system the enterprise spent years perfecting executes at scale in a direction the market has already moved on from.
The Integration Layer
The gap between customer evidence and capability design doesn’t close itself. Closing it requires specific work. In a well-designed organization, that work sits with the Portfolio layer.
Portfolio teams are positioned to do something neither product teams nor executives can do in isolation: integrate the market signal with the strategic frame. Product teams are closest to the customer evidence. Executives own the investment thesis. Portfolio is the interface between them. It translates what the market is telling the business into the capability priorities the business should be betting on, and directs those priorities back into the delivery system as an explicit brief. This is precisely the kind of evidence-informed, hypothesis-driven prioritization that the prior pieces argued governance should enable. The operating model creates the structure for it. Governance creates the forum. The integration layer is the evidence that makes the decision real rather than assumed.
But this work requires more than positional access. It requires craft.
Discovery, done with rigor, is not a matter of collecting customer requirements or documenting feature requests. It’s a discipline of investigation: understanding the pain points and gain creators that matter to customers at root cause, not just the surface-level asks that get escalated. A customer who asks for a faster report is often telling you something about a decision they need to make more quickly, or a process they are trying to stop managing manually. The surface request isn’t the problem. The underlying need, and whether solving it creates something the customer cannot easily find elsewhere, is what makes the evidence strategically useful.
That distinction matters because it connects directly to the investment question. Discovery evidence only becomes valuable to the business when it is filtered through a commercial lens: not “would customers value this?” but “would solving this create monetary value: through differentiation, retention, or the ability to serve a segment the business is currently locked out of?” Customer benefit and business value are not the same thing. Conflating them leads to products that are genuinely useful but commercially irrelevant, and to capability investments that are hard to justify when the business case is examined.
This is where human-centered design practice, user research, and product management discovery converge on the same function: producing the evidence that grounds Portfolio-level investment decisions.
What Good Discovery Signals Look Like
You don’t need certainty to change direction. But you do need evidence that points clearly enough to justify the investment. Four signals that do:
Five different customers. The same root problem.
One complaint is noise. The same underlying issue surfacing across five separate segments, in different forms, from different people, is a pattern worth acting on. It usually means the market has moved in a direction you haven’t designed for yet.
They say one thing. They do something else.
When customers build workarounds, use a competitor for one function and you for another, or quietly abandon features: that’s your real discovery data. Behavior tells you what surveys and roadmap requests don’t. Trust the workaround over the stated preference.
“Good enough” has become their dealbreaker.
Some capabilities have quietly become the price of entry in a segment you already serve. Being behind on those is a retention risk, not just a product problem. The urgency is different, and so is the investment case.
A smaller competitor is growing in a space you’ve ignored.
This is usually the last signal to arrive, because it requires looking outward. A startup winning in your market with something you don’t offer has found a customer need you deprioritized. That gap has a commercial price tag, and it compounds while you’re looking inward.
The weight each signal carries will vary by market maturity and where your organization is in its transformation. All four are worth scanning for regularly, not just when value realization is already in question.
The test across all four is the same: if you addressed this, would it create monetary value for the business, not just a better experience for the customer? Customer benefit matters. But it doesn’t make the business case on its own. Discovery done well produces both.
When the Signals Point Somewhere the Business Doesn’t Want to Go
The four signals above assume discovery is pointing you toward better investment within your current direction. Sometimes it doesn’t. Sometimes the evidence points somewhere the business isn’t organized to go: a market your existing customers don’t represent, a capability set your current products don’t support, a direction that requires cannibalizing what you’ve built rather than extending it.
Consider a business that built a platform to serve an entire market, including competitors of its own core business. The platform generates real revenue. The customer relationships are established. But the discovery evidence is increasingly clear: the highest-margin, highest-growth application of the same capability is not the external market. It’s the parent business itself, which has been systematically under-served because the platform was designed for neutrality rather than for the use case where it would create most value. Exiting or deprioritizing the external customer base isn’t a complicated technical decision. It’s an organizational one: abandoning certain revenue in pursuit of a higher-margin direction, and acknowledging that years of serving the broader market were quietly constraining the business’s most valuable capability.
This pattern repeats in different forms across industries. A financial institution that offers its payments infrastructure to competitors because the external revenue looked attractive, while its own products run on a slower, less capable version of the same thing. A media business that has optimized its technology platform for third-party publishers, at the cost of the features its own editorial teams most need. In each case, the discovery signal isn’t ambiguous. The margin profile, the growth trajectory, and the strategic coherence all point in the same direction. What makes it hard is not the evidence. The system was designed around the customers it currently has: the existing contracts, the account relationships, the revenue forecasts it has built around them.
This is structurally uncomfortable in ways that have nothing to do with the quality of the discovery. Large enterprises are, by design, optimized for the customers they already have. The investment thesis, the governance, the sales motion: all of it runs toward the customers who are already paying. Discovery that challenges that direction isn’t just inconvenient. It’s hard to act on, because the system wasn’t designed to fund investment against its own base.
This is also, frequently, how disruption takes hold. Not because the enterprise missed the signal; often they didn’t. It’s because the signal contradicted what the business had organized itself to do. The startup found the gap precisely because they weren’t carrying the weight of an existing customer base that needed to be protected.
The honest implication of taking discovery seriously at the enterprise level is that the evidence will, periodically, point not to a gap within the current model but to a question about the model itself. Whether the existing customer base is the right one to optimize for. Whether the margin on that base justifies the opportunity cost of not pivoting. Whether the capabilities being invested in are becoming commodities while a higher-value direction goes unexplored.
Discovery is working exactly as it should. The harder question is whether your organization, with its governance, its investment logic, and its appetite for cannibalization, is designed to act on it.
The organizations in this position, with delivery working and value realization lagging, are not failing at execution. They are succeeding at the wrong thing.
The diagnostic question for your organization is not how to make the delivery system more effective. It is: what is the delivery system actually delivering toward? And who, in your organization, is formally responsible for ensuring that answer is grounded in evidence rather than assumption?
If you cannot name that clearly, not as a function but as a practice with methodology, rigor, and a deliberate integration point into the capability decisions the delivery system executes, the delivery system is a precision instrument pointed at a target that someone chose without enough information.
The discipline that closes that gap isn’t new. It is the oldest idea in product development. What is new is the recognition that it belongs not just inside product teams, but inside the investment logic of the enterprise: the upstream input that makes every downstream decision better.
This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.