Template companion to Lesson 3.1 - The One-Page Product Brief (Vibe PRD) · From Idea to First Paying Customer

Input: your validated problem statement (from the Lesson 2.5 synthesis) + the “describe in one sentence” vocabulary from your Lesson 2.6 prototype sessions

Output: a filled one-page Product Brief (Vibe PRD), written in one 90-minute sitting, ready to hand to your AI agent or contractor tomorrow

Vibe PRD Template - One Page, Five Sections

The brief that turns a validated problem into something Lovable (an AI app builder), Cursor (an AI coding editor developers use), or a hired junior can ship on Tuesday morning.

The one-page brief, 5 sections:

1. The problem (copied from your validated problem statement)
2. The user and their context
3. What you’re building (one paragraph, plain English)
4. Success metric (one metric, one target number)
5. What you’re not building (the no-go list)

Why this exists

An AI app builder fills every blank you leave with a reasonable default - that is the whole reason a one-page brief exists. Feed it a bare problem statement and “build the simplest version of this,” and twelve hours later you are deleting a settings page, a billing dashboard, three integrations, and a pile of toggles you never asked for, and that deleting runs three weeks. Give the same builder a one-page brief with a no-go list, and it ships the smallest end-to-end thing in 90 minutes. The page you fill in between those two attempts is the difference: the agent fills blanks with defaults, and the brief is your only way to forbid them.

How to use this

Block 90 minutes on a single morning. Print the template (or copy the markdown block below into a Notion doc). Bring your filled-in validated problem statement. Open Lovable, Cursor, or your contractor’s kickoff doc in a second tab. You will not type into the second tab yet. The page first.

Section 1 copies directly from your validated problem statement, word for word. Section 2 pulls from your Module 2 interview notes and 2.6 prototype-session notes - the moment-of-use detail is already there; don’t invent it. Sections 3 through 5 you write from scratch. Hard cap: 90 minutes total. If you spill, the persona is too broad or you are designing too much.

After the page is filled, read it aloud to one peer over a 20-minute call. Ask them: “If you built this in a week using Lovable, what would you build that isn’t on my no-go list?” Their first answer is your missing no-go item.

Total time budget: 90 minutes to write, 1 hour to read aloud + revise, 0 minutes to convert for the audience. The same page goes to Lovable, Cursor, or the hired junior. The brief is the brief.

The template - copy and paste

Use the markdown blocks below directly in Notion, Lovable’s prompt window, or a Word doc. The SVG of the page is embedded in the Lesson 3.1 post for printing.

Copy section by section, or grab the whole template from the top.

======================= VIBE PRD =======================

Product name (working): _________________________________

Founder: _________________  Date: _______________________

Source: validated problem statement signed ____/____/____
        by ____________________ (advisor 1) and
           ____________________ (advisor 2)

Section 1 - the problem. Copy this straight from your validated problem statement, word for word. Do not soften the wording.

---------------------------------------------------------
1. THE PROBLEM (copy from validated problem statement)
---------------------------------------------------------

Persona + industry + dated 10-call sample:
_________________________________________________________

Quantified cost (time per week + money per month):
_________________________________________________________

Verbatim quote from a strong-signal interview:
"_______________________________________________________"

Why now (trigger / market shift, one sentence):
_________________________________________________________

Inherited from validated problem statement - DO NOT
paraphrase. If you find yourself softening the wording,
stop and reread the original page.

Section 2 - the user and their context. The agent or junior needs the moment of use, not the market size.

---------------------------------------------------------
2. THE USER AND THEIR CONTEXT
---------------------------------------------------------

Who they are while using your product (job + situation):
_________________________________________________________

The 60 seconds before they reach for your product:
_________________________________________________________

The 60 seconds after they close it:
_________________________________________________________

Device + environment (laptop / phone / desk / commute):
_________________________________________________________

Emotional state at the moment of use:
_________________________________________________________

The agent or junior needs the context, not the TAM.
"Tired, two tabs open, wants to be done" beats
"SMB SaaS company, 11-50 employees, Series A."

Section 3 - what you’re building. One paragraph’s worth, verb-led - the fields below assemble it. If it reads like a feature list, the agent builds a settings page nobody asked for.

---------------------------------------------------------
3. WHAT YOU'RE BUILDING (one paragraph, plain English)
---------------------------------------------------------

The smallest end-to-end thing the user can do:
_________________________________________________________
_________________________________________________________

Inputs the user provides:
_________________________________________________________

Output the user gets back:
_________________________________________________________

Authentication method (magic link = email sign-in link / OAuth = "sign in with Google" / none):
_________________________________________________________

What v1 explicitly supports (scope of "done"):
_________________________________________________________

Write this as one paragraph, verb-led. If it reads like
a feature list (Stripe integration + dashboard + settings)
the agent will build a settings page nobody asked for.
Rewrite until it reads like a sentence about what the
user does.

Section 4 - the success metric. One number, not three. Three metrics let you cherry-pick.

---------------------------------------------------------
4. SUCCESS METRIC (one metric)
---------------------------------------------------------

Number + unit + timeframe:
_________________________________________________________

How it's measured (analytics event, not gut feel):
_________________________________________________________

