The Tenhaw Way: from a useful idea to work that delivers

Take the method. Try it with your team.

Give your team a clear result to work towards, a way to build with AI and a way to find out what improved. The Tenhaw Way connects business outcomes, delivery decisions and learning from the people doing the work. It is the operating model behind our engagements, published in full for you to use.
Find a place to startRead the how-to guides
Delivery modes
AI-augmented, AI-native
How-to guides
17, free to read
Delivery roadmap
One quarter
Method and guides
Free to read and use
Published methodUse it with your own team
Help adapting it
An Agentic Design Team: two senior practitioners designing the operating model and architecture with your people. Typically 2–4 months, £35k–£55k a month excluding VAT.
explore the design engagement →
On this page
Start hereFor leadersWhy it existsAugmented vs nativeAlongside your processThe four valuesHow work breaks downThe workflowWhere AI belongsThe cadenceReporting and decisionsQuestionsBuilding with AIHow-to guides
Ask The Tenhaw Wayanswers from this page
Tell me what you are working through. I can explain the method and point you to a useful section or guide.

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

Start here

A method you can put to work

In one paragraph

The Tenhaw Way helps product and delivery teams connect what they build to the business result it should produce. It is an operating model for working with AI agents: four values guide decisions, outcome work carries currency targets, and quarterly roadmaps make room for new work, tech debt and bugs. Two delivery modes define how developers work with AI, with clear approval gates and seven recurring rituals for planning, learning and measuring value. We use it on every Tenhaw engagement and publish it in full for you to adopt with your team.

01
Take the method. Try it with your team.
The full method and all seventeen how-to guides are free to read and use. There is no gated edition, certification or licence to buy. You can apply the practices yourselves; Tenhaw engagements provide paid help adapting and using them.
02
Start with an outcome you care about
Choose a result, agree its monetary value and record the assumptions behind it. Then check monthly what has changed against the baseline. These two practices give your team a useful place to start, alongside the delivery and assurance processes you already use.
03
Choose how your team will build with AI
In AI-augmented delivery, developers write the code with AI support. In AI-native delivery, they direct and verify a model's build from a brief at epic level. Both need clear requirements and human review. The comparison below explains what changes in the work and what your team needs to practise.
For leaders and sponsors

Three ways to make the investment easier to assess

A useful operating model helps you decide what to fund, understand what the team is learning and see what the work returns. Here is how those decisions appear in the method.

  1. 01

    A business outcome, a value and someone responsible

    Each outcome has a monetary target, a baseline you can check, the arithmetic behind the estimate and a named owner in your organisation. Value-delivery epics carry their planned contribution. Tech debt and bug budgets carry reserved capacity instead, so leaders can see both the expected return and the work needed to support it.

    Work through an outcome example→
  2. 02

    A monthly check on what the work delivers

    Re-run the agreed measurement for every live outcome. Report what value has arrived, what has fallen short and where more observation time is needed. Your team can use that evidence to improve the approach, continue measuring or close an outcome as not realised.

    See how value is measured→
  3. 03

    Space for maintenance in every quarter

    Each quarterly roadmap opens with a tech debt epic and a bug budget epic, with capacity reserved before new work is chosen. At the quarter's close, review what that capacity supported alongside the work delivered. This makes the trade-off available to discuss at planning.

    See how the quarter is planned→

The monthly and quarterly reporting is set out in What leaders and teams review, further down this page.

Bring a reporting question to a 30-minute call with James. We can explore which part of the method would help.

Talk it through
Why it exists

Connect what gets built to what gets better

AI can help a team explore and build more quickly. Choosing useful work, checking the result and learning from it still need people who understand the business.

Think of a weekly report assembled from six places. AI might help gather the information, giving your team more time to interpret it. But did the preparation time fall, and did the report become more useful? The people doing the work know which exceptions need checking and which decisions the report supports. The Tenhaw Way connects that knowledge to the plan and the evidence, from the first idea through to measuring what changed.

What would your team do with the time this could give them back?
A useful question to start with

AI gives teams more ways to investigate and build: it can help compare research, draft code and tests, or review a design. Deciding where that help is useful takes the knowledge of the people doing the work. The model brings those decisions into a shared workflow, with a currency target on every outcome, product and engineering approval before development, deliberate uses of AI and a quarterly close that accounts for what shipped and what remains. Flow, feedback and measurement give the team a way to improve the approach as it learns.

