From Output to Outcome: Developers as Product Designers
Those who ask the right questions in software development can achieve real impact instead of just implementing features.
(Image: GaudiLab / Shutterstock.com)
- Dominique Winter
In many software teams, development runs like clockwork. Developers gather requirements, implement features, complete sprints, and deliver releases. They build, test, deploy, over and over again. And yet, a vague feeling often remains. Why this work, why all this code? Even with AI support, generating more code faster doesn't mean that much value is created in the end.
This is where the problem lies for many product teams: the focus is on output. Teams implement more and more features and measure progress based on the work done. Products accumulate more and more functionality and grow continuously. Many product managers believe this is necessary to differentiate themselves from the competition and to constantly offer existing users something new. However, “more” is not always the solution, and sometimes it's even an issue. The more features a product includes, the more work must go into bug fixing and maintenance. And this is precisely where the idea of focusing more on outcome instead of output comes in.
(Image:Â deagreez/123rf.com)
Conference in Cologne: The Product Owner Days on May 5th and 6th, 2026, will cover current topics related to product ownership, AI usage, user research, and more in over 20 talks. The author of this article, Dominique Winter, will hold a workshop on product visions.
Output is not the same as value
What is the difference between output and outcome? Output describes what is produced. Outcome is what the produced thing achieves. Every function, every new piece of documentation, and every new test is initially just output. The more a team delivers, the “more productive” it is. It remains unclear what changes through the generated output. What will change for users?
For example, an online shop with frequent repeat purchases (e.g., for weekly groceries or ordering from a favorite pizzeria) has a feature that reminds users during their purchase that they've forgotten an often-bought product this time (e.g., “You usually add pizza bread. Did you perhaps forget it?”). The feature for this reminder is initially just the output. However, if customers use the feature and it leads them to buy more, that is the outcome. In other contexts, this could also mean faster onboarding, happier customers, or similar. But ultimately, outcome is always the answer to the question of what should improve through the output.
The concept of outcome and output for a complex product can be well illustrated with the example of food for a celebration. Each individual dish, each dip, each sauce, and each side dish is output. If you measure the success of your work by output, the primary goal is to have as much food on the table as possible. However, when it comes to outcome, the joy of eating, the smiles of the guests, and the enjoyment of the food are important. Therefore, you approach the work differently when you ask different questions. Is it about having as much food as possible, or is it about satisfying people gastronomically? Is it about simple satiety or about delight in eating? In terms of software, users are not happy about additional features themselves. Rather, they are happy when they can solve a problem more easily, perform a task faster, or use a function more easily.
Output orientation can be observed in many product teams. They often strive to maximize the working time of developers. A high number of work results creates a feeling of productivity. In the long run, however, this leads not only to products with limited impact but also to frustration within the team. Developers, in particular, often find themselves implementing technically demanding solutions without knowing if they are even sensible.
Outcome is also a developer's task
Now, one could make it relatively easy for oneself. The decision of what to build often lies with product management or conception. As a developer, you “only” have to implement the requirements or convert them into code. However, this translation requires considerable expertise, as building good software is anything but trivial. But retreating to feature implementation does not absolve developers of the responsibility to care about their effectiveness. Seeing oneself only as an implementer is shortsighted because developers, in particular, are in a central position. They translate ideas into reality, but in doing so, they make important architectural decisions and best know the technical possibilities and limitations. If they ask questions about the intended outcome in this process, their knowledge helps to find good solutions instead of just implementing requirements.
Videos by heise
The right questions are the strongest lever
However, developers don't have to take on new roles now. Often, it's enough to ask the right questions at the right points (see text box). Especially in meetings concerning requirements, valuable discussions often arise, and thus opportunities to inquire about the reason (the desired outcome) for a feature and, through the conversation, potentially shift the focus of development. Why should this particular feature be built? Why do users need the feature? How will we know afterward that it was worth developing the feature?
Of course, for those who set the requirements, it is easier to order a specific function directly. But it is surprising how often these people themselves have not yet really thought about why the world requires this feature and what effect it is actually supposed to achieve.
Questions like these noticeably change conversations:
- How do we know in the end that what we are building is valuable?
- Which user behavior should change as a result?
- Which problem is being solved better by this?
- What happens in the user's experience world if we don't build this feature?
- What would be the smallest solution that already has an effect?
Certainly, someone from product management or other areas should be able to answer the above questions, but two important aspects should not be forgotten. Firstly, people work there too. Perhaps they simply find the idea for the feature exciting or just feel like seeing it in the product. The effect it has on users may not have been considered. Secondly, it happens to everyone now and then that they get very caught up in a solution idea and lose sight of the fact that the same effect could be achieved in a different way.
Developers, as full team members, also have the task of ensuring that the right things are done. However, some team members do not want to be perceived as resistant. Especially those who do not have much work experience sometimes put their perspective aside and assume that the rest of the team will know why it makes sense to build the feature. But questions do not slow things down; they sharpen focus. They help teams make more conscious decisions.
Anchor outcome in daily work
However, increased outcome orientation should not depend on the commitment of individual team members. Instead, it must become part of the work routine, and there are effective levers for this as well. Some product teams, for example, use a Definition of Ready (DoR), which describes the properties that must be met for a requirement to be implemented. A DoR can then include, among other things, that certain questions about the intended outcome must be answered. These questions include, for example, those mentioned in the text box. By incorporating such questions into the DoR, individual developers no longer have to ask every time and feel like they are interrupting; instead, the team as a whole commits to working through the questions. If, when reviewing the DoR, it is unclear what the requirement is intended to achieve or how success will be measured, it makes sense to postpone the implementation and first clarify the intended goal or effect.
