The problem is deeply embedded in our minds. We must comprehend what we are actually developing. It appears to be very simple based on the nature of the human brain. When we have a problem, we look for a solution. Once we find it, we develop it, and that is what is called output.
However, such a solution will only benefit you and your peers. For someone else, your solution may not be suitable. As an example, consider the following: I am developing a mobile banking app, and I might make a habit of transferring half of my paycheck to a savings account as soon as I get paid. This is so the money isn't in a checking account, and I don't feel compelled to spend it on frivolous items. However, in the middle of the month, I frequently have to transfer funds from my savings account back to my checking account because my checking account is depleted. To support this scenario, I will create a large "Transfer money from savings account" button and place it right on the app's dashboard. However, we later discover that only a small percentage of our users exhibit this behavior, and the dashboard button makes the application more difficult for all other users.
Why am I bringing it up when we are discussing outputs and outcomes? The issue is that we frequently believe we are only interested in outcomes. We add something to the app that we believe will benefit users and achieve outcomes, but we are mistaking output for outcomes at that point.
Decide whether the changes listed below are outputs or outcomes for our application.
- Add ten new banking products.
- Allow users to pay using NFC.
- Create a section for investing.
If you believe that these are outputs, i. e., functionalities, that we will develop and might bring us nothing but costs in our business, you are correct. Unfortunately, practice shows that these are the tasks that teams prioritize, and there is frequently a disconnect as to why these features should be added to the application at all.
Let's look more closely at the distinction between outcomes and outputs.
Business outcome
It is about the company, where it wants to take its business, and where it is heading. These are objectives such as cost reduction, profit increase, and so on. If we are working in a team to build a product and we get a business outcome like increasing turnover, it can be very complicated because there are several different paths that lead to that outcome, and the team often lacks the authority to move freely in that space. Increased turnover can be obtained by, for example, developing a completely new product, raising product prices, expanding operations to another country, or increasing marketing activities. However, the product development team is frequently unable to do any of these things.
Product outcome
This is about something else, it is about a outcome that the given team can accomplish. The team has both the authority and the means to carry it out.
A product outcome can be, for example:
- improving app onboarding,
- increasing user satisfaction with the application,
- increasing sales of products directly in the application, and so on.
Of course, product outcomes must be based on business outcomes. For example, if a company wants to cut operating costs (business outcome), the product team might be tasked with reducing the number of people who call support with problems or questions about the application.
By reducing the number of callers, the need to employ so many people in customer support will also decrease. Based on the desired output, the team looks for solutions, which can be numerous – introducing a chatbot, directing consumers to appropriate sections, and so on. However, developing such a solution is not without difficulty. If you want to learn more, you can read the article here.
It should be mentioned that business or product results must be measurable. The team then measures them on a regular basis to check how close they are to achieving them. You should always know your progress and how close you are to your target. An example could be a 10% reduction in app abandonment during the onboarding process or a 5% increase in in-app product sales.
Output
The output – sometimes also the solution – most often describes a new function or modification to the application. They are, thus, the team's individual outputs, which are then exposed to real users. I don't mean to imply that this is something that only programmers do to implement a feature. It's a team effort.
An example of the output are the individual functions:
- add filter,
- edit list of items,
- add search, etc.
The issue that arises when you focus solely on outputs is their measurability and connection to product and business results. New features are often added based on ideas, which are frequently made by managers who believe they will be beneficial. There is constantly a disconnect between the business or product outcome and, most importantly, the measurability of each such output.
It should be noted that the team must produce outcomes. However, it is about how they arrive at the given output (i. e., the solution).
What does it take to develop the best solution that will be produced?
- The entire team is aware of the business outcome.
- Product outcome determination.
- Understanding user needs in relation to product outcome fulfillment (satisfying users' true needs, determining what they are missing in the application, what they need there, what they do not understand, and so on). During this stage, there is a lot of interaction with users via various research methods.
- The selection of a specific user need on which the team will work to achieve the desired result, see point 2.
- Development of specific solutions for a given need by a team. There is frequently more than one solution to a problem, and each one fulfills the user's needs and is technologically demanding in a different way.
- Choosing one specific or several different solutions. The most logical option is selected. For example, we don't want to choose a solution that will take three months to develop and we won't get anywhere in those three months; we will develop only one solution during that time, which may be ineffective. It is preferable to select solutions that can be tested or implemented as soon as possible.
- Finally, you assess whether the chosen solution was effective and evaluate its overall impact to learn from it for the next time.
This method is then repeated several times. This way, you can see what path should lead to the creation of outputs that meet the product and business outcome and are not just a reflection of our knowledge of the problem but are based on the actual needs of users.
Conclusion
Developing a product entails more than just adding new features but rather involves solving user problems and meeting product and company objectives. Therefore, it is essential to have a clear connection between the development of new functionalities and the required outputs to be able to concentrate on the objectives and achieve the development of a successful solution.
It's a good idea to look at how you work today and see whether you are just delivering outputs or you are really focused on delivering measurable outcomes and consciously moving towards those outcomes. If you want to learn more about this topic, I recommend Josh Seiden's book Outcomes Over Output: Why Customer Behavior Is the Key Metric for Business Success and Teresa Torres' book Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value.
