Product Managers Can Now Ship a Working Prototype in 20 Minutes. Here's the Map.

The "PM who can't code" job description is on the way out.

Lenny Rachitsky just published a guide to AI prototyping for product managers, and the takeaway isn't subtle: the floor for what a PM can build by themselves has moved from "wireframes in Figma" to "actual working software, deployed and accessible at a URL, in under an hour."

If you can describe a feature, you can now build a prototype of it. The bottleneck isn't engineering capacity — it's how clearly you can describe what you want.

Here's the tool map Lenny lays out, plus where I'd add my own spin from using these tools daily.

Three Tool Categories — Pick the Right One for the Job

Lenny breaks AI prototyping tools into three buckets. Each bucket is good at something different, and using the wrong tool for the job is the most common mistake PMs make when they first start prototyping.

Category 1: Chatbots (Claude, ChatGPT)

Best for: simple, single-page prototypes. Calculators, data visualizations, single-form interactions.

Lenny calls out Claude's Artifact system specifically — the ability to run code inside the chat means you can build and test small interactions without ever leaving the conversation. The catch: editing requires re-prompting, which can be frustrating if you're trying to iterate quickly on visual details.

When I reach for chatbots: brainstorming and one-off "what if it looked like X" tests. Anything that needs to live somewhere or get shared around, I move to category two.

Category 2: Cloud Development Environments (v0, Bolt, Replit, Lovable)

Best for: multi-feature prototypes with real design requirements.

Each one has a personality:

• v0: Beautiful default styling out of the box. Best when you're showing something to a designer or stakeholder and the visuals matter.
• Bolt: Fastest iteration loop. Best for quick proof-of-concepts where you want to make 10 changes in 30 minutes.
• Replit: Strong on data-heavy tools. Best for prototypes with backends, databases, or any kind of file processing.
• Lovable: Bridges to production with real integrations. Best when the prototype needs to actually plug into existing services.

The big advantage over chatbots: these tools handle hosting, deployment, and real infrastructure. You get a URL you can share. Stakeholders can click through it. That alone changes how the prototype gets received.

Category 3: Local Developer Assistants (Cursor, GitHub Copilot)

Best for: experienced developers building production applications.

Lenny is direct: this category isn't for the average PM yet. You need to be comfortable in a code editor, understand multi-file projects, and be able to debug when things go wrong. The upside is unlimited — you can build anything — but the floor is higher.

What I'd add: this is where most PMs will end up in two years. The skill curve isn't impossible, and the value of being a PM who can actually push commits is going to get bigger every quarter.

The Two Workflows You Need to Know

Lenny demonstrates two main use cases, and these are the ones every PM should practice:

Workflow 1: Convert an existing design to a prototype. You have a Figma mockup. You feed it to a tool with a specific prompt: "Build this interface using these exact spacings, colors, and components." The tool outputs working code that matches the design closely enough to get feedback in real interactions, not in static mockups.

Workflow 2: Build a feature from scratch using a generative design system. Tools like Tailwind and Shadcn UI have become the de facto languages of generative AI. Saying "use Shadcn UI components" gets you a clean, modern interface by default. From there, you describe behaviors and iterate.

The One Thing That Matters Most: Specificity

The biggest takeaway in Lenny's piece — and it matches everything I've learned doing this myself — is that the quality of the prototype is directly proportional to the specificity of the prompt.

"Make a signup form" gets you a generic signup form.

"Build a signup form with email and password fields, a 'sign up' button, error states for invalid emails and passwords under 8 characters, and a 'forgot password?' link below the button. Use Shadcn components and Tailwind. The form should be centered on the page with a 480px max width" gets you exactly what you wanted.

The PM skill that's emerging here isn't coding. It's writing prompts the way you'd write engineering specs — concrete, exhaustive, and unambiguous about what "done" looks like.

What I'd Add From My Own Experience

Two more things that aren't in Lenny's piece but matter:

1. Always start with a screenshot or design. If you have any visual reference, paste it. The tools work an order of magnitude better with visual input than with description alone.

2. Build the same thing twice in two different tools. If you can't decide between v0 and Bolt for your use case, just build the same prototype in both. You'll have a clear preference within an hour, and you'll have learned both tools.

The Bottom Line

The shift Lenny is documenting isn't "PMs can prototype." It's "PMs are expected to prototype." Within the next year or two, the answer to "can you mock this up?" is going to default to "yes, give me an hour" instead of "let me write a doc and book time with engineering." If you're a PM and you haven't picked a tool from category two yet, this is the quarter to fix that.