Intent-First Development for SAFe Teams

You run SAFe. Maybe you love it, maybe you tolerate it, maybe it's the operating system the rest of the organization picked and you make it work because at scale, having teams across the org all moving in unison toward their respective goals matters more than the religious-war you'd otherwise be having. Whatever your relationship to the framework, you have one — your calendar revolves around PI (Program Increment) Planning, your quarter has a rhythm of Inspect & Adapt, your backlog has the shape SAFe asks of it.

Then someone hands you a piece on Intent-First Development and asks you to evaluate whether it's worth adopting on your trains.

Your first question is the same question you ask every methodology that crosses your desk: does this fit how we already work, or does it ask us to abandon what we've built?

The honest answer, which this piece will defend in detail: IFD does not compete with SAFe. It composes with it. SAFe answers "how do we coordinate the work of many teams toward shared outcomes at sustainable cadence." IFD answers "how does the design work that the coordination depends on actually happen." Different questions. Different answers. Neither replaces the other.

If you're SAFe-mature enough to be reading this far, you already suspect this is true. The harder question is: where, specifically, does IFD land in the artifacts and ceremonies you already run? That is what this piece is for.

What SAFe was always going to need help with

SAFe is excellent at coordination. It is excellent at cadence. It is excellent at making capacity legible across many teams and at surfacing dependencies before they become impediments. The PI Planning ritual, when run by people who understand it, is one of the better mechanisms the industry has invented for converging a hundred-person organization onto a common quarter.

What SAFe does not strongly opine about is how the design work that produces a Feature gets done in the first place.

The framework gives you the artifact slot — Capability becomes Feature, Feature becomes Stories — but the actual content that fills those slots, the reasoning behind why a Feature is shaped this way and not another way, the constraints that ruled out the obvious alternatives, the assumptions the design rests on, the open questions that haven't yet been resolved: all of that is left to the practitioners. SAFe trusts the Product Manager and the Solution Architect and the System Team to do that work somewhere upstream of PI Planning, in whatever way they prefer.

In a pre-AI organization, "whatever way they prefer" usually meant senior people held the design in their heads and the design legibly entered the system through Feature descriptions written shortly before PI Planning. It worked, imperfectly, because the design rate was constrained by the same humans doing the typing.

That changed when AI assistants started writing code at the rate the design could be articulated. The Feature description in Jira used to be a starting point that engineers translated into design through the act of implementation. Now it is a prompt — and the design that emerges is determined entirely by the richness of that prompt. A two-paragraph Feature description produces two paragraphs' worth of design. A structured intent corpus — what IFD asks you to produce — produces a structured solution.

This is the gap IFD fills. SAFe still does what SAFe does. IFD provides the design substrate that SAFe's coordination ceremonies operate on.

Where IFD outputs land in SAFe artifacts

This is the table SAFe practitioners want to see. Each row maps an IFD artifact to the SAFe artifact (or ceremony) it most naturally feeds.

