Christian Neiderstam ← All artifacts
Facilitation tool · not a Scrum artifact

Product Goal selection

For the session where a vision has to become one goal, and three good ideas have to lose.

Stage 3 of 7 · Chapter 3 · Jump to the prompt

This tool belongs to stage 3 of seven: GOAL. WHY VISION GOAL WHAT EPICS STORIES DONE

The problem this solves

A good vision creates a new problem. Everything now sounds worth building, and everyone wants their part first.

Priority disputes are arguments about invisible pictures. Two people say “that's more important” and mean entirely different things, because each is holding a different mental model of effort, value and risk — and neither has said theirs out loud.

You cannot resolve that by discussion. You resolve it by making the pictures visible and letting people point at them.

Move one — zoom in

“Zoom in for me. What's the single most impactful chunk of our vision we could deliver in the next three to six months? Something that proves the idea rather than completes it.”

Two things are doing work there. Chunk of our vision forces candidates to come from the vision rather than from the room. And proves rather than completes gives people permission to propose something small.

Move two — put the argument on a wall

A two-by-two: business impact against effort. Every candidate goes on it, placed by the room, argued about while it is being placed.

The matrix is not the decision. It is the thing that makes the decision discussable. Once positions are on a wall, people stop arguing about priority and start arguing about placement — which is a far more productive argument, because it is about something specific.

And if you do have to show the list — get it said out loud.

Reading a candidate to the room is not the same as the room agreeing to it. Put it up, then wait for somebody to restate it in their own words, and for at least one other person to push back or add to it. Only then is it theirs.

Because if it stays in your wording, you will be quoted as the author of it — and the first time it is questioned, everyone will look at you rather than at the person accountable for the outcome. That is a bad place for a Scrum Master to be standing, and it is entirely avoidable.

The prompt

Use it to prepare candidates, never to rank them. The amber parts are the ones you replace.

Product Goal selection prompt
I am the Scrum Master, preparing a Product Goal selection
workshop. I am NOT choosing the goal — the Product Owner does
that, in front of the room, or he will not defend it later.

Give me candidates for them to place on a matrix and argue
about.

CONTEXT
  Business drivers:  [paste them, with success outcomes]
  Product Vision:    [paste the filled frame, not just the
                      polished sentence]
  Horizon:           [e.g. three to six months]
  Team:              [size, and any known constraints]
  Already proposed:  [candidates people have suggested,
                      in their words]

PRODUCE

Five to seven candidate capabilities, each one a chunk of
the vision that could be delivered inside the horizon.

For each candidate:

1. NAME — one line, an outcome, not a feature list.

2. WHICH VISION PHRASE IT DELIVERS — quote the specific
   part of the vision frame it comes from. If a candidate
   traces to no phrase in the vision, do not include it.

3. IMPACT — one sentence on what changes for the business
   if this ships and nothing else does.

4. EFFORT SIGNALS — not an estimate. Name the things that
   would make this expensive: an external system, an
   unfamiliar technology, a decision nobody has made yet,
   a dependency on another team.

5. WHAT IT PROVES — a goal should test an assumption, not
   just deliver value. Name the assumption this candidate
   would prove or disprove.

ALSO PRODUCE

One candidate that is obviously wrong for this horizon —
too large, or too far from the drivers. Label it clearly.
Rooms calibrate faster when they have something easy to
reject first.

And flag any candidate that would be attractive to the
room for political rather than strategic reasons: somebody's
pet idea, a feature a competitor announced, a thing that
demos well and delivers little.

CONSTRAINTS
  Do not rank them. Do not recommend one.
  Do not place them on the matrix — that is the room's job,
  and doing it for them removes the only part that matters.
  Every candidate must be deliverable inside the horizon.

What it produced for Beauty Spot

Candidates for a three-to-six month horizon, each traced to a phrase in the vision frame.

