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. There are hard approval gates that agile frameworks usually leave optional: an epic cannot leave ready-for-dev without product approval, engineering approval and an approved story attached. 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. AI-native teams stop at the epic: the outcome ticket is the unit of work.

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.

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.