Photo by Tim Foster, courtesy of Unsplash

Leading Through Shared Goals

Published on 6th February 2018 Last Updated on: 17 Aug 2023

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.

Cascading Product Management GoalsThe 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.

Post a Comment or Ask a Question


  • Chris C says:

    Although I have been working as a product manager with agile scrum frameworks for some time now; I’m only really just starting to appreciate how broad the discipline really is.

    I just found your article, and it really struck a chord with me and some of the challenges we face. The way you have explained this is perfect. This will really help me in my current and future career. Thanks!

  • says:

    Thanks for the write up, I am enjoying your blog posts.

    Two key takeaways for me in this post are
    1: Teamwork needs a common goal .
    2: The right team members are also very strong .

    • Roman Pichler Roman Pichler says:

      Hi Jackie,

      Thank you for your feedback. I am glad that you enjoy reading my articles. You are right: Effective teamwork requires a shared goal. In a product context, teams benefit from several, cascading goals, as I argue in the article: a longer-term inspirational visionary goal, mid-term strategic goals, and short-term tactical ones. (I explain working with cascading gaols in more detail in my book “How to Lead in Product Management“.) But goals alone are not enough, of course. Having the right people on board and helping them do a great job is at least as important.

      Hope this helps!

  • Inna says:

    Amazing article Roman! And thank you for the tools. I love how they relate to each other, and the logical chain of how one affects the other. Great tooling for visualization of the process for stakeholders and teams. Thank you!

    • Roman Pichler Roman Pichler says:

      You’re very welcome Inna. Thank you for your feedback. I am glad that you found the article helpful.

  • Virtue says:

    Thanks, Roman,

    Nice article. Its been helpful for me in my current job as a Product Manager especially in being goal-oriented in all product-related activities

  • Rebecca says:

    Hi Roman,

    What do you think about stretch goals?
    An Agile Coach recently introduced them to a colleague but I’m not so sure. Have read mixed opinions on them.

    Many thanks,


    • Roman Pichler Roman Pichler says:

      Hi Rebecca,

      Thanks for sharing your question. I find that sometimes people misinterpret the term stretch goal, so let me first quickly clarify what it is: It’s an ambitious goal that requires a special effort to be reached. Stretch goals usually involve radical expectations that go beyond current capabilities and performance, and they require new approaches in order to meet them (see “The Stretch Goal Paradox“).

      Based on this definition, the vision makes a good stretch goal: It is an ambitious goal that wants to inspire people. Remember, though, that the vision cannot be measured and may never be fully reached. The other goals discussed in this article should all be realistic: You should be confident that the user, business, and release goals can be met, and so should be the development team and stakeholders. Formulating them as stretch goals risks demotivating the development team and losing the trust of the stakeholders. Sprint goals, finally, must be realistic and achievable. Otherwise, teams simply can’t, and shouldn’t, commit to them.

      Hope this helps!

  • Federico says:

    Great insights Roman, thanks for sharing.
    I’ve found very useful to change the approach to tackle problems instead of jumping right ahead into building the solution. That gives you the possibility of talking about GOALs and KPIs you can translate later into “attainable goals” using a roadmap for instance.
    Have you ever used OKRs to define the business goals / user goals? If so, in which situation.
    Thanks again.

    • Roman Pichler Roman Pichler says:

      Thanks for your feedback and question Frederico, and great to hear that you find working with goals helpful. Here is how I would answer your question: The user and business goals are the objectives; the product capabilities are the key results. The KPIs ensure that the goals are specific and measurable, and they allow us to determine if we are likely to meet the objectives. Does this help?

  • Christian Prison says:

    Nice article (again)! I can absolutely subscribe to everything you said – but I fail sometimes finding the right balance in reminding the team about the shared goals which are ahead of the sprint goal and letting them concentrate on their job (programming). Sometimes the Visioning Meetings, Backlog Refinement or Sprint Plannings occur rather boring to them since they prefer coding over meeting. Any ideas how to balance alignment and focus?


    • Roman Pichler Roman Pichler says:

      Thank you for your feedback Christian and sharing your question. I find two activities helpful to establish and reinforce shared goals: collaborative product discovery and joint product backlog grooming (refinement).

      Additionally, I like to have a Product Vision Board with the vision and product strategy including the user and business goals, as well as the product roadmap on the office wall. This makes the overarching goals visible, and reminds the dev team why the current sprint is carried out.

      In order to avoid that the team loses focus in a sprint, I like to allocate time for joint product backlog and discovery activities in the sprint planning meeting, or use a sprint to experiment and create new knowledge.

      Does this help?

  • Kishan Malur says:

    Thanks for the write up, I am enjoying your blog posts.

    Two key takeaways for me in this post are

    1) The chain of goals concept. It’s something I will definitely try

    2) product vision board

    Kishan Malur

    • Roman Pichler Roman Pichler says:

      Thank you for your feedback Kishan and for sharing your takeaways. Good luck with using the goals!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.