# Product ownership: outcomes, not output

*Saying no to good ideas, and why a roadmap of dates is a promise you cannot keep.*

## Production summary

- Modules to record: 2
- Total script: 1103 words, about 7 minutes of finished audio
- Voices: Amara (host) and Nadia (practice educator)
- Level: New product owners and product managers

## Accreditation wording that must appear in the description

- **The CPD Certification Service** (planned): Application scheduled.

> Do not upgrade any of these words in a description or a thumbnail. Aligned is not accredited, and planned is not approved.


---

## Outcomes, prioritisation, and saying no to good ideas

**Runtime** about 4 minutes. **Words** 602. **Starts at** 00:00 in the full course recording.

### Learning outcomes to state on camera

- Distinguish output from outcome
- Prioritise with a transparent method
- Say no in a way that preserves the relationship
- Write a roadmap that does not promise dates it cannot keep

### Script


`[CUE 1]` *Fourteen features shipped beside an unchanged outcome metric.*

**AMARA**  [00:00]
My product owner role has turned into writing tickets for other people's requests.

**NADIA**  [00:05]
Which is the standard failure mode, and it happens because every individual request is reasonable. Nothing arrives that is obviously stupid, so saying yes always feels correct in the moment.

**AMARA**  [00:17]
So what makes it a real job?

**NADIA**  [00:20]
Deciding what not to build. That is the whole thing. Anybody can maintain a list of what people asked for.

**AMARA**  [00:28]
Start with outcomes then, because I get measured on delivery.


`[CUE 2]` *Before and after: expected change written down, then revisited.*

**NADIA**  [00:32]
Then let us separate two words that get used interchangeably. Output is what you shipped. Outcome is what changed.

**AMARA**  [00:39]
We shipped fourteen features last quarter.

**NADIA**  [00:42]
That is output. Did anything get better?

**AMARA**  [00:44]
Honestly, I do not know.

**NADIA**  [00:46]
And that is not a criticism, it is the normal state. Output metrics feel good because they are countable and always go up. Features, story points, tickets closed. None of them tell you whether the product improved.


`[CUE 3]` *A backlog with forty urgent items, carrying no information.*

**AMARA**  [01:01]
What should I measure?

**NADIA**  [01:03]
Fewer things, and harder ones. Did the task people struggled with get easier. Did support calls about it fall. Do more people finish it. Do they come back.

**AMARA**  [01:14]
How do I make that a habit?

**NADIA**  [01:17]
Before you start anything significant, write down what you expect to change and how you will know. Then, and this is the part everybody skips, actually go back and look.

**AMARA**  [01:29]
Nobody goes back and looks.


`[CUE 4]` *A visible prioritisation score being argued with, versus a feeling being escalated over.*

**NADIA**  [01:31]
Almost nobody, which is why almost no team can tell you whether what they built worked. And if you cannot say what will be different and how you will measure it, you are not prioritising the work. You are just agreeing to it.

**AMARA**  [01:48]
Prioritisation. Everything in my backlog is marked high.

**NADIA**  [01:51]
Then it contains no information. Forty urgent items is the same as zero urgent items, just with more anxiety attached.

**AMARA**  [01:59]
Which framework should I use?

**NADIA**  [02:01]
Genuinely, almost any of them. Weighted shortest job first, value against effort, RICE, a two by two grid. The value is not in the score.


`[CUE 5]` *The displacement question moving a decision to the authority.*

**AMARA**  [02:11]
Where is it?

**NADIA**  [02:12]
In the conversation the score forces, and in the fact that it is visible. A stakeholder can argue with a score. They cannot argue with a feeling, so instead they go over your head. Method is what stops that.

**AMARA**  [02:28]
Right. Saying no. This is the bit I dread.

**NADIA**  [02:31]
Then stop saying no. Say: yes, and here is what it would displace, so which do you want more?

**AMARA**  [02:39]
That is the same sentence from project management.


`[CUE 6]` *Roadmap as now, next, later with problems rather than dated features.*

**NADIA**  [02:42]
It is the same sentence, because it is the same underlying problem. It converts a refusal into a trade and moves the decision to wherever the authority actually sits.

**AMARA**  [02:54]
Anything else?

**NADIA**  [02:55]
Be explicit about the criteria. We are prioritising anything that reduces onboarding time this quarter. Yours does not, so it sits below the line until the quarter turns. That is answerable and it is not personal.

**AMARA**  [03:09]
And if I just quietly drop things?

**NADIA**  [03:12]
They come back louder, through somebody more senior. Keep a visible not now list. People tolerate not now far better than they tolerate being ignored.

**AMARA**  [03:22]
Last thing. My roadmap has dated features on it.

