Module 1 of 2 · 40 minutes
Outcomes, prioritisation, and saying no to good ideas
By the end of this module you will be able to
- 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
Work through it
1 interactive for this module, built on the WAJD Teach engine. Nothing moves until you ask it to, and every one has a written version if you would rather read it.
Amara My product owner role has turned into writing tickets for other people's requests.
Nadia 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 So what makes it a real job?
Nadia Deciding what not to build. That is the whole thing. Anybody can maintain a list of what people asked for.
Amara Start with outcomes then, because I get measured on delivery.
Nadia Then let us separate two words that get used interchangeably. Output is what you shipped. Outcome is what changed.
Amara We shipped fourteen features last quarter.
Nadia That is output. Did anything get better?
Amara Honestly, I do not know.
Nadia 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.
Amara What should I measure?
Nadia 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 How do I make that a habit?
Nadia 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 Nobody goes back and looks.
Nadia 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 Prioritisation. Everything in my backlog is marked high.
Nadia Then it contains no information. Forty urgent items is the same as zero urgent items, just with more anxiety attached.
Amara Which framework should I use?
Nadia 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.
Amara Where is it?
Nadia 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 Right. Saying no. This is the bit I dread.
Nadia Then stop saying no. Say: yes, and here is what it would displace, so which do you want more?
Amara That is the same sentence from project management.
Nadia 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 Anything else?
Nadia 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 And if I just quietly drop things?
Nadia 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 Last thing. My roadmap has dated features on it.
Nadia 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 But people want dates.
Nadia 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.
The written material
Output is what you shipped, outcome is what changed
A team that shipped fourteen features last quarter has produced output. Whether anything improved is a separate question, and it is the only one that matters.
Output metrics feel good because they are countable and always go up. Features shipped, story points, tickets closed, releases. None of them tell you whether the product is better.
Outcome metrics are harder and fewer: did the thing people struggled with get easier, did the number of support calls about it fall, did more people complete the task, did they come back.
The discipline: for every significant piece of work, write down before you start what you expect to change and how you will know. Then go back and look. Most teams never look, which is why most teams cannot tell you whether anything they built worked.
Prioritisation is a method, not a mood
Everything cannot be high priority, and a backlog where forty items are marked urgent contains no information at all.
Any transparent method beats no method, because the value is less in the score and more in the conversation it forces. Weighted shortest job first, value against effort, RICE, or a simple two axis grid all work.
What matters is that the method is visible, applied consistently, and that the reasoning is recorded. A stakeholder can argue with a score. They cannot argue with a feeling, which is why decisions based on feelings get escalated over your head.
Reprioritise on a schedule rather than on demand. A backlog reordered every time somebody walks past has no order at all.
Saying no to a good idea
The hard part of the role is that most rejected requests are good ideas from reasonable people. Almost nothing arrives that is obviously stupid.
The move that works is never a flat no. It is: yes, and here is what it would displace, so which do you want more? That converts a refusal into a trade, and it moves the decision to where the authority is.
Then be explicit about the criteria. 'We are prioritising anything that reduces onboarding time this quarter, because that is the outcome we have committed to. Your request does not do that, so it sits below the line until the quarter turns.' That is answerable, and it is not personal.
And keep a visible not now list. Requests that vanish silently come back louder and through somebody more senior.
A roadmap is intent, not a delivery schedule
A roadmap of dated features is a set of promises you cannot keep, and everybody who has held one has learned this the expensive way. The further out the date, the less it means, but it is quoted back to you with the same confidence as next week.
Better: organise by theme and rough horizon. Now, next, later. Under each, the problem you are solving and the outcome you expect, not the solution and the date. That communicates direction without committing to a specification decided before you learned anything.
Sales and stakeholders will push for dates, and the answer is not to refuse but to be explicit about confidence: firm for the current quarter, directional beyond it, and stated as such every time it is shared.
Knowledge check
The knowledge check and your certificate need a free account, so that your progress and results can be saved as evidence.
The learning itself stays free and open. You are reading all of it right now without an account.