Product-First AI Prompting
Steer AI builders by describing the end-user experience ambitiously, then iterate like you're coaching a collaborator
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 88%
Rauch's practical method for getting great results from AI build tools: be maximally ambitious, describe what you want the end user to experience rather than how to implement it, suspend disbelief that the tool may know more than you, and treat the work as an iterative back-and-forth — including the surprisingly effective prompt 'just try something else.' Code comes last; you live in the product.
Origin
Guillermo Rauch's tips for using v0, generalizable to AI product-building tools.
Core principles
- 01You can be as ambitious as you want in what you ask
- 02Describe the product and user experience, not the implementation
- 03Suspend disbelief — the tool may know things you don't
- 04Iteration is coaching: give feedback, ask it to try again
- 05Code last, not code first — live inside the product
How to run it
- 1
Start ambitious, or fork a starting point
Ask for something bold; if you have writer's block, fork an existing community submission instead of starting from scratch.
Pro tip Rauch declares goals like 'we're going to build the best flight radar on the planet' without prescribing how.
- 2
Describe experience, not implementation
Focus on what you want the end user to experience and what the product should do; let the tool choose the libraries and techniques.
Pro tip Rauch didn't specify Mapbox, Leaflet, or a canvas renderer — he described the outcome and the tool picked better tools than he would have.
Watch out Don't be too opinionated; over-specifying blocks the tool from applying best practices (accessibility, elegant CSS filters) it knows better than you.
- 3
Iterate by coaching
Give feedback like you would to a design agency or a stuck engineer, going back and forth until it's right.
Pro tip When it's stuck, literally prompt 'just try something else' — it works surprisingly often.
- 4
Work experience-first, then make it real
Build the front end and feel first, then add full-stack depth (APIs, data, performance) once the experience is right.
In the wild
Bored on a Tokyo–San Francisco flight with terrible internet, Rauch told v0 to build 'the best flight radar on the planet' without prescribing how. It chose Mapbox and Leaflet on its own; when there were too many flights he simply said 'we have a lot of flights, chief,' and it built a canvas overlay rendering tens of thousands of planes, then he plugged in a real flight API.
→ A full-stack, high-performance flight tracker built in under two hours for about $20/month of tooling — work he estimates would take engineers weeks and tens of thousands of dollars.
Common mistakes
Prescribing the implementation
Telling the tool exactly how to build something wastes its knowledge; Rauch got a more elegant CSS-filter sepia effect and more accessible code precisely because he described intent, not method.
Giving up when it gets stuck
Users abandon at the first blocker instead of iterating; the simple prompt 'just try something else' or handing the code to another AI often breaks the logjam.
Is it for you?
Best for
Product builders, PMs, and designers using AI tools like v0 to prototype and ship real products
Not ideal for
Very large existing codebases where the AI struggles with long context and tasks must be scoped down to single files/components
From the transcript
“you can be as ambitious as you want in terms of what you ask the tool”
“focus more on the product description, right? Like focus more on like what do you want the end user to experience? What do you want…”
“It's amazing how many times I've gotten unstuck in Vero by just saying like, "Just try something else."”
From the episode
Everyone’s an engineer now: Inside v0’s mission to create a hundred million builders
Guillermo Rauch (founder and CEO of Vercel, creators of v0 a