The Spec Before the Spec: How We Define the Process Before We Write a Single Requirement
Before a single requirement gets written, there is a document that most teams skip entirely. We call it the specification of the specification: a short, concrete agreement that defines how the technical specification itself will be prepared. On a recent e-commerce project, this document was approved on day one. Everything that followed ran against it.
It sounds like bureaucracy. It is the opposite.
Why the Process Needs Its Own Document
Preparing a full technical specification for a large online store takes weeks. Without a shared understanding of what that process looks like, it drifts. The audit becomes exhaustive instead of purposeful. Questions pile up in chat threads. The client answers the same thing twice, in different directions, through different people. At the end, a large document arrives that no one knows how to review.
The process specification cuts that drift before it starts. It answers five questions before work begins: what the client will receive at the end, what is explicitly not included in this stage, who makes decisions on each side, how approval works, and what conditions must be met before the pre-project phase closes.
These are not abstract governance questions. They are the difference between a project that moves and one that stalls.
An equally important reader of this document is the AI agent assisting with research and drafting. The agent reads the process specification first and understands the frame: what to investigate now, what to defer, which decisions are already settled and do not need to be raised again with the client. A well-structured process document is, in that sense, the first context file in the project.
We also define the outcomes the site should support: sales and demand handling, convenient product discovery and ordering, search indexing, clear public content for AI systems, and content that can be maintained without constant manual developer work. These goals are distinct from acceptance criteria. Sales growth, Google rankings, and recommendations from a particular AI system cannot be guaranteed; acceptance is based on measurable technical requirements.
Fifteen Deliverables, One Clear Boundary
The process specification for the recent e-commerce project listed 15 deliverables from the pre-project stage.
These included the main technical specification, a current-state audit, a full catalog tree, a characteristics and filters matrix, a content model, a user scenario map, a data migration and URL preservation plan, an HTML design system, SEO and AI visibility requirements, architectural boundaries, a phased plan, an estimate, and a risk and decision register.
That list matters not because it is comprehensive, but because it is bounded. The process specification states explicitly what is not part of this stage: site development, full catalog import, real integration connections, domain transfers, and task preparation for developers. Knowing the boundary is as useful as knowing the contents.
The same logic applies to the audit itself. The audit does not need to be exhaustive. It needs to be deep enough to surface decisions and risks that could change the project scope, architecture, sequence of work, or estimate. Details that do not affect any of those four things can wait until development. That single rule saves clients weeks.
The required structure of the final technical specification is also defined upfront: 30 sections, from the document header and project goals through to testing, launch, operations, and estimation. Because the structure is known in advance, it is always clear which sections are complete and which are still open. Progress is visible at every point.
One Decision-Maker Per Side
One of the most practical rules in the process specification is also the simplest: one person per side makes decisions.
On the client side, that person collects input internally, from accounting, product managers, category specialists, and whoever else holds relevant knowledge, and returns a single consolidated answer. On our side, one document owner manages the structure, open questions, versions, and decision log.
This mirrors the Product Owner principle in Scrum: a single accountable person, not a committee. If someone else inside the client organization sends a conflicting answer through a separate channel, that answer is not treated as a decision until the designated representative confirms it. A verbal agreement or a message in a chat thread gets transferred into the document only if it affects scope, estimate, or acceptance criteria.
This is not formality for its own sake. It is the mechanism that keeps the specification from forking into multiple competing versions.
Blocks, Not a Single Delivery
The technical specification is built in blocks, not delivered as one large document at the end of the process.
Each block follows the same cycle: gather materials, verify facts, separate confirmed data from open hypotheses, prepare a recommended solution with meaningful alternatives, write the block and any related appendices, send the client a focused set of materials and specific questions, incorporate agreed changes, record the decision, and move to the next block.
Once a block is approved, it becomes the baseline. If a decision changes later, the reasons are recorded along with the effect on related sections, timeline, and cost. Nothing is quietly revised.
Clients are not sent a 100-question intake form. The only questions that go to the client are things only they can answer, and decisions that would meaningfully change the architecture, scope, or estimate. Contacts, content, standard workflows, and technical options are researched first internally. The client receives a prepared draft and either confirms it or makes targeted corrections. The load on their side stays proportionate and predictable.
When the Work Is Done
The process specification ends with a readiness checklist. The pre-project stage does not close until every condition is met: the client has approved the final technical specification, the mandatory scope is separated from later phases and optional features, all user scenarios are described, the catalog tree and content model are defined, the design is demonstrated in HTML rather than described in words, quality requirements are measurable, the estimate is tied to specific features, phases, and risks, and no open question remains that could materially change the mandatory estimate.
Certain decisions are recorded as already made before work begins: page language and URL structure, release sequencing, the principle of one canonical address per product, design direction, performance targets, and permission for AI crawlers to access public content. These are not reopened unless research uncovers a serious contradiction.
That readiness checklist is the exit condition. Once every condition is met, the pre-project stage closes. The next step is a separate breakdown of development work based on the approved specification.
The result for the client is straightforward. From day one, they know what they will receive, how many questions will be asked of them, and what done actually looks like. No document arrives out of nowhere after weeks of silence. No decision gets relitigated because it was never properly recorded the first time.
The specification of the specification is not overhead. It is the first real work of the project.