The Spec Follows the Prototype: How AI Changes Product Specification

How AI Is Changing Product Specification

I was two months into building a travel planning tool when I noticed I had stopped writing specs first.

The tool is called newjourn: it generates routes for long, independent trips — sabbaticals, five-week journeys, the kind you can’t book as a package. You answer a handful of questions, it proposes stops, transfers and a reason for each of them.

For the planned MVP we added a second door: Curated Trips.

Ready-made routes we generate and curate ourselves — a five-week loop through northern Spain, a slow circuit of southern Africa. They exist to inspire: you land on one that almost fits and either take it as it is or make it your own. And they give the product something the generator can’t produce on its own — content worth reading and worth finding.

The generator is the product. Curated trips are the shop window.

The moment came on a Tuesday evening. The curated-trips flow worked, the admin pages worked, and there was a collections page — group trips, reorder the groups, rename them, publish them — that I had never specified anywhere. My spec was four pages: goals, users, out of scope, the stories that mattered.

No backlog.

That page existed because I described what I wanted, looked at it, disliked half of it, and said so.

It felt like being six years old with a box of Lego. You want a castle, so you start building. The wall gets too tall and collapses, so you make it shorter. It looks ugly, so it goes away entirely.

You don’t sketch the castle first.

You just start building.

And problems I had filed under “hard to solve, come back later” dissolved into something obvious the second they were visible on screen.

Without noticing, I had moved the place where product decisions get made. Not the document. The running thing.

I’m not arguing that every organisation should stop writing specs tomorrow. I’m describing what happened to mine.

Without AI, I’d have been standing in front of a mountain

In the old setup, this project would have started as a wall of unknowns. Multi-country routing, curated content and a generated itinerary in the same product, a data model I’d have had to commit to before I could test a single assumption. So I’d have written more documentation to feel safer — which is what you do when guessing is the only tool available.

And before any of it moved, I’d have gone looking for capacity: someone to design the screens, someone to wire a clickable dummy. None of that happened here. My colleague and I built it ourselves — with AI doing the execution and product judgement staying with us.

Building it instead didn’t make the project smaller. It made it visible. Every hypothesis got an answer within minutes, and wrong answers cost me a prompt instead of a sprint.

The complexity didn’t disappear. It just became manageable.

TL;DR

The order of product work has flipped. I still write a specification — it’s just no longer the thing I hand over before building. It’s the thing that comes out the other end, once the decisions have actually been made in something clickable.

What actually changed isn’t the writing. It’s the distance between having an idea and knowing whether it was a good one.

• Light context up front. Goals, users, out of scope, plus the two or three key user stories. Three to four pages, not twenty.
• The prototype in the middle. Decisions get made in the running thing, not in a document.
• The detailed spec as output. Written in parallel, as choices settle — the reference a developer can build against.
• Judgement as the bottleneck. AI removes the execution cost, not the responsibility for knowing what’s worth building.

The old order: specify, then build

For most of my career the sequence was fixed. Someone had an intent, and my job was to turn it into something a team could implement: a PRD, a set of user stories, acceptance criteria, edge cases written out in prose because prose was the only prototype available. Waterfall called it the plan. Scrum sliced it into tickets. The direction never changed (see also The Art of Pretotyping).

Specify first, build after.

That translation layer was never the cheap part. Most of my week went into it. So did most of my mistakes — I was describing a product nobody had seen. A panel with three tabs reads perfectly reasonable on page four. Whether it works you find out on a screen, and by then ten people have signed off on it.

So we compensated. Refinements, design reviews, clickable dummies, story mapping — rituals to lower the risk of having guessed wrong on paper. They worked, more or less. They were just slow, and they taught everyone to treat a sentence as a decision instead of a bet.

The document was never the point. It was the cheapest way to make an idea reviewable.

That’s the assumption that broke.

What I actually did instead

My process now has three layers, and only the first one looks like the old world.

Layer one is context. Three to four pages: what this is for, who it’s for, what it is explicitly not, plus the few user stories that carry the intent. I wrote it with ChatGPT, which already knows the product — even the lightweight part isn’t handwork anymore.

