A Product Owner does not spend the day prioritising. The day goes on making sentences agree: what a customer said yesterday, what was promised three weeks ago, what the team is supposed to build tomorrow. Prioritising is the small remainder left over once those three line up.
What follows is an ordinary Tuesday. No escalation, no ship date, nobody off sick — which is exactly why it is worth walking through.
08:40
The coffee is still hot. In the inbox sits the write-up from yesterday's customer call: twenty-eight lines, six of which ask for something. The rest is context, courtesy and a paragraph about the weather.
Six asks, then. The first question is not “how important is this?” but “which of these is actually new?”. Two of those sentences arrived from the same customer in spring, worded differently. Miss that and you create them a second time — and from then on one need has two requirements, with separate states, separate links, and a coverage figure scoring the same promise twice.
Two of the six rows carry that note: 88 percent and 71 percent. The one at 88 really is the March sentence in politer clothing, so it gets discarded — the ask belongs to the requirement that already exists. The one at 71 is something else: similar vocabulary, different purpose. It stays. Two minutes of reading and one decision, instead of explaining three months later why the same need is in the backlog twice and one of them is already built.
By 08:55 there are four new customer requirements in the project, all in draft. None of them is worth anything yet. They are simply in one place — which is more than four sentences in a meeting write-up can claim.
Four lines. That is all that has happened by 08:55. The difference from the inbox is still the whole difference: these four sentences belong to somebody now, they have an address, and not one of them can quietly disappear because an email slid down a screen.
10:15
Refinement is the part of the day nobody can take off your hands. The list there is not a ranking: it is everything sitting as a customer requirement in draft or in review, and the number beside Refine in the sidebar is that same list's length. Product requirements never appear here.
The third of the four reads: “The report needs to get faster.” Beside it sits a hint from Juujuu, marked by a coloured bar down the left edge. The category is quality; how urgent it is comes across in the colour alone, since the word for it appears nowhere. What it says is what any careful reader would say: no starting figure, no target figure, no point of measurement.
So he asks — in the chat beside the requirement, which is attached to this one requirement and knows its text. Two follow-ups and a phone call later the sentence reads: “The monthly report over 12 months and 50,000 documents appears in under 5 seconds; today it takes 40.” Where a hint arrives with finished wording, a tick and a confirmation take it over — title and description, in either language, four fields and no others. Everything else a person types, which is where the responsibility belongs.
Then: confirm. Three go through. The fourth stops, because the source is missing — nowhere does it say who asked for this. Ten seconds of work, one name, carry on. In three months that is the difference between a requirement and a rumour.
13:00
After lunch, the awkward one. “An invoice that has been sent must not be altered.” Clean sentence, source and description in place; it would pass every gate in the building. It still itches. Three weeks ago something was approved that sounded different: “Sales can correct an invoice within 24 hours.” Search finds it — substring matching, not concept understanding, so “invoice” turns up sentences containing “invoice”, which today is enough. Two minutes later both sit side by side, contradicting each other.
Nothing warned him. No comparison runs in the background, no model weighs promises against each other, no similarity check reaches into the lifecycle. Contradictions are found by a person who has read both sentences — a division of labour, not a hole. A tool that claims to spot them gets dismissed after the third false alarm.
A tool does not find the contradiction. It makes sure the contradiction is not forgotten.
He declines, and declining demands the reason: “Contradicts the 24-hour correction window approved on 22 July. Needs a decision from the customer.” Rejected is not a dead end — the one way out leads back to draft, and that is the road the sentence takes at 16:10, once the customer has agreed on the phone to 30 minutes instead of 24 hours. Both requirements get rewritten. The reason written at 13:07 stays where it is, and in six months it explains why the number is 30 minutes and not zero.
Declining is the most uncomfortable click of the day. Somebody thought that ask through, and the answer is no. What separates it from a no in the corridor is that the reason stays put — readable in four months, by somebody who was not here today.
As a rule, and independently of this case: where a contradiction is explicitly on the record, the argument ends. While it stands, nothing gets approved — on both requirements, because it is recorded at both ends. No way around it, no role that overrides it. In refinement a banner names it; on the requirement's own page you find out when you try.
15:00
The afternoon belongs to the plan — not to what matters, which was this morning's job, but to what fits into the next release. The order of two operations decides how good the answer is: size first, assign second.
The reason for that order lives in that column. A requirement with no size is worth zero points. Assign first and read afterwards, and you see a release at 22 of 40 points, call it half empty and load a little more in — while six of the fourteen entries weigh nothing because nobody sized them. The number is not lying. It is staying quiet, and quiet numbers do more damage in a planning meeting than wrong ones.
What does not happen here is just as telling. Nothing gets dragged across a board. There is a selection in a list, an action on it, and a table showing a different number. Less handsome, much harder to misread.
In progress The Timeline tab says as much itself. What sits there today is not a chart but a sentence about what is coming: every product's releases laid against each other, so schedule conflicts show up before they happen. Coming in 2026.09.
17:20
Just before the end of the day, a message from sales: “Meyer AG is asking about the export. Have you got twenty minutes tomorrow?” A year ago that was a meeting the next morning, preceded by a status overview assembled by hand. Today it is two answers and no meeting.
The first is a link. A requirement has an address, and its page carries what sales wants to know: the state, who asked for it, which product requirements hang off it, and — if it has been handed over — the key of the Jira issue that came out of it.
The second question always arrives right behind the first: what else did we promise Meyer AG that nothing covers today? That is the gap report — narrowed to a project and a priority, as PDF or a spreadsheet. It lists the customer requirements with not one confirmed link behind them.
An honest account includes a limit. The card carrying the coverage percentage has no address of its own: it sits on the report page, reached by scrolling rather than by a link, and it has no export. So what gets sent is the report, not the screen. The lists are the other way round — whatever you filter and sort is written into the address bar. A filtered list is a link, and whoever opens it sees the same list, not a screenshot ageing from the second it was taken.
The best status question is the one that answers itself.
17:32, and that is the day. Four new requirements, one phrased so it can be measured, one declined with a reason and back in draft, a release filled with fourteen sized requirements, one status question answered without a meeting. Not a heroic act in the lot — and together the difference between a product you can explain and a product you remember.
Not a heroic day. That is exactly the point: a Tuesday where nothing escalated, because the questions got answered where they came up.
How the same Tuesday looks two desks away, once the requirement genuinely holds, is A day in the dev team — from the ticket in the morning to the question of what the work actually covered. And for these five hours read one level up, as portfolio, dates and progress, there is The overview leadership needs.