The Product Goal is a (mostly) unknown ally of Product Owners.
We rarely talk about Product Goals. I hear Scrum Teams discuss at length the reasons behind a chosen feature versus another, or maybe talk about how to increase the team’s velocity. Product Owners keep changing priorities to follow the latest requests from their customers, and the developers struggle to get anything completed in a Sprint. They blame the process, the company culture, the pressure from customers, but nobody takes a moment to reflect about a simple, yet powerful tool that can bring order to chaos: the Product Goal.
Product Goal
A Product Goal is a clear, concise statement that describes the desired future state of the product. It serves as a guiding light for the Scrum team, providing a long-term objective that all team members can align with.
I like to think of a Product Goal as a medium-term objective: 3 to 6 months away. Not too short to be confused with a Sprint Goal. Not too long to become non-actionable.
Also, I like to think of the Product Goal as the end state of the product in that timeframe. The Product Goal should not be an aspirational description or undefined vision. Not something like, “We strive to make our customers the happiest they can be“. This is a beautiful statement, a great mission in life, but it’s not a goal: it’s not actionable (what specifically are you going to do in your product to achieve it?), is not time-bound (by when will you achieve it?), and it’s not measurable (how do you know if you have achieved the goal?).
Instead, you should define your goal as something that is actionable, time-bound, and measurable. For example, “By the end of November, our product will solve the two biggest pain-points of our customers so that we can increase our customer loyalty by 10%“.
A clearly defined Product Goal (actionable, measurable, and time-bound) gives you a boundary to make decisions on your product. Specifically, what are we going to do? Which features are we going to prioritize? Even more, which features are we NOT going to do? (at least, not in the next 3 months). These are powerful decisions that Product Owners can make on their products and product backlogs.
Without a clear answer to these questions, Product Owners remain enslaved to the latest requests from customers, the latest customer support ticket, the latest idea from management. And while these requests may have value for the product (and we can use some capacity allocation to deal with them), they should not take the focus away from driving the product strategy forward.
We cannot build a product or improve it if we are continually being pulled in a thousand different directions by the latest and newest.
Instead, we need to set a direction. It needs to be bold, valuable, exciting. A direction nonetheless that we commit to undertake. We define a timeframe (again, 3 months maybe) and we create transparency on what we intend to do. This becomes the Product Goal.
Key Characteristics of a Product Goal
For a Product Goal to be valuable, it should satisfy some criteria. Let’s see a few of them:
Actionable: Let’s start with this characteristic as this is probably the most important. The Product Goal should allow us to make decisions on the product, on what to prioritize and build, and (as important) what not to prioritize. If the Product Goal is not actionable, it may be printed in gold letters on a wall and serve as a nice motto for our team, but it may have no other value. Instead, when it is actionable, it allows the Product Owner to clarify his or her intent, clearly define prioritizes, and determine the path forward.
Measurable: The Product Goal should be quantifiable to track progress and determine success. If we are not able to measure our progress toward the goal, how do we know when we have achieved it (or not)?
Time-bound: It has a specific timeframe within which we aim to achieve it – Typically within 3 to 6 months.
It may help to consider additional criteria as we define our Product Goal, for example:
Achievable: It should be realistic and attainable given the team’s resources and capabilities, and within the time-frame we have identified. Setting a goal that is not achievable may be bold and visionary, but it does not help to make product decisions, so it becomes not actionable (it violates the first criteria).
Relevant and Valuable: The Product Goal should align with the overall Product Vision of the product and with the business objectives and strategy. It also needs to be valuable, so that it can clearly explain why we should invest time and resources to achieve it.
Relationship between Product Goal and Product Vision
While the Product Vision is a broad, inspirational statement about the product’s long-term purpose and value, the Product Goal is a more specific, measurable objective that contributes to realizing that vision. We can consider the Product Goal as a step-stone toward the Product Vision, and we will achieve the Product Vision one Product Goal at a time.
For simple, time-limited products, the Product Vision and the Product Goal may overlap and represent the same thing.
For complex products that are not time-bound, the Product Vision is a long-term objective that may never be achieved. Whereas the Product Goal is a concrete step toward that Vision and it represents an objective that we plan on achieving in the medium-term.
An Objective-Based Roadmap
Defining your Product Goal for the next 3 months creates transparency and commitment toward that objective. You can take it a step forward and define objectives beyond the first Product Goal. When you do that, you create a series of objectives that span multiple quarters.
- The first objective, that we call the current Product Goal is pretty much committed and that’s what you focus on.
- The subsequent objectives are future Product Goals that we intend to achieve after we have achieved the first one. As such, they are intentional, but not yet committed to.
We have created an objective-based roadmap. The idea is that you map out the objectives you plan on achieving with your product over a number of quarters (each objective has a timeframe of 3 months, in this case). By creating a plan based on objectives allows you to focus on what really matters, rather than an ever-ending list of features that may not deliver value.
This visualization explains the concept of an objective-based roadmap using Product Goals:
The Product Goal Canvas
The Product Goal Canvas is a collaborative template that we can use to define a Product Goal for our product together with our team or stakeholders. When the Product Goal is clear, articulated, and aligned with our key stakeholders, all we need to do is to communicate and share it. The Product Goal Canvas makes it easier to do so.
Read more about the Product Goal Canvas and download the template.
Questions and Answers
What is the purpose of a Product Goal?
By providing a clear, measurable objective for the product, the Product Goal promotes transparency and alignment on what to do on the product, on its priorities, and on how to measure progress.
How can I ensure that the Product Goal is aligned with the business objectives?
The Product Owner should work closely with stakeholders to ensure that the Product Goal is aligned with the overall business strategy. One way to facilitate that collaboration is by organizing a working session with the stakeholders and together use the Product Goal Canvas to create alignment on one or more objectives for the product.
How can I measure progress towards the Product Goal?
One of the key characteristics of the Product Goal is to be measurable. That means you can define a metric that you can measure at regular intervals to check the progress and validate that you are moving toward that goal.
At Sprint Review, present an update on the Product Goal, sharing the metric and how it is performing. For example, if your Product Goal is, “to fix the performance of the product so it becomes more responsive with a target response rate of less than 3 seconds”, every Sprint Review you should measure the response rate and provide an update on your progress. Are the activities that the team is working on moving the needle so that the performance of the product is improving? How has the response rate improved in the last Sprint? What are we going to do next to further improve?
What should I do if the Product Goal becomes outdated or irrelevant?
The Product Goal is an objective we want to achieve with our product, and as such we commit to achieving it. However, it should never be set in stone: how can we be “agile” if we set in stone an objective and do not allow any changes to it for 3 to 6 months?
Having a commitment is important. So is the ability to adjust if needed. The Product Owner should review the Product Goal regularly and update it as needed. Of course, as soon as a Product Goal is updated, it should be communicated to the team and the stakeholders to create transparency and alignment. Also, the roadmap and the priorities of the Product Backlog should be revisited to align to the updated Product Goal.