Leading Through Shared Goals

As a product manager or product owner, you guide and lead the development team and stakeholders. But you usually don't have the authority to tell people what to do. Creating alignment and ensuring that everybody is moving in the same direction can consequently feel like herding cats. Luckily, there is a solution: working with shared, connected goals, as I explain in this article.

The Product Leadership Conundrum

As the person in charge of a product, you are responsible for achieving product success. But you can’t accomplish it on your own: You rely on the help of the development team and stakeholders. Their contributions are vital to design, implement, provide, and support a successful product. At the same time, you can’t tell the individuals what to do and assign tasks to them. Additionally, you are typically not in a position to offer a bonus, pay rise, or other incentives.

This raises the question of how you can align people? How can you ensure that everyone moves in the same direction and carries out the necessary work? And how do you establish sufficient autonomy so that the individuals can own their work and take pride in it?

Part of the solution is to establish a set of shared goals—goals that people support and that help you progress your product. The development team and stakeholders then use these goals to determine the work they have to do—be it creating a marketing strategy, investigating a new technology, or preparing the distribution channels.

This focuses everyone on the joint outcomes you need to achieve, and it gives people the freedom to manage their work, thereby creating purpose and autonomy.

A Chain of Goals

Let’s take a look at the goals that help you move your product forward and align people.

The picture above shows a set of goals that are linked and operate at different levels. The first and possibly most powerful goal is the vision, which describes the ultimate reason for creating your product and the positive change it should bring about. An example I like to use is healthy eating. As this example shows, the vision is an inspirational, visionary goal that cannot be measured.

The user and business goals are strategic goals that are derived from the vision. The former describes the problem that users want to see addressed, for example, lose weight, or the benefit that users want to obtain, for instance, reduce the risk of developing diabetes. A business goal states the benefits the company developing and providing the product wants to achieve, for instance, diversify the business, open up a new revenue stream, and develop the main brand. Whatever user and business goals you choose, make sure that they are specific and measurable. This allows you to select the right key performance indicators (KPIs) and understand if your product is meeting its goals. I like to capture vision, user, and business goals on my Product Vision Board.

With user and business goals in place, you can take the next step and determine specific product goals. Each product 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, acquire users, increase engagement, generate revenue, or remove technical debt to future-proof the product. I like to capture product goals on the product roadmap together with their metrics, and I have a preference to work with a goal-oriented (or themed) roadmap like my GO Product Roadmap.

Finally, identify the right sprint goal. A sprint goal states the desired outcome of a sprint, such as 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 to the test group. I recommend that you derive the sprint goal from the product goal and 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 works with Kanban instead of Scrum, then it might still be helpful to agree on weekly goals that direct the work of the team members.)

Every sprint goal should be a step towards a product goal; every product goal should help you reach a user or business goal; and the user and business goals should help you realise your vision. The different goals are therefore linked and form a chain that covers all product planning aspects: visionary, strategic and tactical ones.

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 and key stakeholders and run a 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 it 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 goal-setting process and dictate goals.

To mitigate these risks, I recommend that you involve an experienced ScrumMaster, coach, or facilitator, who sets the ground rules, facilitates the workshops, ensures that everybody is heard, and nobody dominates. Additionally, make sure that you apply the right decision rule. As vision, user, and business goals are particularly crucial, you should attempt to achieve consensus, ideally in form of unanimous agreement with everybody fully supporting the goals. (You may want to download my decision-making chart to select the right decision rule.)

If you feel that an open, collaborative approach is not feasible, then consider running individual meetings with the various stakeholders and development team to discuss a draft goal, incorporate people’s feedback, and rework the goal so that everybody can support it.

No matter which approach you choose, be careful that you don’t become a goal broker or mediator: Actively shape the goals and avoid making weak compromises to strike a deal or please people. Don’t be afraid to push back and say no when appropriate. At the same time, appreciate people’s ideas and concerns even if you feel they are not helpful or appropriate. When you care about the individuals, empathise with them, and understand their perspective and needs, they are more likely to support a goal even if they don’t fully agree with it.