From Output to Outcome: Driving Cultural Change in Product Teams

"Agile’s original purpose was not cultural enlightenment. It was building better software. Working software over documentation. Faster, more reliable delivery."

And that is exactly why Jay thinks we are stuck.

Because most teams have become proficient at shipping. They did not necessarily get good at delivering value.

Jay threads two quotes through his talk to reset the room’s focus. The first, via Marty Cagan, is the reminder that the best companies do not just deliver software. They deliver value that changes customer behavior. The second, from Jez Humble, is even more explicit: winning is about outcomes, not outputs, solving real problems for real people.

This is where Jay lands his critique. Agile helped teams learn to ship features quickly and reliably, but many organizations turned that capability into the goal. Speed became the metric. Shipping became the winner. Teams started optimizing for output, and once you are in that loop, it is very easy to mistake activity for impact.

He throws in the number that many people in the industry quote: somewhere between 50 and 80 percent of features fail to create meaningful customer value. He is careful about the range, because it varies by company, but the direction is clear. Even when delivery is flawless, value can still be missing.

Jay’s argument is not that Agile failed. It is that Agile solved a different problem, and now we have a new one.

Why this matters to him

Jay has been building digital products for close to two decades, and for the last ten years, he has been working in the messy overlap where research, design, and agile delivery collide. He has been trying to help organizations shift from feature factories into learning organizations. The case he shares is one of his more recent transformations, and he frames it with the line everyone knows, even if no one can prove who said it first: culture eats strategy for breakfast.

He treats it less like a meme and more like an operating constraint. You can have a strategy. You can have OKRs. You can have a beautiful roadmap. If the culture rewards output, you will get output. If the culture punishes uncertainty, you will get certainty theater. If the culture treats “build this feature” as the entire job, the team will stop asking why.

When Jay joined his organization about a year and a half ago, that was the reality. There was “the business,” and there was “tech.” Business requested features. Tech delivered them. The core measure of success was predictable: did we ship on time?

No questions asked.

Purpose that actually connects to the work

Jay is clear that the team's purpose was not imposed top-down. They built it through co-creation. The wording they landed on is strikingly human: solve people’s problems through collaboration and a human-centered approach to create a sustainable world for us and future generations.

He calls out something many companies miss. Corporate missions often exist at a level that feels abstract to delivery teams. In their case, the company's mission was to be carbon neutral by 2035. That is a strong goal, but a customer service product team can struggle to see how their daily work connects to it. A team-level purpose creates a bridge between the corporate ambition and the practical work.

The values they chose were equally telling: empathy for customers and coworkers, curiosity about market and users, collaboration, trust, innovation, and impact. These are not decorative words in his story. They were chosen to correct real gaps. If trust is missing, naming trust as a value is a way to make the absence discussable.

A structure that makes outcomes a shared responsibility

Jay then moves from purpose to structure. The old setup was siloed: business had its goals, product had its metrics, design and tech had their own measures. In that environment, everyone can succeed locally while the customer experience fails globally.

So they reorganized around a cross-functional value stream. At the core sat a product manager, engineers, and a designer for customer-facing products, aligned in the same team. Around them sat an extended team: data analysts, solution architects, developers, and DevOps. Above, but not separate, sat business stakeholders like marketing, sales, and customer experience.

The key change is not the org chart. It is the ownership model. They planned quarterly OKRs together. They stopped measuring design success separately from business success. Metrics like CSAT, churn reduction, conversion increases, operational efficiency, and cost-to-serve became shared team outcomes. Jay’s subtext is that you cannot ask teams to care about outcomes while measuring them on output. The measurement system is the culture.

Ways of working that prioritize problem framing

Jay is careful with the word “process.” He knows people flinch at it. But he argues that process is necessary, and in this transformation, process was the bridge between purpose and execution.

Their approach starts with problem framing and opportunity framing. Not “what feature should we build next,” but “what problem is worth solving,” “how big is it,” and “what would value look like.” He describes their method as a tailored, opportunity-solution-tree style approach that helped the team quantify problems and avoid the trap of simply pulling the next ticket.

