3.2 · Quality-check your brief: features to outcomes

By JetThoughts Team - May 18, 2026 - 12 min read

Module 3 · Step 2 of 2 · From Idea to First Paying Customer
Input: a one-page Product Brief (from Chapter 3.1)
Output: a one-page Product Brief rewritten so engineers and AI agents stop overengineering

Jump to: What to do tomorrow · Artifacts you carry out

TL;DR: Rewrite every feature noun as an outcome-shaped job story. “Build a CSV export” becomes “When I prepare the weekly report, I want to grab the top 5 metrics in 30 seconds.” The engineer has nothing left to invent.

Skip to the action: What to do tomorrow if you have your Ch 3.1 brief open and want the rewrite steps now. The examples and the theory will still be here.

You sent your engineer (or your AI agent) a one-line spec: “build a simple admin panel.” Ten weeks later you have an admin panel with 47 buttons, role-based permissions, an audit log, and a co-pilot AI assistant. Your engineer isn’t a show-off - those four words “a simple admin panel” don’t tell anyone what “simple” means, who’s using the panel, or what the panel needs to do. The engineer (or the training data) filled in those blanks from every big-company SaaS panel they had ever seen.

A hand-drawn comparison: the simple three-button admin panel you asked for on the left, the absurdly complex 47-button control deck that got built on the right, connected by a red arrow labeled 10-week build, $15K

Why feature briefs overbuild

Engineers and AI agents fill vague requests from training data - big-company SaaS panels, GitHub-scraped baselines, the busiest version of whatever they last saw. A feature word in isolation (“CSV export,” “user roles”) has no anchor to your actual job, so the engineer or agent invents the missing context. An outcome-shaped request (“when I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds before the 4pm call”) leaves nothing for them to invent - the moment, the action, the deadline, and the result are already on the page.

Two briefs, two shapes each

Same job, two ways to write it. Read each pair out loud. Notice how much the engineer or the agent has to invent under the feature shape, and how little they have to invent under the outcome shape.

Feature-shaped brief on the left leading to a sketched BI suite with nine modules; outcome-shaped brief on the right leading to a single ‘Copy top 5 metrics’ button with a five-row data table

Pair 1 - The CSV button

Feature shape: “Build a CSV export button on the dashboard.”

Outcome shape: “When I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds, so I can paste them into the deck before the 4pm call.”

What the engineer builds from the feature shape: a reporting module with three dashboards, scheduled email exports, role-based access on who can export, a date-range picker, custom column selectors, and an audit log of every download. Six weeks of work. You used the CSV button once a week for the investor email and ignored the other eight features.

What the engineer builds from the outcome shape: one button at the bottom of the existing dashboard that says “Copy top 5 metrics to clipboard,” hard-coded to MRR, net new MRR, active accounts, trial-to-paid conversion, and runway. Ninety minutes of work in a Rails controller, one line per metric. The next investor email goes out before the deck even opens.

Pair 2 - The CRM module

Feature shape: “Build a CRM module.”

Outcome shape: “When a new customer signs up, the founder needs to see which 3 of our existing customers most resemble them, so we can pattern-match the onboarding playbook that worked for those three.”

What the engineer builds from the feature shape: companies, contacts, deals, pipelines, activities, tasks, notes, custom fields, email integration, calendar integration, and a Kanban board nobody opens. Three months. You used the contacts list and the notes field.

What the engineer builds from the outcome shape: a 30-line script that runs nightly, scores existing customers against the new signup on three attributes (industry, employee count, plan tier), and posts a Slack message every morning: “New customer Acme Co looks most like Beta Inc, Gamma Ltd, and Delta GmbH - here are their onboarding notes.” Two days. The script is throwaway. When Salesforce is finally worth the bill, you import the script’s three matches into the proper CRM record.

The three-part shape that constrains every spec

Both outcome-shaped briefs in the section above use the same three parts. The shape works because each part forecloses a category of overbuild.

When [trigger context] - the specific situation that activates the need. Names the moment, the day, the deadline, the surrounding tools. “When I prepare the weekly investor report” tells the engineer this happens once a week, that there is a deck involved, that there is a 4pm call. The engineer will not build a real-time streaming dashboard for something that happens on a Tuesday afternoon.

I want [internal motivation] - what you are trying to do, expressed as a verb on a concrete object. “I want to grab the top 5 metrics in 30 seconds” is a verb (grab) and an object (the 5 metrics) and a budget (30 seconds). The engineer will not build a 12-metric dashboard because you said 5, and will not build an asynchronous export queue because you said 30 seconds.

So I can [outcome] - the business or personal result that proves the build worked. “So I can paste them into the deck before the 4pm call” gives a finish line the engineer can hold up against any feature suggestion. The engineer can now say: “Does the build let you paste into the deck before 4pm? Then we are done. Does the audit log help with that? No? Cut it.”

Put the three parts together and the engineer (or the AI agent) has nowhere left to invent. Drop any one part - the timeframe, the action, or the outcome - and the gap gets filled in from training data instead of your intent. The same shape has a name in product-management literature; see Further reading below if you want to chase the lineage.

