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.
Post a Comment or Ask a Question
16 Comments
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 .
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!
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.
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
Thank you for your feedback Virtue. I am glad that you found the article helpful.
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,
Rebecca
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!
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.
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?
Cheers,
Christian
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
Kishan Malur
Thank you for your feedback Kishan and for sharing your takeaways. Good luck with using the goals!