Watch a software team open an AI tool for the first time. They describe a feature and ask it to design the screen. What comes back is fluent, confident, and wrong. It looks like a product. It is not the product. The team walks away quietly, deciding AI is not ready for serious product work.
I have seen this at companies I have advised and inside companies where I ran product, engineering, and marketing teams. Thirty years in technology, most of it spent shipping product. And every time, the same mistake. The screen was never the hard part. The hard part is everything you feed the model before you ask it for anything.
This is a guide to that part. Not the prompt. The inputs.
Why this wave is different
I have lived through a few technology waves. This one is different, and the reason is worth slowing down on.
Every wave before this amplified something other than thought. The Industrial Revolution replaced muscle. The mainframe, the PC, the internet, and the cloud moved and stored information. AI goes straight at the one thing that made us who we are. We are not the strongest animal, or the biggest, or the fastest. We reached the top on intelligence alone. AI is the first technology that amplifies exactly that. That is why it matters, and why the lazy use of it is such a waste.
So treat it as the ultimate sparring partner for your judgment, not a replacement for it. The question is not whether the tool is good enough. The question is whether you step into the ring.
The trap: asking AI for the output
Back to that team asking for a screen.
The output is generic because the input was generic. The model knew nothing about the customer, the workflow, the strategy, or the thing the product is quietly bad at today. You asked a brilliant, well-read stranger to design your product in a sentence, and it did exactly that.
An AI output is a mirror of the context you give it. Thin context, thin output. This is the whole game, and almost everyone is playing the wrong half of it. They polish the prompt when they should be building the inputs.
The reframe: the inputs are the asset
None of this is new. A prototype has always been a way to gauge a reaction and ideate off it. You put something in front of a potential customer, you watch what they do, you learn. AI does not change that purpose. It changes how fast you reach it.
What also has not changed is that requirements still matter, whatever people say today. A product is only ever as good as the brief. Before AI, I would ask my software teams if they understood what product management was asking them to build. Blank stares told me everything. If a team cannot explain the brief back to you, the product is already in trouble.
So treat the prototype as a customer-development instrument, not a deliverable. Its job is not to be shipped. Its job is to be reacted to. Once you see it that way, the work moves upstream, to the context you assemble before you ever open the tool.
My years running product at Amazon Web Services taught me more about that than anywhere else I have worked. The PRFAQ was where it clicked. It was the ultimate prototype, written in prose. We argued the customer, the problem, and the promise on paper over many rounds of editing, long before anyone built an MVP. The document was the thing we put in front of people and reacted to. Same loop as a clickable prototype. No code.
That habit of obsessing over the inputs is the whole point. In practice I build that context in five layers. Each one is real work, and each one compounds on the last.
Layer one: captured customer voice. Every customer conversation, written down close to verbatim, not paraphrased into what you wish they had said. Paraphrase is where the signal dies. The exact words matter, because the exact words are what you hand the model later. Build this log first. It becomes the most valuable thing you own, and it keeps compounding while everything else churns.
Layer two: the verified workflow. A plain map of how someone actually spends their day in your product, from the first thing they open to the last. Draft it from the customer calls, then have real users correct it line by line. Verification is the point. AI on top of an unverified assumption gives you confident fiction. AI on top of a verified workflow gives you a map of where the value actually is.
Layer three: the strategy. One document that says who you are, who you are for, and just as importantly what you are not. Most design briefs start from a blank page. They should start from an agreed strategy, so the model pulls in one direction rather than inventing its own.
Layer four: the written bet. Write the press release for the product that does not exist yet, then answer the hard questions about it. This is the PRFAQ from earlier, turned into an input. It makes you name what is automated, what stays human, and what you will deliberately not build. You find out a thing is boring or unbuildable before you spend a dollar, not after.
Layer five: the honest critique. Walk your existing product, screen by screen, in writing. What confuses you. What hides. What a brand-new user would never find. Most teams have never written this down. It is uncomfortable, and it is the richest input of the lot, because it tells the model what good looks like by showing it exactly where today falls short.
Stack those five and something changes. By the time a request reaches the AI, it is carrying real customer language, a verified workflow, an agreed strategy, a written bet, and an honest critique. That is why the output stops being generic. You did not write a better prompt. You built a better world for the prompt to live in.
The handoff is a single page
All five layers collapse into one short brief. Who the user is, by name and role. The job they are doing and the seam it falls through today. The data you already hold that could power it. And what the thing must do, and must never pretend to do.
Because the layers already exist, writing one of these takes an hour, not a week. From that one page, a working, interactive prototype in a day. Built by one person, alongside the day job. Not a deck. Not a wireframe. Something a customer can click.
The loop: validation before investment
Then you put it back in front of the people whose problem it is, and you watch.
This is the part that pays for everything. The customers rank your bets for you. One idea wins across every conversation and another quietly dies, and you learn which is which before you have written a line of production code. The cost of being wrong, which is the single largest cost in product development, collapses toward zero.
One discipline matters here. A prototype is a north star, not next sprint’s commitment. Showing someone what is possible is not the same as promising it next month. Hold that line, or you will frighten the very users you are trying to learn from.
Three things that actually matter
If you take only the method, you have missed the point. Three lessons sit underneath it.
The inputs are the asset. The prototypes are disposable. Build the customer log first, be religious about the verbatims, and let everything compound from there.
Humans verify both ends. Your team validates the workflow going in. Your customers validate the prototype coming out. AI only accelerates the middle. Take the humans off either end and you are generating confident fiction faster.
The leader has to be in the loop, and at the start. The inputs come from conversations only you are having. Deciding what the customer voice actually means is not a task to delegate. It is the job.
You do not need a program. You need to start.
There is a version of this that turns into a steering committee and a six-month tooling evaluation. Resist it.
Find the people on your team already using these tools on their own time, and give them room. Their work rises to
the top and the habit spreads. Use the tools yourself, visibly, because you cannot ask a team to go all in while you watch from the sidelines. And anchor everything to truth. AI sitting on top of a trusted source of truth is leverage. AI sitting on top of noise is just faster nonsense. The advantage does not go to whoever has the cleverest prompt. It goes to whoever did the unglamorous work of the inputs.
That work is not new. Talking to customers, mapping the workflow, writing the strategy, telling the truth about your own product. We have always known we should do these things. What is new is that, done well, they now turn into working software in a day.
The prototype really is the easy part. It always was. We just could not see it until the easy part got easy.