Most AI builds fail in the planning, not the code. A product requirements document is how you decide what to build and why before a model writes a line of it. Plan first, specify the system, and the build phase becomes execution rather than guesswork. That sequence is the single biggest predictor of whether the result is worth the spend.
We have learned this the hard way and the cheap way. The cheap way is to write things down first.
What a Product Requirements Document Is
A product requirements document, or PRD, is a written specification of what a product should do, who it is for, and how you will know it works, agreed before any building starts. It records the problem, the users, the features in scope, the features explicitly out of scope, and the measures of success. It is the contract between the idea and the build.
People ask what is a product requirements document because the term sounds heavier than it is. A PRD is not a hundred-page tome. For a small project it is a few pages that any non-technical owner can read and recognise as their own business. It sits alongside its more technical cousin, the software requirements specification, which describes the system's behaviour in detail: inputs, outputs, data, and the rules that connect them. The PRD answers what and why. The specification answers how the software must behave to satisfy it.
The reason this matters more with AI than it did before is a change in where the work happens. A large language model can produce working code in seconds. That speed is real, and it moves the bottleneck. The constraint is no longer typing the code. The constraint is knowing precisely what the code should do.
Why Planning Matters More with AI, Not Less
There is a tempting story that AI removes the need for planning. The code is fast, so why not just build and see. The evidence does not support the story.
In a randomised controlled trial run by METR, 16 experienced open-source developers completed 246 real tasks on their own mature repositories, mostly using Cursor Pro with Claude. Allowing AI tools made them 19% slower. The detail that should stop every founder is the perception gap. The same developers forecast a 24% speedup beforehand, and even after finishing, still believed AI had sped them up by about 20%. The tool feels fast while it is making you slower. That gap is corroborated in the peer-archived preprint by Becker, Rush, Barnes and Rein.
The lesson is not that AI is useless. We use these tools every day. The lesson is that undirected AI use does not reliably deliver the productivity people assume, and that you cannot judge a build by how fast it feels while you are inside it. Speed of typing was never the bottleneck on a project that mattered. Knowing what to type was. A model is fast at producing code and unreliable at deciding what the code should be. Planning is how you supply the decision the model cannot make for itself. You plan and specify first, then use the build phase to direct the model, not to let it think for you.
This is the core of any AI implementation plan, and it is what makes the difference between an AI build that pays back and one that quietly does not, a question we take up in measuring AI ROI: the model is a builder you brief, not an architect you trust to design the system. The brief is the PRD.
What a Small-Project PRD Contains
People search for a product requirements document template hoping for a download that does the thinking for them. The template is the easy part. The thinking is the point. A useful small-project PRD covers six things, and you can write it in a shared document in an afternoon.
The problem. One paragraph on the real problem, stated in the language of the business, not the solution. "Enquiries take two days to answer and we lose a third of them" is a problem. "Build a chatbot" is a solution wearing a problem's clothes.
The users and the job. Who uses this, and what are they trying to get done. A feature with no named user is a feature nobody asked for.
Scope, in and out. The list of what is being built, and the equally important list of what is not. Naming what is out is how you stop a small project quietly becoming a large one.
Success measures. What changes, in numbers. "Cut response time from two days to two hours." A measure you cannot check is a wish.
Constraints. Budget, deadline, the systems it must connect to, the data it can and cannot touch. For an AI build this is also where privacy and access rules belong, a subject we treat on its own in AI security, privacy and trust.
The AI-specific section. Where the model fits, what it is allowed to decide, and where a person stays in the loop. This last part is not optional, and we explain why in our piece on keeping a human in the loop.
That is the whole document. How to write a PRD is mostly the discipline of answering those six questions honestly before the work that depends on them begins.
Specify the System Before the Model Builds It
Once the PRD says what to build, the next step is deciding how it fits together. This is where AI planning earns its keep, because the build phase should be the model building what you specified, not the model designing the system on the fly.
Thoughtworks named this practice directly in late 2025. In a piece on spec-driven development, technology director Liu Shangqi argues that vibe coding is "too fast, spontaneous and haphazard," and that it produces "too much unmaintainable, defective, one-off code." The remedy is to write a clear specification first, separating planning from implementation. His finding is the one worth pinning to the wall: clear specifications, he writes, "can still help reduce model hallucinations" and produce code that holds up over time. A model with a precise spec has less room to invent. A model without one fills the gaps with plausible guesses, and plausible is not the same as correct.
For software project planning this changes the order of operations. You decide the data model, the integrations, the API boundaries, and where any retrieval-augmented component gets its facts, before the model starts assembling parts. If the build involves agentic AI or tool use through the Model Context Protocol, you decide what those agents are permitted to do up front, on paper, where a permission is a sentence rather than an incident. The architecture is a planning decision. Handing it to the model to improvise is how you get a system nobody can maintain.
Planning Is the Cheapest Place to Be Wrong
The case for planning is, at bottom, a case about cost. A wrong assumption is cheap to fix while it is still a sentence in a document and expensive to fix once it is built into a system.
This is long-established engineering lore, often called the 1:10:100 rule: a defect caught in design is far cheaper to fix than one caught in implementation, which is far cheaper than one found after release. The best-known multipliers, summarised by Functionize, trace to internal IBM materials from the 1980s and should be read as directional rather than precise, since later work has found the escalation real but context-dependent. The direction is what matters: the wrong decision gets more expensive the longer it survives, and planning is simply the phase where it is cheapest to find.
Scope is the other half of the cost story. The Standish Group's CHAOS research, the long-running benchmark for IT project outcomes, has consistently found small projects succeed around 90% of the time while large projects succeed less than 10% of the time. Its original 1994 large-organisation data, only 9% succeeding outright with 61.5% challenged and 29.5% cancelled, set a pattern that later reports kept confirming. Keeping a small project genuinely small is one of the strongest predictors of success, and a PRD that names what is out of scope is the tool that does it. AI sharpens this risk rather than removing it. When code is cheap to generate, scope expands quietly, one easy feature at a time, until the system is larger than anyone planned and harder than anyone wanted to maintain. The document is not bureaucracy. It is risk control with a word count.
How to Plan an AI Build Without Slowing It Down
The fear is that planning makes a fast thing slow. Done well, it does the opposite, because the slow part of any build is rework, and rework is what planning removes.
For a small business, the planning phase for an AI build runs days, not months. It starts the way every good engagement starts, with discovery: understanding the business and the real problem before proposing a solution, which we cover in the value of discovery and audit. From there you write the PRD, sketch the system, and pick the smallest version that proves the idea. Building the smallest useful thing first is its own discipline, and we treat it fully in taking an MVP from zero to one.
Planning also decides the build-versus-buy question before money is committed. Some problems are solved by configuring software that already exists; some need a custom solution. A short planning phase is where you make that call deliberately rather than discovering, three weeks in, that you have rebuilt something you could have bought, a trade-off we examine in build versus buy. The shape of the developer's job has shifted toward exactly this kind of specifying and directing, a shift we cover in the changing role of the developer.
None of this is heavy. It is a written problem, a scope with edges, success in numbers, and a system sketched before the model builds it. Set against a build that runs for weeks and a budget that cannot absorb a rebuild, a few days of planning is the cheapest insurance available.
The Enki Approach
We do not start AI builds in the code editor. We start in a document, with the problem, the scope, the success measures, and the system sketched out, because the build phase goes far better when the model is executing a decision rather than making one.
In our work building for small businesses, we treat the PRD and the architecture spec as the deliverables that protect everything downstream. We agree what is in and what is out, we write success as a number, and we decide where the AI fits and where a person stays in control before anyone runs a build. The model is fast, and we use that speed deliberately, pointed at a target we defined first. That is how planning an AI build pays for itself: not in the planning, but in the rebuild you never have to do.