0 Contact
Home > Blog > AI-Native SAFe > From Outputs to Outcomes: What AI-Native SAFe Changes

From Outputs to Outcomes: What AI-Native SAFe Changes

Two weeks ago, I wrote about the first session of Scaled Agile's AI-Native SAFe series and Andrew Sales's central premise: your organisation's ability to get value from AI depends on having a standard framework, not just the technology itself. Session two picked up exactly where that left off, walking through the guidance now live on the AI-Native SAFe big picture for the shift from outputs to outcomes.

The Barrier to Build Has Evaporated

Andrew's premise is that when AI makes it cheap to produce endless output, chasing more output becomes exactly the wrong strategy. The value comes from what you learn and validate, not from volume. He credited this to Mik Kersten, author of Project to Product, whose new book Output to Outcome is out on 14 July, and illustrated it with Cognition, the company behind the AI software engineer Devin. Their process: build multiple new agents and features every week, review them with senior leadership on a weekly cadence, keep pursuing whatever looks promising, and drop everything else. Most of what they build never sees the light of day.

I think he's right, and I don't need Cognition's example to believe it. I'm about as far from a software engineer as you can get, and I can now sit down with an LLM and produce working code myself. The barrier to building, or at least to prototyping, has all but evaporated. This still blows my mind.

Where I'd add a caveat is that this isn't true for every organisation today, which is exactly why Core SAFe and AI-Native SAFe exist side by side rather than one replacing the other. Not everyone is operating at the same level as Cognition.

The Outcome-Driven Product Development Cycle

Andrew then walked through the five-stage cycle sitting at the heart of the whole model: outcomes, priorities, outputs, measurements, value. It applies at every level, portfolio, ART and team. Outcomes set the destination and are expressed as OKRs. Priorities decide where funding and capacity go. At the portfolio level, that means investment strategy; at the team and ART level, it means committed capacity. Outputs are the features, prototypes and experiments teams produce. Measurements tell you whether those outputs are moving you toward the outcome and give you the basis to decide whether to continue, stop, or pivot to something else. And value is the tangible result, deliberately made concrete rather than abstract: customer outcomes and business results, measured through ROI. Every step feeds back into the one before it.

Outcome-Drive Development in AI-Native SAFe

The five-stage cycle feels somewhat familiar. It echoes the SAFe Lean Startup Cycle and the Continuous Delivery Pipeline from Core SAFe and, in my mind, represents the intent of these practices. Of course, there is often a stark difference between how Core SAFe is intended and how it is implemented. It will be interesting to see how the AI-Native reimagining of the Product Development Cycle to be Outcome-Driven changes the reality of SAFe in the field. If AI-Native can crack this nut, I see a huge opportunity to make a similar change to Core SAFe.

There are, however, two clear differences I noticed from Core SAFe. The treatment of OKRs and the treatment of ROI.

Andrew described outcomes being expressed as OKRs “down to the individual contribution that a team is making in a particular PI.” This was interesting to me, as the Core SAFe OKR guidance explicitly cautions against using OKRs to define PI Objectives, warning that they take too long to write and that key results are often lagging indicators, poorly suited to a PI timebox. So after the call, I looked at the AI-Native SAFe guidance to validate the shift, and there it was: AI-Native SAFe uses PI and team-level OKRs to maintain strategic alignment and intent. This is new.

AI-Native SAFe shifts the value conversation toward ROI in an effort to make it more tangible. Core SAFe promotes Innovation Accounting instead, deliberately deferring heavy financial modelling until organisations are more confident they're building the right thing. When Andrew mentioned using ROI to measure value, I got curious and went to the AI-Native SAFe guidance to learn more.

It's more nuanced than a straight swap. The guidance agrees that ROI is a lagging indicator and builds its own leading indicators to compensate for it: feature adoption, cycle time, and customer retention. But it also recommends modelling ROI upfront and continuously, with forecasted ROI shaping which initiatives get funded from day one, treating token and inference costs as variable operating expenses that must be built into the calculation from the earliest planning stages, not bolted on after launch. That's the part Innovation Accounting explicitly said to defer. 

Four Pressures on the Portfolio

Andrew named four pressures AI is putting on portfolio-level investment.

Technology velocity: annual budget cycles can take six to nine months to formulate, and by the time the budget is approved, the technology it was built around may already be behind. His fix is shorter, more frequent funding cycles rather than one annual lock-in.

I think organisations are underestimating the impact of this one. I look at organisations kicking off multi-year ERP replacements right now and wonder whether the solution will be fit for purpose by the time it is completed (or abandoned mid-flight!)

ROI predictability: nobody has a reliable five-year return model for AI yet, and it’s causing decision paralysis for some organisations. His fix borrows from venture capital: place a number of small bets, let the failures die quickly, and put more weight behind whatever's working.

ROI has always been hard. The money now pouring into AI is just sharpening the question.

Competitive dynamics: whoever gets to market first is building an advantage that's proving very hard for anyone else to close, so speed to a working version now matters more than a polished launch later.

First-mover advantage has always mattered. AI turns the dial up. I find myself wondering whether falling behind in this age will be harder to claw back from than it ever was before.

