Thinking in Outcomes, not Features

Product teams often slide into dangerous patterns without realizing it. Feature factories prioritize shipping over creating value, measuring success by counting releases rather than tracking impact. The most damaging warning signs include:

• The absence of measurement. Teams ship features but never check if their work helped users or moved business metrics. They celebrate launches, then immediately move to the next project.
• "Success theater." Teams perform elaborate feature demonstrations but rarely discuss whether previous work achieved its goals.
• Rapid team shuffling. Instead of giving teams ownership over outcomes, feature factories treat developers like interchangeable parts. Teams get reassigned constantly, preventing them from seeing long-term impact. This reinforces that shipping matters more than results.^[1]

The distinction between outputs and outcomes fundamentally changes how teams work. Outputs are tangible things teams produce: features, designs, code, and releases. Outcomes represent changes in user behavior or business metrics resulting from those outputs.

Teams often confuse the two and end up chasing the wrong outcomes. For example, a team might expand into a new market but fail to measure whether the move actually increases revenue or customer adoption. In this case, the market launch is just an output, not an outcome, because its real impact on the business remains untested.

For instance, a team might expand into a new market but fail to measure whether revenue or customer adoption actually grows.

Building an Android app is an output. Increasing mobile engagement by 30% is an outcome. The app only matters if it drives the engagement change. Yet many teams celebrate shipping the app without measuring whether it achieved its purpose.

This confusion leads to wasted effort. Teams spend months perfecting features that users ignore. They build exactly what stakeholders requested but fail to solve underlying problems. Without focusing on outcomes, teams work hard while creating minimal value. Every feature must connect to the desired behavior change.^[2]

Feature factories create hidden costs that compound over time. Each new feature makes the product harder to maintain and improve. Technical debt accumulates when teams focus on feature launches instead of measuring performance. Features built quickly to "close deals" require extensive rework later. Initial development might take weeks, but teams pay for hasty decisions over years of maintenance.

User experience suffers as products become bloated. Each additional option increases cognitive load. Features that seemed valuable in isolation create confusion when combined. The product tries to do everything but excels at nothing. Users struggle to find core functionality buried under rarely-used features.

The biggest cost might be opportunity. While teams build features that don't matter, competitors solve real problems. Markets shift, needs evolve, but feature factories keep churning predetermined roadmaps. By the time they realize they're building the wrong things, competitors have captured the market.^[3]

OKRs played a key role in Google’s early growth from 40 employees to a global giant. This goal-setting framework keeps teams focused on what matters most through two complementary components. Objectives answer the question "Where do we need to go?" They provide direction without prescribing the path. Good objectives inspire teams beyond incremental improvements. They're qualitative, ambitious, memorable. These goals push organizations forward through their aspirational nature.

Key results answer "How will we know we're getting there?" They measure progress with specific metrics. The fundamental rule: it's not a key result unless it has a number. This forces teams to define success concretely. If you don’t yet have a metric, a valid key result could be to research and define one, for example, a retention or activation metric. It’s better to invest time in identifying the right measure than to chase a target you don’t understand.

OKRs embrace ambitious targets, expecting 70% achievement rather than 100%. They separate aspirational goals from committed deliverables. Most importantly, they focus on outcomes over activities. At Google, transparency is one of the fundamental principles that amplifies their success. Everyone sees everyone else's OKRs, from engineers to the CEO. This visibility creates accountability and shows how individual work connects to company goals.^[4]

Effective objectives inspire action without dictating solutions. They should be tangible, objective, and unambiguous. They paint success pictures that motivate creative paths forward. Poor objectives hide outputs in outcome language. "Launch mobile app by Q3" prescribes the solution. Better: "Delight users with seamless mobile experiences." This focuses on intended impact while leaving room for innovation:

• Use active verbs to create energy.
• Use specific nouns to provide clarity.
• Avoid jargon to ensure understanding.

Well-crafted objectives should make people uncomfortable. If achieving them feels easy, they lack ambition. Strong objectives balance this discomfort with clarity. They push beyond comfortable targets while remaining grounded in reality. Context shapes quality. Startup objectives differ from those of established companies. Early teams might seek product-market fit, while mature organizations optimize existing successes. Best objectives reflect current challenges and opportunities, not generic aspirations.

