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.
Post a Comment or Ask a Question
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!
Thank you for your feedback Chris. Great to hear that you found the article helpful!
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 .
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!
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!
You’re very welcome Inna. Thank you for your feedback. I am glad that you found the article helpful.
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
Thank you for your feedback Virtue. I am glad that you found the article helpful.
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.
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!
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 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?
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?
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?
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
Thank you for your feedback Kishan and for sharing your takeaways. Good luck with using the goals!