How to manage day-to-day product delivery
A product manager's daily job is sequencing decisions, not status updates. If you are spending all day in chat, something is wrong.
- steps
- 8
- named failure modes
- 5
- definition-of-done criteria
- 6
How to manage day-to-day product delivery, in one paragraph
Day-to-day product delivery is the work of keeping a quarter's committed epics moving through their gates in a sensible order, and making the small decisions that unblock people within hours rather than days. It is not status collection. Done well, your day is a short pass over the board, a pass over the approval queue, and then the two or three sequencing calls nobody else can make. If you are in chat all day, you are being used as a lookup table for information the board should already carry.
What these are. The delivery operating model our engagements install alongside client teams: the method underneath the agentic work rather than the agentic work itself, published in full and free to use. It is written for the person running a quarter, not for a buyer, so if you are evaluating us, read the five priced engagements or the case studies instead.
Every working day of a live quarter, from the day the roadmap opens to the day it closes. The trigger is epics being in flight, not a problem appearing: if you only run this when something is wrong, you are running recovery rather than delivery.
- Time to run it once
- About two hours a day, spread across the working day
- What you need
- The delivery board
- The quarter's p50 and p85 forecast range
Step by step
Each step is deep-linkable, so you can send a colleague the one that is in dispute.
- 1
Open the board before you open chat
Five to ten minutes, first thing, in this order.
Work in progress per team against the limit you set: over it, you stop starting before you start chasing. Anything with no state change and no comment for two working days: name it and act on it today. The Ready for Dev queue: is anything sitting one approval away from starting. Bug budget burn against the pace you planned for this week of the quarter. Write down the two or three items you will act on. If the pass takes forty minutes because you are reconstructing the truth from memory, the board is stale, and fixing it is item one.
- 2
Clear the approval queue before anything else
You are the constraint on this queue, so work it daily, in sequence order rather than arrival order.
In AI-augmented teams an epic cannot leave Ready for Dev without product approval, engineering approval and at least one product-approved story attached, and a story cannot leave the backlog until its parent epic is product-approved. In AI-native teams the outcome ticket needs its currency share, its key user journeys and its test requirements before either approval lands. Approve or reject inside one working day, and make a rejection name the missing artefact. Never approve an epic whose planned value is blank: that is the number the quarter is measured on.
- 3
Set one sequence per team and hold it
Each team gets exactly one prioritised order, visible on the board, with a single item labelled next.
Set it or confirm it once a day, in the same pass. When two items look equally urgent, take the one attached to the outcome furthest from its currency target, because that is where the missing value sits. Three things earn a resequence: a validation result, a slip that changes what can land, a dependency arriving early or late. A message from a loud stakeholder is not one of them. Resequencing on volume costs the switch, costs the re-plan, and costs you a team that has stopped believing the order means anything.
- 4
Route every new item to a parent immediately
Nothing lives unparented, and you route in the morning pass, not at the end of the week.
A bug found this quarter links to the Bug Budget epic. Debt raised during the build links to the Tech Debt epic. A missed requirement is not a bug: it is a story, or in AI-native mode an amendment to the outcome ticket, so relabel it. Risks and issues go to the RAID log with a named owner. Anything that cannot name a parent epic, and through it an outcome, does not start today. Ten minutes of routing is what keeps the burn rates meaningful for the rest of the quarter.
- 5
Answer blocking questions inside four hours
Hold one fixed window in the middle of the day, forty-five minutes, and publish it.
The rule: any question blocking a build gets an answer, or a written assumption on the ticket, within four working hours. Anything not blocking waits for refinement. Recording the assumption is the important half. Write what you assumed, who owns it, and what you would change if it turns out wrong. A guess is safe once it is written down and owned, and dangerous only while it lives in someone's head. Watch the pattern too: repeated questions on one epic mean the ticket was approved too thin, so fix the ticket.
- 6
Move the value number the day scope moves
When scope changes, the epic's planned currency share changes the same day, by you, not by the monthly outcome validation.
If a £240k epic loses the half of its scope that carried most of the value, it is a £150k epic now and its outcome is £90k short. Write the new number on the epic, let the gap show on the outcome, and add one line naming the option you would take: a new epic, a scope trade from elsewhere, or a lower target agreed openly. With eight weeks of quarter left, that gap is something you can still act on. In week thirteen it is a postmortem.
- 7
Hand shipped work into monitoring, not done
A done story is reviewed, product-approved, scheduled, and released with its ship kit: user notes, developer changelog, executive one-pager, rollout plan and comms. It then enters live monitoring for the first seven days, where a named person owns the continue, watch or rollback call. Only epics go on to value monitoring, and an epic stays there until validation confirms the value or you close it with an honest note that the value did not land. In AI-native teams nothing is shippable until the ticket's test requirements pass and its named journeys are demonstrated working in front of a person.
- 8
Close the day by naming what slipped
Five minutes.
Compare where the work sits against your p50 and p85 forecast range rather than a single invented date. Anything that has fallen outside p85 for landing inside the quarter gets said today, to the person who has to make the choice, with the three options attached: cut scope, move the epic to next quarter, accept the risk. Do not soften it into an amber status with no ask. A slip raised in week four costs a conversation. The same slip raised in week twelve costs a commitment somebody else has already made to the business.
A Tuesday in week four of a thirteen-week quarter
Northbank Retail, an invented mid-market retailer, has one live outcome: lift checkout conversion by 1.4 points, worth £1.2m a year. The quarter's roadmap carries four value epics plus the standing Tech Debt and Bug Budget epics. Guest checkout is planned at £480k, saved payment methods at £300k, address autocomplete at £180k, error-state rework at £140k. That is £1.1m against a £1.2m target, a £100k gap that was visible before the quarter started. The morning pass takes eight minutes and surfaces three things. Guest checkout has sat in Ready for Dev for three days with engineering approval and no product-approved story, so it is blocked by the product manager rather than by engineering: two stories are written and approved by ten o'clock. The bug budget is at 14 bugs in four weeks against a planned 30 across thirteen, so burn is running hot, and the pattern behind it goes on Thursday's refinement agenda rather than into a new meeting. Address autocomplete has lost its international-address scope, so its planned value drops to £110k and the outcome gap moves from £100k to £170k. That number goes on the outcome the same day, with a line proposing a fifth epic, rather than being discovered quietly in week twelve. Everything above took under an hour, spread across three passes.
Where this goes wrong
- 01
Deciding in chat and leaving the ticket unchanged.
The decision was real, the trail is not, and three weeks later nobody can say why the scope moved or who owned the assumption. Every decision from your midday window lands on the ticket the same hour, or it did not happen.
- 02
Answering status questions the board should answer.
If people ask you rather than reading it, you have accepted a job that scales to about six people and then collapses. Answer once with a link, fix whatever made the link useless, then stop answering.
- 03
Waving an epic through the gate because a developer is idle.
That is the exact pressure the gate exists for. An epic approved with no product-approved story, or with no journeys and test requirements in AI-native mode, buys two days of activity and pays for it with a rebuild.
- 04
Re-prioritising every morning.
A sequence that changes daily is not a sequence, it is a mood. Change it on evidence: a validation result, a slip, a dependency landing early. Not because a message arrived before your morning pass.
- 05
Accepting a model's own report of completion in an AI-native team.
Done means both things: the test requirements in the ticket pass, and the key user journeys are demonstrated. A model saying it has finished is a claim, not evidence.
Done means
- Every epic in flight carries product approval, engineering approval, and either at least one product-approved story or, in AI-native mode, written key user journeys and test requirements.
- Nothing raised in the last working day is unparented: every bug, debt item and story sits under an epic, and every epic under an outcome.
- Every question that blocked a build in the last working day has an answer on the ticket, or a written assumption with a named owner.
- Each team has one visible prioritised order with exactly one item marked next, and you can say what changed it since yesterday.
- For each live outcome, the sum of its epics' planned values still covers the target, or the gap is written on the outcome with an owner, a date and a proposed option.
- Anything now outside p85 for landing this quarter has been raised on the day it became visible, with cut, defer or accept attached.
The rhythm is identical, the artefacts are not. In an AI-augmented team the approval queue is mostly stories, and your morning pass watches story-level flow: what is in review, what has sat in progress too long, what needs breaking into chapters. In an AI-native team there are no stories, so the queue is epic-level outcome tickets, and you are approving the currency share, the key user journeys and the test requirements rather than acceptance criteria. The board carries fewer, larger items, so one stuck ticket is a much bigger share of the quarter and a two-day stall matters more, not less. The heaviest difference sits at the other end: done costs you real attention, because you or a named developer has to watch the tests pass and the journeys demonstrated before the ticket moves.
The two delivery modes, side by side →Questions
How long should this take each day?
Twenty to thirty minutes of passes, plus one forty-five minute decision window. Roughly ten minutes on the board and routing, ten on the approval queue, five on the close. If it reliably takes more, diagnose which part is swelling. A long morning pass means a stale board. A long approval queue means you are batching approvals that should clear daily, or tickets are arriving too thin to approve at all.
What if I cover three teams?
One sequence per team, one pass covering all three, one shared decision window. The part that does not scale is the approval queue, because you are the constraint on it. If clearing it takes more than about forty-five minutes a day, delegate product approval to a named person per team with the gate rules unchanged, rather than approving faster and looking less closely.
An urgent customer request just came in. Does it beat the sequence?
A live production incident does, and it goes into the RAID log as an issue rather than being quietly slotted into the roadmap. Everything else waits for your next sequencing pass. If it does beat the current next item, say out loud what it displaces and where that work now lands, because unnamed displacement is how a quarter goes missing.
How is this different from stand-up?
Stand-up belongs to the team and covers what they are doing. This is your own loop, and most of it happens before stand-up so you arrive with decisions rather than questions. If you need stand-up to find out the state of the board, the board is the problem, and fixing that will save you more time than any change to the meeting.
More on measuring and managing
These guides are written to be read in order.
03How to manage delivery to be on time
Predictable delivery is not about pushing harder. It is about seeing the slip early enough to make a real choice about it.
← All seventeen guidesWant help installing this?
These guides are free and you owe us nothing for using them. If you would rather have operators install the operating model alongside your teams and stay until it sticks, that is what our engagements do.
Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks