Product Ownership is Goal Oriented

According to Scrum, the Product Owner is the person responsible for the ROI of the "product" (whatever a "product" is in your world). Being responsible for the ROI, the business case, simply means that you are to make sure that the value brought to you by the product over time is higher than the cost of taking you there.

The cost comes from having people do things to the product. Those things we call "tasks". Goals is mapped to the tasks needed to achieve them.

Now, if we set a goal for the product that should be met once a year, they will probably be mapped to a huge amount of tasks (or else we should be able to meet the goals much earlier). The problem with that is that we will never know where we are in relation to our goal until it is too late. Yes, we can follow up on the tasks during the year, but we will not be sure whether the tasks ultimately will make us achieve the goal. Halfway through the task-list: are we really halfway to the goal?

This is a symptom of having feedback-loop that is way to slow. And we won't move faster in the loop if we just follow up on the tasks more often and check whether they are completed in due time. The completion of tasks alone doesn't tell us where we are in relationship to our goal.

This is why successful product ownership is goal-oriented in all stages. The interesting question is always what the product's capabilities are at a certain point in time. When detailing what we are trying to achieve, we find lots of sub-goals that need to be met in order to reach there. When we specify and follow up on those sub-goals instead of tasks, we will always have a clear indication on how far we are from meeting the greater goal.

User Stories are Goals

The concept of user stories supports this. A user story is the most fine-grained unit that exists in the backlog, and specifies a small feature that is useful for a certain kind of user (which is specified, and because of a business reason, which is also specified). In order to be doable in a predictable manner by the developers, it should also be small enough to fit into a predefined time-box (such as a sprint in Scrum). A user story doesn't specify a task, doesn't tell anyone what to do. It declares a small goal that the product should be able to meet. Goal oriented.

So as product owners we need to find a way to work with the goals, from the targets that may be set yearly by a product management, down to the doable user stories that are to be implemented in the following sprint. What tasks need to be done is up to the teams to figure out, we should focus on goals.

There are a couple of strategies one can use for both goal refinement and goal break-down, and I will return to them in time. I recommend for example a classification where a Business Goal is broken down into one or many Features, where each feature is implemented through a set of User Stories, of which some of them are Epics (= too big stories that need to be broken down further).

But no matter what strategies you employ, make sure that all your backlog items - from the largest to the smallest - are expressed as goals.