How your team builds

Two delivery modes: AI-augmented and AI-native

Both modes share priced outcomes, delivery epics with planned value contributions and one quarterly roadmap, including the separate Tech Debt and Bug Budget capacity allocations. The difference is how the team writes and builds the work: developers can use AI within their existing workflow or direct a model to build from a complete outcome ticket.

Who it is for

AI-augmented
Teams where developers write the code and use AI within that workflow, for example to scaffold a component, draft tests, investigate a question or support a review. Stories give each developer a defined piece of work to build and verify.
AI-native
Teams where the model does the building and the developer directs and verifies it. The method keeps the outcome, user journeys and test requirements together at epic level, giving the model the context it needs and the developer a clear basis for checking the result.

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. Write it for someone who has not been in the planning conversations: it must contain enough to build from when handed over whole.

Work breaks down into

AI-augmented
Outcome, epic and story, with optional chapters when a developer needs to break a story down during the build.
AI-native
Two levels: outcome and epic. The outcome ticket is the unit of work; this mode uses no stories or chapters below it.

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. These checks establish the value, scope and first testable piece before development starts.
AI-native
State the outcome and its currency share, list the key user journeys and define the test requirements. Both product and engineering must approve before the epic leaves Ready for Dev. The ticket carries the required detail itself, so no child story is required.

Done means

AI-augmented
The story's acceptance criteria are met and a human has reviewed the change.
AI-native
The ticket's test requirements pass and every key user journey named in it is demonstrated working. Both are required. The developer verifies the result against that evidence, including human review of the change.

It reaches the builder by

AI-augmented
The story goes to a developer, who builds it and uses AI where it helps. The developer remains responsible for understanding and reviewing the change.
AI-native
Turn a product brief into outcome tickets and prioritise them. Each ticket goes directly to a model or to a developer who directs the model and iterates until the test requirements pass and the user journeys work. Business value is then checked through outcome validation.

Use a 30-minute call with James to discuss how your team builds today and what a change of mode would involve.

Talk it through
Alongside your existing process

Using the method with Scrum, SAFe or your own approach

Start by mapping the method to the work your teams already do. Your existing roles, delivery process and assurance controls provide the context. Agree where outcome ownership, product and engineering approval, and value measurement sit within them.

The Tenhaw Way makes three choices explicit: business outcomes have monetary targets; both product and engineering approve an epic before development starts; and each quarterly roadmap reserves capacity for tech debt and bugs. In AI-augmented delivery, the epic also needs at least one product-approved story. These requirements give teams a shared basis for choosing and starting work.

Then look at how your team uses AI. A team directing a model's build needs to practise writing a complete outcome ticket and checking the resulting user journeys. A team using AI within a developer-led build keeps stories, with optional chapters. Choose the mode for the team and support it with the review skills and feedback it needs.

Values that guide everyday decisions
4
Delivery modes, with a standing choice for each team
2
Quarter per delivery roadmap, with maintenance capacity reserved
1
Regular practices for learning, planning and reviewing results
7

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

The four values

Four values you can use in the working day

Each value has a practical expression: a reason for the work, a way to assess its value, a visible issue to act on or feedback that helps the team improve.

01

Radical transparency

Everyone should be able to see why their work matters: the business outcome it supports and its expected value, or the maintenance budget it belongs to.

In practice

Every item has a visible path to its parent epic. Outcome work traces through to the business result and its currency target; bugs and tech debt link to the quarter's dedicated capacity budgets. Establish the relevant chain before work starts. It gives your team the context to question a priority, suggest a better approach or explain why a task belongs in the plan.

02

Measure value in currency

A currency target connects a proposed improvement to an investment decision. For example, an illustrative £1m in estimated additional revenue gives a checkout improvement a financial target as well as a conversion measure. Record the assumptions and measurement period so the estimate can be checked. For time savings, distinguish recovered capacity from cash savings, which require a change in spending.

In practice

