Strategic Product Goals: A Guide to Achieving Measurable Results with Your Product

What makes a good Product Goal?

If you’re wondering, you’re not alone. In this article, I’ll show you how I use the business model equation to define a Product Goal that aligns with the company’s goals.

Before we dive into the process, let’s clear up a common misconception.

What is a Product Goal in Scrum?

According to the Scrum Guide, the Product Goal is defined as follows:

“The Product Goal describes a future state of the product that can serve as a planning target for the Scrum team.

When you hear “future state”, you may think of features or characteristics that the product will have in the future. In other words, it’s about what the product will become, right?

I see it differently.

Let’s take a closer look at the Scrum Guide. The next sentence provides an important insight:

"The rest of the Product Backlog emerges to define 'what' will fulfill the Product Goal."

You might ask yourself: if the Product Backlog defines the “what”, what exactly does the Product Goal describe? Is it also about the “what”?

That wouldn’t make sense.

Exactly. In my view, the Product Goal describes the outcome we want to achieve for our customers or users.

Joshua Seiden, author of Outcomes Over Output: Why Customer Behavior Is The Key Metric For Business Success, explains outcomes this way:

“An outcome is a change in human behavior that produces business results.”

A Product Goal should focus on such outcomes. It should define the behaviors we want users to adopt that will drive business results. Achieving results means building the right features into the product, but it’s not the features themselves that matter, it’s the outcomes users get from them. Those results are what ultimately benefit the business.

To summarize:

The Product Goal should define why we want to improve the product. The Product Backlog then becomes a series of hypotheses and experiments aimed at achieving that outcome.

Now that we’ve got that out of the way, the next question is: If Product Goals are not about features, how do we define them?

Let me walk you through an example.

Analyzing the Business Model

Product Goals are derived from the business model. 

In other words, to define an outcome-focused product goal, we need to step back and examine the entire business model. 

Let’s walk through this process together using a small, local online newspaper as an example.

On the newspaper’s homepage, local news articles are freely available to all visitors in short formats. By registering, readers can access up to three additional articles per day, including analysis and opinion columns. If readers want unlimited daily articles, they can subscribe for €10 per month.

• Here are some key figures from the newspaper’s business model:
• In December, the home page received 500,000 visits.
• 30% of those visitors registered for free access by providing only their email address. This means that the subscription rate for free access is 30%.
• Of those who signed up for free access, 0.5% converted to a paid subscription, for a conversion rate of 0.5%.
• Meanwhile, 7% of paid subscribers canceled their subscriptions last month, for a churn rate of 7%.
• The newspaper had 10,000 paid subscribers in December, with an average subscription price of €10.

The business model of this newspaper follows a classic B2C subscription strategy with three key stages:

1. Offer a valuable product.
2. Encourage people to try it.
3. Convince them to subscribe.

Monetization can be through advertising (e.g., Instagram, Snapchat) or paid subscriptions (e.g., Duolingo, Spotify). For these models to succeed and remain profitable, the strategic focus must always be on increasing user engagement. The more users interact with the product, the better the monetization potential.

Now back to the online newspaper that has chosen the paid subscription model.

The newspaper’s CEO has shared the company’s financial goal: to generate $1,350,000 by the end of the year. If this goal isn’t met, the company will no longer be able to cover its costs, as profitability has decreased and reserves will be depleted by the end of the year.

Let’s look at the numbers again. What stands out?

Most of the numbers seem typical for the industry. However, one number raises a red flag: the churn rate is 7%. I guess this is higher as for Netflix. This could this be a critical issue? But instead of relying on gut instinct, let’s dig deeper and analyze the situation mathematically.

This requires math.

Creating a Business Model Equation

To avoid relying on gut feelings, we need to express the business model as an equation. This allows us to make precise calculations. 

Here’s what it looks like in our example:

Here is the formula again:

• Profit = Revenue - Costs
• Revenue = Number of subscribers in the current month × Average price per subscription
• Number of subscribers in the current month = Number of subscribers in the previous month + New subscribers - (Number of subscribers in the previous month × Churn rate)
• New subscribers = Visitors to the homepage × Subscription rate × Conversion rate

Using these equations, we can create a forecast for the year.

When we add up the sales forecast for the next 12 months, we get $1,230,440. According to the CEO, this is a problem. The instinctive reaction in a situation like this might be to cut costs. But the real question is:

Should we focus on cost cutting or growth?

Which lever in the business model equation should we improve? A closer look at the cost structure helps clarify things. The newspaper has 15 employees in three teams: editorial, website management, sales and marketing, and administration. There are also a few freelancers. The average salary is €45,000 per employee, and personnel costs account for about 60-70% of total expenses, with the remaining 30-40% covering other operational costs. If you ask my opinion, I’d lean towards growth. Reducing costs offers limited potential to significantly increase profits.

