Published in full. Free to adopt.

The operating model we run, published for you to take.

How a product and delivery organisation works once AI agents do a growing share of the building. It is the methodology behind every Tenhaw engagement, all of it is on this page, and you do not have to hire us to use it.

Delivery modes: AI-augmented and AI-native
2
How-to guides, free to read and use
17
Every roadmap, no epic crosses the boundary
1 quarter
To adopt it, with us or without us
£0
Start with AI-augmented vs AI-nativeRead the how-to guides
Ask The Tenhaw Wayanswers from this page
Ask anything about the operating model and I will answer from this page, then point you at the section to read in full.

Prefer to talk it through? Ask us on a discovery call →

If you are reading this as a board-level buyer

Read three things, then stop

The rest of this page is written for the people running the work. These three are the ones you will feel in your own reporting, and each one changes what you are able to ask for.

  1. 01

    Every outcome is priced in currency, with a named owner on your side

    Nothing enters the system without a business result, a baseline anyone can re-run, one visible line of arithmetic and one person in whose plan the number sits. What reaches you is a portfolio of priced commitments with owners against them, rather than a list of features in flight.

    How an outcome is priced→
  2. 02

    Outcome validation runs monthly, on every live outcome

    Once a month the validation query is re-run and the answer is reported as it comes out: the value landed, it did not, or it is too early to say. It changes the reporting question from what shipped to what arrived, and it means an outcome can be closed in front of you as not realised instead of quietly left open.

    How value is validated→
  3. 03

    Every quarter opens with a tech debt epic and a bug budget epic

    Both are on the roadmap with capacity against them before any new work is chosen, and both are closed honestly at the end of the quarter. The trade-off between new value and maintenance becomes a number you approve at planning rather than a surprise reported to you in the quarter it goes wrong.

    How the quarter is bounded→

What those three produce each month is set out in What leadership sees each month, further down this page.

Read this first

What this is, and what it is not

In one paragraph

The Tenhaw Way is an operating model for product and delivery organisations working with AI agents. It rests on four values enforced as operating decisions rather than posters, a work breakdown where nothing exists that does not trace to a priced business outcome, two delivery modes for AI-augmented and AI-native teams, quarterly timeboxes that leave tech debt and bugs nowhere to hide, hard approval gates at the points agile usually skips, and a fixed cadence of rituals each owned by a named role. It is the methodology behind every Tenhaw engagement, and it is published in full so you can adopt it without hiring us.

01
It is published free, and it is yours
Everything is on this page, and the seventeen how-to guides behind it are free to read and use too. There is no gated version, no certification and no licence to buy. Adopting it does not require an engagement with us, and we would rather you took it than admired it.
02
It is not a framework rollout
Nothing here asks you to replace an SDLC, a change framework or an assurance structure you already have, and nothing here needs a new job title. Take the parts that pay for themselves. The two that carry most of the value are pricing every outcome in currency and validating monthly whether the money actually arrived.
03
The genuinely new part is the delivery mode
Most of what follows will be familiar to anyone who has run a delivery organisation. What is new is what a ticket becomes when the model does the building and the developer directs it, rather than a developer building with AI alongside. That is the next section, and it is the one worth your time.
The problem it was built for

Why it exists

Not because agile is bad. Because the operating model underneath it was designed for a world where a person did all of the building.

Most teams we meet have the same problem: they are busy. Boards are full, meetings run on time, retros fill the whiteboard. And yet the business still does not trust the roadmap, features ship without anyone measuring whether they worked, and nobody can answer a simple question: how much value did this quarter produce?

If value is not priced, technology is a cost centre.
Value 02, measure value in currency

The issue is not effort. The operating model was designed for a world before AI could do research, scaffold code, write tests, critique designs and scrape the competition on demand. Agile was tuned for a slower, quieter environment. The Tenhaw Way keeps what still works (flow, feedback, honest measurement) and adds the four things that matter now: currency on every outcome, a workflow with real approval gates, AI applied deliberately at each phase rather than sprayed across the team, and a quarterly timebox that nothing escapes without being accounted for.

The part that is actually new

Two delivery modes: AI-augmented and AI-native