Every outcome carries a currency target, and its delivery epics carry planned contributions. Compare their sum with the target and give any gap an owner. Calibrate using your own data: at 70% historical realisation, a £1m target needs about £1.43m in planned value. Keep contributions distinct to avoid counting the same benefit twice. The Tech Debt and Bug Budget epics carry capacity shares, not outcome value. Planned value remains an estimate until outcome validation confirms it.

03

Predictable delivery

Give people a forecast they can plan around, with its uncertainty visible and enough notice to respond when it changes.

In practice

Size the work and simulate the whole portfolio against your team's historical throughput. Publish p50 and p85 forecast dates with the item count and assumptions behind them: the dates by which 50% and 85% of simulation runs finish. Use the range to plan the commitments and surface slips early. These are forecasts based on the data, so changes in scope or throughput require a fresh forecast.

04

Embrace feedback loops

Make room to examine what happened and improve it, from the value an outcome delivered to how safe people feel raising a concern.

In practice

Run retrospectives every two weeks, health checks every month and monthly outcome validation on every live outcome. Show the work as often as you can; daily demos are welcome. Your team's observations, including the awkward examples, should shape the next change. Track the actions so people can see what their feedback led to.

How work breaks down

Four levels, one direction

Follow a piece of work back to the business outcome it supports. Value-delivery epics carry their share of the monetary target; tech debt and bug budget epics record maintenance capacity separately.

  1. L1

    Outcomes

    A business result with a currency target. Outcomes can span several quarters, and more than one can be active at a time.

  2. L2

    Epics

    Each epic that delivers an outcome links to exactly one outcome and carries a planned currency contribution. Together, those epics should cover the target, with headroom calibrated from historical realisation where that data exists. The standing Tech Debt and Bug Budget epics are exceptions: they carry capacity shares in person-weeks, not contributions to an outcome target.

  3. L3

    Stories

    Each story belongs to one epic. The parent epic must exist when the story is created and must have product approval before the story leaves the backlog.

  4. L4

    Chapters

    An optional breakdown created by developers when a story needs smaller pieces during the build. Each chapter belongs to exactly one story.

AI-augmented teams use outcomes, epics and stories, adding chapters when useful. In this method, AI-native teams work at L1 and L2: the epic-level outcome ticket holds the requirements, user journeys and tests together. Engineers still plan and review the implementation; the tracked unit is the epic.

What this says about team structure

The method does not prescribe an organisation chart. You can organise around products, platforms, journeys or disciplines, provided the teams can plan and measure the work together. The requirements below give them a shared roadmap, clear dependencies and enough continuity to learn from their own delivery history.

  • The roadmap sits above the team

    The portfolio has one quarterly roadmap, shared across teams and disciplines. Teams draw work from it, so priorities, capacity and dependencies can be considered together.

  • A team holds a delivery mode

    Each team makes a standing choice between AI-augmented and AI-native delivery. Keep the team stable enough to develop the writing, review and verification habits its mode requires.

  • A team accumulates throughput history

    Forecasts sample the team's own past weeks. Continuity makes that history more useful; when the team changes, review whether earlier throughput still represents the work and capacity you are forecasting.

  • A team runs the rituals

    Refinement, retrospectives and health checks run per team. Keeping the team together lets people follow actions through and read the trends across quarters.

  • Cross-team dependencies carry an owner and a date

    Agree both before the epic they block leaves Ready for Dev. That gives the teams involved a chance to resolve the dependency while they are planning the work.

The requirement is stable teams working from one portfolio roadmap, with outcome work linked to priced targets, maintenance linked to its capacity budgets and the approval gates observed. Choose the organisation structure that helps your people do that well.

Roadmaps are quarterly timeboxes

A roadmap is exactly one quarter. Outcomes can span quarters; each epic belongs to one roadmap, the quarter it ships in. If the work will not fit, split it into epics with their own value contributions. This gives the portfolio a defined delivery window to forecast against; validating the value can continue after the quarter ends.

Tech Debt epic

Open every roadmap with a Tech Debt epic and allocated capacity. Link the debt raised during the quarter to it, so maintaining the systems has a visible place alongside new work.

Bug Budget epic

Open every roadmap with a Bug Budget epic and allocated capacity. Link bugs found during the quarter to it and track the burn rate over time, so the team can see how quality affects the plan.

