Leading Through Shared Goals

Ensuring that development teams and stakeholders are moving in the same direction is crucial to achieving product success. But it can sometimes feel like herding cats. In the worst case, people 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 guide and align the development teams and the stakeholders.

The Product Leadership Conundrum

As the person in charge of a product, you are responsible for achieving product success. But can’t do it on your own: You rely on the help of the development team and stakeholders who design, implement, test, market, sell, and support the product. To ensure that their work results in a successful product, they must move in the same direction. Otherwise, the product features, the marketing messages, and the sales channels might either be wrong or they might not fit together.

How can you then align and guide people? And how do you establish sufficient autonomy so that the individuals can own their work and take pride in it? The solution is to establish shared goals that align and guide people. The development team and stakeholders 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 Goal-setting Framework for Product People

Let’s take a look at the goals that help you move your product forward and align people. You can download the framework below by clicking on the picture below.

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, losing weight, or the benefit that users want to obtain, for instance, reducing the risk of developing diabetes. A business goal states the benefits the company developing and providing the product wants to achieve, for instance, diversifying the business, creating a new revenue source, and developing the main brand. Whatever user and business goals you choose, make sure that they are specific enough to select the right key performance indicators (KPIs) and understand if your product is creating the desired value. 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, acquiring users, increasing engagement, generating revenue, or removing 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 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 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 coach like a Scrum Master, 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 unanimous agreement with everybody fully supporting the goals.

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 don’t consider them as helpful. 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.