Outcomes Over Output

High-Level Overview: Key Arguments and Goals

Critique of Feature-Driven Development: Teams are trapped in building features (outputs) without knowing if they create value, leading to wasted effort and "feature factories" that ship constantly but fail to move business metrics.

Redefining Success Metrics: Success should be measured by outcomes (changes in customer behavior) rather than outputs (features shipped), connecting team work to actual business results.

The Problem with Traditional Roadmaps: Feature roadmaps create false certainty and rigid commitments to solutions before understanding whether they will actually work.

Outcomes as the Better Goal: Giving teams outcome-based goals (desired changes in customer behavior) instead of output-based goals (specific features to build) creates focus, eliminates needless work, and enables experimentation.

Experimentation and Learning: Combining outcome-based targets with experimentation unlocks the true power of agile approaches, allowing teams to test hypotheses and find the best solutions iteratively.

The Three Levels of Goals: Impact (high-level business results), outcomes (changes in customer behavior that drive those results), and outputs (things we build). Outcomes sit at the perfect middle level for team goals.

Organizational Transformation Required: Successfully implementing outcomes over outputs requires fundamental changes in team structure, goal-setting, measurement systems, and leadership mindset.

Empowering Teams: Outcome-based goals give teams meaningful business objectives while providing freedom to experiment and find the best path forward.

Overall Summary

Joshua Seiden's Outcomes Over Output: Why Customer Behavior is the Key Metric for Business Success argues that contemporary product development is fundamentally broken. Teams build features constantly but often create no value, wasting time and resources on outputs that fail to move the needle on what actually matters. The problem is not that teams are incompetent but that they're being given the wrong kind of goals. Features are outputs (what we make), but what really matters are outcomes (the changes in customer behavior that drive business results).

The book makes a crucial distinction between three levels of goals. At the highest level are impacts: big business goals like increased revenue or reduced costs. These are too broad for teams to act on directly. At the lowest level are outputs: the tangible things teams produce like features or deliverables. These are easy to measure but don't guarantee value. In the middle are outcomes: changes in human behavior that bridge the gap between what we make and the business results we seek. An outcome is defined precisely as "a change in customer behavior that drives business results." This is the sweet spot for team goals.

By shifting from output-based goals to outcome-based goals, organizations can transform how teams work. Instead of asking "what features should we build?" the question becomes "what customer behaviors do we want to change?" This reframing eliminates the false certainty of feature roadmaps, acknowledges inherent uncertainty, and gives teams permission to experiment their way to the best solution. When combined with experimentation and iterative learning, outcome-based goals unlock team creativity, reduce waste, and ensure work actually delivers value.

The transformation is challenging but essential. It requires changes at every level: teams must be genuinely cross-functional with clear outcome goals and freedom to experiment; organizations must restructure around outcomes rather than products or channels; leadership must embrace uncertainty and trust teams to find solutions; and culture must value learning over certainty. The book provides both the philosophical framework and practical tools for making this shift, offering a path toward more engaged teams, better products, and greater business impact.

Part I: Understanding the Problem with Outputs

The Three Levels of Goals

Seiden introduces a critical framework adapted from the Program Logic Model. Impacts are high-level business goals like increasing revenue or market share. These are what executives care about but they're too broad for teams to act on directly. Outputs are the tangible things teams produce: features, products, campaigns. These are easy to measure, which is why organizations gravitate toward them, but outputs don't guarantee value. Outcomes are changes in human behavior that bridge the gap between what we make and the business results we seek. They answer "what do we want people to do differently?" Outcomes are the sweet spot: specific enough to guide action but meaningful enough to drive value.

The Feature Factory Problem

Most organizations manage by outputs, telling teams what to make rather than what to achieve. This creates what Seiden calls a "feature factory": teams cranking out features that may or may not matter. Several problems emerge. First, features don't guarantee value. You can build everything on the roadmap and still fail to achieve business goals because the features don't actually change customer behavior in desired ways. Second, output-based management removes team agency. When told exactly what to build, teams become order-takers rather than problem-solvers. Third, output-based roadmaps create false certainty, implying we know the solution before testing it.

Output-based thinking leads to problematic patterns. Teams measure success by velocity (how much they ship) rather than value (whether it works). Roadmaps become commitment devices rather than learning plans. Organizations optimize for utilization (keeping people busy) rather than outcomes (ensuring work delivers value). The result is wasted effort and frustration.

Why Managing by Impact Also Fails

Some organizations try to solve the output problem by managing to impact, asking teams to directly influence high-level metrics like revenue. While this seems logical, it creates different problems. Impact goals are too big and abstract for teams to act on effectively. A team can't directly control whether the company hits its revenue target. Impact goals also provide no guidance on what to actually do. "Increase revenue" doesn't tell a team whether to improve the product, expand marketing, or pursue new customer segments. Without the intermediate layer of outcomes, there's no clear path from team actions to business results.

The Power of Outcomes

Outcomes solve both problems. They're specific enough to guide action but meaningful enough to drive value. They connect what teams can directly influence (product changes, features, experiences) to what the business cares about (results, metrics, impact). Outcomes acknowledge uncertainty while providing direction. An outcome-based goal says "we want customers to do X more often" without specifying exactly how to make that happen, giving teams freedom to experiment.

Managing by outcomes creates focus by eliminating work that doesn't contribute to desired behavior changes. It enables experimentation because teams aren't locked into specific solutions. It empowers teams by giving them meaningful goals and autonomy. And it centers work on customer value rather than internal deliverables.

Part II: Finding and Using Outcomes

The Magic Questions

To identify the right outcomes, Seiden proposes two fundamental questions. The first: "What are the customer behaviors that drive business results?" This forces you to think about the connection between what customers do and what the business achieves. If your goal is to increase revenue, what customer behaviors actually drive that? More purchases? Larger purchases? More frequent purchases? Referrals?

The second question follows: "How can we get people to do more of those behaviors?" Once you've identified the behaviors that matter, the question becomes how to encourage or enable them. This is where team creativity and experimentation come in. There are often multiple ways to influence a behavior, and teams need freedom to explore different approaches.

These questions shift the conversation from "what should we build?" to "what behaviors do we want to change?" This reframing is powerful because it acknowledges that features are just means to an end. The goal is changed behavior, and features are hypotheses about how to create that change.

Mapping Outcomes to Customer Journeys

For complex products with multiple outcomes, Seiden recommends mapping outcomes onto customer journeys. This helps visualize where different behaviors occur and how they relate to each other. You can identify "booster" behaviors (things customers do that lead to success) and "blocker" behaviors (things that lead to failure or dissatisfaction).

Journey mapping also helps coordinate across teams. In many organizations, teams are structured around products (iOS team, web team) or channels (marketing, support) rather than customer experiences. This makes it hard to work on outcomes that span multiple touchpoints. A journey map makes these cross-functional opportunities visible.

Distinguishing Outcomes from Impact

A common mistake is confusing outcomes with impact. They're different and keeping them distinct is crucial. Impact is aspirational and high-level: "increase revenue by 20%," "become the market leader." Outcomes are specific behavior changes: "customers share purchases on social media," "users complete onboarding in one session."

The relationship is causal: outcomes drive impact. If you achieve the right outcomes (behavior changes), you should see movement on impact (business results). But focusing on impact doesn't tell you which outcomes to pursue. You need to work backwards: start with the impact you want, identify what customer behaviors would drive that impact, then set those behaviors as your outcome goals.

Part III: Experimentation as the Companion to Outcomes

Outcomes and Hypotheses

The natural companion to outcome-based goals is experimentation. When you're uncertain whether a particular solution will create the desired behavior change, treat it as a hypothesis to test. Seiden recommends framing hypotheses explicitly: "We believe that if we [make this change], then [customers will do this behavior]. We'll know we're right when we see [this measurable result]."

Thinking in hypotheses changes how teams work. Instead of debating which solution is best, teams design experiments to test different solutions. Instead of spending months building features, teams build small tests to learn quickly. Instead of launching and hoping, teams learn and iterate.

Redefining MVP

Seiden tackles a common misconception about MVPs (Minimum Viable Products). Many teams think MVP means "version 1.0" or "the first release with core features." This leads to teams building elaborate first versions and calling them MVPs. Seiden corrects this: "An MVP is NOT version 1.0 of your product. An MVP is an experiment designed to test a hypothesis."

The key word is "experiment." An MVP is the smallest thing you can build to learn whether your hypothesis is correct. Sometimes it's just a landing page. Sometimes it's a manual process that simulates the intended experience. The point is learning, not launching. This redefinition changes expectations. MVPs should be fast and cheap to build. You should be able to run multiple MVPs in the time it would take to build "version 1.0." And you should expect most to fail or teach you something unexpected.

The Build-Test-Learn Cycle

Experimentation creates a continuous cycle: build an MVP, test it with real users, learn from the results, then repeat. This cycle should be as fast as possible because speed enables learning. The faster you can test ideas, the more you learn and the sooner you find solutions that work.

This cycle changes the question teams ask. Instead of "what should we build?" the question becomes "what could we do to deliver value early?" This question assumes uncertainty, acknowledges the need for learning, and prioritizes speed. Teams start looking for the quickest, cheapest way to test whether their hypothesis is correct rather than the most complete solution.

Part IV: Organizational Transformation

The HBR.org Case Study

Seiden includes a detailed case study of Harvard Business Review's digital transformation. HBR.org faced a common problem: teams were organized around products and channels (website team, app team) rather than around customer experiences or outcomes. This structure made it hard to coordinate on initiatives that spanned multiple touchpoints.

The transformation required restructuring teams around customer segments and outcomes. Instead of an "iOS team" responsible for the app, HBR created cross-functional teams responsible for specific outcomes like subscriber retention or new user acquisition. These teams had the skills and authority to work across channels to achieve their outcomes. The case study illustrates that outcome-based transformation requires structural change, not just mindset change.

Structural Barriers to Outcomes

Many organizational structures implicitly prioritize outputs over outcomes. Common problems include siloed teams organized by product or channel, output-based incentives that reward shipping features, rigid roadmaps that lock teams into planned features regardless of learning, and functional specialization that prevents cohesive cross-functional teams.

Requirements for Transformation

Successfully transforming to outcome-based work requires changes at multiple levels. At the team level, teams need to be genuinely cross-functional with all necessary skills. They need clear outcome-based goals, freedom to experiment, and accountability for results rather than delivery.

At the organizational level, structures must align around outcomes or customer journeys rather than products. Incentives must reward outcomes achieved, not features shipped. Roadmaps must become flexible learning plans rather than rigid delivery schedules. And leadership must embrace uncertainty, understanding that detailed long-term plans are impossible in environments of high change.

At the cultural level, the organization must value learning and experimentation over certainty. Failure must be reframed as learning. Speed must be prioritized over perfection. And customer value must trump internal efficiency.

The Three Rules

Seiden distills the transformation into three rules:

1. Give teams outcomes to achieve, not features to build: Stop telling teams what to make and start telling them what customer behavior you want to change.
2. Give teams the freedom to experiment: Teams need autonomy to try different solutions, to fail fast, and to pivot based on learning.
3. Hold teams accountable for outcomes, not outputs: Track whether teams are achieving their outcome goals, not whether they're shipping features on schedule.

These rules sound simple but require profound changes in how most organizations operate.

Part V: Practical Implementation

Writing Good OKRs

Seiden addresses OKRs (Objectives and Key Results), noting that while the framework sounds good in theory, many teams struggle to write them well. The common mistake is reverse-engineering current work into OKR language rather than using OKRs to think critically about goals. Teams write key results like "launch feature X," which are just outputs disguised as OKRs.

The solution is to express key results as measurable customer behaviors (outcomes). Instead of "launch new checkout flow," write "increase checkout completion rate from 45% to 60%." This automatically creates a well-formed OKR because it focuses on results rather than activities.

Practical Shifts

Seiden encourages several practical changes. Name projects by outcomes rather than outputs ("Increase Homepage Conversion by 10%" instead of "Homepage Redesign"). Audit existing features and kill "zombie features" that provide little value but add complexity. Consider wiping the backlog clean and starting fresh with outcome-based goals rather than maintaining lists of hundreds of outdated feature tickets.

Conclusion: Empowerment Through Outcomes

Joshua Seiden's Outcomes Over Output concludes with a message about empowerment. When organizations give teams outcomes to achieve rather than features to build, they unlock creativity, motivation, and real results. Teams move from feeling like order-takers to feeling like problem-solvers. They're measured by whether they create value, not by how much they ship. They have permission to experiment, to fail, to learn, and to find the best solutions to real problems.

This shift requires courage from leadership. It means giving up detailed control and accepting uncertainty. It means trusting teams to find solutions rather than dictating them. It means changing how success is measured and rewarded. But the payoff is immense: teams that are more engaged, products that deliver real value, and organizations that can adapt to continuous change.

The book is ultimately optimistic about what's possible when organizations embrace outcomes. While critical of current practices (feature factories, rigid roadmaps, output obsession), it offers a clear path forward. The path requires fundamental transformation, not superficial changes, but it's achievable. In a world where digital services are never done, where change is constant, and where uncertainty is the norm, output-based thinking no longer works. Outcomes provide a better way, acknowledging uncertainty while providing direction, empowering teams while maintaining accountability, and ensuring that work actually delivers value.