The Prompt Has Quietly Replaced the Product Spec

The product team that used to spend two weeks producing a forty page product requirement document, complete with stakeholder review cycles, a sign-off matrix, and an appendix of competitive screenshots that nobody read, now spends two days writing a twelve hundred word prompt that a model uses to generate a first pass of the feature in question. The product manager edits the prompt, runs the generation again, edits the prompt again, and ships a feature inside the same week the previous workflow would still have been negotiating the wireframe deck. The format has won the argument in most of the regional product organisations we have seen, and the winning is fast enough that the consulting class that was selling the old format has not yet quite acknowledged it.

Why the prompt is now a better document than the spec ever was

Because the spec, in its honest hours, was always trying to do two contradictory things at once. It was trying to be precise enough that the engineering team could implement against it without making decisions the product team had not signed off on, and it was trying to be flexible enough that the inevitable mid-build discoveries did not require a full requirements revisit. The two goals are in tension. The spec resolved the tension by being long, ambiguous in the places that mattered, and read in full by nobody other than its author.

The prompt does not pretend to be precise. It articulates the intent of the feature, the user the feature is for, the constraints that matter, and the categories of decision the model is empowered to make on its own. The engineering team reads the prompt and reads the model's first output and forms a working impression of the feature in an afternoon that the spec, in its older form, would have required a quarter to communicate. The format itself reflects the trade-off the product work has actually been making all along, and the explicit acknowledgement of the trade-off is, in itself, the part that makes the prompt the more honest document.

What the prompt format reveals about the previous era

It reveals that a large portion of the spec ritual was, in functional terms, a defensive posture against blame. The spec existed so that, when a feature shipped poorly, the product team could point to the document and demonstrate that the failure was a deviation from the documented requirements rather than an inadequacy in the requirements themselves. The defensive function was understood by everyone in the organisation and was never written into the spec's stated purpose, but it shaped the format more than the stated purpose did. The prompt does not have the same defensive function, because the prompt is, by its nature, a living document that the team iterates against in real time, and the iteration history is the record rather than any single version of the prompt.

The defensive function has migrated. It now lives in the evaluation harness that the team runs against the model's output before each release, and in the structured commentary the team appends to the prompt when an edit changes the output in ways that matter. The new defensive function is more honest than the old one because it is tied to observed outputs rather than to documented intentions, and the difference shows up in the quality of the post-launch conversations the team has when something does not work as expected.

What the consulting class needs to update

The consulting class that was selling the spec format as a competence is going to need to update its offering, because the spec format is no longer the competence the product organisations are willing to pay for. The new competence is the ability to write the prompt well, instrument the evaluation harness usefully, and run the iteration cycle on a cadence that the older format could not have sustained. The consulting firms that figure out how to teach this competence will, in the prevailing reading, capture the next several years of product-tooling consulting spend. The firms that keep selling the spec format will, on the present trajectory, find themselves selling a competence that the better product organisations have already retired.

The shift is, in our view, mostly a good shift. The product work is happening faster, the documentation overhead is lower, and the conversations between the product, design, and engineering disciplines have become more direct. The losers, in the small ways the shift has produced losers, are the consulting firms whose business model depended on the older format and the senior product managers whose careers were built around producing the older artefact. The new product manager is, by every observable metric, doing the more interesting version of the job.