%%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% flowchart TD Feature["FEATURE brief: Build a CRM module"] Feature --> F1["Companies + contacts"] Feature --> F2["Deals + pipelines"] Feature --> F3["Email + calendar integration"] Feature --> F4["Custom fields + Kanban"] F1 --> FOut["3 months. $40K. You used contacts + notes."] F2 --> FOut F3 --> FOut F4 --> FOut Outcome["OUTCOME brief: Match new signups to 3 similar customers"] Outcome --> O1["Nightly scoring script"] Outcome --> O2["Slack message each morning"] O1 --> OOut["2 days. $600. Onboarding playbook ready Monday."] O2 --> OOut classDef bad fill:#fff5f5,stroke:#cc342d,stroke-width:2.5px,color:#1a1a1a classDef good fill:#f0f9f0,stroke:#2e7d32,stroke-width:2.5px,color:#1a1a1a class Feature,F1,F2,F3,F4,FOut bad class Outcome,O1,O2,OOut good

What to do tomorrow

Three actions, in order.

Open your filled-in one-page brief from Chapter 3.1. Find Section 3 (“What you’re building”). Read the section out loud. If any line begins with a noun-shaped feature (“a CSV button,” “a CRM,” “user roles,” “a settings page”), it is feature-shaped. Mark it.
Rewrite each marked line in the When / I want / So I can shape. The when has to name a specific moment with a deadline, the I want has to name a verb and a budget, and the so I can has to name a result you can measure that week. Keep the whole section to a single focused pass. If you spill, the section is too big - your one-page brief is trying to be three.
Share the rewritten section with your engineer or your AI agent and ask exactly one question: “What would you build differently from this brief than you would have built from the feature list?” Their first answer is the scope you were about to lose. Their second answer is the scope you are about to keep.

The pass/fail rubric. Read the peer’s answer. The brief PASSES quality-check only if their answer stays inside your scope - the features in your Section 3 and the items NOT in your no-go list. The brief FAILS if their answer:
names any feature you didn’t list in Section 3, OR
mentions anything you explicitly cut in your no-go list, OR
includes 2+ items outside the no-go list (your scope is too vague).
FAIL = revise Section 3 outcome-shape and ask a fresh peer. Do NOT advance to Module 4 with a failed brief; the Lovable build will inherit the fuzziness.

Module 3 AI critic/simulator block
No peer available? Use Claude or ChatGPT as the peer. Paste your full Section 3 + Section 5 (no-go list) into Claude, then paste this prompt:
Imagine you are a contractor reading this brief to build the product. Based ONLY on Section 3, name 5 things you would build that are NOT in Section 5's no-go list. Be specific - feature names, not categories.
If Claude names 2+ items outside your no-go list, the brief failed quality-check the same as a peer flagging them. Revise Section 3 and re-run. This is the same failure signal a peer would surface, with no calendar coordination needed.
What AI cannot prove or substitute:
Whether your scope solves the validated problem (only the Module 4 build + real users can)
Whether a real contractor would interpret the brief the same way (AI is a proxy, not a substitute)
The real gate: a clean peer QA (human or AI) where the answer stays inside your scope AND no-go list.

The cheap fix for this whole pattern is the rewrite tomorrow morning. The expensive fix is the salvage decision you read after the spaceship lands and investors ask why the demo is so heavy. One focused pass with a marker now spares you the build-and-throwaway later.

Optional: stack-rank features with real users. After you have rewritten Section 3 as outcome-shaped job stories, you still have a list. If you need to know which outcome to build first, OpinionX (free tier available) uses forced-ranking pairwise voting - users pick A or B, not rate everything “very important.” Paste your 5-7 outcome statements, send the link to your Ch 2.3 (a + b) interviewees, and the forced-choice format surfaces real priorities that a 1-10 rating scale hides. The output is a ranked list backed by pairwise win rates, not averaged scores. Use this before handing the brief to Lovable or a contractor - it prevents the “build everything because everything scored 8/10” trap.

Artifacts you carry out of Module 3

After finishing Ch 3.1-3.2, Sam has five artifacts. Each one feeds a specific downstream destination - this table is the map:

Artifact	Where it goes next
One-Page Product Brief / Vibe PRD (Ch 3.1 output)	Ch 4.1 build-path decision (the brief is the input the worksheet routes against) + Ch 4.3 (a + b) Lovable kickoff prompt. The single source of truth Module 4 builds from.
Outcome-shaped feature list (Ch 3.2 rewrite of Section 3 in Job Story format)	Ch 4.1 contractor SOW (if you route to hire) + Ch 4.3 (a + b) Lovable prompt body. Replaces the noun-shaped feature list that causes overbuild.
No-Go list (5-10 items you explicitly cut from Ch 3.1 Section 5)	Ch 4.3 (a + b) self-serve scope guard + Ch 4.4 ceiling-signal monitoring. The written “we are not building this yet” line that prevents Module 4 scope creep.
Audience-of-one fork (the audience choice from Ch 3.1: AI agent / junior dev / senior team)	Ch 4.1 Q2 build-path routing. The fork decides whether the brief routes to Lovable (AI agent) or a contractor (junior or senior team).
Quality-check verdict (Ch 3.2 - peer answers “what would you build differently?” cleanly?)	Checkpoint before Module 4. If the peer cannot answer cleanly, return to Ch 3.2 and rewrite Section 3 before opening Lovable or sending the SOW.

Module 3 closes here. Before opening Module 4, you should have: (1) a one-page Product Brief (Vibe PRD) with 5 sections filled in (Ch 3.1), (2) Section 3 rewritten as outcome-shaped job stories that pass the peer “what would you build differently?” test (this chapter), and (3) a no-go list of 5-10 items you explicitly cut. Both in your Founder OS folder. Missing one? Go back - Module 4 reads the brief into Lovable prompts; a half-written brief produces a half-working MVP.

When your brief skips the moment, the action, and the result, the engineer or the AI agent fills them in from training data. Name those three and there is nothing left for them to invent.