Output
An output answers the question: "What have we produced or delivered?"
It can be a released feature, a new screen, an API, a research report, a communication campaign, an internal guide, a prototype, or a release. Outputs are necessary: without them there is no product, no materialized learning, and no operational change.
The problem arises when the team measures success only by outputs. Delivering something does not prove that it has created value.
Output vs. outcome
| Concept | Question it answers | Example |
|---|---|---|
| Output | What have we produced? | Launch a new onboarding flow. |
| Outcome | What change has it generated? | Increase new user activation from 28% to 40%. |
The output is the means. The outcome is the expected effect.
A team can complete all its outputs and still fail strategically if users do not change their behavior, if the problem remains the same, or if the relevant metric does not move.
Examples of outputs
Examples of outputs include:
- a new feature;
- an interface redesign;
- a release;
- an API;
- a technical migration;
- a dashboard;
- an email campaign;
- a user guide;
- internal documentation;
- a prototype;
- a completed interview;
- a discovery report;
- a list of experiments;
- a set of tests;
- a spec;
- a data model;
- an automation.
Some outputs are visible to the user. Others are internal. Both can be valuable, but they need to be connected to the result they pursue.
Outputs Are Not Bad
Being outcome-oriented does not mean dismissing outputs. This is a common misconception.
Outputs are necessary to put decisions into practice. You cannot improve a product without producing changes, artifacts, experiments, or deliverables. What is being questioned is not producing, but turning production into the main measure of success.
A healthy team needs outputs, but evaluates them based on their contribution to the expected outcome.
The problem with measuring only outputs
Measuring only outputs creates problematic incentives:
- prioritizing quantity over impact;
- filling the roadmap with features;
- celebrating deploys without checking adoption;
- turning OKRs into task lists;
- reducing discovery to justifying solutions that have already been decided;
- confusing activity with progress;
- avoiding difficult conversations about value.
When an organization primarily measures outputs, it is easy to fall into becoming a feature factory: an organization that churns out features, where success is defined by delivering more, not by solving problems better.
Outputs in OKRs
A KR framed as an output usually takes this form:
- "Launch the new reporting module."
- "Complete 12 roadmap initiatives."
- "Publish 8 releases."
- "Implement the checkout redesign."
- "Close 40 tickets."
These KRs can provide visibility into the work, but they do not measure impact. An outcome-oriented KR would state the expected change:
- "Reduce data access support tickets from 45 per month to 15 per month."
- "Increase checkout conversion from 31% to 38%."
- "Reduce mean incident resolution time from 2 days to 8 hours."
The key test is to ask: "If we complete the output and nothing changes, will we consider ourselves successful?"
When managing outputs makes sense
Although outcomes are preferable for measuring value, there are situations in which managing outputs is useful or necessary.
| Situation | Why the output matters |
|---|---|
| Regulatory work | There are mandatory deliverables that must be completed for regulatory compliance. |
| Technical dependencies | A team may need to deliver an API, a migration, or infrastructure to enable later work. |
| Critical maintenance | Some outputs are needed to reduce risk, technical debt, or operational fragility. |
| Early exploration | A prototype or an interview may be the output that enables learning. |
| Contractual commitments | Some deliverables have value because of a contractual or service obligation. |
Even in these cases, it is advisable to connect the output with its purpose. A technical migration may aim to reduce incidents, improve throughput, lower maintenance costs, or enable new capabilities.
Learning outputs
Not all outputs are features. In contexts of uncertainty, an output can be an experiment, an interview, a prototype, or a synthesis report.
These outputs are valuable when they generate actionable learning.
Example:
- Output: conduct 12 interviews with enterprise users.
- Learning outcome: identify the three main problems blocking adoption in enterprise accounts and decide which hypothesis to validate first.
The mistake would be to count interviews as success without drawing decisions from them.
Output and AI
Generative AI multiplies the capacity to produce outputs: texts, designs, code, test cases, analyses, summaries, prototypes, or specs.
This can be very positive if the team knows what result it is pursuing. But it can also amplify the noise. When producing becomes easier, the risk of generating more artifacts than the team can review, integrate, or turn into value increases.
In AI-enabled teams, it is also worth measuring:
- human review time per output;
- outputs discarded or redone;
- outputs that reached production;
- outputs that generated useful learning;
- outputs that moved a metric;
- outputs that introduced technical debt or rework.
The question is not "how much has AI produced?" but "which outputs have contributed to a relevant outcome?"
Output, roadmap, and commitment
Traditional roadmaps tend to present outputs tied to dates. This can create an illusion of control: if the team delivers what was promised, it seems the strategy is moving forward.
But a roadmap full of outputs can become disconnected from actual results. That is why approaches such as the Now-Next-Later Roadmap try to order priorities without turning every future output into a fixed promise.
A mature roadmap does not just say what will be built. It explains why it matters and what outcome it aims to achieve.
How to reframe an output
To turn an output into an outcome-oriented conversation:
- Identify the requested output.
- Ask what problem it solves.
- Define which user, customer, or process it affects.
- Formulate what behavior or metric should change.
- Consider alternative solutions.
- Decide whether the requested output is the best hypothesis for moving that result.
Example:
- Request: "We need an advanced reporting module."
- Problem: enterprise customers cannot make decisions without asking support for data.
- Possible outcome: reduce data-related support tickets from 45 per month to 15 per month.
- Hypothesis: a reporting module may help, but exports, alerts, templates, or better self-service could also help.
Signs of excessive output orientation
An organization is too output-oriented when:
- success is measured by features delivered;
- teams celebrate releases without reviewing adoption;
- KRs are task lists;
- the roadmap doesn't change even when the data does;
- discovery is used to validate solutions that have already been decided;
- stakeholders ask "When will it be ready?" before asking "What problem does it solve?";
- there are many deliveries and little evidence of impact;
- the team doesn't know which metrics each initiative should move.
Best practices
To use outputs without falling into output-ism:
- Connect each output to a hypothesis. What do we believe will change?
- Define success signals before building. Don't wait until the end to think about how to measure.
- Don't turn the roadmap into a closed list of deliverables. Leave room for learning.
- Distinguish product outputs from learning outputs. Both can be valuable if they lead to decisions.
- Review adoption and impact after delivery. Delivery doesn't close the loop.
- Use outputs as bets, not as guarantees. A feature is a value hypothesis.
- Avoid KRs based solely on tasks. They measure activity, not outcomes.
Common mistake
Treating the output as proof of value. The fact that something has been delivered does not show that it has worked. An output only takes on strategic meaning when it is connected to a problem, a hypothesis, and a signal of impact. Without that connection, the team can produce a lot and learn little.
Resources
🏦 OKRs y estrategia de producto [OKRs and Product Strategy, in Spanish]Skill Arena · Scrum Manager
References
- Cagan, Marty. (2018). Inspired: How to Create Tech Products Customers Love. Wiley.
- Scrum Manager. (2026). OKRs y estrategia de producto [OKRs and Product Strategy, in Spanish]. Scrum Manager.
- Seiden, Josh. (2019). Outcomes Over Output. Sense & Respond Press.
- Torres, Teresa. (2021). Continuous Discovery Habits. Product Talk LLC.
- Torres, Teresa. (2024). "Shifting from Outputs to Outcomes: Why It Matters and How to Get Started," Product Talk.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.