A developer on IndieHackers posted: "I built 7 apps last year with Cursor. Zero of them have users." The comment got 400+ upvotes. The replies identified the same cause: he started coding before he defined who the product was for or what problem it solved. Writing a product brief before coding takes 15 minutes and determines whether the next 4-40 hours of building time produce a product or a project.

Why the brief matters more when AI writes the code

When coding took months, a bad product idea cost months. When Cursor builds a prototype in hours, a bad product idea costs hours — plus the opportunity cost of the better idea you didn't pursue. Speed amplifies both good and bad decisions. The product brief before coding is the 15-minute investment that determines whether AI-generated speed works for you or against you.

The brief also improves the code. A vague prompt ("build a CRM") produces a generic CRM. A specific brief ("build a CRM for freelance translators managing 15-30 client relationships, focused on project handoff tracking") produces a product with differentiated architecture from the first commit.

The 5-field product brief

Five fields. One page. Fifteen minutes. Each field answers one question that most developers skip when they open Cursor immediately.

This format comes from observing what successful indie founders do before they code. Marc Lou writes a similar brief before every product. Pieter Levels starts with a problem statement pasted from a real user. The 5-field structure captures the common elements across their approaches.

Field 1: The problem (paste someone else's words)

Don't write the problem in your own words. Find a Reddit comment, forum post, or tweet where a real person described the frustration. Copy-paste it. The person's exact language is better than your abstraction because it contains specifics you wouldn't invent: "I spend 45 minutes every Monday copying data from three spreadsheets into a summary email for my manager."

If you can't find someone describing this problem in their own words, the problem might not exist. The search itself is validation.

Field 2: The person (one specific job title)

"Everyone" is not an answer. Name one job title: "freelance UX designer billing £4K-8K/month in the UK." The specificity determines every design decision. A CRM for freelance translators looks completely different from a CRM for real estate agents, even though both are "CRMs."

April Dunford, who literally wrote the book on positioning ("Obviously Awesome"), argues that the most common positioning mistake is trying to serve everyone. Narrowing your audience feels like shrinking your market. It actually sharpens every product decision downstream — from features to copy to pricing.

Field 3: The opinion (what you believe)

Complete this sentence: "Most tools in this space assume [X]. I believe [opposite of X]." Example: "Most project management tools assume teams need multiple views (list, board, timeline, calendar). I believe one view — a flat list sorted by urgency — serves solo freelancers better." The opinion is your product's point of view. It determines what you build and, more importantly, what you refuse to build.

Field 4: The one feature (what v1 does)

One feature. Not three. Not "and also." The single action the user takes that solves the core problem. "Paste a Stripe transaction URL and get a formatted invoice PDF in 2 seconds." That's a product. Ship it. Test it. Add features only after users ask.

Jason Fried calls this "less is more" at a structural level. Not fewer settings or a cleaner UI — fewer capabilities. Ship one thing that works perfectly. The temptation to add "and also" before launch is the single biggest source of projects that never ship.

Field 5: The reach (how they find you)

Where does the person from Field 2 hang out online? Paste the exact URL. r/freelance. Freelancer subreddits. A specific Slack community. One Twitter account they all follow. This field forces you to verify that your target audience is reachable. If you can't name a specific community, you can't launch.

The product brief before coding template

Problem: [paste a real person's words]. Person: [one job title]. Opinion: [most tools assume X, I believe Y]. Feature: [one action]. Reach: [one URL where they gather]. That's it. Fifteen minutes. Five fields. This brief becomes the first prompt you paste into Cursor. The AI produces better code because the input was specific. The product brief before coding step is the most impactful 15 minutes in any build cycle.

Making the brief a reflex

Sparks trains the structured thinking behind each field: reverse thinking for Field 3 (find your opinion by describing the worst product and flipping it), SCAMPER for Field 4 (run seven transformations to find the single feature worth building), forced connections for Field 1 (cross-domain techniques for spotting non-obvious problems). Daily 5-minute exercises, AI-scored, building the habit of thinking before prompting.