Monday, 8:50am · from Carl
Not much coding, and not much drawing either. A product owner mostly decides things: what we build next, what can wait, and how to say no without losing a friend.
That catches out people who come to product from design. Mostly you decide things, and the hard one is saying no to someone senior without losing a friend.
The Scrum Guide is more formal about it. It says the Product Owner is accountable for maximising the value of the product, and for looking after the backlog, which is an ordered list of what the product needs next.1 My version is shorter: you decide the order.
Below is how that tends to play out, one day at a time, with four things to have a go at: a sticky-note board to sort ideas, a RICE scorer, a user-story builder that nags you when you write an answer instead of a need, and a boss who wants something by Thursday. The week and the advice are my teaching view. The numbers and definitions are sourced, pinned to the board on index cards and listed at the bottom.
Monday backlog and sorting
Tidy the top of the backlog
Start with the backlog, because you’ll live in it. A story that you put in three weeks ago will make no sense now (it happens to all of us, really), so rewrite it and bin the rest. The top of the list is the bit that counts, because that’s what the developers will pick up next, and a tidy top can save you a lot of questions before lunch.
Rewrite or bin the stale stories, then check the first handful read clearly. Whatever is at the top is what gets built next.
A long list nobody has ordered. The Scrum Guide calls the backlog an “ordered list”, and ordering it is your job.1
Sort it
Prioritising without a fight
When everything’s “high priority”, nothing is, and you will need a way to sort things out. The simplest I know is value against effort. Grab a sheet of paper and draw a big cross on it, with effort going from left to right and value going from the bottom to the top. Write your ideas on sticky notes and slap them on. The top left, high value and low effort, is where I’d start, and the bottom right is where good ideas go to wait (they’re allowed to wait).
Drag the notes onto the board for an imaginary café app (or focus one and use the arrow keys). There’s no single right answer, which is the point: your team will disagree, and now you can see why.
Your start-here list
Ideas and positions are made up for the exercise.
Tuesday sprint planning and scoring
Sprint planning: what matters, and why
A sprint is a short burst of work the team agrees to, a month at most1 (two weeks is common). Before it starts you explain what matters most and why, and then the developers say what they think will fit. Expect some haggling. I’d say that’s healthy, really.
Telling developers how long things will take. They tell you.
Score it
RICE, but not as gospel
If you want to get a bit more serious, there’s RICE. It scores an idea on reach, impact, confidence and effort, and the folk who made it up have given us the scales. Impact goes from 3 for massive down to 0.25 for minimal, confidence is 100%, 80% or 50%, and effort is counted in person-months.2 You multiply reach, impact and confidence, and then divide by the effort.
I wouldn’t treat the score as gospel though. What it’s really good for is getting everyone looking at the same page, so the chat moves on from “I just like this one” to “hang on, why do you reckon the reach is that big?”. Change the numbers and watch the ranking move. It starts with the three example projects from Intercom’s article, with sums done by me.
Try raising the confidence on Idea C, or doubling the effort on Idea A, and see what happens. The argument you have about those inputs is the useful part!
Wednesday be findable, write it down
Be easy to find
Once the sprint is running, your job is to be reachable. A developer stuck on half a story won’t wait politely until Friday!
Back-to-back meetings with your phone off.
Write it
A user story people can build from
A good user story is very small. It’s a sentence with who, what and why in it, like “As a customer, I want to save my basket, so that I can finish buying later.” Underneath you add a couple of plain lines about how you’ll know it’s finished. The template comes from Mountain Goat Software, who describe a story as a short description of functionality “told from the perspective of someone who wants or needs that functionality”.3 Atlassian boils it down to “persona + need + purpose” and says it puts end users at the centre of the conversation, which I really like.6
Where people go wrong, I’d say, is writing the answer instead of the need. “Add a dropdown to the checkout page” is an instruction. “Customers can’t tell if we deliver to their postcode” is a problem, and your designer or developer might well solve it better than a dropdown would. Write a story and see what the checker thinks.
Story card
The checker only spots a few giveaway words. It’s a nudge, not an oracle.
Thursday the stakeholders turn up
The stakeholders turn up
Sales want their feature, support want theirs, and the boss has spotted something on a rival’s site and wants it by Thursday. Saying no kindly, with a reason, is a big chunk of the job. Reply to the message.
Pick a reply.
Be careful with that 35%, though. It comes from a LinkedIn poll, and only the folk who fancied answering took part, so it’s a fair picture of them and not of everyone.4
Saying no kindly
Give every “no” a name and a reason
MoSCoW is a tidy way to do it. All the requests get a label, there are four to choose from, and “Won’t have this time” is a perfectly respectable answer, not a rude one. Go on, tap a label and have a look.
Ron Jeffries described a story as a card, a conversation and a confirmation.7 I think the same idea works for a no. Write it on the card, talk it through, and agree what would change your answer (that last bit is just my teaching view).
Friday numbers, then your own fortnight
Peek at the numbers
Take a peek at the numbers, which just means the stuff that tells you what people really do in the product. Nothing settles an argument about what users want like that does, and I’d much rather lose to a graph than win on a hunch.
Only looking when someone challenges you.
How to try it in your current job
Own one small thing for a fortnight
If you’re in UX or project management already, you’ve got a head start. So find one small thing coming up on your team, maybe a feature, maybe a niggly fix everyone keeps putting off, and put your hand up to own the “what and why” of it. Write down the problem and who has it, and how you’d tell it was solved. Then wander over to whoever builds it and ask what they’d need from you before they could begin. That’s it. You’ve just done a bit of product ownership.
That one exercise covers a surprising amount of the job. In a fortnight you’ll have a pretty good idea whether you like it, which is a lot cheaper than finding out after you’ve switched careers!
Try this today Pick the thing your team keeps pushing back
Tick them off as you go. Your progress stays on this device.
If you’re wondering how everybody else fits round you, our post on the 12 rituals of high-performing product teams is a handy companion. But first, what keeps getting pushed back on your list? Start there!
The end of the week
So, what does a product owner do all day?
Decides things! That was my answer on Monday and it’s the same on Friday. In five days you tidied the top of the backlog, argued about a score, and wrote a story about a need, not a dropdown. You also told the boss “not this sprint” and stayed friends. There wasn’t much code in any of it, and you didn’t have to draw a thing.
The boss got his answer on Thursday and I’d guess he’s forgotten all about it by Monday. A no feels huge to you and very small to them, as long as you gave a reason and a day when you’ll look at it again. The people who really do lose friends are the ones who say yes to everything and then miss every date!
What you actually have at the end
You don’t have a new job, to be honest with you. What you have is a feel for the work and a fair idea of whether you’d like it, and that’s worth a lot. Have a go at the fortnight exercise and you will know, one way or the other, which is much cheaper than finding out after you’ve switched careers.
My guess, and it’s only my teaching view, not a statistic, is that two weeks will tell you if you like deciding things. Then you’ll want a few months of looking after something small before it feels steady. Saying no to someone senior takes longer, and you can feel a bit nervous about it for a year or more. You’re not alone, really. Mind the Product ran a poll asking over 600 product folk about their year, and 35% said influencing stakeholders was the main obstacle.4 Another 35% wanted to get better at leadership. Mind you, only the folk who fancied answering took part.
Another thing, if you’re job hunting. Atlassian points out that a Scrum role isn’t a job title, and you can do the work of a Product Owner under any title, even the one you have now.9 You may be doing a good chunk of it already in design, and in project management too! ProductPlan says Product Owners are mostly found in agile teams, looking after the day-to-day detail, while product managers think about the long-term direction.10 When you read an advert, look at the work and forget the title.
What to do next
This week I’d start small. Think of a little job that your team keeps putting off, and write down the problem and who has it. Then write how you’ll know it’s fixed, and have a chat with the person who builds it about what they’d need from you to start. It will take you about ten minutes, really.
A month in, I’d put the backlog on a value-against-effort board, and if you can, do it with a developer standing beside you. Score the top few ideas with RICE together and see where you disagree. Then turn a few of the complaints you hear into stories, and ask the developer which ones they couldn’t start tomorrow. If they will let you, go to a sprint planning session and just listen.
After that, ask to look after a slice of the backlog properly, with your name on it. You will have to say a few nos, with a reason attached, and see how it feels. If you like it, that’s the time to think about a course.
How people get good at this
You get good by doing it where other people can see. You can’t learn to prioritise from a book, because the learning happens when a developer says “I can’t build that from this”, and when someone senior looks at your ordered list and asks why their idea is fifth. Those little bruises are the lesson, and we all get them.
You’ll make the ones from the sticky notes, I promise. A long list that nobody has ordered, an instruction dressed up as a story, telling the developers how long things will take, and only looking at the numbers when somebody challenges you. We all make at least one of those, and that’s fine.
If you fancy some reading, the Scrum Guide is free and very short, so you can get through it on the train.1 Check out Mountain Goat Software’s guide to user stories as well, which is free too, and Atlassian’s page on writing them with a template.36
The short version
- A product owner mostly decides the order of things, and says no kindly.
- Write the need, not the answer, and let the team solve it.
- A score like RICE is there to start the conversation, not end it.
- Try owning one small thing for a fortnight before you change anything big.
Courses we’d suggest
Our Product Ownership Career Course is where I’d start. You will go from the basics of the job right up to running a team, and we cover roadmaps, RICE, MoSCoW, sprint planning, stakeholders and so on. It’s a group course, so you learn with other people, on weekend mornings in the room and weekday evenings online.
If you’re new to thinking about users, UX Design Essentials is a good step before it. It’s six lessons over three weeks, in the room at True Digital Park, and you learn to look at a product from the user’s side, which will help a lot when you have to decide what goes first. And if you end up leading a team that’s starting to use these new tools, we also have a short evening course for managers and product leaders that fits nicely after it.
Reading list
Where the numbers come from
- The 2020 Scrum Guide. Schwaber and Sutherland. Product Owner “accountable for maximizing the value”; “one person, not a committee”; Sprints “of one month or less”; Product Backlog “an emergent, ordered list”.
- RICE: Simple prioritization for product managers. Intercom. Impact 3 to 0.25, confidence 100/80/50%, effort in person-months. Example inputs used in the scorer; scores calculated here.
- User Stories. Mountain Goat Software. Template, perspective wording, Ron Jeffries’ card, conversation, confirmation.
- What product professionals are focusing on in 2025. Mind the Product, 31 January 2025. 600+ responses via LinkedIn; influencing stakeholders 35%; 35% aim to strengthen leadership skills.
- What is MoSCoW Prioritization? Agile Business Consortium. Definitions; “typically no more than 60% Must Have effort”; Could Have pool around 20%.
- User stories with examples and a template. Atlassian, Max Rehkopf. User stories are “persona + need + purpose” and put end users at the centre of the conversation.
- Essential XP: Card, Conversation, Confirmation. Ron Jeffries, 30 August 2001. “The card is a token representing the requirement.”
- Product Ownership Career Course. Web Courses Bangkok course page: topics, formats, who it suits.
- Agile scrum roles and responsibilities. Atlassian, Dave West. Scrum roles “aren’t job titles”; “any job title, even your existing ones, can be used to perform one of the roles”.
- Product Manager vs. Product Owner. ProductPlan. Product managers are strategic; product owners, typically in agile organisations, are more tactical.