Everything up to this point is the same for every team: outcomes carry a currency target, epics carry their share of it, and the roadmap is one quarter. What changes is how a ticket gets written once the roadmap is set, and that depends on whether the developers are being assisted by AI or directing it.

Who it is for

AI-augmented
Teams where developers still work broadly traditionally and AI assists inside that workflow: scaffolding, tests, review, research. This is where most organisations are today, and for those teams the full breakdown is still the right answer.
AI-native
Teams where the model does the building and the developer directs and verifies it. Decomposing into stories here is counterproductive: it strips out the surrounding context the model needed, and pre-empts judgement the model is now capable of exercising itself.

A ticket is

AI-augmented
A story. The smallest piece of user-visible value the team can ship, small enough to build in a sprint and specific enough to test.
AI-native
An outcome ticket, written at epic level. It carries the outcome, its share of the currency target, the key user journeys, and the test requirements. It is written to be handed over whole, so it has to contain enough for someone to work from it without a follow-up conversation.

Work breaks down into

AI-augmented
All four levels. Outcome, epic, story, and chapters where a developer needs to break a story down mid-build.
AI-native
Three levels, not four. Outcome and epic. Stories and chapters do not exist, because the outcome ticket is the unit of work and splitting it below that loses more than it gains.

Before work starts

AI-augmented
An epic cannot leave Ready for Dev without product approval, engineering approval and at least one product-approved story attached. A story cannot leave the backlog until its parent epic is product-approved.
AI-native
The outcome is stated with its currency share, the key user journeys are listed, the test requirements are defined, and both product and engineering have approved. There is no child-story requirement, because the ticket already carries what a story used to prove.

Done means

AI-augmented
The story's acceptance criteria are met and a human has reviewed the change.
AI-native
Both, not either: the test requirements in the ticket pass, and the key user journeys named in the ticket are demonstrated working. A model reporting that it has finished is not evidence that it has.

It reaches the builder by

AI-augmented
The story goes to a developer, who builds it and uses AI wherever it helps.
AI-native
A product brief becomes outcome tickets, the tickets are prioritised, and each one goes either straight to a model or to a developer who runs it into a model and iterates until the outcome is met.
Values, each one an operating decision rather than a poster
4
Delivery modes, chosen per team rather than per ticket
2
Quarter per roadmap, opened with a tech debt and a bug budget epic
1
Rituals on a fixed cadence, each owned by a named role
7

All of it is published here, including the seventeen how-to guides.

The four values

Four decisions that change what a team is allowed to do

Not wall posters. Each one removes an option teams normally have, which is the only reason any of them survive contact with a hard quarter.

01

Radical transparency

Everyone in the room should know why they are doing the work, how it ladders to an outcome, and what value sits at the top of that ladder.

In practice

Open any piece of work (story, chapter, bug, tech debt) and you can see the parent epic, the outcome it rolls up to, and the currency target behind that outcome. Nobody is ever more than one step from knowing why their work matters. If that chain is broken anywhere, the work should not have started.

02

Measure value in currency

If value is not priced, technology is a cost centre. "Increase checkout conversion by 1%" is not enough. "Increase checkout conversion by 1%, lifting revenue by £1m" gives you a number you can plan against, report on, and close the loop on.

In practice

Every outcome carries a target value in currency. Every epic carries a planned contribution to that target. When the sum of the epics does not cover the target, that gap is visible and someone owns it. And if your organisation historically realises 70% of what it plans, you plan headroom accordingly, with calibration grounded in your own delivery data, not optimism.

03

Predictable delivery

You cannot plan or prioritise honestly if delivery does not land when you said it would.

In practice

Size the work, simulate against your own historical throughput, and schedule the portfolio so the whole set of commitments lands, not just the loudest one. No single-point estimates: produce p50/p85 confidence intervals from your flow data and surface slips before the deadline arrives. Miss a gate early; react early.

04

Embrace feedback loops

Reviewing what happened, why, and how to improve runs from outcome validation all the way down to team psychological safety.

In practice

Retrospectives every two weeks. Health checks every month. Outcome validation every month on every live outcome. Demos as often as you can manage, daily is fine. The team that talks about its own output honestly, every week, is the team that compounds.

How work breaks down

Four levels, one direction

Nothing exists in the system that does not trace to a priced outcome. That is the whole purpose of the hierarchy: it is a traceability rule, not a taxonomy to be certified in.

  1. L1

    Outcomes

    A business outcome with a currency target. Can span multiple quarters. Usually more than one active at a time.

  2. L2

    Epics

    Each linked to exactly one outcome, each carrying a planned currency value. The sum of an outcome's epics should at minimum cover its target, ideally with calibration headroom on top.

  3. L3

    Stories

    Each linked to one epic. A story cannot exist without a parent epic, and it cannot leave the backlog until that epic has been product-approved.

  4. L4

    Chapters

    Optional. Created by developers when a story needs breaking down further mid-build. Always belong to exactly one story.

An AI-native team stops at L2. Stories and chapters do not exist for them, because the outcome ticket is the unit of work and splitting below it loses more than it gains. Two of these four levels are a choice, not a requirement.

Roadmaps are quarterly timeboxes

A roadmap is exactly one quarter. Outcomes can span quarters; epics cannot. Each epic belongs to one roadmap, the quarter it ships in. That single constraint is what makes the portfolio predictable.

Tech Debt epic

Every roadmap opens with one. Tech debt raised during the quarter is linked here, so debt reduction stays first-class rather than waiting for "when there is time", there never is.

Bug Budget epic

Bugs found during the quarter are linked here. Burn rate over time tells you whether quality is genuinely improving or quietly rotting.

End to end

How one piece of work travels

From “we think this is valuable” to “we know this delivered value”, including the step most organisations quietly skip.

  1. 01

    Outcome shaping

    The business names outcomes with tangible value attached. An outcome's target is a currency number, not a vibe. Outcomes move through a clear lifecycle (Idea, Exploring, Ready for Review, Committed, Working On, Value Monitoring, Closed) so it is always obvious which ones the team is actually working on.
  2. 02

    Breaking outcomes into epics

    Once an outcome is committed it is broken into epics. One, ten, a hundred: whatever fits, but every outcome needs at least one. Each epic carries a planned value: its share of the outcome's target. If an outcome has a £1m target and you plan four epics at £200k each, that is a £200k hole, and it should be visible before the quarter starts rather than after it ends.
  3. 03

    Approval gates: the bit agile usually skips

    Epics travel through product phases: idea, research, design, ready-for-dev. Two gates cannot be bypassed. An epic cannot leave Ready for Dev without product approval, engineering approval, and at least one product-approved story attached. A story cannot leave the backlog until its parent epic is product-approved. You can stage future stories; they just cannot start.
  4. 04

    Development

    Stories flow through todo, in-progress, in-review, done. When a story turns out to be too big mid-build, the developer splits it into chapters. Tech debt and bugs flow through the same phases and are linked to the quarter's Tech Debt or Bug Budget epic. Debt never floats unbucketed.
  5. 05

    Release

    A done story is reviewed, product-approved, and scheduled for release. Stories from the same epic can release on different days, that is fine. Each release produces its ship kit: user notes, developer changelog, an executive one-pager, a rollout plan and comms.
  6. 06

    Live monitoring, then value monitoring

    Once shipped, a story enters live monitoring for post-release triage: customer impact, FAQ, support macro, and the continue / watch / rollback call. After that, only epics enter value monitoring. An epic sits there until its value has been confirmed by outcome validation, or until it is deliberately closed with a note that the expected value did not land. A £200k epic generating £40k a month takes months to validate, that is the point. Close the loop honestly.
  7. 07

    Outcome closure

    When every epic under an outcome is closed, the outcome closes with a clear reason: all linked epics done, value realised, or accepted as not realised. Outcomes are reviewed on a rolling basis to confirm they are on track, and can be closed manually whenever it is time to call it.
Applied deliberately

Where AI actually belongs

AI is applied deliberately at specific phases, grounded in real data and verified before it acts, not sprayed across the team and hoped for.

Research and discovery

synthesising interviews and market scans into evidence linked to the outcome it informs, rather than a deck nobody reopens

Breakdown

turning a committed outcome into a first-draft epic and story structure a human then edits, which is faster than starting from an empty backlog

Review

technical review and test-plan generation as a first pass before a human reviewer, not instead of one

Release

producing the four audiences' release notes (customer, support, executive, on-call) from one shipped change

Monitoring