Five candidates · three-to-six month horizon
01 Personalised profile with a loyalty barcode Impact: members get something they use at a till. Proves: that members will actually present a phone at the counter. Effort signals: point-of-sale scanner hardware nobody on the team has seen.
02 Curated campaign showcase driving to e-commerce Impact: first measurable link between app and turnover. Proves: that in-app browsing converts. Effort signals: depends on the existing e-commerce platform's checkout.
03 Personalised discount alerts Impact: reason to open the app between visits. Proves: that members tolerate notifications from a retailer. Effort signals: needs purchase history, which needs the barcode first.
04 · the pet idea Community forum Impact: hard to state. Proves: nothing measurable in six months. Flagged: attractive for political reasons. Demos well, needs moderation nobody has staffed, and an empty forum is worse than no forum.
05 · deliberately too large Full in-store point-of-sale integration Impact: high. Proves: everything. Not deliverable in the horizon. Depends on a vendor the team has never spoken to.

The forum is the one that matters here. In the book it was my own idea, and Alex cut it — which is the outcome you want, because a goal the Product Owner has pruned himself is a goal he will defend when somebody senior pushes back.

The prompt flagging it as politically attractive is useful preparation. It is not useful in the room. Never say “the model thinks this one is a pet idea” — put it on the matrix with the others and let its position make the argument.

The part that decides whether this works

Somebody in that room has a favourite. Often it is you.

The best cut is the one they make themselves. A Product Owner who removes his own idea from the goal has done something no amount of your persuasion could achieve — and he will defend that goal afterwards, because it is his.

So when a candidate lands bottom-right on the matrix, do not rescue it and do not kill it. Ask:

“So where does that leave it for this goal?”

Then stop talking. The silence is the tool.

Cutting something from a Product Goal is not deleting it. It goes back to the Product Backlog, visible, competing on merit next time. Say that out loud in the room. It is the sentence that makes people willing to let go of things.

The homework applies here too.

Everything in this session lands better if you already know where the sector is going and how this client arrived where they are — the mergers, the exits, the restructure nobody mentions. It is what lets you hear what is underneath a stakeholder's first answer.

There's a research prompt for it on the business drivers page.

Running the session

Before

Candidates come from the vision, not from you. If you cannot trace a candidate to a phrase in the vision frame, it does not go on the wall.

In the room

Zoom-in question. Let the room propose first. Draw the matrix. Have them place their own candidates. Argue about placement, not about priority.

Draft the goal from what survives — and have the Product Owner say it in his own words before anyone writes it down.

After

Close the loop upwards: “Does this synchronise with our vision, or do you see anything that should change?” Asking whether the vision needs to move is what makes this inspect-and-adapt rather than a decision.

Limits

A model can generate plausible candidates. It cannot tell you which one the CFO has already privately vetoed, or which one the team tried in 2023.

And note what this stage is not. Only the Product Goal is Scrum. The matrix, the candidate list, the horizon — all practice. Useful practice, but do not present it as framework.


The same pattern elsewhere

Wrong-list-first works anywhere a group has to produce something from a blank page.

Transparency

An artifact board everyone can open

Transparency is one of Scrum's three pillars, alongside inspection and adaptation. Without it the other two have nothing to work on. It's also what makes a why-to-done chain worth building.

Every outcome of that chain should be readable by anyone involved in the project, formally or informally. Not a folder somebody has to request access to. A board you can open.

That matters most in the later stages. You're four Sprints in, arguing about whether something's in scope. The answer usually sits in a decision made months earlier. And the only useful version of it is the one written down at the time, not the one people remember.

It also means the chain can be inspected. Markets throw curveballs and businesses change their minds. Drivers that were right in January can be wrong by June. Put them somewhere visible, revisit them on a deliberate cadence, and the chain adapts. Leave them in a document nobody reopens and it quietly stops being true.

The stakeholders own the top of that chain — the drivers, the vision and the Product Goal — so they're the ones who inspect and adapt it. Not the Scrum Master, and not the team. Your job is to put the question in front of them on a cadence they've agreed to, and to make sure what they decide gets written where everyone can see it.

Beauty Spot's board is public, and free to read whether you buy the book or not.

Open the board →

This is one of thirty-one artifacts from Worth Building with Scrum: From Why to Done — the chain from a business driver to a line of finished code, worked through one team's four Sprints. About the book · read chapter 1 free.