End to end

How one piece of work travels

Shape the outcome, agree the work, build and release it, then measure what happened. Evidence may confirm the expected value, suggest a change or show that it was not realised.

  1. 01

    Outcome shaping

    Name the business result and give it a currency target, with the assumptions and a way to measure it. Bring together the people who understand the work and those who own the number. Outcomes move through Idea, Exploring, Ready for Review, Committed, Working On, Value Monitoring and Closed, making the difference between an idea and an active commitment visible.
  2. 02

    Breaking outcomes into epics

    Break a committed outcome into at least one delivery epic, each carrying a planned share of its target. Compare the total before the quarter starts: four epics at £200k each against a £1m target leave £200k still to plan for. Name an owner for that gap, so the team and the business can decide how to address it. The standing maintenance epics are accounted for separately as capacity budgets.
  3. 03

    Approval gates

    Epics move through Idea, Research, Design and Ready for Dev. Before an epic leaves Ready for Dev, both product and engineering must approve it. AI-augmented teams also need at least one product-approved story attached; AI-native teams need the key user journeys and test requirements on the outcome ticket. A story cannot leave the backlog until its parent epic is product-approved. Future stories can be prepared while they wait. These gates are required in both modes.
  4. 04

    Development

    Work moves through To Do, In Progress, In Review and Done. AI-augmented teams build stories and can create chapters when a story needs smaller pieces during the build. AI-native teams work from the whole outcome ticket, directing the model and verifying its output. Tech debt and bugs follow the same delivery phases and link to the quarter's Tech Debt or Bug Budget epic.
  5. 05

    Release

    Completed work is reviewed, product-approved and scheduled for release. In AI-augmented mode, stories from the same epic can release on different days; in AI-native mode, release evidence comes from the outcome ticket's tests and demonstrated journeys. Prepare a ship kit for each release: user notes, developer changelog, an executive one-pager, a rollout plan and communications. Give each audience what it needs to use, support or assess the change.
  6. 06

    Live monitoring, then value monitoring

    Monitor the released work for customer impact, update the FAQ and support macro, and record the continue, watch or rollback decision. Then assess business value at epic level, rather than on individual stories. A delivery epic stays in value monitoring until outcome validation confirms its value or it is deliberately closed with the expected value recorded as not realised. An illustrative £200k target generating £40k a month takes five months to reach. Delivery belongs to one quarter; value monitoring can continue afterwards.
  7. 07

    Outcome closure

    When every linked epic is closed, close the outcome with a clear reason: all linked epics done, value realised, or accepted as not realised. Keep the distinction between completing work and realising its value visible. Review outcomes on a rolling basis, and close one manually with a recorded reason when that is the decision.

Bring one piece of work to a 30-minute call with James and explore how it could move through the method.

Talk it through
Applied deliberately

Where AI can help the work

Choose a task where AI can help, give it the relevant evidence and have people verify the result before it informs a decision or action. The uses below connect AI to the work and make the team's knowledge part of the process.

Research and discovery

draft a synthesis of interviews and market scans, with links to the evidence. Researchers and subject-matter experts check the interpretation against the outcome it informs

Breakdown

draft epics from a committed outcome, with stories for AI-augmented teams or complete outcome tickets for AI-native teams. Product and engineering edit the draft and keep the approval decisions

Review

use AI for a first technical review and draft test plan. The human reviewer checks the findings, adds the team's difficult cases and verifies the change

Release

draft notes for customer, support, executive and on-call audiences from one shipped change. Check each claim against the release evidence before publication

Monitoring

use live delivery data to surface high-severity signals for the people responsible for investigating and acting on them

Dependencies

identify possible cross-team dependencies from live work, then have the teams confirm what is needed, who owns it and the date

A useful first draft gives people something to examine together. Test where AI reduces effort or improves the result in your workflow, and keep that evidence separate from assumptions about what it could save. Developers, designers and product managers bring the context, challenge the output and remain responsible for decisions, including what ships.

The cadence

A rhythm for learning and making decisions

Seven practices connect day-to-day delivery with longer-term results. Use the conversations your team already has where they serve the same purpose, and keep the agreed review cadence visible.

Daily

Dashboarding and lookahead

