When Outcomes Become Commitments

The shift from outputs to outcomes was supposed to change everything.

Organizations recognized that shipping features didn’t necessarily create value. Products could ship on time, on budget, and to specification — and still fail. Customers ignored them. Behaviors remained unchanged. Business performance stagnated. The problem wasn’t execution. It was assuming that building something guaranteed it would matter.

So the question changed. Instead of asking “Did we build it?” organizations began asking “Did it work?” It was an important evolution — in theory. In practice, many organizations adopted outcome language while retaining familiar expectations of certainty.

The trap is not that organizations care about outcomes. The trap is that they try to manage outcomes with the same certainty they once applied to outputs.

That distinction is worth sitting with, because it changes what the rest of this argument is about. The shift toward outcomes began with an important realization:

Features are not benefits; they are assumptions about how benefits to the user might be achieved.

Shipping functionality doesn’t guarantee that customers will buy it, adopt it, trust it, or improve their lives and work because of it. The intended benefit may never materialize. Outcome thinking acknowledged this uncertainty — features became hypotheses rather than evidence of value.

What didn’t change is organizations’ tolerance for the uncertainty that acknowledgment implies. Teams are still asked to forecast, commit, and deliver with confidence. Only now they’re being asked to commit to discoveries — to promise, in advance, benefits that can only be understood through experimentation, testing, and iteration. The outcome becomes something to guarantee rather than something to investigate.

Organizations often pursue certainty downstream, seeking confidence in a predetermined solution, rather than investing upstream in the learning required to know whether they’re solving the right problem in the first place.

When Outcome Language Hides Output Thinking

In my work, this shows up first in language—a team fluent in outcomes still planning as if the answer were already known. This is what happens when outcome language outruns organizational behavior: the vocabulary updates before the operating model does.

Discovery becomes difficult to justify — research reads as too time-consuming, too expensive, too uncertain. Customers get replaced by internal proxies. Testing becomes validation rather than learning. Opinions become evidence. Product definition prescribes solutions rather than frames problems. The vocabulary changed faster than the operating model.

Customer requests became requirements. Requirements became specifications. Specifications became commitments. The benefits those commitments were meant to create were increasingly assumed rather than investigated.

Discovery exists precisely because the relationship between features and benefits is uncertain. Research can invalidate assumptions. Prototypes can produce unexpected results. Customer feedback can reveal that the original problem statement was incomplete. That’s how understanding increases — even when confidence drops, at least temporarily. That’s precisely why discovery exists.

If we already knew the answer, experimentation would be unnecessary.

The Bridge Builder

In a village beside a dangerous river, leaders became increasingly effective at rescuing children swept downstream. One leader ventured upstream to understand why the children were falling in, and discovered they were crossing on unstable rocks. She proposed building a bridge instead.

This time, the story isn’t about recognizing bridge builders. It’s about understanding why organizations repeatedly favor rescuers instead.

Leaders set an ambitious target: “Reduce drownings by 25 percent this year.” The rescuers scaled up. Response times improved. More volunteers were recruited. The village tracked progress carefully.

Meanwhile, the bridge builder had questions:

  • Why are the children crossing here?
  • Would a bridge solve the problem?
  • Is there another route entirely?

These questions slowed momentum, complicated planning, and introduced uncertainty. So they went unanswered. The village hit its rescue target. The river stayed just as dangerous to cross.

The drowning-reduction target was an outcome. But the moment it became something to hit rather than something to understand, it started functioning like an output — a number the rescuers could commit to and control, in a way that “should we even be building a bridge” never could. That’s the certainty trap again: an outcome metric managed with output-era confidence, at the expense of the question that might have made the metric unnecessary.

Discovery Under Pressure

Organizations often experience discovery this same way. Research disrupts certainty. Testing challenges commitments. Learning introduces ambiguity. These activities improve understanding, but they threaten systems optimized for predictability — so discovery gets constrained.

Design is increasingly asked to refine commitments rather than shape them. As certainty takes precedence over discovery, design moves downstream — from framing problems to refining solutions that have already been chosen. The Design Cycle of Doom quietly re-emerges. Not because organizations dislike design, but because they struggle to reward uncertainty in pursuit of better understanding.

Reframing Discovery as Risk Reduction

The trap closes when discovery is treated as a threat to certainty. It opens when discovery is reframed as the earliest form of risk management available to the organization.

That reframe isn’t semantic — it changes which conversation discovery belongs in. Risk management belongs in planning. It belongs in portfolio review. It belongs in the conversation between product leadership and the business. When I position discovery that way—as a tool that reduces the probability of investing significantly in the wrong direction—it stops competing with delivery timelines and starts looking like protection for them.

In practice, this means I bring assumption inventories into planning conversations, not just research findings. Before a team commits to a quarter of work, I want us to be able to name the three or four assumptions that, if wrong, would invalidate the entire investment. Those are the assumptions worth testing first. Not every assumption needs a research study—some need a prototype, some need a single customer conversation, some can be resolved by looking at behavioral data that already exists. The goal is to sequence uncertainty reduction against resource commitment, not to delay delivery indefinitely.

I’ve also changed how discovery gets reported. “Here is what we learned” reads as interesting but optional. “Here is what we now know, here is what we still don’t know, and here is the risk profile of proceeding without knowing it” is an input to a decision. That shift—from insight delivery to decision support—changes how leaders engage with it.

The organizations that do this well share one trait: they’ve stopped treating the confidence of a commitment as a measure of planning quality. High confidence in an unvalidated direction isn’t a sign of rigor. The better signal is whether the team can name what it still needs to learn—and has a plan for learning it before the cost of being wrong becomes unrecoverable.

What We’re Actually Committing To

The promise of outcome thinking was never that organizations would get better at predicting the future. It was that they’d get better at learning from it. Outcomes were meant to encourage exploration, not become another form of commitment managed with old expectations of certainty.

When organizations treat discoveries as deliverables, certainty takes precedence over learning, and the systems designed to encourage adaptation start suppressing it instead.

Perhaps the question isn’t whether we should focus on outputs or outcomes. Perhaps the more important question is: what exactly are we committing to?

Features can be delivered. Benefits often have to be discovered. Confusion begins when organizations expect one to behave like the other.