Phase 1: Definition

The upstream work that keeps the Implementation Phase moving.

The Definition Phase turns broad product intent into targets precise enough that an AI coding agent can build them without guessing. Its output is a spec An evergreen description of how a part of the system or experience works. Kept current with actual behavior; when the team wants a change, the spec is updated first and implementation brings the system into alignment. : a description of the behavior to build, what counts as done, the constraints to preserve, and the questions or areas of discretion still open. Implementation works from those specs.

This set of work matters more now than it used to because building has gotten cheap and fast while Definition hasn't. A team used to fill the gaps in a spec with the shared context that never gets written down. An agent doesn't have that context. When Implementation and Definition fall out of step, the agent hits an ambiguous spec and fills the gap with a plausible guess that isn't what the team wanted. The resulting drift only surfaces an iteration later, as shipped work that misses the team’s intent.

The Definition Phase can begin as soon as the product has a rough shape: a working sense of who the users are, what constraints exist, and what the product first needs to do. That's enough to start asking which part to make buildable next, long before every product decision is settled. At Atomic Object, that early shape comes from a Research, Design, and Planning (RDP) engagement where teams run discovery and framing work. The output becomes the Product Backlog, where an item sits at the right level of specificity for sequencing but is still too broad to build. Definition starts there, by narrowing it.

Definition narrows Backlog Items through a repeating pipeline: gather information, synthesize it into the Knowledge Base, and write or revise the specs that agents execute against during the Implementation Phase. Definition stays at least an iteration ahead of the build so that the agents don’t get blocked waiting for new specs.

Most of the Definition Phase is judgment work: which inputs to trust, how much to validate before building versus after, and when to gather more signal instead of betting on what you already have. That judgment is what keeps the spec accurate enough to hand to an agent.

What happens in this phase

In the overall process, the team runs two iterations a week, each following the same pattern: 1 Planning, 2 Definition and Implementation work, then 3 Review. Everyone participates in the Planning and Review Phases as a full team. Definition-Phase work happens between those ceremonies, running concurrently with the Implementation Phase of the work defined in a previous iteration. At any given moment, the team is balancing Definition work across the current, next, and following iteration:

If all three horizons aren't getting attention, the system breaks. For example, if the team over-focuses on current-iteration support, the next Planning Phase goes underfed. If there’s too much focus on the future, the current Implementation-Phase questions go unanswered. Use the rhythm to keep those three horizons visible, whatever the exact meeting schedule becomes.

To pursue those horizons in a balanced way, each turn of the Definition pipeline runs the three activities below. Most Backlog Items take several turns before the specs are ready.

Each pass ends with the same question: Are the specs ready to implement? If they are, they go into an iteration. If not, the work loops back for more information gathering. The worked example at the end of this chapter shows how one team made that call.

The three activities also create natural handoff points. Work can move from one teammate to another, or one person can move through all three in a single pass. For example, a project manager captures a transcript in a stakeholder session on Tuesday. A tech lead synthesizes it into Knowledge Base updates on Wednesday. The designer updates the interaction spec on Thursday.

At any given moment, the team is making a judgment call: do they gather more information or process what they already have? Sometimes, the answer is driven by demand: Implementation needs specs for the next iteration, so the team synthesizes what it has and gets specs into shape. Other times, the answer is driven by supply: a stakeholder session is coming up, and the team prepares to gather information regardless of immediate downstream demand.

The mix of definition work shifts based on what the team needs. In a typical week, expect a rough allocation like this:

Time allocations are approximate and vary by project, work type, and point in the project.

Two habits keep the rhythm on track. The team should synthesize stakeholder input while the context is still fresh, and they should review active specs often enough to catch stale, contradictory, or missing coverage before the Planning Phase. The point is to keep ready work flowing without letting current-iteration support consume every Definition hour.

Who picks up the work

The Definition pipeline is stable; the role assignments are not. The person closest to the uncertainty takes the next pass, and the work can move between people as the question changes.

A tech lead doing a technical investigation might gather information, synthesize it, and update a spec in a single pass. A project manager on a technically complex project might focus on stakeholder information gathering and hand off synthesis to someone closer to the technical domain. A designer might carry a visual improvement from product evaluation through UX spec updates, then guide an agent through the CSS and interaction changes.

Some responsibilities do stay with specific project roles.

The project manager takes point on business stewardship and information gathering from stakeholders. The designer leads information gathering through user research and design activities: product backbones, journey mapping, personas, UX design. The tech lead specifies data models, API contracts, and architectural decisions, and they get ahead of the structure upcoming work will need. When a feature will lean on a new subsystem or a key new module, that architecture-focused spec is written in the Definition Phase, ahead of the iteration that builds against it. The timing is a deliberate trade-off, since technical design that steers the system's structure is easy to get wrong under the build pressure of an iteration, where the pull is toward whatever unblocks the current feature.

Spec authoring lands with whoever owns the Definition work for that area, often the project manager or designer, sometimes a senior dev, often a pair. These are starting points. The type of work dictates which role picks up the next piece.

Those assignments show up in the working system. For example, a stakeholder session about seat limits might become a synthesis task to update seat-management context in the Knowledge Base, then split into spec-authoring tasks such as "write the feature spec Invite Members" and "draft the architecture spec Read-only Access." The Work Board makes the handoffs visible, and the Knowledge Base keeps the decisions available when questions arise during Implementation.

Whoever writes it, a ready spec pulls several perspectives into one place: product behavior, experience details, technical constraints, and the operating context around them. Some specs hold all four directly; others link out to a mockup, an API contract, a testing policy, or a deployment note. Specs must clear the same bar the rest of Definition aims at: an agent can build from it without inventing a product, design, or an architecture decision nobody made.

Pulling those perspectives together is the point, because each covers the others' blind spots. Product intent without technical constraints leaves gaps agents fill with guesses. Technical direction without product intent produces correct-looking software pointed at the wrong outcome.

Example: Defining the Seats & Membership Backlog Item

Acme's Anvil platform has the Backlog Item Seats & Membership on its Product Backlog, one that's too vague for Implementation. The team knows organizations need to invite teammates, control who holds a paid editor seat, and remove access when someone leaves. The team does not yet know how seat reservation should work, how the invite flow chooses viewer or editor, or how read-only access fits a product where every member can edit today. One pass through the Definition pipeline turns the next buildable target into the feature spec Invite Members, something the team can plan and build next iteration, and surfaces the foundational work around it.

The output is a set of repo artifacts used in the Planning and Implementation Phases: Knowledge Base decisions, explicit open questions, revised specs, and architecture tasks that make the dependencies visible. The remaining uncertainty is tracked, but it no longer hides implicitly inside the feature.