Using Goals for Product Delivery

Product Delivery is an emerging, nonlinear process with many unknowns. Unsurprisingly, the odds of building a successful product are extremely low when a predictive method is used instead of an empirical approach. The empirical approach involves making decisions based on evidence, and in a space with many unknowns, goals provide direction and focus within a set timebox.

Many people have written about their experiences and research into using goals for Product Delivery; however, our work shows that adopting goals remains a challenge, especially in large organisations. Several reasons are cited for the struggle, including competing demands from customers and stakeholders, regulatory and compliance needs, and fixing Production defects, among many others. 

A business leader once told me, “This is all too simplistic.”

All these reasons point to a struggle and inability to focus; these factors lead to organisations trying to do too many things and end up building silos into their teams.

I like to refer to goals as the compass that guides product development, providing direction, focus, and clarity. In the dynamic world of product delivery, understanding how to craft, implement, and adapt goals is crucial for team success.

Goals serve as a north star for product teams, creating a shared understanding of what needs to be achieved. In the Scrum framework, this is epitomised by Product Goals and Sprint Goals, which:

• Provides a clear, unified vision for the entire team and their stakeholder

• Create transparency by making expectations explicit and the ability to inspect progress toward these expectations.

• Aligns team efforts towards a common objective.

• Enable stakeholders to understand the team's current direction and progress.

I want to emphasise the third point, aligning the team with a common objective. Setting great goals won’t eliminate all disruptions, but it should provide a framework for the team to evaluate unexpected work and minimise disruptions to work towards the objective. In addition, the team designs a process for handling urgent and unplanned tasks. One strategy we’ve used with our clients is to help their teams ringfence the majority of their capacity towards the strategic objective that the Goal represents.

Some other approaches that have helped with the use of goals for Product Delivery include:

• Allocate a small percentage of sprint capacity for unexpected work

• Use a clear prioritisation framework for evaluating interruptions

• Maintain transparency about how unexpected tasks impact goals

• Regularly reassess and adjust goals based on emerging insights

I find two elements of the Scrum Framework handy for Product Delivery: Product Goals and Sprint Goals. These are two types of goals with different delivery horizons. Typically, the Product Goal represents a Strategic Direction toward the Product Vision, while the Sprint Goal represents a tactical direction toward the Product Goal.

The Product Goal guides the emergency of the Product Backlog, and most of the Product Backlog Items should be represented by the Product Goal but not limited to it. In practical terms, work to keep the product stable, Product Defects, and Regulatory work should be carefully planned alongside work to deliver the Product Goal.

Similarly, the Sprint Goal guides the selection of Product Backlog Items into the Sprint Backlog but should not be limited by the Sprint Goal.

Validation: Measuring Progress toward the Goal.

It wouldn't be an empirical or evidence-based approach if we didn't discuss how to validate progress towards the goals. Using the examples from the Scrum Framework, the Sprint Goal can be tactical and is easier to measure, as it presents the output of the team’s work. It provides flexibility to the developers on how to get the job done, and it is relatively easy to determine if the Sprint Goal has been met.

On the other hand, Product Goals measure the desired outcome, which is much more challenging. These measures are lagging in nature, and what has worked with some of our clients is to derive some leading indicators that indicate whether the team is moving in the direct direction of the Product Goal.

The diagram below shows how the Product and Sprint Goals are related. Although this may not fit your context, we hope it paints an excellent picture of how you might approach using goals within your context.

When implemented thoughtfully, the adoption of Goals transforms product delivery from a chaotic journey to a focused, collaborative effort. As with everything else, it takes a lot of practice before your teams get comfortable with goals, and this shouldn’t be an excuse. One final word is that most teams create items that represent work and then retrofit a goal that they believe should represent these items. It is the other way around; Leaders should build a process for creating goals collaboratively, thinking about the most value for the product's users; only then should items be created.