Product Goals: How to Write and Use Them

Product goals may be one of the most obscure parts of the Scrum framework. Some confusion with Scrum terminology is unforgivable in Agile circles – like mixing up Agile and Scrum.

But everyone will forgive you if you have:

That’s because the term “Product Goal” is relatively new in Scrum.

Product Goals only made an appearance in the latest 2020 edition of the Scrum Guide to give teams a new perspective. Product Goals are an objective that’s further off than short-term Sprint Goals but closer and more concrete than the elusive product vision.

This article explains everything you need to know about Product Goals, with tips on how to write one, examples, and a handy checklist.

A Product Goal is a measurable and actionable target describing what the Scrum Team aims to build in the months ahead and for what purpose. It acts as a bridge between the product vision – which is very long-term and somewhat vague – and a team’s short-term Sprint Goals.

A Product Goal goal can be deconstructed as follows:

An example of a Product Goal may be to “improve onboarding to increase conversions” or “overhaul the online shopping experience to increase revenue.” 

Here’s what this looks like with an example from our work at Parabol:

The Scrum Team uses a Product Goal to plan, prioritize, and focus their work. Members of the team should add the Product Goal to the top of the Product Backlog, just like you may state a Sprint Goal at the top of the Sprint Backlog.

By completing items in the Product Backlog, Scrum teams should eventually fulfill the Product Goal. Just as completing items in the Sprint Backlog helps teams achieve their Sprint Goal. 

A team can only have one Product Goal at a time and it usually spans a few months, though the Scrum Guide doesn’t prescribe a specific length or timebox.

The Product Owner writes the Product Goals for a Scrum team. Writing Product Goals fits with the Product Owner’s overall responsibility for the direction of the product. The Product Owner will usually consult other stakeholders in the business before confirming Product Goals with other members of the Scrum team.

Setting Product Goals helps Scrum Teams:

A Product Goal is to the Product Backlog what a Sprint Goal is to the Sprint Backlog.

The Product Goal gives guidance on which items to place, refine, and prioritize in the Product Backlog. The Sprint Goal does the same, but in a shorter time frame – one Sprint.

The main difference between epics and Product Goals are that Product Goals:

For example, a cluster of epics might contribute to achieving a Product Goal.

We suggest following these steps to craft effective Product Goals.

Besides your long-term product vision, user needs and business objectives should inform your Product Goal. Thinking about this triad of variables helps make sure you’re building a product people want. 

As with a good user story, product owners shouldn’t dictate how the team should achieve their goal. That’s up to them to figure out.

However, you do want to explain what they need to achieve. 

“Give the user access to every conceivable organic recipe from any device instantly” is a valid Product Goal for a cooking community platform. 

Stating that you want “a recipe search function with filters for cuisines and ingredients” is too specific, at least for a Product Goal.

Once you have a draft Product Goal, see if there’s more data or information to help improve it. You want to verify that it’s the best objective for the given moment.

You can gather such information from existing product usage data or even market research and industry reports to validate whether there’s a need for what you’re thinking of building.

Make sure to run the draft goal by your team members and other knowledgeable folks for feedback to refine and finish it. Your Product Goal shouldn’t be a secret you unveil at the last minute, but something you’ve shaped over time with the team and other stakeholders.

The new Scrum Guide from 2022 doesn’t say anything about Product Goal metrics, but we recommend connecting at least some metrics to your Product Goal. This will make it measurable.

With metrics, it’s clear to the team when they have reached their objective. It also allows the product owner to track progress along the way.

Say your Product Goal is to “help users have better online retrospectives so they’ll use our product more,” then session length and weekly retention could be helpful KPIs to set and track along with your goal.

Besides giving the team a clear target to work toward, the Product Goal should inspire ambition and motivate team members to push beyond what they thought possible.

The Product Goal should also be achievable. When the goal is impossible, you set the team up for failure and achieve the opposite effect: a demotivated Scrum Team.

Getting this balance right is a bit of an art. But if your team already has an agile mindset of continuous improvement and is intrinsically motivated, they’ll want a somewhat ambitious goal and will help you craft one. If they don’t, you have bigger worries than getting your Product Goal right.

When looking at Product Goal examples, it’s helpful to compare them to the product vision and Sprint Goals that go along with them. That way, you can see the differences and relations between them.

Product management expert Roman Pichler provides one of the best Product Goal examples:

His Product Goal is more specific than the product vision and gives direction. At the same time, it doesn’t say how to achieve the objective, which would make it more like a task or epic (a large task or user story).

Simon Kneafsey, a Professional Scrum Trainer with Scrum.org and TheScrumMaster.co.uk, also provides a Product Goal sample using the case of a fictional bakery:

While Simon’s example is valid, it’s hard to see the difference between his Product Goal and a regular project milestone or epic. His goal arguably veers too much into prescribing how to achieve the objective instead of inspiring ambition by only giving a what and why.

Here are a few pointers and best practices for when and how to use your well-crafted Product Goal to the greatest effect.

Your Product Goal should be used as a:

A Product Goal must be a straightforward statement that the entire team understands. Essentially it says:

Do something for the user and/or business with this purpose.

To ensure your Product Goal is ready to go, ask yourself these product goal questions”

If the answer to any of these questions is “no” or “I don’t know,” then revisit your Product Goal. Keep calm and carry on crafting. Take your draft to the team and discuss the issues you found through the checklist above – together, you’ll arrive at a perfect Product Goal. 💪

Here’s a handy infographic that covers everything you need to know about Product Goals in one place. Consider sharing it with your team or your network if you find it helpful! This infographic summarizes this blog in an easily digestible way.