When we create, we typically start by establishing the business objective, then move on to the product goal, opportunities, and finally, the solution. When building a tree, it is not required to move only from goals to solutions; you may also do it the opposite way around. Based on experimentation with solutions, we may change opportunities and then use them to affect goals. This process should be cyclical, and the tree should constantly evolve with new findings. It may be argued that it will never be completely finished, much like a digital product.
Business outcome
A business outcome measures value to the business, mainly financial metrics or strategic initiatives – e. g., market growth in a specific region or turnover. The issue is that they are frequently not measurable in advance and are only evaluated retrospectively. However, it is still possible to establish some metrics that can be used to predict how the business objective will evolve (e. g., if the taste of chocolate and its composition improve, it will bring more customers and, therefore, more money).
This outcome is set, for example by the owner or CEO, who is in charge of the strategic development of the organization and the product itself.
Product outcome
A product outcome should describe a change in user behavior to support the business. The product trio – the product owner, designer, and tech lead – primarily concentrates on and has the most impact on this area. An example of a correctly set product goal is Increase in product sales in a mobile application or Increase in PMF score.
Product outcome should be set in collaboration with the product owner and the product trio. However, the product owner should never try to determine the solution; that is the task of the product trio. Their goal is to bring a broader view of the business and determine what is currently important and in which direction the product should go.
On the other hand, if the team is tasked with developing a product outcome without a product owner, it is acceptable to consult them regarding the context – what is currently the most important in the business (within the outcome), which customer segment we are focusing on and whether any of the segments are more important than others, or what strategic initiatives we should know about. Based on this, the team will be able to select the product outcome they can influence the most.
The following errors should be avoided when establishing product outcome:
- pursuing too many outcomes at once (ideally having only one to three),
- moving from one outcome to another and extinguishing crises (it is better to focus on one specific goal for an extended period of time),
- setting an outcome that cannot be measured (e. g., the goal to "improve usability"- we can't determine what exactly 'improved usability' means),
- setting individual outcomes instead of the product trio's goals (for example, when the tech lead determines that their goal is to increase the loading speed of the mobile application even at the expense of usability, while the designer's goal may be to improve the search for a specific product at the expense of loading speed – this forces each of them to focus on something else)
- choosing an output instead of a goal (the output can be "create a filter" – it's not a goal, but rather a solution),
- focusing on one goal at the expense of everything else (for example, when we set a product goal that explicitly goes against company policies or the goals of other teams in the company).
Opportunities and sub-opportunities
Problems, needs, desires, or concerns of the customer are referred to as an opportunity as a whole. This does not only include issues that need to be resolved. For example, ice cream serves as a source of calories for the body's operations, but its primary objective is to satisfy the sense of taste -> not to solve any specific issues. Therefore, the goal of the product trio should be to accurately define the opportunities before choosing which ones are worth developing.
We approach new opportunities in different ways. We can obtain them through customer interviews (link), tracking customers when they interact with our products (link), or questionnaire surveys. We then visualize the opportunities found in the tree as another layer right after the product goals. This will allow us to see hierarchical and equal relationships and better understand the opportunities worth pursuing in more detail.
An opportunity must be added to the tree if it meets the following criteria:
- is defined as a customer need or problem, not as a solution (that the customer proposes),
- is unique to a specific customer (not repeated),
- supports the stated product goal.
Top opportunity mapping errors:
- opportunities are written from the perspective of the business, not the customer (e. g., We want to improve NPS from 6 to 8 vs. I just need to know where the closest physical location is),
- we only have vertical opportunities (a parent has one child that has one child within the hierarchy -> we lack sibling ties, so it is necessary to examine them during interviews and add them to the visualization, see example),
- opportunities have multiple parent ties (opportunities are probably too broadly defined),
- opportunities are not specific enough (e. g., I want to improve usability vs. I simply want to find a product in the e‑shop),
- opportunities are just veiled solutions (the easiest way to distinguish them is to ask – is there more than one solution to this opportunity? If so, we have an opportunity, if not, it's already a solution),
- capturing feelings as an opportunity (it is necessary to look for the cause of the given emotion as the opportunity is usually hidden behind it, e. g., I am afraid that my laptop will be damaged during transport -> I want to deliver the product home safely).
But how do we choose the opportunity we should focus on first and which to put aside? We will focus on this process in one of the following articles we are currently preparing.
Solution
Rarely the first idea is the best. They are not entirely original and are most obvious at first glance. On the other hand, the best ideas frequently come to us at the very end of the idealization process after we have already completely moved past the original ideas.
We most often come up with solutions to individual opportunities thanks to ideas. We frequently create them individually and then share them with team members. We repeat this process until we have 15 to 20 ideas for each selected opportunity.
We then test these individual opportunity solutions, focusing mainly on those for which we do not have sufficient evidence. When testing, it is important to try to simulate a situation, thanks to which we can verify our assumption about the solution with the user. Before the very beginning of the test, we also need to define what it means that the assumption is correct (e. g., at least 7 out of 10 respondents in the model situation can find the right button, fill out the form and send the order). An important aspect of testing is also the correct recruitment of respondents (link). Thanks to it, we can prevent failed or falsely successful tests.
Based on the results of these tests, we find out which solution is the most suitable for the given opportunity, and then we move this to the delivery phase. Product creation is a cyclical process, and it is necessary to return to the individual steps constantly. In one of the other articles, you will learn how Continuous Product Discovery fits into the entire process.
Resources
- Teresa Torres – Continuous Discovery Habits
- Teresa Torres – Product Talk
