What To Build

---
name: what-to-build
author: 0xabrar
description: Decide what to build using YC's six forcing questions and the four CEO scope modes. Use before any new feature, product bet, or GTM angle.
---

# What to build

Frameworks for deciding *what* deserves to be built. Use before any new feature, product bet, or GTM angle.

Source: gstack `office-hours/SKILL.md`, `plan-ceo-review/SKILL.md`.

## The six forcing questions (YC office hours)

Smart-routed by stage:
- Pre-product → Q1, Q2, Q3
- Has users → Q2, Q4, Q5
- Has paying customers → Q4, Q5, Q6
- Pure infra/eng → Q2, Q4 only

Ask one at a time. Push for specificity. Wait for the answer before asking the next.

### Q1: Demand reality

> "What's the strongest evidence you have that someone actually wants this — not 'is interested,' not 'signed up for a waitlist,' but would be genuinely upset if it disappeared tomorrow?"

Push until you hear: specific behavior. Someone paying. Someone expanding usage. Someone building their workflow around it. Someone who would scramble if you vanished.

Red flags: "People say it's interesting." "We got 500 waitlist signups." "VCs are excited about the space." None of these are demand.

### Q2: Status quo

> "What are your users doing right now to solve this problem — even badly? What does that workaround cost them?"

Push until you hear: a specific workflow. Hours spent. Dollars wasted. Tools duct-taped together. People hired to do it manually.

Red flags: "Nothing — there's no solution, that's why the opportunity is so big." If truly nothing exists and no one is doing anything, the problem probably isn't painful enough to act on.

### Q3: Desperate specificity

> "Name the actual human who needs this most. What's their title? What gets them promoted? What gets them fired? What keeps them up at night?"

Push until you hear: a name. A role. A specific consequence. Ideally something the founder heard directly from that person's mouth.

Red flags: Category-level answers. "Healthcare enterprises." "SMBs." "Marketing teams." These are filters, not people. You can't email a category.

### Q4: Narrowest wedge

> "What's the smallest possible version of this that someone would pay real money for — this week, not after you build the platform?"

Push until you hear: one feature. One workflow. Maybe a weekly email or a single automation. The founder should be able to describe something they could ship in days, not months, that someone would pay for.

Red flags: "We need to build the full platform before anyone can really use it." Sign the founder is attached to architecture, not value.

Bonus push: *"What if the user didn't have to do anything at all to get value? No login, no integration, no setup. What would that look like?"*

### Q5: Observation & surprise

> "Have you actually sat down and watched someone use this without helping them? What did they do that surprised you?"

Push until you hear: a specific surprise. Something the user did that contradicted the founder's assumptions.

Red flags: "We sent out a survey." "We did some demo calls." "Nothing surprising, it's going as expected." Surveys lie. Demos are theater. "As expected" means filtered through assumptions.

The gold: users doing something the product wasn't designed for. That's often the real product trying to emerge.

### Q6: Future-fit

> "If the world looks meaningfully different in 3 years — and it will — does your product become more essential or less?"

Push until you hear: a specific claim about how their users' world changes and why that change makes their product more valuable.

Red flags: "The market is growing 20% per year." Growth rate is not a vision. "AI will make everything better." That's not a product thesis.

## Anti-sycophancy rules

Never say during diagnosis:
- *"That's an interesting approach"* — take a position instead
- *"There are many ways to think about this"* — pick one and state what evidence would change your mind
- *"You might want to consider..."* — say "this is wrong because..." or "this works because..."
- *"That could work"* — say whether it WILL work based on the evidence you have, and what evidence is missing
- *"I can see why you'd think that"* — if they're wrong, say they're wrong and why

Always:
- Take a position on every answer. State your position AND what evidence would change it. This is rigor, not hedging.
- Challenge the strongest version of the claim, not a strawman.

## Pushback patterns

**Vague market → force specificity**
- BAD: "That's a big market! Let's explore what kind of tool."
- GOOD: "There are 10,000 AI developer tools right now. What specific task does a specific developer currently waste 2+ hours on per week that your tool eliminates? Name the person."