Spend five minutes reviewing current delivery metrics and the work ahead before stand-up. Flag the exceptions that need attention, so the team can use its conversation to decide what to do about them.

Every 2 weeks

Refinement and sizing

Each team sizes new work, breaks down items that are too large for its delivery mode and revisits estimates where understanding has changed. Record the changes so the next forecast uses what the team now knows.

Every 2 weeks

Retrospectives

Each team reviews what happened and chooses actions to improve it. Track those actions and revisit them at the next retrospective. Look for recurring themes across quarters as well as something useful to change now.

Monthly

Health checks

Run a health check with each team and have both the team and management review it. Read the trend alongside people's explanations; a score becomes useful when it leads to understanding and action.

Monthly

Outcome validation

Check every live outcome every month against its baseline and measurement plan. Report the value realised, not realised or still too early to assess. This is where the team learns whether the delivered work is producing the result it was built for.

Quarterly

Roadmap close and open

Close the current roadmap, including its Tech Debt and Bug Budget epics, before opening the next one. Account for completed and unfinished work so the next quarter starts from a shared picture.

As often as you can

Demos

Show the work to people who did not build it and invite them to try it. Daily demos are welcome. Their questions and difficult cases give the team something specific to test or improve next.

Reporting and decisions

What leaders and teams review

Monthly reviews show the value emerging and how the team is doing. The quarterly close adds a view of delivery and maintenance, so the next plan can use what you have learned.

Monthly

Outcome validation for every live outcome

Compare the monetary target with the agreed measurement over the relevant time window. Report value realised, a shortfall or an observation period that is still in progress. Where more time is needed, explain why and give the next review date. Measurement can continue beyond the delivery quarter. Record a reason when closing an outcome, including when the expected value was not realised.

Monthly

Team health, with context and a trend

Every team runs a monthly health check and reviews it with management. Look at the trend alongside the team's explanation of what is changing. Use that discussion to adjust capacity, scope or support. A serious concern deserves attention when it appears; it does not have to wait for a trend.

Quarterly

The quarterly close, including maintenance

Close the quarter before opening the next: what was planned, what shipped, what remains and why. Include capacity used by the tech debt and bug budget epics alongside the value-delivery work. Review any continuing value measurement separately, then use the findings to plan the next quarter.

Your reporting uses your own outcomes, delivery data and team feedback. Agree the measures and review responsibilities together so the findings support a decision.

A 30-minute call with James is a place to explore what you would like your delivery reporting to help you decide.

Talk it through
Free, no engagement needed

Pick the guide your week needs

Seventeen practical guides, each with steps, a worked example and things to watch for. Start with a decision you need to make: setting an outcome, planning a quarter, reviewing a build or measuring its value. Try the approach and use what you learn.

Read the how-to guides
The engineering half

How we build with AI

Explore how requirements guide an AI build, how engineers investigate gaps and contradictions, and how tests and user journeys help them check the result. Pair-programming brings your engineers into those decisions as the system takes shape.

Read the build method
In a regulated firm
Plan the work around your assurance requirements →

Explore the financial-services context for AI delivery, including accountability, model risk and operational resilience, with links to the relevant sources.

As a supplier
Review Tenhaw's supplier information →

Published insurance cover, contractual terms, AI tooling policy and the current status of our assurance work.

book a call

Bring the workflow everyone has learned to work around.

The method is free to use. If you would like help applying it, book a 30-minute discovery call with James Rooney. We will explore what your team wants to improve and where to start. You will leave with a rough scope whether you engage us or not.

Book a callExplore the free guides

30 minutes with James · start with the problem as it is

// pick a slot · cal.com/tenhaw/professional-servicesLIVE CALENDAR

Calendar not loading? Open it on cal.com or email hello@tenhaw.com.

The Tenhaw Way: your questions

What is The Tenhaw Way?

It is an operating model that helps product and delivery teams connect the work they build to measurable business results while working with AI agents. It combines four values, currency targets on outcomes, quarterly roadmaps, product and engineering approval gates, and seven recurring rituals.

AI-augmented teams use outcomes, epics, stories and optional chapters. AI-native teams work at outcome and epic level. Tech Debt and Bug Budget epics reserve capacity separately from the planned value of outcome work. We use the method on every Tenhaw engagement and publish it in full for you to adopt.

