Product ownership: outcomes, not output

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.

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.