Resource allocation: locking your full budget into legacy IT roadmaps leaves nothing to redirect when something better comes along. His fix is a strategic AI reserve, budget deliberately held back so you can move when it's worth funding.

Strip away the AI framing, and resource allocation is just agility: the ability to respond to change. It's the one pressure I'd bet most transformations already claim to have solved and few actually have. Watch how fast a strategic reserve gets raided the moment a project runs over budget.

A New Scale of Budget Risk

Andrew also flagged a shift in how ART budgets work. Costs used to be predictable: salaries, licences, some infrastructure. Token consumption is now pulling a growing share of that into variable spend, bringing three new risks.

  • A popular product can quietly get expensive. Cost now follows usage in real time, which Andrew called "a good problem to have" until the bill arrives.

  • A simple-looking prompt can hide real complexity. Retrieval, conversation history, and system instructions can all fire behind the scenes, again and again, turning one request into tens of thousands of tokens.

  • Vendors keep rewriting the rules. Models get deprecated at a pace we haven’t experienced before, pricing structures change, and it can catch you out mid-cycle.

In my experience, the use of SaaS products had already begun pushing ARTs to think beyond labour, licences and infrastructure, but token consumption is an entirely new scale-of-usage challenge. There are plenty of stories doing the rounds about enterprises blowing through token budgets. Andrew's point about vendor pricing risk is real, but it reminded me there's a second risk he didn't mention: we're also watching model access get switched off overnight by politicians. The age of AI is clearly going to be an unpredictable place to be managing a budget in.

ART Outcomes, Vision and Roadmap Get an Upgrade

Andrew introduced the AI-Native SAFe Outcome Tree as the replacement for the old planning chain, epics cascading into features, features cascading into stories. Features still exist; they're still one of the outputs teams produce, but the fixed hierarchy that used to link and trace them upward is gone. His reasoning: increasingly, we can't specify in advance what's going to get built or exactly how, so a rigid cascade of outputs handed down from the top doesn't hold up anymore. Instead, strategic outcomes set at the portfolio level cascade down to teams, who define their own outcomes at a much shorter horizon, sometimes just days. I like the outcome tree, though I'm genuinely curious about how the mechanics will work at the scale of an ERP replacement. 

AI-Native SAFe Outcome Tree

He also drew a clear distinction between ART outcomes and the PI objectives we already know. ART outcomes come before planning. They're not a commitment; they're the direction an ART is aiming for and the thing PI Planning has to work out how to pursue. Their job is to help the portfolio monitor and steer, give each ART a boundary for what it's there to achieve, and give teams a reason for the work rather than just a list of it. 

Andrew was equally specific about product vision, built on three pillars:

  • Informed by data, using AI to run sentiment analysis and track competitors and industry movement at a scale no product manager could do manually.

  • Aligned with what the portfolio is funding and the financial limits it's operating inside.

  • Anchored to the technology and architecture an organisation can actually deliver on, not just what's technically possible somewhere else.

AI-Native Product Vision
An effective product vision is informed by data and aligns with strategy

Roadmaps change shape too, moving away from a straight list of features toward outcome-based swim lanes, with milestones and releases still marked, but read as a tool for checking direction rather than a delivery schedule. A swim lane for outcomes doesn't close when a feature ships. Several outcomes only reveal themselves over time, so that lane keeps being watched and validated well after release.

AI-Native Roadmap

Organisations have always struggled with vision and roadmaps. Whatever an organisation does badly today, I expect the age of AI will amplify.

Context Is King: Curated Data Is the Enabler

Andrew closed out the session by talking about how AI gets briefed to do its job: context. I love this! Context came out as my number one strength on one of those workplace strengths assessments. (Maybe I was an AI in a previous life!) So I'm biased, but the point stands: context is king.

His argument: AI only becomes a reliable partner, rather than a generic tool, when intent (why we're doing this), specifications (what good looks like and where the limits sit), and context (the environment the product lives in) are working together. Miss any of the three, and you get output that's either off-target or hallucinated. Connect them, and an AI agent stops needing to be walked through the background of a task every time because it can pull its own intent, specs and context from a shared source instead of starting cold.

That shared source is what Andrew called curated data: complete, accurate, maintained and securely accessed, built intentionally ahead of time as part of the architectural runway rather than assembled under pressure when it's suddenly needed. He tied it directly to the cycle itself: intent and context feed outcomes, performance data feeds priorities, specifications feed outputs, feedback data feeds measurement and value. Nothing in the model runs without it.

Intent, specifications, and context drive AI-Native execution and delivery

I suspect a lot of organisations are heading for a 20/20 hindsight moment when they realise how much they've underinvested in this space. I've always said an enterprise's data is its greatest competitive advantage. In the age of AI, I think that's even more true.

Stay Tuned

Not much in this session was new to me, and I don't think that's a bad thing. Good frameworks should feel like validation of what good practitioners already know.

For those wondering how they will get up to speed with AI-Native SAFe, Andrew announced that an on-demand upgrade path will become available from 25th August, letting anyone with an existing SAFe certification upgrade to AI-Native SAFe. 

Session three was about ARTs, Teams and Roles. My take on it is here: So What is an AI-Native ART?