Key results transform vague aspirations into concrete targets. They answer: "How do we know we're succeeding?" Without measurement, objectives remain wishes rather than goals. Each key result must be obviously achieved or not, with no room for interpretation.

"Improve user satisfaction" fails this test. "Increase NPS score from 42 to 50" provides clear success criteria. This specificity prevents teams from declaring victory based on feelings rather than facts. Effective key results focus on outcomes, not activities.

"Conduct 20 user interviews" describes an activity. "Reduce user error rate by 40%" measures the outcome. This distinction prevents confusing being busy with being effective. The activity might not produce the desired result, but the outcome directly indicates success.

The number of key results per objective really depends on the size of your team. A squad should own a key result, so in many cases, you only need one or two per objective. Don’t over-engineer it. Quarterly deadlines create urgency and enable planning. Without deadlines, key results become permanent aspirations rather than achievable targets.

OKRs create a decision framework transforming how teams evaluate opportunities. Every feature request and design change can be measured against current objectives. This alignment prevents chasing shiny objects that don't advance strategic goals. Strong teams use OKRs to maintain focus. When stakeholders propose features, teams ask: "Which key result does this improve?" If unclear, the feature likely doesn't deserve priority. This discipline protects from feature creep. The connection must be explicit, not assumed.

Teams sometimes try to stretch logic so that any feature appears to support objectives. Real alignment requires showing exactly how a change drives a key result.

Regular check-ins strengthen connections between daily work and quarterly goals. Teams reviewing progress weekly make better decisions than those checking only at quarter's end. Continuous alignment prevents drift and enables course correction before it's too late. OKRs provide objective criteria when politics might otherwise drive decisions.

Design decisions often start with solutions rather than problems. Stakeholders request a progress bar or insist on "better search filters." These prescriptive requests bypass the crucial question: What user behavior are we trying to change?

Outcome-focused teams flip this dynamic. Before discussing UI elements, they articulate desired behavior change. Instead of "add progress bar," they ask "how might we motivate profile completion?" This reframing opens creative solutions beyond initial requests. The process requires resisting obvious solutions.

A request for "better search filters" becomes exploring why users struggle finding what they need. The solution might involve filters or take entirely different forms. Hypotheses link decisions to measurable outcomes. "We believe progress indicators will increase profile completion by 25%" creates testable propositions. This changes stakeholder communication. Instead of debating preferences, conversations focus on goals and metrics. Discussions shift from "I don't like how this looks" to "This doesn't drive the behavior change we need." Evidence replaces opinion in design decisions.

Many teams confuse motion with progress. They track features shipped, tickets closed, meetings held. These metrics create productivity illusions without revealing value creation. True impact metrics measure changes in user behavior or business outcomes. Product management success equals product success. Teams must look beyond outputs to actual outcomes. Instead of counting releases, track whether features improved retention, increased revenue, or reduced support tickets. This shift changes what teams celebrate and optimize.

Vanity metrics pose particular danger. Page views, registered users, download counts might grow while business struggles. These numbers feel good but hide problems. A million registered users mean nothing without engagement. Surface metrics distract from fundamental health indicators.

Choosing right metrics requires understanding causal chains from action to outcome. Teams improving onboarding might track completion rates, but real impact appears in week-two retention or lifetime value. Both matter, but ultimate success depends on long-term outcomes. Measurement discipline includes accepting when metrics don't move.

Cultural transformation requires consistent practices, shared language, and aligned incentives. The shift from feature factory to value creator needs patience and persistence. Small rituals create big changes over time.

Teams starting meetings by reviewing OKRs maintain better focus than those checking quarterly. Regular "impact reviews" analyzing whether shipped features achieved goals build measurement discipline. These simple practices fundamentally change team thinking. Language shapes culture profoundly.

Teams discussing "shipping features" think differently than those discussing "changing user behavior." Vocabulary shifts gradually as leaders model new speaking patterns. Eventually, outcome language becomes natural. Resistance comes from unexpected places. Some feel threatened when work gets measured by impact rather than output.

Success breeds success. When teams see outcome focus leads to better products and happier users, skepticism fades. Early wins with small experiments build confidence for bigger changes. Culture evolves as teams experience satisfaction from creating real value rather than staying busy. The journey requires empathetic leadership and steady commitment.