How is The Tenhaw Way different from Scrum or SAFe?

Compare the concrete operating rules with the way your organisation uses its current framework. The Tenhaw Way requires currency targets on outcomes, planned value contributions from delivery epics, and a quarterly roadmap that reserves capacity for Tech Debt and Bug Budget epics.

Before an epic leaves Ready for Dev, product and engineering must approve it. AI-augmented teams also need an approved story; AI-native teams put user journeys and test requirements on the epic itself. Monthly outcome validation checks what value arrived. Those requirements, together with the two delivery modes, are the useful basis for deciding what the model would add to your practice.

Why price outcomes in currency?

A currency target gives an improvement a financial basis for prioritisation and investment. For a checkout change, connect the expected conversion improvement to order volume, value per order and a stated period. Record whether a percentage change means a relative increase or a percentage-point increase, and show the assumptions behind the estimate.

Compare the planned contributions of the delivery epics with the target and give any gap an owner. Then validate the result after delivery. Recovered working time is capacity; it becomes a cash saving only when spending changes.

What are the levels of work in The Tenhaw Way?

Outcomes (L1) are business results with currency targets and can span quarters. Each delivery epic (L2) links to exactly one outcome, carries a planned share of its value and belongs to the quarter it ships in. The standing Tech Debt and Bug Budget epics are exceptions: they carry capacity shares rather than contributions to an outcome target.

AI-augmented teams also use stories (L3), each linked to one epic and unable to leave the backlog until that epic is product-approved. Developers can create chapters (L4) under a story during the build. AI-native teams stop at the epic: the outcome ticket is their unit of work.

Why is a roadmap exactly one quarter?

It gives the portfolio a defined window for planning delivery, reviewing commitments and accounting for unfinished work. Outcomes can span quarters, but each epic belongs to one roadmap: the quarter it ships in. Split work that will not fit into separate epics, each with its own contribution. Value monitoring can continue after delivery.

Every roadmap opens with Tech Debt and Bug Budget epics and allocated capacity, so maintenance is included when the team and business agree the plan. The timebox supports forecasting; it does not guarantee that a plan will land.

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

The difference is how the team builds and verifies the work. In an AI-augmented team, developers write code with AI assistance and use stories, with optional chapters. In an AI-native team, the model builds and the developer directs and verifies it.

The AI-native outcome ticket sits at epic level and carries the outcome, its currency share, key user journeys and test requirements. It is handed over whole, directly to a model or through a developer. Completion requires passing tests and demonstrated journeys; business value is validated afterwards. The mode is a standing choice for each team.

How should my teams be structured to use The Tenhaw Way?

Choose the structure that suits your organisation; the method does not prescribe a team topology. It requires one quarterly portfolio roadmap shared across teams and disciplines. Teams need enough stability to hold a delivery mode, build useful throughput history and follow through on refinement, retrospectives and health checks.

Every cross-team dependency needs an owner and a date before the epic it blocks leaves Ready for Dev. Within those requirements, you can organise by product, platform, journey or discipline. Keep the links from outcome work to its priced target, maintenance to its budget, and the approval responsibilities clear.

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

No. The method and its how-to guides are published in full and free to use. Read the model with your team, choose a starting point and use the relevant guide to try it. Tenhaw engagements help organisations apply and adapt the method, and the same instructions are available to you without an engagement.

Where does AI fit in The Tenhaw Way?

Use it for defined tasks with evidence the team can check: synthesising research, drafting epics and the ticket structure for your delivery mode, preparing a technical review or test plan, and drafting release notes for customer, support, executive and on-call audiences. AI can also surface high-severity delivery signals and possible dependencies from live work.

For example, it could compare interview notes and link recurring concerns back to the source. The people who know the work check the interpretation and decide what it means for the outcome. Product and engineering keep their approvals, and people verify the output before acting on it.

Does adopting The Tenhaw Way mean more meetings?

It depends on what your team already does. The model specifies seven rituals; map them to your current routine and give each a clear purpose. The daily dashboard and lookahead takes five minutes before stand-up. Refinement and retrospectives run every two weeks per team. Health checks and validation of every live outcome run monthly. Roadmap close and open is quarterly, and demos happen as often as the team can manage, including daily.

