Leading Through Shared Goals

Ensuring that development teams and stakeholders are moving in the same direction is crucial to achieving product success. But aligning people can sometimes feel like herding cats. In the worst case, they go off in different directions and create work results that don't fit together. In this article, I describe my framework for setting effective goals to help you guide and align the stakeholders and the development teams.

Overview of the Goal-setting Framework

The framework I have developed uses four different types of goals: product vision, user and business goals, product goal, and sprint goal, as the following image shows. You can download the framework below by clicking on the picture below.

The goals in the framework above describe the outcomes you want to achieve. What’s more, they are systematically linked—they inform each other. Let’s take a look at them in more detail.

The Product Vision

The first and possibly most powerful goal is the product vision. It describes the ultimate reason for creating a product and the positive change it should bring about. A sample vision I like to use is “healthy eating.” This example shows that the vision is best captured as a brief statement or slogan.

What’s more, an effective vision inspires people; it provides motivation and purpose. As the vision is a big, hairy, audacious goal, it cannot be measured. In fact, you might never fully realise your vision. That’s okay, as long as it acts as the product’s true north that provides continued guidance. To learn more, watch the following video:

The User and Business Goals

A user goal describes a problem users want to see addressed or a benefit people want to gain, for instance, “reducing the risk of developing type 2 diabetes.” A business goal states the benefits the company developing and providing the product wants to achieve. This might be diversifying the business, opening up a new revenue stream, or developing the main brand.

Whatever user and business goals you choose, make sure that they are clear. It would be a mistake, for example, to state “improve people’s eating habits.” This user goal is too vague. Working with specific user and business goals offers better alignment and allows you to select the right key performance indicators. These help you understand if the product is creating the desired value and if you are making progress towards the goals.

Product Goals

With user and business goals in place, you can take the next step and determine specific product goals. Each goal should be a step towards meeting the user and business goals, and it should describe a specific and measurable benefit or outcome, for example, acquiring users, increasing engagement, generating revenue, or removing technical debt to future-proof the product. I find that product goals are especially valuable to align stakeholders and communicate the impact you want to achieve with your product in the coming months.

The last goal in my framework is the sprint goal. Achieving this goal should move you closer towards meeting the overarching product goal. Each sprint goal is therefore a step towards a product goal.

Sprint Goals

The last goal in my framework is the sprint goal. Achieving this goal should move you closer towards meeting the overarching product goal. Each sprint goal is therefore a step towards a product goal.

When setting a sprint goal, make sure that it states the desired outcome of a sprint, for example, “find out if users are willing to share personal information,” “test integration with leading smart scales,” or “finish the dashboard to release a first version and learn from the feedback.”

I recommend that you derive the sprint goal from the product goal and that you state it on the sprint backlog or task board. This ensures that each sprint moves you closer towards the overarching product goal. (If your development team does not use Scrum, then it might still be helpful to agree on weekly or fortnightly goals that direct the work of the team members.)

The Connections between the Goals

As you may have noticed, the goals in my framework are connected. The vision guides the selection of the user and business goals, which help you choose the right product goals; and a product goal is broken over time into several sprint goals. This way, the vision ultimately guides product delivery.

As you move from the product vision to the sprint goal, the objectives become more and more focused and describe increasingly shorter time frames. A vision might cover the next five to ten years. A sprint goal, however, lasts only two to four weeks.

However, the connections in my framework are not only top-down. They are bidirectional and also work bottom-up. If one or more sprint goals cannot be met, the product goal might have to be adjusted. If you struggle to achieve the product goals you have set, you may have to change the user and business goals. Consequently, you’ll have to keep your goals in sync. To achieve this, you should regularly review them. Inspect and adapt user, business, and product goals at least once per quarter.

The DecisionsGoals and Product Management Artefacts

I need to point out that the goals in my framework don’t exist on their own. Instead, they are related to product management artefacts. I like to capture the vision together with the product strategy, and the strategy should contain the user and business goals.

A handy tool to capture the vision, user, and business goals is my Product Vision Board, which you can download from my website and by clicking on the images below for free. State the user goals in the “Needs” section and the business goals in the “Business Goals” one.

The product goals are best captured on an outcome-based, goal-oriented roadmap like my GO Product Roadmap. Simply use the “Goal” row to state the product goals.The sprint goal, finally, can be captured on the sprint backlog or task board. This way it is visible and directs the work of the development team members. To create effective, outcome-based sprint goals, use my sprint goal template.

What about OKRs?

You might be wondering if and how my framework is connected to OKRs—to objectives and key results. OKRs are a goal-setting method, which was originally developed at Intel in the 1970ies and has become increasingly popular in recent years. My framework states the type of goals you should have in place to achieve product success—but it does not prescribe how you formulate them. You can therefore use OKRs to express the goals in my framework.

Having said this, I am not a big fan of using OKRs in product management, though. I prefer to work with visual tools like my Product Vision Board and GO Product Roadmap, as I explain in more detail in the article OKRs in Product Management.

But no matter which method you choose, the important thing is that you set the right goals—that’s what’s going to help you most in offering a great product and achieving product success.

Getting to Shared Goals

It’s great to know what goals are helpful to direct and align the development team and stakeholders. But it’s not enough. The individuals involved in developing and providing the product must support the goals to move together in the same direction. Otherwise, people are likely to follow their own goals; orchestrating everyone’s efforts will become very difficult, if not impossible.

The best way to achieve strong-buy in is to actively involve the right people in the goal-setting process. I like to bring together the development team members and key stakeholders and run collaborative workshops with them: a strategizing workshop to come up with a meaningful, inspiring vision everybody believes in and a product strategy that contains the right user and business goals; a roadmapping workshop that identifies realistic product goals using the product strategy as an input; joint product strategy and roadmap review meetings to update or change to the strategy and roadmap; and sprint planning meetings that establish meaningful and realistic sprint goals. (Note that stakeholders don’t participate in sprint planning meetings in Scrum. Instead, they are invited to offer feedback on the latest product increment in the sprint review meetings.)

Bringing together the right people allows you not only to generate strong buy-in; it also leverages their collective knowledge and creativity, and establish meaningful goals—goals that are worthwhile to pursue. But a collaborative approach also carries the risk of friction and conflict. In the worst case, powerful individuals (HIPPOs) might hijack the process and dictate goals.

To mitigate these risks, I recommend that you involve an experienced coach like a Scrum Master, who sets the ground rules, facilitates the workshops, and ensures that everybody is heard, and nobody dominates. Additionally, make sure that you apply the right decision rule. For example, you might want to use unanimous agreement to set the vision and consent to choose the right product goals. Watch the video below for more guidance.

Be careful, though, that you don’t make the mistake of trying to please people and brokering a weak compromise. Don’t be afraid to say no when appropriate. At the same time, value people’s ideas and appreciate their concerns even if you don’t agree with them. When you care about the individuals and understand their perspectives and needs, they are more likely to support the goals even if they don’t fully agree with it.