How to run product delivery day to 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.

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. Tenhaw's founder James Rooney worked that delegation problem at scale in a role inside HSBC Global Payment Solutions, co-leading a target operating model for 500 teams and a $450M portfolio, piloted and due for global rollout in 2026.

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.

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.

Make the board answer them. Tenhaw ran that move at Globelynx, where operational data was collated continuously into trends leadership could act on rather than assembled into a report whenever somebody asked, and delivery lead times fell 60% within six months. If people ask you instead of reading it, you have accepted a job that scales to about six people and then collapses. Answer once with a link to the item, then fix whatever made the link useless: a stale state, a missing comment, a decision that happened in chat and never landed on the ticket. Your morning pass exists to keep the board carrying the truth, so anyone can self-serve the state of any epic without you.

Look for anything with no state change and no comment for two working days, then name it and act on it the same day. That check sits in the morning pass, alongside work in progress against each team's limit, the Ready for Dev queue and bug budget burn. Silence usually traces back to a question blocking the build that never got an answer, a ticket approved too thin, or a decision made in chat that never reached the board. Find which one it is, then answer the question, fix the ticket, or bring the record back onto the board. And if the pass takes forty minutes, the board is stale, and fixing it is item one.

Within four working hours, either with an answer or with a written assumption on the ticket. Hold one fixed forty-five minute window in the middle of the day, publish it, and let anything that is not blocking wait for refinement. The written assumption is the important half. Record what you assumed, who owns it, and what you would change if it turns out wrong, because a guess is safe once it is written down and owned. Watch the pattern too. Repeated blocking questions on one epic mean the ticket was approved too thin, so the durable fix is the ticket, not faster answers.

Confirm it daily, change it rarely. Each team gets exactly one visible prioritised order with a single item marked next, set or confirmed once a day in the same pass. Only three things earn a resequence: a validation result, a slip that changes what can land, or a dependency arriving early or late. A message from a loud stakeholder is not one of them. An order that changes every morning is not a sequence, it is a mood, and it costs the switch, the re-plan, and a team that has stopped believing the order means anything.

The planned value moves the same day, and you move it, rather than leaving it for the monthly outcome validation to discover. Tenhaw holds its own retainers to that standard, reporting a month that delivers no measurable value as a failed month. 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, or a lower target agreed openly. With eight weeks of quarter left that gap is actionable. Found in week thirteen, it is a postmortem.

No. An idle developer is the exact pressure the approval gate exists to resist. An epic waved through without product approval, engineering approval and at least one product-approved story buys two days of activity and pays for it with a rebuild. Tenhaw does not trust memory to hold rules under that pressure either, which is why its engineering handbook carries 72 numbered rules written to be enforced by an agent. The honest fix is queue speed, not gate removal. Work the approval queue every day, in sequence order rather than arrival order, and approve or reject inside one working day, with any rejection naming the missing artefact. Run that way, the gate rarely leaves anyone idle for long, and the short wait is cheaper than the rework.

No, because the pass is over the board, not over the people. Tenhaw spent six months on that job at Greggs, Scrum Master support across the Mobile App and Integration squads plus agile coaching beyond engineering. It takes five to ten minutes and checks four things: work in progress against each team's limit, anything with no state change or comment for two working days, the Ready for Dev queue, and bug budget burn. You are not asking anyone how their day is going. You are collecting the two or three items only you can act on, clearing the approvals that are yours, and getting out of the way. Micromanagement is telling people how to do the work. This is deciding what order it happens in.

Two artefacts carry most of it, a delivery board that holds the truth, and the quarter's p50 and p85 forecast range. Around those, four rules agreed in advance. A work in progress limit per team. One visible prioritised order per team, with a single item marked next. A planned currency value on every epic, because that is the number the quarter is measured on and no epic should be approved with it blank. And gate rules everyone knows, so an epic cannot leave Ready for Dev without product approval, engineering approval and at least one product-approved story attached. None of it is proprietary, and Tenhaw publishes the method in full, free for anyone to adopt. Everything else in the routine is habit rather than kit.

Stop starting before you start chasing. Pushing on every item at once feels like management, but attention does not add capacity and the queue only shortens when work leaves it, so the first move is to start nothing new and finish something. Take the item closest to done and clear whatever it is holding: an approval sitting in your own queue, a question blocking the build, a review nobody picked up. The breach itself should be visible the same day, because work in progress against the limit is the first thing the morning pass checks, ahead of stalled items, the Ready for Dev queue and bug budget burn.

Take the one attached to the outcome furthest from its currency target, because that is where the missing value sits. Urgency and volume are the tie-breakers most teams reach for, and the least informative, because two items can both be genuinely pressing while only one of them closes a gap on the number the quarter is measured against. Each team carries exactly one prioritised order with a single item marked next, so the tie gets broken somewhere visible rather than in a private judgement call. Put the choice on the board as the order, not in your head, or you will re-explain it every morning.

Land every decision on the ticket in the hour it is made. The familiar failure is that something real gets decided in a thread and the ticket is never touched, so the decision was real but the trail is not, and three weeks later nobody can say why the scope moved or who owned the assumption. Hold one published decision window in the middle of the day, forty-five minutes, then write each call onto the item it affects the same hour, with any assumption named and owned. Chat is fine for reaching a decision. It is not a record, because nobody reads a thread back, and the board is what everyone else self-serves from.

Yes, and routing them takes about ten minutes a day. A bug found this quarter links to the Bug Budget epic, debt raised during the build links to the Tech Debt epic, risks and issues go to the RAID log with a named owner, and every epic sits under an outcome. The Tenhaw Way is blunt about the rest. Anything that cannot name a parent does not start today. It reads like bureaucracy until you see that it buys burn rates that stay meaningful all quarter, and an honest answer when someone asks where the capacity went. Route in the morning pass, not at the end of the week when nobody remembers half the items.

Because the board carries fewer, larger items. In an AI-native team there are no stories, so your approval queue is epic-level outcome tickets and you approve the currency share, the key user journeys and the test requirements rather than acceptance criteria. One of those stalling is a far bigger share of the quarter than a stalled story ever was, so a two-day stall matters more, not less, and it gets named the morning it shows. Tenhaw sets that operating model up with a delivery team of two or three rather than twenty. A model reporting completion is a claim, not evidence, so done costs more attention too, with someone named watching the tests pass and the journeys demonstrated in front of a person.