watching delivery data and surfacing high-severity signals automatically, so nobody has to hunt for the red flags

Dependencies

detecting cross-team dependencies from live work rather than from a map declared once and left to rot

The goal is not to replace the developer, the designer or the product manager. It is to collapse the research, drafting, QA and review work that AI is now demonstrably better suited to, and give people back the time for the parts that still need them: judgement, relationships, and the call on what ships and what does not.

The cadence

Principles do not work without rhythm

Seven rituals, each owned by a specific role, each running on a specific clock. Most of these you already run. The one organisations do not run is the fifth.

Daily

Dashboarding and lookahead

Proactive lookahead plus real-time delivery metrics, so what is off track surfaces before stand-up rather than during it. Five minutes, not a ceremony.

Every 2 weeks

Refinement and sizing

Per team. Size new work, break down anything too big, re-point anything that has shifted in understanding. Recorded so the data feeds the forecasts.

Every 2 weeks

Retrospectives

Per team, with actions tracked and revisited at the next retro. Recurring themes across quarters matter more than any single session.

Monthly

Health checks

Per team, reviewed by both the team and management. Trends matter far more than any single month's score.

Monthly

Outcome validation

Every live outcome, every month. Did the value land? This is the ritual most organisations skip, and skipping it is why nobody can answer what the quarter produced.

Quarterly

Roadmap close and open

Close the quarter's roadmap honestly, including the tech debt and bug budget epics, before opening the next one.

As often as you can

Demos

Show the work to people who did not build it. Daily is fine. The feedback loop is the product of the ritual, not the meeting.

What comes out of the cadence

What leadership sees each month

Three outputs, on a fixed clock, none of them a status update. Each one is a question with an answer rather than a page of progress.

Monthly

Outcome validation, on every live outcome

For each outcome currently live: the priced target, the validation query re-run against the agreed comparison window, and one of three answers. The value landed, it did not, or it is too early to say. The third answer is only allowed where the signal genuinely has not had time to accumulate, and the date it will be answerable is stated with it. Outcomes are closed on a reason, and accepted as not realised is one of the permitted reasons.

Monthly

The health-check trend, not the health-check score

Every team runs a health check monthly and both the team and management review it. What goes upward is the trend across months rather than any single month's number, because one bad month is noise and three in the same direction is a decision waiting to be made about capacity, scope or people.

Quarterly

The roadmap close, including the two epics nobody reports on

The quarter closes before the next one opens: what was planned, what landed, what did not and why, together with the burn on the tech debt epic and the bug budget epic that opened it. Those two are reported in the same pack as the value work, so maintenance is a trade-off you approve rather than one you are told about after it bites.

This is the shape of what arrives, not sample data. What the pack contains on a live engagement is whatever your own outcomes, teams and quarter produce.

Free, no engagement needed

Doing it, not just reading it

Seventeen step-by-step guides for the moves this model asks you to make, each with the steps, a worked example and the ways it goes wrong. Written for the person doing the work rather than the deck reviewing the framework.

Read the how-to guides
The engineering half

How we build with AI

This page is how the work is organised. The build method is a separate thing: requirements as the source code, gaps and contradictions found before any code, and pair-programming throughout so the capability stays with your engineers.

Read the build method

The Tenhaw Way: your questions

What is The Tenhaw Way?

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.

How is The Tenhaw Way different from Scrum or SAFe?

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.

Why price outcomes in currency?

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.

What are the levels of work in The Tenhaw Way?

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.

Why is a roadmap exactly one quarter?

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.

What is the difference between an AI-augmented and an AI-native team?

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.

Do I need to hire Tenhaw to use The Tenhaw Way?

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.

Where does AI fit in The Tenhaw Way?

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.

In a regulated firm
This model is what produces the evidence. How the regimes bind →

SM&CR, SS1/23, Consumer Duty, operational resilience and Solvency II, and what each one decides about the order agentic work can move in.

As a supplier
What we hold, and what we do not yet hold →

Insurance cover levels, contractual position, AI tooling policy and the assurance items still in progress.

Want help landing this?

The Tenhaw Way is free to adopt. If you would rather have operators install it alongside your teams, that is what our engagements do. A 30-minute call with James will tell you which of the two you need.

30 minutesWith James personallyNo obligation
See the proof first

Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks