The Tenhaw Way, answered in full.

The Tenhaw Way is an operating model for product and delivery organisations working with AI agents. It combines four values enforced as operating decisions, a four-level work breakdown (outcomes, epics, stories, chapters) where nothing exists that does not trace to a priced business outcome, quarterly roadmap timeboxes with dedicated tech debt and bug budget epics, hard approval gates between product and development, and seven rituals on a fixed cadence. Tenhaw publishes it in full and applies it on every engagement.

Three differences. Every outcome carries a target value in currency, so prioritisation maximises value delivered rather than tickets closed. An epic cannot leave ready-for-dev without product approval, engineering approval and, in AI-augmented mode, an approved story attached, which is the kind of gate agile frameworks usually leave optional. And the quarterly roadmap opens with dedicated tech debt and bug budget epics, so neither can hide until there is time. It also rejects the parts of SAFe that add ceremony without adding feedback.

Because if value is not priced, technology is treated as a cost centre. "Increase checkout conversion by 1%" cannot be planned against or reported on. "Increase checkout conversion by 1%, lifting revenue by £1m" can. Pricing the outcome also makes the gap visible when the planned epics do not add up to the target, which is the moment to fix it, before the quarter starts, rather than at the end of it.

Outcomes (L1) are business results with a currency target and can span quarters. Epics (L2) each link to exactly one outcome and carry a planned share of its value; an epic belongs to a single quarter. Below that it depends on the delivery mode. AI-augmented teams also use stories (L3), each linked to one epic and unable to leave the backlog until that epic is product-approved, and chapters (L4) that a developer creates when a story turns out to be too big mid-build. For AI-native teams the outcome ticket is the unit of work, so they stop at the epic.

Because outcomes that span quarters are fine but epics that do are not, an epic without a quarter it must ship in is how portfolios become unpredictable. Fixing epics to a single quarter is the constraint that makes forecasting possible. Every roadmap also opens with a tech debt epic and a bug budget epic, so both stay first-class rather than waiting for capacity that never arrives.

It is a difference in who does the building. In an AI-augmented team a developer writes the code and AI assists inside that workflow, so work still breaks down into stories and chapters. In an AI-native team the model does the building and the developer directs and verifies it, so the ticket is written at epic level and carries the outcome, its currency share, the key user journeys and the test requirements. That ticket is handed over whole, either straight to a model or to a developer who runs it into one and iterates until the outcome is met. The mode is a standing choice per team, not a per-ticket decision.

However they already are, in most cases. The Tenhaw Way constrains the work, not the org chart, and carries no team topology to adopt, so reorganisation is rarely the fix. It requires five things. One quarterly roadmap sits above the teams, not one per team or discipline, because three teams holding three roadmaps is how traceability dies. Teams stay stable enough to hold a standing delivery mode, accumulate the throughput history their forecasts sample, and run refinement, retrospectives and health checks whose value is the trend across quarters. Every cross-team dependency carries an owner and a date before the epic it blocks leaves Ready for Dev. Beyond that the shape is yours, by product, platform, journey or discipline, provided the work traces to a priced outcome and the gates hold.

No. It is published in full, including the how-to guides, specifically so a team can adopt it without an engagement. Tenhaw engagements apply it and adapt it to the organisation, but the methodology itself is free to take and use.

At specific phases rather than everywhere: research and discovery synthesis, first-draft breakdown of a committed outcome into epics and stories, technical review and test-plan generation as a first pass, release-note production for four different audiences, automated surfacing of high-severity delivery signals, and dependency detection from live work. The intent is to collapse the research, drafting, QA and review work AI is better suited to, so people keep the judgement calls.

It means seven rituals on a fixed cadence, most of them short. The daily one is a dashboard and lookahead, five minutes rather than a ceremony, so what is off track surfaces before stand-up rather than during it. Refinement and retrospectives run every two weeks per team, health checks and outcome validation run monthly, the roadmap closes and opens once a quarter, and demos happen as often as you can manage, daily is fine. The genuine addition for most organisations is outcome validation on every live outcome, every month. Did the value land? Skipping it is why nobody can answer what the quarter produced, so it is the one worth adding even if you take nothing else.

