Goals - Product, Sprint, and Otherwise
Breaking down goals, how to set them, and how to actually derive value instead of just going through the motions.
I’ve been receiving educational lectures on goals since elementary school. SMART goals, career goals, goal setting, goals to execute other goals, how to measure the goals set to execute other goals... you get the picture. I’ve also found that our obsession with goals has bled into the world of product management, and, while well-intentioned, often does more harm than good.
I work in an Agile shop. This Agile shop is more or less in line with most other Agile shops. Work is organized into logical orders like company vision and initiatives, which house specific product features or enhancements, which are comprised of sprints and issues.
Simple enough.
Now I want to pause here and say that this blog post is not intended to be a discourse on agile project management or the nuances of hierarchical project organization. There are enough artifacts on those subjects to fill many lifetimes worth of certifications, we don’t need yet another. I do, however, want to talk about the functional use of product goals and the associated sprint goals as a means toward a productive end. Let's start with definitions:
A Product Goal is a quantifiable and explicit objective intended to articulate and guide a development team toward an outcome or solution to a specific problem.
A Sprint Goal is a quantifiable and explicit set of objectives indented to drive a development team toward a desired outcome within a two-week sprint.
Running with these two definitions, there are two key differences: Duration and Rigidity.
If the point of a Product Goal is to convey information resulting in a solution or outcome, it can be argued that the manner in which the solution or outcome is achieved is irrelevant. In other words, creativity is encouraged.
Sprint Goals on the other hand are meant to drive the completion of formalized and, if written correctly, explicit sets of user stories. The outcome, method, tools, details, test, and all other information has been predefined, timeboxed, estimated, and otherwise penned with the intention of minimal deviation from the plan. In this case, creativity is not really appreciated.
Far too often we see success in the execution of our explicit and regimented sprint goals, apply the pattern to a product goal, and are subsequently frustrated with the product fails upon deployment. Why? Because we force a creative and organic outcome through an overly explicit and inflexible system for the sake of having something measurable and objective.
So, what makes for a good Product Goal then?
It’s outcome-oriented: “This product solves X problem”
It associates outcome with value: “This product will enable Y return on Z asset or market”
Its value is aligned with a business objective: “The product allows us to best our competitors’ value prop and win back market share”
And most importantly, it solves an existing problem: Money follows pain.
Over-enforcing process or organizational frameworks upon creative outputs significantly interferes with the path of least resistance and greatly increases the necessary escape velocity for your product to skyrocket. We should encourage PMs to spend their time doing market research, vetting outcome impacts, and doing the hard work to validate the value to be derived, not filling out overly verbose templates or ensuring that their SMART Product Goal is smart enough to get a 36 on its ACT.