Have you ever been in a situation where you are working on an assignment – which, of course, is being executed to perfection – and suddenly think to yourself:
Why is it exactly that I'm working on this? Is it even relevant? How will this assignment create any kind of value for me, my organization, and our customers?
I think this train of thought is very common among product developers.
One of the reasons we think this way is that there often seems to be a gap between our everyday work items and our product goals. This statement might sound weird, as an intrinsic part of a product goal is to set a direction for work on the product. Still, I see many organizations use time and money to create product goals, but they never seem to fall into place as part of product development. You might argue that our daily work originates from a well-prioritized product backlog.
However, if your product backlog items haven't been aligned with your product goal well, then you have just made a well-established plan to go off course. If you are reading this article, I assume you are familiar with the concept of product goals and maybe even like the idea of using them. But you might find it challenging to integrate goals as a natural part of the development process.
In this article, I will share my thoughts and findings on how you can bridge your daily work with your goals.
A product goal should descend directly from your Product Vision as part of the Product strategy. Imagine the vision as the peak of Mount Everest. The strategy and the underlining product goals are the camps along the way to the top. Sometimes the peak can seem so far away that it becomes discouraging and difficult to handle. And this is where a product goal can help you make your journey more manageable and ensure that you and your team are on the right track to deliver the intended value.
In 2020 product goals were added to the Scrum Guide to emphasize the importance of having a long-term goal in addition to the Sprint Goals. In the guide, it is referred to as an artifact that can help create focus, knowledge integration, motivation, and team effectiveness – And that sounds great, right?!. However, if you use Agile frameworks like Scrum, it can be challenging to figure out how to integrate a product goal. I often experience product goals being invisible or even non-existing for the product teams. I would argue that if we manage to make our goals visible and relevant for our product teams, it would be the key to our products to succeed when reaching the market.
If you would like to learn more about product goals, I recommend you look at this article from scrum.org's website – The Product Goal explained.
So how do we bridge the gap? Let's imagine that we have a clear and well-defined product goal, and we might even have well-established cadences within which we deliver our work. So, how do we bridge the two so the work we deliver also benefits our goal? I will argue that there are six pillars to support that bridge.
Start by making your product goal clear and easy to understand. Doing so will make it much easier for teams to adopt and become invested in the goal. I would argue that if you phrase your goal so the average person on the street can understand the value you intend to bring, then you have done a great job.
A good way to make the value of the product goal clear is to create ways to measure success. In addition, a product goal should include metrics that act as our measurables. They will indicate an intended success criterion and clarify when you have reached your goal. To learn more about setting product goals and success metrics, I recommend you read this article from Prodbee, "How to set Product Goals & Success Metrics" https://prodbee.com/product-goal-metrics/
Here are a few examples of metrics:
Business – Revenue, Profit, or Efficiency
Users – Target group usage
Platform – Page load time or Downtime efficiency
Having clear and measurable metrics should also make the next step easier. Because now, we need to communicate the product goal and make it relevant to our peers.
If we want the goal to guide our work, we have to ensure the goal is communicated effectively. Including the communication to and alignment with our stakeholders that this is the intended goal and these are the metrics we are striving toward. But just as important is the communication process with your product team. You should make it clear why the goal is important – let your team understand the value they will bring when they reach that goal – hint: use your metrics.
If the team can relate and maybe even share your investment in the goal, it will create a shared unity and focus on reaching that goal. Doing so will also make it very transparent why the team does the work they do. Communicating your product goal is not a one-time thing – it should be done frequently and continuously so that the team is reminded of what they are pursuing. If the goal evolves, then make it clear to everyone involved and then share an updated version of the goal.
Planning is a key event in agile software development, but it is also an obvious place to bring in the product goal. Even though it might seem obvious, it is rarely something I see as part of the planning session. We should use this chance to pause and align our upcoming work based on our goal. If they are, in fact, aligned, our planned work for the next iteration will for sure bring direct value towards reaching our goal.
Sometimes even product goals can seem so distant that they become unattainable. In that case, you can break the product goal into smaller sub-goals.
Hint: You can use sprint goals as sub-product goals.
If you are in a scaled setting where numerous teams work on a shared goal, then include it as part of your Big Room/PI/Master planning. Compare your work items with your goal before you start planning anything. Use the goal as a bearing mark during your planning sessions as an indicator of whether you are on the right track or not. The goals and their metrics will also help you clear out any irrelevant work on the product backlog.
Hint: Incorporate your product goal as an integrated part of your planning board.
Making your goals visible seems simple, but it is a rare sight. I often experience that the goals are in some PowerPoint presentation hidden away in a folder somewhere. In all fairness, many of the process tools we use to manage our daily work do not include product goals as a feature. However, I think it should and should be included in block letters as the guiding star that we follow every day when we look at our assignments. Try to help your teams by making your goal and its metrics accessible and visible in your workspace. I strive to bring in the goal whenever a team has a product conversation. The product goal might not be the point of the topic, but if it is there, it often seems to impact the conversation and make it more relatable to our goal. It can also work as an anchor if the conversation goes off-topic. Hey guys! Is this conversation important to what we are aiming for? Trust me, visibility might seem simple, but it will have a huge impact.
If you have a review with your stakeholders as part of your cadence, then make a great deal out of your goal achievements. Let your stakeholders know that value is delivered continuously. Tell your stakeholders that you are one step closer to the product vision – and share any new learnings you had reaching for that goal. If new learnings indicate a change of direction, then make that clear to the stakeholders. Likewise, if your goal is in danger of becoming obsolete because of new learnings, work with your stakeholder to refine the product goal and its metrics.
Hint: Learning something can be as valuable as any written code or implementation. Even negative learnings! Help stakeholders understand the value of learning and adjustments.
Celebrate your achievement! We often forget to celebrate when we reach our goals. I have seen numerous occasions where teams pass by milestones as if nothing ever happened. HALLO! We just reached a new base camp – let's celebrate! But how do we celebrate? Make a gimmick out of it - the last time I reached a goal with a team, I made a beer-tasting event. It was simple and fun, and the team invested more in making future goals. Make sure that everyone sees or hears that you have reached a goal. The excitement of external parties will have an immediate positive impact on the product team's motivation. We need to celebrate; it will make the product journey a lot more fun and our work more meaningful.
Hint: My favorite goal-setting tool is Objectives and Key Results (OKR). I can recommend the book "OKR at the center" or the blog post (in danish): OKR: Det nye sort – eller bare et falmende modefænomen indenfor produktudvikling?