Then he introduces the discovery delivery loop they implemented. Discovery and delivery were not treated as separate phases that throw work over a wall. They ran together, with cross-functional involvement throughout. Discovery itself had three phases: insights, ideation, and validation. Data analysts and researchers brought quantitative and qualitative input. The team translated insights into hypotheses. Those hypotheses were validated through research and experimentation. The output of the system did not feature. It was learning.

Jay repeats this idea because it is the hinge of his whole talk. If you want to innovate, the differentiator is what you learn about your customers, how quickly you learn it, and how widely that learning spreads.

Redefining success so people can actually change

Jay knows that culture change does not happen on a quarterly deadline. If you set aggressive business KPIs and expect instant outcomes, you create panic. Panic drives teams back to the old habits: ship more, faster, just to prove progress. So they redefined success in a way that reduced fear. He uses a SpaceX line he loves: every rocket failure gets us closer to Mars. It is not a celebration of failure for its own sake. It is a celebration of learning that reduces future risk.

They made a simple equation explicit: learning equals success.

Success could come from shipping a feature, but only if they measured it and understood its impact. Success could come from a research effort that disproves an assumption. Success could come from an experiment that failed, as long as the learning was captured and shared.

To make that real, they rewarded knowledge sharing. People were encouraged to present learnings in all hands, including the failures, not just the wins. They also rewarded the process through performance management: how many discoveries did you initiate, how much research did you trigger, what did you validate or invalidate?

In other words, they rewarded the behaviors that create outcomes, not just the deliverables that look like progress.

What rewarding failure looked like in practice

In the Q&A, someone asks the question everyone is secretly thinking: what does rewarding failure actually look like?

Jay’s answer is refreshingly concrete. They offered small rewards for people who presented a failure in all hands, because people were hesitant to stand up and say, “We tried this, and it did not work.” Once they signaled that sharing a failure was valued, people started doing it, and other teams avoided repeating the same mistakes.

It is a small intervention, but it changes the social risk. When it becomes safe to share what did not work, learning scales.

Balancing learning with quality

Another question challenges the learning narrative: what if teams pursue learning at the expense of quality for users?

Jay pushes back on the false tradeoff. Learning does not mean chaos. Teams still ship features. The difference is that they do not ship and immediately sprint away to the next backlog item without measuring, reflecting, and adjusting. If you do not measure, you are not learning. If you do not learn, you are just producing.

His point is subtle: the enemy is not delivery. The enemy is unexamined delivery.

The results he could share

Jay says he cannot show all the numbers, but he does share one meaningful outcome from the transformation. They had a financial goal to reduce the operational cost and bring down the cost to serve customers. After piloting the approach, particularly with the customer service team using their problem framing and discovery delivery methods, they exceeded the target by 28 percent.

Jay uses that result carefully. It is not “look at the magic process.” It is “this is what becomes possible when teams have purpose, shared outcomes, and the cultural permission to challenge requests and learn fast.”

The real takeaway: outcomes are a culture, not a KPI

By the end, Jay’s story lands in a place that feels both obvious and hard.

You cannot KPI your way out of an output culture.
You cannot roadmap your way into curiosity.
You cannot demand outcomes from teams you measure on shipping.

The shift from output to outcome is cultural. It starts with a shared purpose that feels real at the team level. It becomes durable when the structure aligns incentives around shared goals. It sticks when teams have a repeatable way to frame problems and validate solutions. And it survives when success is defined as learning and impact, not only delivery.

Jay ends with a practical invitation. Pick something small from his playbook: co-create a team purpose, align OKRs cross-functionally, measure outcomes together, celebrate learning publicly, and reward the behaviors that create insight. Cultural change is a long game, but it is not abstract.

It is built, one reinforced behavior at a time.

Want to watch the full talk?

You can find it here on UXDX: https://uxdx.com/session/from-output-to-outcome-driving-cultural-change-in-product-teams/

Or explore all the insights in the UXDX EMEA 2025 Post Show Report: https://uxdx.com/post-show-report