It exists so neither I nor the AI drifts. It is not a plan.

Layer two is the prototype. I describe a screen, it appears, and most of the time I don’t like it — the card says too much, the button promises something we can’t deliver. Each of those is a decision I would once have argued about on paper.

Now I just look at both.

There’s a second effect I didn’t expect:

Sitting in front of a clickable thing puts me in the user’s seat by default.

I stop thinking in features and start thinking in flows: where did I come from, what do I want next, why is this button here. A document lets me stay in my own head.

Which means a good part of solution discovery has moved here too. Not the part about who the users are and what they struggle with — that still happens outside the screen. But “does this shape work” is no longer a workshop question. It’s a five-minute one.

A document describes the product. A prototype makes you use it.

I started in UX Pilot — the right tool on a green field — and moved to Lovable once the context got big: re-specifying our own UX patterns for an external tool cost more than building the screen where they already existed. Database, auth and model access come included, so there’s no setup detour between an idea and a running thing.

Layer three is the spec — and I don’t write it. The AI writes it in parallel as the choices settle, and I read it against what we built: which screens exist, which states they have, what happens on mobile. My job is to catch the sentence that sounds plausible and isn’t.

I don’t write specifications anymore. I review them.

Two assumptions that lasted an afternoon

Curated trips are grouped into collections — “Family Trips”, “First-Time Asia”, that kind of thing. In the spec, a trip pointed at its collection by name. One line, obvious, nobody would have questioned it in review.

Then I renamed a collection in the admin view and every trip in it fell out. Names are not identities. Two prompts later the collections had stable IDs and the names were just labels again.

The second one was the home page. The spec said: show three curated trips, side by side, as a taste of what a journey looks like. On screen those three cards looked like the entire offer — finished, closed, nothing to reach for. Nobody would go looking for the rest. Now the trips sit in a row you can push sideways, and the last card is an invitation to see them all.

Both would have survived a review. Neither survived being visible.

So I stopped treating the prototype as a demo and started treating it as a question. Once a screen has answered it, it has done its job — and I keep it or delete it.

What this does not solve

Building fast moves the bottleneck, it doesn’t remove it. Everything the prototype cannot answer is still mine: what we are actually for, who we are not for, and the “out of scope” section that keeps a good idea from eating the release.

The model will build whatever I ask for. It will not tell me whether it should exist.

It also writes very convincing wrong sentences. A spec paragraph describing behaviour we never built reads exactly like one that’s true. Catching that is the job now, and it needs someone who was there when the decision was made.

And sparring with an AI is not sparring. It’s fast, it’s patient, it never gets bored — but it agrees too easily. The sharpest questions on this project came from showing the prototype to a colleague for ten minutes.

Two other things hurt.

The document drifts: the prototype changes on Wednesday, the spec still describes Tuesday, and only a habit of re-reading catches it. And a working screen looks finished when it isn’t — no empty states, no error paths, no load under real data.

Fast to build is not close to done.

Lessons learned

• Context, not coverage. Write enough up front that nobody drifts — goals, users, out of scope, a few key stories. Everything else is guessing in prose.
• Build the question, not the demo. A screen exists to answer one open question. Once it has, keep it or delete it without ceremony.
• Let the AI write the spec. It documents faster and more completely than you do. Your job is reading it against what actually got built.
• Distrust the plausible sentence. The dangerous output isn’t the obvious error, it’s the paragraph that sounds exactly right and describes nothing you shipped.
• Keep a human in the loop. The model agrees too easily. Ten minutes with a colleague in front of the prototype beats an hour of chat.

Your turn

I’m curious where this breaks for other people. If you’ve tried building before specifying: what did it cost you? Did the missing document show up later as rework, in handover, in an audit — or not at all?

And the honest open question: does this scale past a two-person project? I don’t know yet.

What I do know is that we stopped drawing castles. We started building them.

Book recommendation

Click, buy, and enrich me – my literature recommendation on the subject and an enlightening read on Prototyping with AI: Creative Prototyping with Generative AI

Hero image: by Phil Hearing on Unsplash