The shape discipline is the practice of establishing shared understanding between product and engineering — through user story mapping, evidence-based personas, and walking-skeleton MVPs — before any code is written. It's the upstream control that complements the downstream build-it-right controls we covered last week, and it becomes critical when AI accelerates execution but not alignment. Teams that skip it ship well-built fragments of the wrong product, faster.
Last week we wrote about harness engineering — the framework that defines what coding agents need beyond the model itself. Guides steer before action. Sensors observe after. A steering loop makes both better over time.
The framework covers the downstream — the controls that ensure things are built right. But there's an upstream complement that deserves its own treatment.
Every downstream control in the harness — architecture rules, coding standards, TDD workflows, mutation testing, fitness functions — assumes the agent knows what it's building. The downstream ensures the thing gets built right. It does not ensure the right thing is being built.
That's the upstream discipline. And teams that skip it are the ones failing most quietly.
The Upstream Problem Nobody Names
Here's the failure mode, concretely. A tech lead sits down on Tuesday morning with a ticket: "Add promo code validation to checkout." The spec is one sentence. The team has Cursor, Claude Code, a clean architecture, good tests, and a disciplined TDD workflow. Everything the harness wants.
The agent writes the validation logic in forty seconds. The tests pass. The PR merges. On Thursday, checkout starts returning five-hundreds on 8% of sessions. The root cause: the agent wrote a test that asserted the implementation, not the intended behavior. The sign on the expiration check was inverted. The bug was in the spec itself — nobody wrote a spec, the agent inferred one.
But that's not the actual problem. The actual problem is that nobody knows if promo codes even matter in the MVP. Nobody agrees on what the MVP is. Product thinks the MVP is "the end-to-end checkout flow." Engineering thinks the MVP is "core payment processing." The designer thinks the MVP is "the user can redeem a code and feel confident." The CTO thinks the MVP is "a demo for the next board meeting."
So the team built promo code validation — well. It shipped. It broke. It got fixed. Thirty hours of work.
And promo codes weren't in the MVP.
AI scales execution, not alignment. When product and engineering don't share a picture, the agent faithfully builds whoever wrote the ticket's version — which is usually wrong because no single ticket captures the shared understanding that was never established.
Traditional harness controls — TDD, Clean Architecture, mutation testing, gates — verify that code is built right. They do not verify that it's building the right thing. That check has to sit upstream.
The Shape Discipline
The missing control has a name: shape. It comes from design thinking — sense what's needed, shape the response before committing to build. The technique Prevention uses to operationalize it is Jeff Patton's User Story Mapping (O'Reilly, 2014), and it has three core moves.
First, evidence-based personas with Jobs-to-Be-Done. Not demographic profiles. Not invented users. Real people with documented pain who hire your product for a specific job. The format is strict: "When [situation], I want to [motivation], so I can [expected outcome]." If you can't complete that sentence with evidence — an interview, an observation, a support ticket — you don't have a persona, you have a guess.
Second, a journey backbone. The end-to-end sequence of things the persona does to get value from your product, left to right in time order. Not a feature list. Not a sitemap. A narrative of what happens from the moment they first encounter the product until they're getting ongoing value. Every phase has a goal ("why are they here") and an activity ("what are they doing").
Third, release slices by outcome. Stories are stacked vertically under each backbone phase by priority. Horizontal lines divide the map into releases — MVP, R2, R3 — named by the outcome they add, not the features they contain. "Teams self-serve adoption" is a valid R2 name. "Dashboards and email alerts" is not.
The critical rule underneath all three is the walking skeleton. An MVP is not the smallest feature set. It is the thinnest end-to-end slice that walks the full backbone and delivers real value. Every backbone phase must have at least one MVP story. If any phase is empty, the skeleton is broken — users can't walk the full journey in MVP, so there is no MVP, there is a fragment.
This rule is easy to state and almost impossible to internalize without practice. Most "MVPs" shipped by AI-assisted teams are fragments. They look like MVPs because they have a feature list and a ship date. They aren't MVPs because the user's journey has dead zones — the user can discover the product, but can't trial it. Or they can trial it, but can't set it up. Or they can set it up, but there's no feedback loop that tells them it's working.
Fragments are easy to build. Walking skeletons are hard.
Why Fragments Are the Default for AI Teams
Three structural reasons.
One: velocity obscures direction. When the agent writes code at machine speed, the team's attention shifts to keeping up with output. Ten features shipped per week feels like progress. Nobody asks "are these the right ten features" because the output is visible and the question isn't.
Two: features are addictive, outcomes are uncomfortable. Feature lists let you measure progress in units. Outcomes require you to measure progress in user behavior — slower, noisier, less gratifying. Teams with AI agents have exactly the wrong incentive: they can ship features faster than they can learn whether the features matter.
Three: the product-engineering handoff is already broken, and AI widens it. Pre-AI, the handoff was slow enough that misunderstandings surfaced during implementation — someone would say "wait, this doesn't match the spec" three days in, and the conversation would happen. With AI, implementation is fast enough that misunderstandings make it all the way to production before anyone notices.
The result is a team that ships quickly, looks productive, and produces six-month features for users who don't exist.
The B2B Trap: Loved by Users, Cancelled at Renewal
There's a second failure mode that shape makes visible, and it's specific to B2B products.
In B2B, the user (who runs the product daily) is usually not the buyer (who approves the purchase and the renewal). The user is a developer, a sales rep, an analyst. The buyer is a CTO, a VP of sales, a CFO. They have different jobs, different surfaces, different success criteria.
Most MVPs are designed for the user. The reasoning is that if the user loves it, word of mouth drives adoption, and the buyer will renew. This is correct in consumer products. It is wrong in B2B.
In B2B, the user loves the product, adopts it enthusiastically, tells the buyer how much they love it — and the buyer cancels at renewal because they couldn't see ROI. The buyer never experienced the product the way the user did. The buyer experienced it through quarterly check-ins and board slides, and neither gave them the confidence to renew.
Shape makes this trap visible by forcing a second walking skeleton. The user's walking skeleton is their daily loop — the full journey from adoption to ongoing value. The buyer's walking skeleton is different: discover → evaluate → see early signal → decide to renew. Both must walk in MVP, even though the buyer's surface is typically thin (four to six stories: a landing page pitch, a trial command, a weekly status signal, a renewal flow). Skipping the buyer's skeleton is the single most common reason B2B MVPs get adopted and cancelled.
A team with an agent harness but no shape discipline will build a beautiful product for the user. And lose the contract.
The Story Map as a Feedforward Control
Here's where shape maps to the harness engineering vocabulary.
In harness engineering, guides are feedforward controls that steer the agent before it acts — architecture rules, coding standards, specification files that anticipate agent behavior and constrain the solution space.
A story map is the most upstream guide there is. It doesn't tell the agent how to write code. It tells the agent what to write. When the planner reads the story map and says "we're building story s-plan-03: Priya runs /avesta-plan <story-id> and sees Example Mapping output" — that's a feedforward control. The agent now knows which backbone phase this story belongs to, which persona it serves, which release it's in, and what outcome it delivers. Example Mapping (the downstream guide) can now generate rules and examples with the right context instead of inventing them.
Without the story map, the agent operates in a vacuum. The ticket says "add example mapping flow." The agent assumes. The team assumes differently. Eight hours later, someone notices the assumptions diverged.
With the story map, the agent has a concrete reference point: this story exists at a specific place in the backbone, serves a specific persona, is part of a specific release with a specific outcome. Every downstream guide — acceptance tests, TDD, code review — inherits that context.
The story map is also the only guide that catches misalignment before the agent starts. Every other harness control catches misalignment after code is generated. Architecture checks fire at commit time. Mutation testing fires in CI. Code review fires at PR time. All of these are expensive — the agent already spent tokens, the team already spent attention — and they catch technical misalignment (wrong layer, missing test), not product misalignment (wrong feature, wrong user).
Shape fires before any of that. The cost of catching misalignment at shape is a conversation. The cost of catching it at code review is a rewrite. The cost of catching it at renewal is the contract.
Shape as Waste Elimination
There's a value stream lens on all of this that makes the economics clearer.
Every practice in the Prevention workflow eliminates a specific category of waste by shifting feedback left — catching problems earlier, when the cost of correction is low. TDD catches implementation defects before they reach integration. ATDD catches specification gaps before they reach code. Code review catches architectural drift before it reaches production. Continuous delivery catches deployment risk before it accumulates into a big-bang release.
Shape eliminates the most expensive waste of all: building the wrong thing. A feature that nobody needs costs exactly the same to build as a feature that everybody needs. The code is just as clean, the tests are just as green, the architecture is just as sound. The waste is invisible until the product hits users and nothing happens.
In value stream terms, shape is the earliest feedback loop. It fires before a single line of code exists. The feedback comes from the conversation itself — the team draws the map, walks the skeleton, and discovers misalignment while the cost of correction is a whiteboard eraser, not a sprint of rework.
Every other practice in the workflow shifts feedback left within the build process. Shape shifts feedback left of the build process entirely. That's why it eliminates a category of waste the downstream controls can't touch — you can't TDD your way out of building the wrong product.
How This Integrates With Prevention
In the Prevention platform, shape is a hard phase with its own gate. It sits between vision (why the product exists) and plan (how we build the next feature). Feature planning cannot proceed until shape is approved for new feature work.
The workflow:
Vision → Shape → Plan → ATDD → TDD → Review → Ship → Observe → Triage → Learn
/avesta-shape facilitates a three-round workshop — Who & Why (personas and JTBD), Journey & Backbone (the time-ordered phases), Stories & Slices (what ships and in what order). The output is a YAML source of truth plus a rendered HTML story map plus one markdown file per persona with narrative evidence. The YAML becomes the input to /avesta-plan — planners read the story map to understand which story they're planning, which backbone phase it belongs to, which persona it serves, and which release it's part of. Example Mapping happens downstream, on a story the map has already contextualized.
The gate is strict for features and lax for everything else. Feature changes require an approved story map before planning can begin. Bug fixes, tech debt work, and spikes bypass the gate because they operate below the map level — they fix or improve specific things that already exist in the journey rather than adding new journey steps.
The map is also continuously updated. Every /avesta-ship marks shipped stories as status: shipped and re-renders the HTML. Every release triggers an optional /avesta-shape review pass that invites the user to update the map based on learnings. Stories that turned out to be wrong get retired, not just unstarted. The map evolves with reality.
This is shape as a living artifact, not documentation. The Confluence page version of shape — "write it once, stick it on the wiki, never touch it again" — is worse than useless because it gives teams the feeling of shared understanding without the substance. The working version is a YAML file under version control, read by every feature plan, updated by every release, rendered into a picture that stakeholders can still see six months from now.
What Happens Without the Shape Discipline
Let's make this concrete. Two teams, same AI tools, same harness discipline, same eight-week runway to MVP.
Team A has a solid agent harness (TDD, Clean Architecture, mutation testing, DORA tracking) and skips shape. They sprint straight into Example Mapping from individual tickets. Week one, they're shipping features. Week four, they're still shipping features. Week six, the CTO asks the tech lead "are we on track for MVP?" and the tech lead says "we've shipped 23 features so far." The CTO asks "is that enough?" Nobody knows.
Week eight, they demo to a prospective customer. The customer walks through the product, stops at the "set up your first project" phase, and says "how do I do this?". Setup is the third backbone phase. Team A has two stories in Setup — both are edge cases for advanced users. The happy path isn't there. The MVP has a dead zone at phase three of seven. The customer thanks them and takes a pass.
Team B has the same harness and runs /avesta-shape in week one. Two hours of facilitated conversation produces a map with five personas, eleven backbone phases, and eighty-four MVP stories. Week one they start /avesta-plan on the highest-priority story in phase one. The walking-skeleton rule forces them to have at least one story in every phase before they optimize any phase. Week six, the same CTO asks "are we on track?" and the tech lead shows him the rendered story map with sixty shipped stories in MVP and twenty-four remaining. Every backbone phase has green checkmarks. The skeleton walks.
Week eight, they demo the same customer. The customer walks through the full journey, hits the same "set up your first project" phase, and finds a working (thin) happy path. They can't customize everything yet, but they can walk all the way to the outcome. Team B closes the pilot.
Team A shipped more features. Team B shipped the right features. The difference is shape.
The harness made Team A faster at the wrong thing. It made Team B faster at the right thing. Same tools, same discipline, different outcomes — entirely because of the upstream control.
Will Your AI Tool Do This for You?
Here's the uncomfortable question: will Claude Code, Cursor, or any AI coding agent identify that your value stream has a shape gap? Will it look at your backlog and say "you're building a fragment, not a walking skeleton"? Will it notice that your MVP has dead zones at phases three and four?
No. It will not.
AI coding tools accelerate execution of whatever you tell them to build. They don't tell you what to build. They don't map your value stream. They don't facilitate shared understanding between product and engineering. They don't detect that your team has five different pictures of the MVP. They don't flag that your buyer persona has no walking skeleton.
This is exactly why mastering these practices matters more in the age of AI, not less. The teams that get the most value from AI-assisted tooling aren't the ones with the best prompts or the most expensive models. They're the ones who bring discipline to the conversation before the agent starts writing code. Shape, value stream thinking, walking-skeleton design — these are human practices that no tool does by default.
AI makes mastery more valuable, not less. A team that knows how to shape gets ten times more value from an AI agent than a team that doesn't — because the agent builds the right thing at machine speed instead of the wrong thing at machine speed. The leverage isn't in the tool. It's in the practice the team brings to the tool.
The Bottom Line
The downstream controls — TDD, Clean Architecture, mutation testing, quality gates — ensure things are built right. Shape, sitting upstream, ensures the right thing is being built. Both are part of the same harness. Both are engineering disciplines.
Shape produces a feedforward guide (the story map) that constrains the agent's solution space before the agent starts. In value stream terms, it's the earliest feedback loop — the one that eliminates the most expensive waste (building the wrong thing) at the lowest cost (a conversation).
No AI tool does this by default. You have to bring the discipline. Teams that do ship walking skeletons. Teams that don't ship well-built fragments of the wrong product, faster.
Build the right thing. Then build it right. In that order.