Ask any UK AI delivery partner to show you the whole model in writing, not a slide about values. Ours is on this page: four values applied as operating decisions, a work breakdown where nothing exists that does not trace to a priced business outcome, quarterly roadmaps that open with a tech debt epic and a bug budget epic, two approval gates between product and engineering, and seven rituals on a fixed cadence. Then ask what arrives on your desk each month, because that is where a method shows: outcome validation on every live outcome, the health-check trend per team, and an honest quarterly close. Ours is published in full, so you can read it before you talk to us.

No, although pricing the objective is part of it. OKRs set a target and then rely on everyone remembering it. This model makes the link structural instead. Every epic links to exactly one outcome and carries a planned share of its currency target, every story links to one epic, and if that chain is broken anywhere the work should not have started. Open any piece of work and the outcome above it and the money behind it are one step away. The other half is the loop that closes. Outcome validation runs monthly on every live outcome, so the question asked is whether the value arrived, not whether the key result got updated.

They slow the start, deliberately, and the start is where time is cheapest. Two gates cannot be bypassed. An epic cannot leave Ready for Dev without product approval, engineering approval and, in an AI-augmented team, at least one product-approved story attached. A story cannot leave the backlog until its parent epic is product-approved. You can still stage future stories, they simply cannot start. What the gates buy is that nothing gets built before somebody has priced it, approved it and agreed its shape, which is the rework nobody counts. Miss a gate early, react early.

Existing ones, in almost every case. The Tenhaw Way constrains the work rather than the org chart, so what it asks for is responsibilities rather than hires. Someone in product and someone in engineering who can approve an epic out of Ready for Dev, because neither gate can be bypassed and both approvals are required. Someone who owns the currency target on an outcome, so when the planned epics do not cover it the gap has a name against it. And teams stable enough to hold a delivery mode and build the throughput history their forecasts sample. The model is published in full, including the how-to guides, so you can pick it up with the people you have.

Put a currency target on every outcome, and check monthly whether the money arrived. Those two changes carry most of the value. The first stops work entering the system without a business result above it, and it makes the shortfall visible when the planned epics do not add up to the target, which is a conversation worth having before the quarter starts rather than after it ends. The second is the ritual most organisations skip, and without it nobody can say afterwards what the quarter was worth. If you want a third, open every roadmap with a tech debt epic and a bug budget epic, so maintenance becomes a trade-off you approve at planning. Take those and leave the rest.

Yes, and most organisations we work with run both across different teams. The mode is a standing choice per team rather than a decision taken ticket by ticket, because the two need different habits and switching mid-quarter gives you the worst of both. Everything above the ticket is identical either way. Outcomes carry a currency target, epics carry their share of it, and the roadmap is exactly one quarter, so a portfolio holding both kinds of team still adds up to one plan. Our view is that AI-augmented is the stepping stone and most product teams end up AI-native, though moving a team across is deliberate work on how it writes, reviews and verifies rather than a switch someone flips.

Every cross-team dependency carries an owner and a date, and both are settled before the epic it blocks leaves Ready for Dev. That puts the conversation into planning rather than into week nine, which is where an unowned dependency normally surfaces. It is also one of the places AI is applied deliberately, which means dependencies are detected from live work rather than read off a map declared once at the start of the quarter and left to rot. The structural constraint helps as well. One quarterly roadmap sits above the teams rather than one per team, because three teams holding three roadmaps is how traceability dies.

Seven: idea, exploring, ready for review, committed, working on, value monitoring, then closed. Naming them matters because it keeps it obvious which outcomes a team is genuinely working on rather than which ones somebody once mentioned in a meeting. An outcome is only broken into epics once it is committed, and every outcome needs at least one. It reaches value monitoring once the work under it has shipped and is being measured. It closes on a stated reason: all linked epics done, value realised, or accepted as not realised. Outcomes are reviewed on a rolling basis, and can be closed manually whenever it is time to call it.