Outcome validation checks whether the work produced its intended value. Keep that monthly review explicit, even if it fits within a meeting you already hold.

What should we ask a UK AI delivery partner about their operating model?

Ask how a business goal becomes approved work, who makes the decisions and how the team will find out whether the result was useful. Request the model in writing so your product, engineering and business colleagues can review it together.

Then ask what the reporting will show. In The Tenhaw Way, monthly outcome validation distinguishes expected value from value realised, health checks show each team's experience and trends, and the quarterly close accounts for the roadmap, including maintenance budgets. The method is published here in full, including its approval rules and seven rituals.

Is this just OKRs with a currency figure attached?

It can sit alongside OKRs. The Tenhaw Way specifies how a priced outcome connects to delivery and measurement: each delivery epic links to exactly one outcome and carries a planned share of its target. Stories belong to one epic, with optional chapters below them in AI-augmented mode. Establish those links before work starts. Maintenance has its own capacity budgets.

The model also defines approval gates, quarterly planning and monthly validation on every live outcome. That gives your team a way to trace a target through the work and compare the expected value with what was realised.

Won't the approval gates just slow delivery down?

They require time before development starts so product and engineering can agree the value, scope, dependencies and evidence needed. That gives the people building the work a clear brief and a chance to resolve questions while changes are still in the plan.

The gates are mandatory. An epic cannot leave Ready for Dev without both approvals and, for AI-augmented teams, at least one product-approved story. AI-native teams need the key user journeys and test requirements on the outcome ticket. A story cannot leave the backlog until its parent epic is product-approved, though future stories can be prepared. Track gate dates so a delay prompts a decision early.

Do we need new roles to run this, or do our existing ones cover it?

Start by mapping the responsibilities to your existing roles. The method does not prescribe additional job titles. You need someone in product and someone in engineering with authority to approve an epic, and a named owner for each outcome's currency target and any gap in its planned value. Both approvals are required before an epic leaves Ready for Dev.

Teams also need enough stability to hold a delivery mode, build throughput history and follow through on the rituals. Review the responsibilities with the people who will carry them; the how-to guides explain what each activity involves.

We cannot adopt all of this at once. What matters most?

Start with a currency target on every outcome and a monthly check of whether that value was realised. Agree the baseline, assumptions, measurement period and owner, then compare the planned contributions of the delivery epics with the target. That gives you a practical way to discuss both the plan and the result.

Next, open each roadmap with Tech Debt and Bug Budget epics and allocated capacity, so maintenance is part of the planning decision. These are useful first steps towards the full model, which also retains its work hierarchy, delivery modes, approval gates and cadence.

Can different teams run different delivery modes at the same time?

Yes. Each team has a standing delivery mode, and both can contribute to the same portfolio roadmap. Outcomes carry currency targets, delivery epics carry planned value contributions and the roadmap covers one quarter, with separate capacity budgets for tech debt and bugs.

The difference sits in how the work is written and built. Keep the choice stable within each team so its writing, review and verification habits are consistent. A move between modes is a planned change with the people doing the work; the method does not require every team to move to AI-native delivery.

How do you stop another team's dependency derailing the quarter?

Give every cross-team dependency an owner and a date before the epic it blocks leaves Ready for Dev. Agree those with the people providing what you need, and plan all teams' commitments on one quarterly portfolio roadmap. That makes competing demands visible while there is time to adjust.

Keep checking dependencies against live work as the quarter progresses. AI can help identify possible links, and the teams confirm them and decide what to do. Ownership and early review help you respond to changes; they do not remove the uncertainty in work another team must deliver.

What stages does an outcome move through, from idea to closed?

Seven: Idea, Exploring, Ready for Review, Committed, Working On, Value Monitoring and Closed. These states help everyone see which ideas are being investigated and which outcomes the team has committed to deliver.

Break an outcome into epics only once it is committed; every outcome needs at least one. Value monitoring follows delivery and measures the result. When every linked epic is closed, close the outcome with a stated reason: all linked epics done, value realised, or accepted as not realised. Outcomes are reviewed on a rolling basis and can also be closed manually with a recorded reason.