The Tenhaw Way, answered in full.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.