Before You Build Anything: How to Write Your Product and Business Thesis with AI
Before You Build Anything: How to Write Your Product and Business Thesis with AI
Meta Description: Most founders skip the most important step: getting clear on what they’re building and why — in writing. The CLEAR method helps you develop your product thesis using AI. That thesis becomes the foundation everything else builds from.
There’s a step that almost every builder skips.
They have an idea. They start building. They run into a decision — should the form have 3 questions or 7? Should this be a web app or a Slack bot? — and they make a call based on gut feel. Six weeks later they’ve made 50 small decisions, and they don’t add up to anything coherent.
The missing step is the thesis.
Not a business plan. Not a pitch deck. A one-to-two page document that answers three questions:
- What am I building, and what problem does it solve?
- Who specifically is it for, and why does their current solution fail them?
- Why does it work — what’s the core mechanism that makes this thing actually solve the problem?
That document goes in your repo. It’s the first thing Claude reads every time you start a working session. It’s why your AI can help you build coherently instead of just executing one instruction at a time.
This post is about how to write it — using AI, in one sitting.
Why the Thesis Comes Before the Code
Most people think they need to start building to figure out what they’re building. That’s backward.
When you build without a thesis, you make micro-decisions without a frame. You add features that feel useful but don’t connect. You pivot when you hit resistance instead of pushing through. You can’t describe what you made at Demo Day because you never decided what you were making.
When you build with a thesis, every decision has a standard to be measured against. “Should I add email notifications?” — does that serve the person in my thesis? Yes? Build it. No? Backlog it.
Your thesis is your north star. It lives in your repo. Claude reads it. Your Linear backlog flows from it.
Let’s write it.
The CLEAR Method
CLEAR is a prompt framework — a structured conversation with AI that takes you from vague concept to written, pressure-tested thesis.
C — Context: Who are you, what are you building, who is it for? L — Limitation: What are you explicitly not building? E — Examples: What does success look like? What similar things exist? A — Ask: What specific output do you need? R — Refine: Push back on the output until it’s actually true.
Run this in Claude (preferred), ChatGPT, or Gemini. Don’t rush it. The friction you feel in the middle is the friction of real thinking — that’s supposed to happen.
Part 1: Develop the Thesis
Prompt 1 — Establish Context
I'm building an AI tool to [describe your rough idea in 1-2 sentences].
My target user is [describe who, specifically — "solo consultants who charge by the hour"
not "small businesses"].
The pain I'm solving for them is [describe the problem in their words, not yours].
Act as a product strategist. Don't give me recommendations yet. First, ask me 3-5
clarifying questions that will help you understand the real shape of this idea.Answer the questions honestly. If the answers reveal that your idea is fuzzier than you thought — good. That’s what this is for.
Prompt 2 — Define the Mechanism
This is the question most founders can’t answer: why does it work?
Based on what we've discussed, help me articulate the core mechanism of this product.
What is the specific thing it does that makes the problem go away? Not the features —
the underlying logic. Why does this approach work when other approaches don't?
Give me 2-3 candidate answers, then help me identify which one is most defensible.The mechanism is what makes your product a real thing instead of a collection of features. A client intake bot’s mechanism isn’t “it asks questions” — it’s “it replaces synchronous calendar time with async input collection, which removes the scheduling bottleneck that limits how many clients you can take on.”
One sentence. What’s the mechanism that makes your thing work?
Prompt 3 — Scope It Ruthlessly
Now help me define the smallest version of this that would still be genuinely useful
to my target user — and prove the mechanism works.
Specifically:
1. What are the 2-3 things it must do for version 1 to be worth using?
2. What are things I might want to add later, but should explicitly cut from v1?
3. What's the one metric that tells me v1 is working?The cut list matters as much as the feature list. Write it down. You’ll need it in Week 2 when scope creep knocks.
Prompt 4 — Stress Test
Now push back on all of this. Play devil's advocate.
1. What's the most likely reason this doesn't work as described?
2. What would a skeptical target user say when I pitch it to them?
3. Is there a simpler version that solves 80% of the problem in 20% of the time?
4. What assumption am I making that might be wrong?If the AI surfaces a real flaw — a workflow that doesn’t work the way you assumed, a user who wouldn’t actually switch tools — better to find it now than in Week 3.
Prompt 5 — Write the Thesis
Based on everything we've covered, write my product thesis. It should be 3 short sections:
1. **What it is:** One paragraph describing the product, who it's for, and the problem it solves.
2. **Why it works:** One paragraph describing the core mechanism — why this approach solves
the problem when other approaches don't.
3. **What it's not:** A bulleted list of 4-6 things explicitly out of scope for version 1.
Write it as if you were explaining it to a smart person who has no context on what I'm building.
Clear enough that they could make product decisions without asking me.That output is your thesis. Take it, clean it up, and put it in a file called docs/thesis.md in your project repo.
Part 2: The Thesis Goes In the Repo
Your thesis document belongs in your GitHub repository. Here’s why:
Claude Code (and any AI you use to help you build) reads your project context from the repo. When Claude can read your thesis, it makes better decisions — because it understands what you’re building and why, not just what you asked it to do right now.
Create this file structure in your repo:
your-project/
├── README.md ← One-sentence description (public-facing)
├── CLAUDE.md ← Claude's instruction manual for your project
├── docs/
│ └── thesis.md ← Your product + business thesis (detailed)CLAUDE.md is a special file that Claude Code reads automatically. Put this in it:
# Project: [Your Project Name]
## Thesis
[Paste your one-sentence mechanism description here]
For full product thesis, read: docs/thesis.md
## Target User
[One sentence — specific person, specific pain]
## Version 1 Scope
[The 2-3 things it must do]
## Explicitly Out of Scope (V1)
[Your cut list]
## Current Week
[Update this each week: "Week 1 — Foundation"]Every time Claude reads this file, it has the context to help you make coherent decisions — not just execute individual requests.
Part 3: From Thesis to Backlog
Once your thesis is in the repo, Claude can do something powerful: read your thesis and generate your Linear backlog directly.
This is the next step in the workflow — and it’s where most builders save the most time. Instead of translating your roadmap into tasks by hand, you give Claude access to your repo and ask it to create your issues in Linear.
We cover the full setup in the Linear guide →. But the prompt looks like this:
Read my docs/thesis.md and CLAUDE.md. Based on my product thesis, scope, and a
4-week build sprint structure, create a Linear backlog with 3 concrete tasks per week.
Each task should be specific enough to act on without clarification — not "build the form"
but "create a 5-question HTML intake form with validation for required fields."
Create these directly in my Linear project: [project name]Claude reads your thesis. Claude writes your backlog. You start building.
One More Thing: The Business Thesis
Your product thesis answers “what am I building?” Your business thesis answers “why does this matter beyond the product?”
This one’s optional for the sprint — but powerful if you care about scaling what you build.
One more question: help me articulate the business thesis for this.
If this works as designed, what does it make possible for me (or for a team) in 6-12 months?
What does the product enable beyond the immediate use case?
Write 2-3 sentences — not a vision statement, a logical consequence of the product working.That goes at the bottom of docs/thesis.md. It’s the “why this matters” that you’ll come back to when the build gets hard.
What You Have When You’re Done
docs/thesis.md— your product and business thesis, written and pressure-testedCLAUDE.md— Claude’s instruction manual for your project- A clear understanding of what you’re building, who it’s for, and why it works
From here: GitHub setup, Linear backlog, VS Code + Claude Code, and 30 days of building.
Next: Setting up your GitHub repo for an AI project →
Alien Brain Trust builds AI education for working founders. The AI Builder Sprint is our 30-day live build program — Zero to Shipped, May 19 – June 13.
Comments