Most product specs are read by three people: the PM who wrote them, the designer they pinged, and the engineering lead they had a 1:1 with. Everyone else skims the title and scrolls to the screenshots — if there are any. The screenshots are out of date by Monday because the design moved.
The workflow below replaces the spec with a thing the team can actually use. The PM still writes the why. The designer still owns the visual system. The engineer still owns the production build. But the brief — the artefact people argue about — is a working URL, not a Notion page that will rot.
Why "the deck" is the wrong artefact
A deck or PRD is good for two things: persuading executives, and creating a record. It's bad at the third thing it gets used for, which is communicating intent across functions. Reasons:
- Static text underspecifies behaviour. The PRD says "the user can edit their profile". Twelve different engineers read that and build twelve different things. Eleven of them are wrong, but you find out in QA, six weeks late.
- Screenshots and Figma frames lie about state. They show one moment in the user journey. The PRD describes the journey in prose. Connecting the two is mental work the reader does, badly.
- Decks reward consensus, not clarity. Sentences that nobody objects to in review get shipped. Working products are the opposite — every detail forces a decision.
The fix is to make the brief itself be the working version. The thing engineers read is the thing the customer sees. The thing executives review is the thing sales can demo on Friday.
The five-step workflow
Step 1 — Write the spec as a one-paragraph user prompt
Not three pages. One paragraph. Who the user is, what they're trying to do, what makes this version different from the obvious one. If you can't write that paragraph, you don't understand the product yet, and the engineers won't either.
Example, from a real fintech we worked with:
"A payments dashboard for accountants whose clients are five-to-twenty-person businesses. The accountant sees all clients on one screen, sorted by 'overdue invoices'. Click a client to see this month's transactions, late payers in red, with a one-click 'send reminder email' button that drafts the language and waits for the accountant to approve and send. Stripe-style minimal UI, no charts, no fluff."
That paragraph is the spec. Everything below this line is what you do with it.
Step 2 — Generate a working prototype the same morning
Paste the paragraph into Marcus, or any AI builder you trust. Ask for the working version with seeded data, signup, and a hosted URL.
What you get back, twenty minutes later, is a clickable site at https://your-prototype.aimarcus.love/ with the dashboard, the client list, the click-through detail view, the reminder draft, and a working signup. The visual is generic but reasonable. The behaviour is real — you can click, the data updates, the reminder modal opens.
The prototype is not the final product. It's a 70%-correct first draft of the brief, in working form.
Step 3 — Review with stakeholders by giving them the URL
Don't book a "PRD review meeting". Send the URL to your designer, your engineering lead, your VP, and the head of customer success. Ask them to use the prototype for ten minutes, not read about it.
The feedback you get is qualitatively different from PRD review. Designers point at specific spacing decisions. Engineers ask about data model edge cases — "what happens when the client has no invoices?" — that the prototype either handles or visibly fails on. Sales asks "can I demo this on Tuesday to the prospect we just disqualified?" and the answer is yes, with the prospect's logo on it by Monday.
Each of those conversations is a real product decision, surfaced because the prototype was concrete. Twenty of them happen in two days, instead of two months of "we still need to align on what the dashboard does".
Step 4 — Iterate by talking, not by ticketing
When the engineering lead points at the data model, you reply to Marcus with "the client object should also have a `default_payment_method` field, and the late-payer list should sort by days-overdue descending, not invoice-id". Two minutes later, the prototype reflects that change. The engineering lead clicks the URL again.
This is the moment the workflow stops being "PM with PRD pingponging engineering" and starts being "team converging on the same artefact". Designers push the visual changes the same way; sales asks for the prospect-branded variant and gets it as a separate URL the same hour.
By the end of week one, you've run thirty changes against the prototype. Each one is a logged Marcus prompt, which becomes the changelog. The team argues about the artefact, not their interpretation of the PRD.
Step 5 — Hand off the prototype as the brief
When the prototype reflects the team's converged vision — usually two to three weeks in, depending on complexity — you hand it to engineering as the spec. They get:
- The working URL, with full behaviour.
- The Marcus-generated source code, exported and committed to Git, as the starting implementation.
- The full changelog of prompts, which double as design rationale.
- A list of the engineering-grade concerns Marcus didn't optimise for: latency targets, scaling, the integration with your real Stripe account, the migration to your single sign-on, the auth model that matches your enterprise IT policy.
That last list is the actual brief: the things Marcus got 70% right and engineering needs to take to 100%. Engineers read a small list of pointed concerns instead of a 12-page PRD that conflates "obvious to anyone" with "load-bearing detail".
What this changes about the PM job
The PM job stops being "describe what you'd build if you were a designer and engineer". It becomes "operate a feedback loop on a working artefact". The shift moves time away from spec-writing and toward customer interviews, prioritisation, and judgement calls about the trade-offs the prototype surfaces.
It also kills the political function of the PRD. You can no longer use length and detail to signal effort. The artefact is judged on whether stakeholders can use it, not on how thorough the underlying document was. Most PMs experience this as freeing once they get past the loss-of-control discomfort.
When this workflow doesn't fit
Three cases where you should still write a long-form PRD:
- Regulatory or compliance-heavy features. The audit trail is the artefact. The prototype is a supplement, not a replacement.
- Cross-team architecture decisions. When the question is "should this feature live in service A or service B", a clickable prototype doesn't help. A 6-page architecture doc with diagrams does.
- Deep ML or data products. The prototype can show the UI but not the model behaviour. Model evaluation is its own document.
For everything else — most product features in most B2B and B2C SaaS — the working URL is a strictly better brief than the PRD it replaces.
The metric that changes
The PM team metric to track is not "PRDs shipped" or "specs reviewed". It's time from idea to first working version stakeholders can react to. In a deck-based workflow, that's typically two to four weeks. In the workflow above, with an AI builder, it's typically one to two days.
Compounded across a quarter, that means you run six to ten times more product experiments, and your decisions are based on six to ten times more data. The team that does this for two quarters has a measurable lead on the team that's still on Notion PRDs, even if the engineering quality of the final shipped product is identical.