The Product Owner Toolbox

I was a product owner for more than four years: for Quickline’s TV products, then at localsearch, then as head of the product owners at Lifestage before I took over IT. Today I’m on the other side of the table. I work with product owners, I hire them, and now and then I have to explain why a team with a full backlog still isn’t shipping anything that matters.

It’s rarely because a method is missing. Usually the methods are all there, but nobody remembers what they’re for. The user story template is filled in perfectly, there’s a Definition of Ready that nobody reads, and the backlog has 600 items that nobody has the heart to delete.

So over the next few months I’ll go through the toolbox one tool per post, in the order you actually need them: from the product vision down to the story the team picks up on Monday, and the checklist that says it’s done.

Most of these tools aren’t mine. INVEST is Bill Wake’s, story mapping is Jeff Patton’s, the vision template is Geoffrey Moore’s. I’ll name the source each time. What’s mine is the opinion on which parts hold up in practice.

One example, all the way through

Tools explained one by one end up standing next to each other instead of connecting. So the whole series uses a single example.

A company with 300 employees handles holiday requests with an Excel file on a shared drive. You send an email to your team lead, the team lead replies, someone forwards it to HR, and HR updates the file. Nobody knows their remaining balance without asking. Every August, half of the warehouse is away at the same time.

Everyone knows it’s bad, but nobody owns fixing it. We’ll build the replacement.

It’s a deliberately boring example. Most of the software a company needs is boring.

What a product owner is for

The job fits in one sentence: maximise the value of the product. Everything else serves that.

That sentence is useless until the team agrees on what “value” means. For the leave tool it could be less time HR spends chasing approvals, fewer teams that are half empty in August, or employees who know their balance without asking. These goals pull in different directions. The product owner chooses between them, says out loud what was chosen, and sticks to it for longer than a sprint. That is what a roadmap is for: it turns value into a commitment instead of a mood.

Seven principles worth keeping

Maximise value. Value means something to the user and to the company. If you can only name one of the two, you haven’t found it yet.

Refine continuously. A story records who wants what and why. The team gets to a shared understanding by looking at it from several angles (business, UX, testing, development) at the right time, not in one big workshop at the start.

Reduce waste. Delete backlog items that won’t deliver the value you’re after, and do it early. That goes double for stories that have been in the backlog for a year without anyone touching them. Ignore sunk costs: the time it took to write them is gone either way.

Be transparent. Put the product backlog, the product goal, the sprint goal, the increment and the Definition of Done where the team and the stakeholders can see them, and talk about them. Transparency also means explaining why priorities changed and saying plainly what didn’t get done.

Keep it simple. If a story is small, it can deliver a small piece of value on its own and fit into a sprint. Complexity will show up on its own soon enough, so there’s no need to invite it.

Fail early, fail cheap. Mistakes will happen. The cheapest place to make them is before anything is built. Validate with real users, turn only validated ideas into code and drop the rest.

Build quality in. In an agile setup, quality isn’t a phase at the end. It starts with the backlog item: regular refinement, a Definition of Ready, testable acceptance criteria and pairing.

Five things a product owner actually does

1. Communicate. The product owner is the interface between the business, the users and the team. Most of the work happens in refinements and plannings, and in all the conversations in between.
2. Know the users. Surveys, interviews, prototypes, A/B tests, feedback channels. A product owner who only knows the users through stakeholders is relaying someone else’s opinion.
3. Turn needs into backlog items. The product owner owns the what. The how belongs to the team.
4. Prioritise. Order the backlog by business value. Anyone can write a story, but only one person decides the order. If that isn’t clear, you don’t have a product owner, you have a committee.
5. Accept and collect feedback. At the end of the iteration, the product owner checks the work and accepts it. Then they get feedback from the people who use it and turn that into the next changes.

What this looks like varies from one organisation to the next. The five jobs stay the same.

Next

Before we write a single requirement for the leave tool, there’s one thing to settle: how much to write down, and when. The answer is less than you think, and later than you think.