Pass threshold (build is validated above this):
_________________________________________________________

Fail threshold (kill or rewrite below this):
_________________________________________________________

One metric, not three. Three metrics let you cherry-pick.
One metric forces a build/no-build call in 30 days.

Section 5 - what you’re not building. The longer this no-go list, the cheaper your build.

---------------------------------------------------------
5. WHAT YOU'RE NOT BUILDING (the no-go list)
---------------------------------------------------------

5 to 8 lines naming what a competent agent or junior
might add unprompted that you explicitly do not want in v1.

[ ] _____________________________________________________
[ ] _____________________________________________________
[ ] _____________________________________________________
[ ] _____________________________________________________
[ ] _____________________________________________________
[ ] _____________________________________________________
[ ] _____________________________________________________
[ ] _____________________________________________________

If this section is shorter than 5 lines, you have not
finished. The agent fills blanks. The longer your list,
the cheaper your build.

Hand-off. Who the brief is going to, and the dates that keep it honest.

---------------------------------------------------------
HAND-OFF
---------------------------------------------------------

Audience for this brief:
 [ ] Lovable / Bolt / v0 (paste as prompt)
 [ ] Cursor / Claude Code (paste as context file)
 [ ] Hired junior contractor (page + 30-min kickoff call)
 [ ] Hired senior engineer  → switch to traditional PRD
 [ ] Product committee      → switch to traditional PRD

Date handed off: ___________________________________
Build start target: ________________________________
Metric check-in: 30 days from build start: __________

========================================================

Audience decision: who is this brief going to?

The same one page works for the first three audiences below. Senior engineers and product committees expect a longer document - the one-page brief is too thin for either.

What good looks like vs what bad looks like

Section 1 - The problem

Bad: “Founders need a better way to handle their finances.”

Good: “Pre-seed B2B SaaS founders running their own Stripe-to-QuickBooks reconciliation lose 6 hours per week and $800 per month in CFO contractor time. 8 of 10 interviewees confirmed (May 2026 sample). Quote: ‘Tuesday at 9pm I spent 40 minutes copying Stripe payouts into QuickBooks. I called my CFO. She did it in 90 seconds.’ Why now: the AI step that does the matching now costs a fraction of a cent per transaction - cheap enough to sell the whole tool at $9/month per seat.”

The good version is inherited from the validated problem statement. It names the persona by stage, industry, and specific workflow. It puts the cost in time and money. It includes a verbatim quote with a specific moment. It names the why-now with a specific number. A peer can argue with it. The bad version is too broad to argue with, which is why the agent or the junior fills it in for you.

Section 3 - What you’re building

Bad: “A modern reconciliation platform with AI-powered automation, Stripe integration, QuickBooks integration, custom reporting, user roles, and a mobile app.”

Good: “A web app where the founder pastes a Stripe payout CSV and the app returns a QuickBooks-compatible journal entry CSV they can import in one click. The first version supports USD only, one Stripe account per user, and no multi-currency. The user authenticates with email plus magic link. We never store the CSV after the conversion completes.”

The good version is one paragraph, verb-led. It names the input (paste CSV), the output (journal entry CSV), the scope of v1 (USD only, one account), the auth choice (magic link), and one storage rule. The bad version is a feature list. Feature lists produce settings pages.

Section 5 - What you’re NOT building

Bad: (blank)

Good: “Not in v1: multi-currency support. Multi-Stripe-account support. Automatic recurring sync. A settings page. A billing dashboard. User roles and permissions. A marketing site beyond the signup page. Mobile responsive design beyond ‘works on a 1024px screen.’ We will revisit each of these after the Section 4 metric is hit.”

The good no-go list names eight things a competent agent or junior might add. Each is concrete. The bad version is blank, which is how the EdTech founder who opens Lesson 3.1 ended up with 17 settings toggles in version one - 12 with no backend, 2 that crashed. Her team had read the brief as a wish list and added everything she didn’t forbid.

What to do after

• Read the brief aloud to one peer in a 20-minute call. Ask them: “If you had to build this in a week using Lovable, what would you build that isn’t in my no-go list?” Their first answer is your missing no-go item. Add it. The peer is doing the work of an external red-team.
• Paste the brief into Lovable, Cursor, or your contractor’s first kickoff doc - unchanged. Do not edit it for the audience. The same one page goes to all three. If the agent or the contractor asks a question whose answer is in the brief, your brief failed; rewrite the section that confused them before you take a second pass at the build.
• Set a 30-day calendar reminder for the Section 4 metric. The reminder fires whether or not you remember it. On day 30, open your analytics tool and read the conversion-completed count. Above the pass threshold = the brief was right and you build the next layer. Below = the brief was wrong somewhere, and you reread the page before adding anything.

Skip the no-go list and you ship a working demo of a product nobody asked for. Six weeks later you’re posting a salvage or rebuild question about an MVP you can’t extend. The page is cheap. The build round you save by writing it is the expensive thing you avoid.

If you want the doctrine in long form, the Lesson 3.1 post walks through the five sections with the worked example, the decision between one-page brief and traditional PRD, and the case for paying for a live cohort vs writing the page yourself for free.

Built by JetThoughts as part of the From Idea to First Paying Customer curriculum.