Spec over Sprint

The belief

When iteration is cheap, preparation is the lever. Generative tools produce full layouts in seconds - wrong fonts, wrong colors, approximate everything. The tool averaged across a population; the spec had already converged. Invest upstream in what you want, not downstream in how fast you ship it.

How to apply

1. Default to spec-first when AI is in the loop. Before opening any generative tool, write down what you want: the exact typography scale, the color tokens, the interaction model, the core jobs-to-be-done. The AI amplifies whatever you give it. Give it precision, get precision back. Give it a vague brief, get a plausible-but-wrong draft back.

1. Audit the spec before blaming the tool. When a generative output disappoints - wrong voice, wrong layout, missing constraints - the first question is not "how do I re-prompt?" It is "what was missing from the spec?" Most tool failures are spec gaps wearing a prompt mask.

1. Treat quick-and-dirty as a cost, not a virtue. The case for "ship fast and iterate" was built on the assumption that iteration was scarce. When a design round took two weeks and a coding cycle took four, fast prototypes delivered irreplaceable signal. That economics has changed. When a tool can produce a full layout in 30 seconds, a fast prototype produces noise. The correct virtue is: ship the well-spec'd prototype.

1. Hold the scope line in the PRD before the sprint begins. Scope creep is a spec failure that shows up late. "Should we do it?" is the PM's job. "Can we do it?" is the bonus question at the end. Every hour of sprint debate that could have been settled in the PRD is a tax on spec quality. The 99 "should we" questions are spec-work.

1. Use iteration for refinement, not discovery. Fast iteration is real leverage when the question is "how polished is this?" not "what are we building?" Generative tools excel at refinement. They are poor instruments for discovering what you want in the first place. Discovery lives in the spec.

What this is not

• Not "never ship until the spec is perfect." The spec governs what you build, not whether you build. The second-brain v1 shipped as plain markdown: "Plain markdown. Git. Open source. MIT. Free forever." That is Spec > Sprint in action: a tight scope, shipped fully, without iteration-as-discovery.
• Not "agile is dead." Sprints still matter for sequencing, unblocking, and team cadence. The belief targets the sub-axiom that equates sprint velocity with product quality. Speed inside a well-spec'd system is a virtue. Speed as a substitute for a spec is not.
• Not a solo PM principle only. The claim applies anywhere AI is generating work output: design, code, copy, data pipelines. If you are directing a model, your spec quality is the binding constraint on output quality. The domain is irrelevant.

Argues against

• "Move fast and iterate - the market will tell you what to build."
• "Good prompting can compensate for a weak brief - just keep refining."
• "Spec-first slows teams down; velocity is the real competitive advantage."

Where to go from here

If you want the parent theme that this belief belongs to, go to spec-first-taste. The theme holds the full argument for why preparation outranks execution speed across the spec-first trilogy.

If you want the trilogy partner that makes the same claim at the craft layer, go to taste over execution. If you want it at the tooling layer, go to context over prompt. The three beliefs share one structural claim: the load-bearing work has migrated from doing to deciding.

If you want the anti-pattern this belief directly argues against - the instinct to customize rather than scope tightly - go to anti-customization.