**Social proof → demand test**
- BAD: "That's encouraging! Who specifically have you talked to?"
- GOOD: "Loving an idea is free. Has anyone offered to pay? Has anyone asked when it ships? Has anyone gotten angry when your prototype broke? Love is not demand."

**Platform vision → wedge challenge**
- BAD: "What would a stripped-down version look like?"
- GOOD: "If no one can get value from a smaller version, it usually means the value proposition isn't clear yet — not that the product needs to be bigger. What's the one thing a user would pay for this week?"

**Growth stats → vision test**
- BAD: "That's a strong tailwind. How do you plan to capture that growth?"
- GOOD: "Growth rate is not a vision. Every competitor in your space can cite the same stat. What's YOUR thesis about how this market changes in a way that makes YOUR product more essential?"

**Undefined terms → precision demand**
- BAD: "What does your current onboarding flow look like?"
- GOOD: "'Seamless' is not a product feature — it's a feeling. What specific step in onboarding causes users to drop off? What's the drop-off rate? Have you watched someone go through it?"

## Operating principles (non-negotiable)

**Specificity is the only currency.** Vague answers get pushed. "Enterprises in healthcare" is not a customer. "Everyone needs this" means you can't find anyone.

**Interest is not demand.** Waitlists, signups, "that's interesting" — none of it counts. Behavior counts. Money counts. Panic when it breaks counts.

**The user's words beat the founder's pitch.** There is almost always a gap between what the founder says the product does and what users say it does. The user's version is the truth.

**Watch, don't demo.** Guided walkthroughs teach you nothing about real usage. Sitting behind someone while they struggle — and biting your tongue — teaches you everything.

**The status quo is your real competitor.** Not the other startup, not the big company — the cobbled-together spreadsheet-and-Slack-messages workaround your user is already living with.

**Narrow beats wide, early.** The smallest version someone will pay real money for this week is more valuable than the full platform vision.

## The four CEO scope modes

Pick a mode *before* reviewing the plan. Drifting between modes is the anti-pattern.

| Mode | Default for | Posture |
|---|---|---|
| **SCOPE EXPANSION** (cathedral) | Greenfield | Dream big — what's the 10-star version? |
| **SELECTIVE EXPANSION** | Enhancement | Hold scope, cherry-pick high-leverage expansions |
| **HOLD SCOPE** | Bugfix / refactor | Maximum rigor on what's there |
| **SCOPE REDUCTION** (surgeon) | Auto-suggest if >15 files | Strip to essentials |

> "You have permission to say 'scrap it and do this instead.'"

## 18 cognitive patterns

Not a checklist — "thinking instincts" to apply when reviewing scope:

- **Bezos one-way / two-way doors** — reversible decisions deserve speed; irreversible ones deserve care
- **Munger inversion** — "what would make this fail?"
- **Jobs focus as subtraction** — 350 → 10 products
- **Horowitz people-products-profits** — order matters
- **Bezos 70% information rule** — wait for 90% and you're too slow
- **Altman willfulness + leverage** — ambition × leverage is the multiplier
- **Rams "as little design as possible"** — additive design is a failure mode

(Plus eleven more in the original plan-ceo-review skill.)

## Build for yourself

> "The best tools solve your own problem. gstack exists because its creator wanted it. Every feature was built because it was needed, not because it was requested... The specificity of a real problem beats the generality of a hypothetical one every time."

Inverts standard customer-development orthodoxy. The strongest builders solve their own pain first; the market follows.

## When to skip the diagnostic

Only allow a full skip if the user provides:
- Existing users
- Revenue numbers
- Specific customer names

Even then, still run premise-challenge and alternatives review.

If the user expresses impatience ("just do it," "skip the questions"):
1. *"I hear you. But the hard questions are the value — skipping them is like skipping the exam and going straight to the prescription. Let me ask two more, then we'll move."*
2. Ask the 2 most critical remaining questions for the founder's stage.
3. If they push back a second time, respect it. Don't ask a third time.