Phase 6: Prompt Engineering & GenAI Feature Design · 40 min · Model playgrounds · v0 · Bolt.new

Rapid Prototyping AI Features

A full PRD answers 'how do we build this right.' A same-day prototype answers the cheaper, earlier question: should we build this at all.

Hiring signal: Portfolio-first hiring rewards candidates who can show, not just describe, product judgment -- and the fastest way to generate that proof is a same-day prototype test before committing engineering time to a full spec. Interviewers ask 'how would you validate this idea before writing a PRD' specifically to filter out candidates whose only tool is more upfront analysis; the strong answer is a structured, cheap, fast prototype test with a predefined kill criterion.

What you will learn

Select the right prototyping tool (model playground vs. AI-assisted UI builder) for a given validation question
Structure a same-day prototype test with a specific, falsifiable hypothesis and kill criterion
Distinguish what a prototype can and can't validate before a full PRD is justified
Avoid the most common rapid-prototyping trap: polishing a prototype instead of testing the risky assumption

The Problem

A PM has an idea: an AI feature that turns a rambling voice memo into a structured meeting-action-item list. Following the course's process so far, the instinct is to go straight to a full PRD (Phase 4), complete with a cost model, an evaluation plan (Phase 5), and prompt specs (this phase's Lesson 1) — three to five days of work before a single real user has seen anything. Two weeks after that PRD is approved and engineering starts building, user interviews reveal the actual problem: users don't want structured action items extracted automatically, they want to edit the AI's interpretation before it's finalized, because the raw transcription is often ambiguous about who owns what. The core interaction model was wrong, and the team spent two weeks of engineering time building the wrong thing before finding out — a finding that a single afternoon with a model playground and five real user tests would have surfaced for near-zero cost.

This is the case for rapid prototyping as a distinct, earlier step: validate the riskiest assumption cheaply, before committing the cost of a full PRD and engineering build to it.

Choosing the Right Prototyping Tool for the Question

Different validation questions call for different tools, and picking the wrong one wastes the exact time rapid prototyping is supposed to save:

Model playgrounds (Anthropic Console/Workbench, OpenAI Playground) are the right tool when the question is about the model's behavior itself — can it reliably do the core task at all, what does the output actually look like, how does it fail. This is the fastest, cheapest prototyping step and should almost always come first: there's no point building UI around a core capability you haven't confirmed works.
AI-assisted UI builders (v0, Bolt.new, Replit) are the right tool when the question is about the interaction model — does a user actually want to interact with this capability the way you've imagined, is the proposed UX intuitive, does seeing a real (even rough) interface change how people react to the idea compared to describing it. These tools can produce a working, clickable interface in hours instead of days, letting a PM test the interaction model without waiting for an engineering sprint.
A working interface is not always necessary. For some questions — is the core AI capability good enough, does a specific prompt approach handle a specific hard case — a Workbench session and a handful of pasted examples answers the question faster than any UI build.

Match the prototype's fidelity to the question, not to what's impressive
The most common rapid-prototyping trap is spending the "same day" budget polishing visual details of a UI builder output instead of testing the actual risky assumption. If the risky assumption is "can the model reliably extract action items from a rambling voice memo," a Workbench session testing that exact task against 10 real (or realistic) voice memo transcripts answers the question in an hour. If the risky assumption is "do users want to edit the AI's interpretation before it's finalized," a rough, even ugly, clickable v0 prototype that lets 5 real users try editing an example output answers that question far better than a polished but non-interactive mockup. Polish answers a different question (does this look professional) than validation does (was our core assumption right) -- spending scarce prototype time on the former instead of the latter is the trap.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Structuring a Same-Day Prototype Test, From Prototype to PRD: What a Prototype Can and Can't Tell You, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.