**NADIA**  [03:25]
Then it is a set of promises you cannot keep, and you will learn that expensively. The further out the date, the less it means, and yet it gets quoted back at you with exactly the same confidence as next week.

**AMARA**  [03:42]
But people want dates.

**NADIA**  [03:43]
They want confidence, so give them honest confidence. Now, next, later. Under each, the problem and the expected outcome rather than the solution and the date. Firm for this quarter, directional beyond it, and say which every single time you share it.

### Sources for the on screen credit

- Outcomes over outputs in product management literature, Product management research
- The Scrum Guide, Scrum.org
- Government Digital Service product management guidance, GDS

---

## Discovery: knowing before you build

**Runtime** about 3 minutes. **Words** 501. **Starts at** 04:00 in the full course recording.

### Learning outcomes to state on camera

- Run discovery that produces decisions rather than decks
- Talk to users in a way that yields truth rather than politeness
- Write and test assumptions cheaply before committing a team
- Kill an idea well, and keep the learning

### Script


`[CUE 1]` *Discovery and delivery as two questions: should we, then can we.*

**AMARA**  [04:00]
My roadmap is full before any discovery happens. Is that normal?

**NADIA**  [04:05]
It is normal and it is backwards. Delivery answers whether we can build it. Discovery answers whether we should. Skip the second question and you spend three months building what a week of discovery would have killed.

**AMARA**  [04:20]
So what does discovery actually consist of?

**NADIA**  [04:22]
Assumptions. Every idea rests on a stack of them. People have this problem. It is painful enough that they act. They would use this solution. They can find it. It is worth what it costs.


`[CUE 2]` *An assumption stack ranked by fatality, with the fatal one tested first.*

**AMARA**  [04:36]
And I test them?

**NADIA**  [04:38]
In the right order, which is the part everybody gets wrong. Rank them by how fatal it would be to be wrong, and test the most fatal first.

**AMARA**  [04:49]
Why does the order matter so much?

**NADIA**  [04:52]
Because teams naturally test the easy assumptions, confirm them, and feel validated, while the fatal one sits untested at the end. Then it fails in production, expensively, after everything else was proven right.


`[CUE 3]` *Easy assumptions confirmed while the fatal one waits untested.*

**AMARA**  [05:05]
How cheaply can an assumption be tested?

**NADIA**  [05:08]
Cheaper than you think. A conversation before a prototype. A prototype before a build. A landing page describing the feature before the feature exists, measuring who clicks. Pounds to avoid thousands.

**AMARA**  [05:20]
User research. I ask people if they would use things and they always say yes.

**NADIA**  [05:26]
Because people are polite, and politeness ruins research. A yes to would you use this is a kindness, not a data point.


`[CUE 4]` *Would you use this producing a polite yes, beside walk me through last time.*

**AMARA**  [05:35]
So what do I ask?

**NADIA**  [05:37]
The past, never the future. Walk me through the last time you had this problem. What did you do? What did you try? What did it cost you? Behaviour that already happened is evidence. Predicted behaviour is a favour.

**AMARA**  [05:53]
Can I show them my idea?

**NADIA**  [05:55]
Not during the questions. The moment you pitch with enthusiasm, every answer afterwards is contaminated, because they are now helping you rather than informing you. Ask first, show later if at all.


`[CUE 5]` *A pitch contaminating every answer that follows.*

**AMARA**  [06:08]
How many people do I need? Surely five is not a sample.

**NADIA**  [06:13]
You are not doing statistics, you are hunting the surprise. The workaround you did not know existed. The step you assumed was painful that is not. The person who already solved it with a spreadsheet. Five or six good conversations usually surface the pattern, and the surprise is worth more than the sample size.

**AMARA**  [06:34]
And if discovery says no?

**NADIA**  [06:36]
Then it worked. Discovery that never kills anything is a corridor, not a filter. Killing an idea after a week instead of a quarter is the single largest saving this discipline ever produces.


`[CUE 6]` *A killed idea recorded, and returning eighteen months later to meet the record.*

**AMARA**  [06:50]
How do I kill it without burning the person who proposed it?

**NADIA**  [06:54]
Make it about the evidence, never the judgement. Say what was learned, what changed the picture, and what would need to be true for it to come back. And write it down somewhere findable.

**AMARA**  [07:08]
Why findable?

**NADIA**  [07:09]
Because the same idea returns every eighteen months with a new sponsor, and the record is the only thing standing between the organisation and paying for the same discovery twice.

### Sources for the on screen credit

- Discovery and user research guidance, Government Digital Service
- Assumption testing and lean experiment literature, Product management research
- Interviewing users methodology, User research practice literature

---

*Copyright WAJD Group. Built by WAJD AI.*