IFD Artifact	SAFe Landing Spot
Vision explanation document (at IFD's 50K altitude — the vision level)	Solution Vision / Strategic Themes / Portfolio Canvas
Capabilities explanation document (at IFD's 30K altitude — the capability level)	Capabilities (the SAFe artifact, conveniently named the same)
Architecture explanation document (at IFD's 10K altitude — the architecture level)	Architectural Runway items; Solution Architect's working corpus
Feature artifact (IFD F-###)	SAFe Feature in the program backlog — the IFD artifact carries the intent the SAFe Feature description has historically had to invent from scratch
Design Decision Documents (DDDs)	Architecture Decision Records; reviewed by Architecture Council where one exists
Captured Assumptions, Risks, Open Questions	ROAM (Resolved/Owned/Accepted/Mitigated) register inputs; Risks and Impediments; PI Risk Review
Boundary inventory (from the boundary-mapping pass)	Solution Intent dependency map; cross-ART (Agile Release Train) dependency artifacts
Project Context Card (a one-page document capturing project-level constants)	A Solution-level constants document that PI Planning preparation assumes — usually unwritten today, often re-derived from memory each quarter

A few observations from this mapping that SAFe practitioners notice immediately:

The IFD Feature artifact is richer than what most teams write into a SAFe Feature today. Today, the Feature description in your portfolio backlog is typically a paragraph plus acceptance criteria — sometimes plus a benefit hypothesis if the team has Lean Startup discipline. The IFD Feature artifact carries: the explicit why, the rationale (why this feature rather than alternatives), stakeholders by role, scope boundary with named scope-creep traps, dependencies, and an acceptance signal. When you plug that into the SAFe Feature slot, PI Planning prep gets dramatically faster — the WSJF (Weighted Shortest Job First) inputs are already there, the dependencies are already named, the stakeholder list is explicit.

Capabilities at IFD's 30K altitude map almost 1:1 onto SAFe Capabilities. This is happy accident — the two methodologies arrived at the same vocabulary for the same level of abstraction independently. An IFD 30K capabilities document and a SAFe Capability document can be the same document, with the IFD version carrying more reasoning and the SAFe version carrying the formal portfolio metadata.

DDDs and ARs are siblings, not rivals. Some Solution Trains run an Architecture Council that maintains an ADR-style (ADR=Architectural Decision Record) register. IFD's DDDs slot directly into that register; the format separates Recommendation from Decision and records the Decision Driver explicitly, which is more rigor than most ADR practices currently demand. If you have an Architecture Council, the DDDs are inputs to it. If you don't, the DDDs are how you get a lightweight one without spinning up new ceremony.

The Project Context Card fills a gap most Solution Trains have but don't name. Every PI Planning quarter, your team re-derives the same constants — what's our time-to-market window, what's our team skill ceiling, what's our rewrite horizon, what hard problems is this Solution responsible for? The Card writes those down once. Future PIs cite the Card rather than re-deriving them. Decisions that depended on the Card's answers know to flag themselves for re-evaluation when the Card changes.

What changes around PI Planning

PI Planning is where SAFe practitioners see the most visible difference between a corpus-driven program and a description-driven one. The difference is felt at three points in the cycle.

Pre-PI prep is faster. Today, your Product Managers and Product Owners spend the two weeks before PI Planning writing Feature descriptions — generating the artifact slot in the backlog, deciding what's in scope, articulating benefit hypotheses, pre-discussing with Solution Architects to find dependencies. Each of those activities is the team manually producing what IFD has already captured upstream. With a corpus, the pre-PI prep collapses into grooming the artifacts that already exist — the Feature artifact is already written, the dependencies are already mapped from the boundary inventory, the benefit hypothesis derives from the Why field, the scope boundary is already explicit.

The PI Planning ritual itself runs against richer inputs. Teams refining Features into Stories during the breakouts have the explanation document, the DDDs, and the captured assumptions to read from. Stories derived from this reading anchor against documented intent rather than against a Product Owner's verbal interpretation of a Feature. Estimation becomes more honest because the constraints are visible in the corpus rather than implicit in the Product Owner's head.

Cross-team dependencies surface earlier. The boundary inventory produced by IFD's discovery work (when adopting on existing systems) names every integration point — REST endpoints, message contracts, shared databases, UI-to-service paths. A Feature that touches a boundary owned by another ART has that dependency visible before the Day-2 dependency-mapping ritual rather than during it. PI Planning's most chaotic moment — when teams discover a critical dependency they hadn't surfaced — gets shorter.

The frame this all lands in: PI Planning has historically been a discovery ritual as much as a planning one. Teams discover what they're being asked to build, what they depend on, what's at risk. With an IFD corpus upstream, the discovery has already happened. PI Planning becomes what its name says — planning against discovered work.

What changes for each role

For the Product Manager and Product Owner. Your job becomes authoring the corpus, not just authoring the Feature description. The Feature description is what the corpus produces; the corpus is what you produce. This is more upfront work, but the work is less reactive — instead of writing Features in the two weeks before PI Planning, you're running design sessions throughout the PI on the next-PI's candidate Features, and the artifacts accumulate over time. You also gain a better handoff to the team, because Stories derived from Features anchored in a corpus carry less ambiguity than Stories derived from a paragraph. The "what does the PM actually want?" question that consumes refinement sessions today happens less often.

For the Solution Architect and System Architect. The DDDs are your primary new artifact. Architectural decisions that previously lived in your head, in working documents, or in ADRs scattered across team Confluences now live in docs/reference/decisions/ with a consistent shape. The Architectural Runway becomes the explanation document at IFD's 10K altitude — a coherent narrative of what the solution is, what bounded contexts it has, what cross-cutting concerns shape it. You are also the gate-keeper of altitude discipline; teams will try to descend to implementation altitude during design sessions before the architecture is settled, and the methodology asks you to hold the line.

For the Release Train Engineer (RTE). You inherit a corpus that makes your facilitation work easier. Pre-PI dependency mapping is faster because boundaries are documented. PI Risk Review has structured Risk artifacts to draw from rather than Risks invented during the ceremony. Inspect & Adapt has captured Open Questions and Assumptions that were named throughout the PI — the retrospective has substance from the start. You do not run new ceremonies; you run the existing ones against richer inputs.

For Engineering Managers and team leads. Your teams' code review process gains a documentation review layer. Implementation that diverges from the documented design surfaces a question — is the design wrong, or is the implementation wrong? Both answers are valid; the methodology asks you to capture the answer. Over time, the documented design and the implementation stay in step, which means new team members onboard against a corpus that reflects reality rather than against a Confluence that's eighteen months stale.

For the team. Stories are derived from Features that have explanation documents and DDDs behind them. Refinement gets shorter because the why is already articulated. Implementation gets cleaner because the design is documented, not inferred. AI-assisted development becomes more useful because the AI reads the corpus as conversation context — generating code that aligns with documented intent rather than code that the team has to retrofit to match what the PM probably meant.

What IFD doesn't do, and what SAFe still does

This is the section that lets you defend the methodology to skeptics on the train.

IFD does not run ceremonies. It does not manage cadence. It does not balance capacity across ARTs. It does not coordinate releases. It does not produce burn-down charts or velocity trends. It does not know what a Solution Train is, or that you have one, or how many ARTs are in it. It does not enforce DoR or DoD. It does not weigh WSJF priorities or run Lean Portfolio Management.

All of those remain SAFe's job. SAFe is the operating system. IFD is one application that runs on it — the one concerned with how design intent gets captured, structured, maintained, and made legible to AI assistants that are now writing significant portions of the implementation.

The honest framing: SAFe is what coordinates teams toward shared outcomes. IFD is what makes the outcomes themselves coherent. Run both. They were not designed for each other, but they were designed in service of compatible goals — work that scales without losing the thread.

What "deeply familiar with SAFe" practitioners notice immediately

A few things experienced SAFe practitioners will recognize when they read IFD's structure:

• IFD's altitude-gated design protocol is structurally similar to SAFe's notion of Solution Intent emerging at multiple levels of fidelity over time. SAFe says intent fidelity grows from fixed to variable across the PI; IFD says design descends through altitudes as higher altitudes stabilize. Different vocabulary, related discipline.
• IFD's Risk artifacts are what gets ROAM'd during PI Risk Review — and they carry more structure than most teams bring to that ceremony: likelihood and impact rated explicitly, mitigation strategies named, trigger signals listed, lifecycle states tracked across PIs. ROAM is the disposition; the IFD Risk artifact is the substance the disposition is applied to. A Solution Train that runs PI Risk Review seriously will find the IFD format makes the ROAM call easier and more defensible.
• The IFD Feature artifact and the SAFe Feature template overlap meaningfully but not perfectly. The IFD version is richer on intent (Why, Rationale, Scope Boundary). The SAFe version is richer on portfolio metadata (Benefit Hypothesis, Acceptance Criteria, WSJF inputs). The two compose — the SAFe Feature cites the IFD Feature artifact rather than duplicating it.
• IFD's notion of Recommendation distinct from Decision in DDDs maps onto SAFe's notion of architect-led but team-empowered decisions. The Recommendation is what the analysis supports; the Decision is what the team or architect actually chose, sometimes constrained by factors the analysis did not capture. SAFe practitioners running Architecture Council have been trying to maintain this distinction informally for years; IFD makes it formal.

If any of those resonated, the methodology is closer to your existing practice than the cornerstone piece's framing might have suggested. IFD is not a foreign body; it is what SAFe-mature practitioners have been doing in their heads, made durable.

Frequently Asked Questions

Who does the corpus-building work? My PMs and architects are already at capacity.

The corpus is built by whoever is already doing the design work — PMs on Features, Solution Architects on architecture, teams on component design. The difference is not who does the work; it's that the work produces a durable artifact rather than disappearing into a conversation or a whiteboard photo. Pre-PI prep currently consumes two weeks writing Feature descriptions — which is the corpus work, done informally, producing an artifact that's immediately outdated. IFD asks for that same work to produce a richer, more structured artifact that lives in the repo and is read by AI sessions throughout the PI. The time doesn't increase significantly; the output durability does.

We just finished a SAFe rollout. I'm not interested in another methodology on top of it.

IFD is not a methodology on top of SAFe. It's the design substrate SAFe coordinates against. SAFe coordinates teams, manages cadence, balances capacity, runs ceremonies. IFD is how the design work that SAFe's ceremonies depend on actually gets done. You're not adding a methodology; you're improving the quality of the inputs to the methodology you already run. A PI Planning session that reads IFD-corpus Features instead of Jira paragraph Features is still SAFe PI Planning. The ceremonies don't change. The materials the ceremonies operate on are richer.

SAFe is already documentation-heavy. Isn't this just adding more overhead?

SAFe does not specify how the design work behind Features gets done — it specifies where the resulting artifact lands (the program backlog). An IFD Feature artifact is richer than a Jira Feature description, but it replaces a Jira Feature description — it doesn't add a second document. The DDD replaces informal architecture decisions scattered across email and ADR repos. The distinction: overhead is work that doesn't improve the output. Work that produces richer inputs to ceremonies you're already running is not overhead; it's improved efficiency of the ceremonies.

Our Architecture Council already maintains ADRs. The DDD format adds structure we don't need.

If your ADRs already separate Recommendation from Decision and name the Decision Driver explicitly, you have DDDs by another name — adopt the label and move on. Most ADR practices don't make those distinctions. They record "we chose X" without distinguishing whether X was the recommended option or the chosen one under constraint. The DDD format closes that gap: when conditions change and the team wants to revisit a decision, they can tell whether the original analysis supported the chosen option or was overridden by a non-technical factor. If your ADRs already carry this information, the change is cosmetic. If they don't, it closes a failure mode that will surface next time conditions change.

Can a single team adopt this and get value without train-level buy-in?

Yes — team-level adoption produces immediate value at the Feature level. A team that writes IFD Feature artifacts, produces explanation docs, and maintains DDDs has richer PI Planning inputs, shorter refinement sessions, and implementation sessions directed by documented intent. The train-level benefits (richer Solution Intent, cross-ART dependency visibility from boundary inventory, PI Risk inputs from Risk artifacts) require Solution Architect involvement. But team-level benefits are available before any of that. The adoption path that works most reliably: one team, one PI, one Feature done the IFD way. Evaluate whether the improved planning session is worth the upfront artifact work. If it is, run the pattern on three Features the next PI.

A note on XTIVIA

This piece is methodology, not marketing. But here is what is also true: XTIVIA helps SAFe-running organizations adopt IFD as part of their PI cadence. If your train is curious about the framing in this piece and wants help running the first design session, the first DDD, the first PI of corpus-driven planning — that is work we do, and we are happy to talk about it. We offer IFD engagement support when an organization wants the IFD pattern installed faster than it would arrive on its own.