To solve the problem through growth, we need to examine the left side of the equation and explore potential improvements. 

Let’s run through a few scenarios:

• Increase in visitor numbers: To meet the revenue goal, the number of unique visitors would need to increase to 548,550 per month.
• Increase subscription rate: The subscription rate would need to increase by 32,913%.
• Increase conversion rate: The conversion rate would need to increase to 0.5486%.
• Reduce churn: The churn rate should decrease to 6.38%.
• Raise the price: The average subscription price would have to increase to $10.97.

In these scenarios, I kept all the other parameters constant and only changed one to make it easier to evaluate. What stands out is that each parameter requires about a 10% improvement. This analysis shows that there’s no strong justification for focusing solely on reducing churn.

So we have several areas where we can make improvements.

Now, let’s bring this back to the Product Goal—stay with me!

The product goal helps us determine which of these metrics to focus on.

Conversion rate, subscription rate, and churn rate all reflect changes in user behavior that directly impact business outcomes. For example, if visitors choose to share their email addresses in exchange for more content, the conversion rate increases, which benefits the newspaper. Conversely, if users choose to switch to another news site, this negative behavior affects the churn rate.

Let’s go back to the example:

Suppose we decide to improve the conversion rate. How do we translate that into a meaningful product goal?

In the “Professional Scrum Product Owner - Advanced” training, we use this template for this:

"How can we improve [the product/service] so that our customers are more successful in [solving their problem], which will be reflected in [these measurable changes in customer behavior]?"

Applying this to our example, the product goal might be:

"How can we improve our website so that more readers sign up for free access? We’ll be successful if we can increase registrations from 30% to 33%.

With this goal in mind, the team can get to work. They can hypothesize, experiment, and validate results-these efforts would then be reflected in the product backlog, with each item aimed at achieving the goal.

Is the Product Goal SMART?

Although the goal is specific, measurable, and relevant to the business, we don’t know if it’s achievable or time-bound. So it doesn’t fully meet the SMART criteria.

However, I don’t always rely on SMART criteria for defining Product Goals, and I explain why during Sprint Reviews…

The Sprint Review Surprise

Many Sprint Reviews fall short of expectations, resulting in frustrated stakeholders who eventually stop attending.

Why does this happen?

In my opinion, it’s often because of how the Product Goal is defined. If the product goal focuses only on features or functions, then only parts of those features can be demonstrated or discussed during the Sprint Review. While these new features may be of interest to company stakeholders, the feedback usually isn’t very useful to the Scrum Team. Why is that? Because the stakeholders aren’t the end users. They don’t interact intensively with these features and therefore provide little valuable feedback. One option might be to invite real users to the sprint review so that they can try out the new features firsthand. But this approach is often impractical. So what else can we do?

Wouldn’t it be better to make the Sprint Review what it is supposed to be? According to the Scrum Guide:

“The Scrum Team presents the outcome of its work to key stakeholders, and progress towards the product goal is discussed.”

It’s important to note the wording here: it doesn’t say the team presents the work, it says they present the outcome of their work. This means that the focus is on demonstrating changes in user behavior, indicating that users are already interacting with the new features. During the sprint review, the impact of these features on business outcomes is presented, which is of great interest to all stakeholders, including management. In other words, a sprint review is not just a demo of new features; it’s a workshop for reviewing and adjusting the product strategy based on changing market conditions.

In this year’s fourth Sprint Review, the numbers for the online newspaper looked like this:

When we analyze the numbers, we see that:

• The subscription rate is climbing towards our target of 33%. Great, goal reached?
• The number of subscribers has increased from 10,000 to 10,184.
• However, the churn rate fluctuates between 6.80% and 7.30%.
• Consequently, the revenue varies between 100,188 and €102,960.
• So far, after one third of the year, we’ve only reached 30.26% of the required total revenue. What does this mean? It means that we can expect an annual income of €1,225,377.60, which is about 15% short of the goal of €1,350,000.

Now let’s remember what the Scrum Guide says:

"The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.".

So I ask you: How would you interpret this situation? Should the team continue to pursue the current goal, or is it time to define a new Product Goal after four months?

A team shouldn’t have to answer these questions alone, which is why we have the Sprint Review. This is where stakeholders can help determine the best course of action; it’s critical to the future of the online newspaper.

Finally, here’s the answer I owe you:

Why shouldn’t Product Goals be SMART? As we’ve seen with the online newspaper example, the future is always uncertain. For this reason, I don’t believe that Product Goals need to be "achievable" or "time-bound. What’s more important is that the Scrum team and stakeholders meet at least once a month to review the results of the team’s work and decide on the next steps.

In this way, the Product Goal serves as a link between user needs and the company’s business strategy -- a link that should be reevaluated monthly.