A product leader can now put a working prototype in front of users in days. The long PRD should shrink to a decision memo plus a prototype, with clear rules on what the prototype proves and what it does not.
Most product requirement documents are written to be approved, not to be used. They describe a future product in prose, get reviewed by people who skim them, and then lose an argument with reality in the first week of engineering. For most of my career that was an acceptable cost, because the alternative, building something to find out, was more expensive than writing about it. That is no longer true. With AI coding agents, a product leader who can read code can put a working prototype in front of real users in three to five days, and the forty-page PRD should shrink to two artifacts: a short decision memo and a prototype.
I build prototypes myself, usually in Next.js and TypeScript with Postgres behind them, deployed to a preview URL I can send to a user the same afternoon. I have also worked where a wrong assumption costs real money, including conversational AI for collections and payments in an ISO 27001 environment. Both experiences point the same way. A clickable, data-backed prototype exposes wrong assumptions faster than any document, in front of the people whose opinion matters. It only works, though, if everyone is clear about what the prototype is allowed to prove.
The decision memo is one or two pages. It states the problem, who has it, what we believe will change if we solve it, the decision we are asking for, and the constraints that are not up for debate (compliance, budget, integrations, deadlines). It also names the questions the prototype will answer and the ones it will not. The memo is where judgment lives. It is short because it should only contain things a prototype cannot show: why this matters now, what we will stop doing to make room for it, and how we will know we were wrong.
The prototype carries everything that prose describes badly: flow, sequence, density, tone, the moment where a user hesitates. A sentence like "the user reviews suggested matches and confirms them" hides a dozen decisions. A prototype forces every one of them, and then a user shows you which ones you got wrong. Engineers also read a prototype more honestly than a document. They see the states, the edge cases you forgot, and the data you assumed would exist.
A prototype is evidence about desirability and usability. It can show that users understand the concept without a walkthrough, that the core flow fits how they already work, that the output is useful enough that they ask when they can have it, and that the language and information density suit this audience. Those are exactly the questions a PRD answers worst, because a document can make any flow sound reasonable.
A prototype says almost nothing about feasibility at scale, cost to operate, security, reliability, or behavior with messy production data. It runs on a handful of clean records, one cooperative user, and no adversaries. If an AI feature in the prototype produces a great answer on twenty curated examples, that tells you the idea deserves a proper test, not that the model is ready. I write this boundary into the memo explicitly, under a heading like "What this prototype does not show", because stakeholders who see something working will assume the hard part is done. It usually is not. The hard part has merely become visible.
The scoping rule I use is one question, one user type, one path. Pick the riskiest assumption in the memo, the one that would kill the initiative if it were false, and build only what is needed to test it with the user type who matters most. Everything else is hard-coded, faked, or left out.
Take a B2B invoicing tool that wants to add automatic matching of incoming bank payments to open invoices. The riskiest assumption is not whether matching is technically possible (it is), but whether finance teams will trust suggested matches enough to confirm them in bulk instead of checking each one. A five-day plan might look like this:
Notice what is missing: no bank integration, no real authentication model, no permissions, no settings page. If a stakeholder asks for those, the answer is that they do not change the answer to the one question. That discipline is harder than the build. AI agents make it very easy to add one more screen, and every extra screen dilutes the test and makes the prototype look more finished than it is.
The biggest risk of a fast prototype is not that it fails. It is that it succeeds, and somebody decides it is ninety percent of the way to production. Code written in five days by a product leader with an agent, against synthetic data, with no threat model, is not ninety percent of anything. It is a very good specification that happens to run.
I handle the handover with a few rules. The prototype lives in a separate repository, clearly named as a prototype, and never shares a deployment pipeline, database or credentials with production. It is handed over together with the memo, the session notes and a short list of the decisions it encodes ("bulk confirm requires at least one manual review", "uncertain matches are never preselected"). Engineering is explicitly free to throw away every line, and I say so in the handover meeting, because engineers will otherwise feel obliged to preserve something a senior person built. What they must preserve are the decisions, not the code.
The questions I then ask the engineering lead are simple. Which of these decisions are expensive in our real architecture? What did the prototype fake that will turn out to be the actual project? What would you build differently if you had started from the memo alone? The answers often reshape the estimate more than the prototype did, and that is fine. The prototype has done its job if the conversation is about real constraints instead of competing interpretations of a paragraph.
False confidence is the first. Five users liking a prototype is a signal, not validation. They were polite, they saw clean data, and they did not pay for anything. Treat a positive result as permission to invest in the next, more expensive test, not as proof of demand.
Demo-ware is the second. A prototype shown in executive reviews more often than to users has become a sales prop. You can tell because it starts gaining features that only matter in a demo: animated charts, a polished onboarding, a dashboard nobody asked for. At that point the prototype is testing whether executives like it, which was never the question.
Security shortcuts are the third, and the one I take most seriously after years in audited environments. Prototypes get built with real customer data "just for the test", API keys pasted into chat, and preview URLs that are public by default. None of that becomes acceptable because something is temporary. Use synthetic or properly anonymized data, put the preview behind authentication, keep secrets out of the repository, and delete the environment when the test ends. If your organization holds a certification like ISO 27001, the prototype is still in scope of your information security controls, whatever the team calls it.
There are areas where prototype-first is the wrong default, and pretending otherwise is how teams get into trouble.
Regulated flows are the clearest case. Credit decisions, collections communications, payment authorization, identity verification and anything that touches consent need precise written rules, because the rules are the product. A prototype can show how a disclosure looks. It cannot be the record of what the disclosure must say, when, and to whom. That belongs in a document that compliance and legal sign.
Integrations are the second. When a feature depends on a partner API, a bank file format or a card network message, the contract between systems has to be written down field by field. A prototype that mocks the integration hides exactly the details that will cost you a month later. Write the interface spec first, and prototype the user experience around it.
Contracts, in the commercial sense, are the third. If a feature is promised to a customer in a statement of work or an enterprise agreement, the written description is a legal commitment. A prototype helps that negotiation as a shared picture, but the commitment must be text that both sides can point to.
Finally, the approach assumes the person building the prototype understands the domain and can read what the agent writes. A prototype built by someone who cannot judge its output just produces confident-looking mistakes faster.
Take the next initiative that is about to get a long PRD. Write the one-page memo instead, name the riskiest assumption, and give yourself five days to put one working path in front of five real users. Then hand engineering the memo, the notes and the list of decisions, and tell them the code is theirs to delete. If the conversation that follows is sharper than the one your last PRD produced, you know which document your team actually needs.
Written by
Ratomir Jovanovic
In collections and payments, the conversation design is the compliance work. How to set guardrails on promises, detect vulnerability, keep audit trails and measure outcomes that matter more than containment.
27 August 2026
Approval rates, retries, failure messages, fees and reconciliation shape revenue and customer trust directly. That makes payments a product area with an owner, metrics and a roadmap.
12 August 2026
Most LLM features that disappoint in production were judged badly, not built badly. A practical evaluation process for product leaders: job definition, golden sets, failure taxonomy, budgets and a ship/no-ship rule.
8 July 2026