Ideation

Phase 0 of the playbook: finding a problem worth testing, choosing one idea in at most a week, and handing a one-page problem hypothesis plus 20 names to validation. It covers where good ideas come from, which ones to avoid, how to score and size them, the "why now?" test, and when to kill an idea. Attributed advice from Paul Graham and YC partners is summarized here and collected on the y-combinator sheet; Peter Thiel's "secrets" framing is on the peter-thiel sheet.

Entry criteria and timebox

Where good ideas come from

The canonical source is Paul Graham's essay How to Get Startup Ideas (opens in a new tab) (November 2012). Its opening line: "The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself."

Schlep blindness. Graham's separate essay Schlep Blindness (opens in a new tab) (January 2012) defines a schlep as "a tedious, unpleasant task" and argues that programmers' unconscious filters hid obvious opportunities for years: payments were painful for everyone, yet few tried to fix them until Stripe. His summary: "A company is defined by the schleps it will undertake." For a technical founder, the schleps are usually sales, compliance, integrations with ugly legacy systems, and operations. Those are exactly where the uncontested problems are.

Organic ideas dominate. YC partner Jared Friedman's Startup School talk "How to Get and Evaluate Startup Ideas" (2022) looked at where YC's most successful companies got their ideas and found that most (roughly 70% of the top 100, by his count) came organically rather than from deliberate brainstorming. He also names the common mistakes: a solution in search of a problem (SISP), tarpit ideas, jumping into the first idea without evaluating it, and waiting for a perfect idea.

For ambition, not for copying. Graham's Frighteningly Ambitious Startup Ideas (opens in a new tab) (March 2012) lists seven: a new search engine, replace email, replace universities, internet drama, the next Steve Jobs, bring back Moore's law, and ongoing diagnosis. Read it to calibrate how big ideas can be, not as a menu for a 6-week MVP.

Tarpit ideas and made-up ideas

YC partners Dalton Caldwell and Michael Seibel coined tarpit ideas in a 2022 video ("Avoid These Tempting Startup Ideas", followed by "Tarpit Ideas: The Sequel"). Paraphrasing: a tarpit idea is one that looks obviously good, seems easy, and appears unclaimed, but has been tried many times and fails for structural reasons that aren't visible from the outside. The idea seems open not because nobody noticed it, but because everyone who tried got stuck.

Tarpits are not forbidden. They require a specific answer to "why did the others fail, and why will we not?" If you can't write that answer in two sentences, move on.

Idea sources

Ideation techniques

For a TypeScript/Next.js/Postgres developer, the highest-yield sources are usually developer tooling you've wished for, and the internal tools at past jobs that non-engineers struggled with. Both give you founder–market fit and reachable users.

Evaluating ideas

Friedman's talk lists ten questions to ask of any idea (paraphrased):

He also names three counterintuitive signs of a good idea: it's hard to get started on, it's in a boring space, and it has existing competitors.

Scoring matrix

Score 1–5 on each criterion, multiply by the weight, sum. The matrix is a tool for making your reasoning explicit and comparing ideas consistently, not an oracle. Change the weights to reflect your goals (an indie business weights willingness to pay and founder–market fit more; a venture-scale bet weights market size more), but set them before scoring.

IDEA SCORING MATRIX                               Date: ______
Score each 1 (bad) - 5 (excellent). Weighted = score x weight.
 
Criterion                          Wt | Idea A | Idea B | Idea C
-----------------------------------------------------------------
Founder-market fit                  3 |        |        |
Problem acuteness                   3 |        |        |
Want it myself / know people who do 2 |        |        |
Can reach first 20 users this week  2 |        |        |
Evidence of willingness to pay      2 |        |        |
Would work on it for years          2 |        |        |
Why now (specific recent change)    1 |        |        |
Market size (bottom-up)             1 |        |        |
Competition shape (gap exists)      1 |        |        |
Low tarpit / made-up risk           1 |        |        |
-----------------------------------------------------------------
TOTAL (max 90)                     18 |        |        |
Kill any idea scoring 1 on acuteness or reachability.

Worked example: three ideas scored

A backend-leaning TypeScript/Postgres developer with six years at SaaS companies scores three ideas. The scores are illustrative judgments, not data.

• A. Migration safety checker: a CI check that flags risky Postgres schema migrations (locks, table rewrites, missing concurrent index builds) before they reach production, for small SaaS teams.
• B. AI meal planner: a consumer app that plans weekly meals and shopping lists.
• C. Clinic admin tool: scheduling and invoicing for independent physiotherapists.

Reading it:

• A wins on fit and reach. The founder is the user, knows 20 people with the problem, and can judge quality. Its weakness is acuteness: teams may see migration failures as rare. That becomes the riskiest assumption to test first.
• C is the dark horse. Higher acuteness and clearer willingness to pay (clinics already pay for software), but weak founder–market fit and access. Park it with a note; revisit if the founder can get 5 physio interviews quickly.
• B is killed. Consumer, low urgency, crowded, no founder insight, weak willingness to pay: the tarpit profile. A high "why now" score doesn't rescue it.
• Decision: take A into validation for 1–2 weeks with pre-set kill criteria; keep C as the fallback.

Problem, solution and market risk

Every idea carries three kinds of risk. Validation should attack them in this order, because each is cheaper to test than the next and a failure early saves all the later work.

Technical founders habitually test technical risk first because it is the fun one, and it is rarely the one that kills the company. If you are unsure whether the thing can be built, do a one-day spike during ideation and move on.

Founder–market fit

Founder–market fit is how well your specific knowledge, access and motivation match the market. It matters because in the first six weeks your only unfair advantages are insight and access.

Weak fit is not fatal, but it adds weeks. Fix it by partnering with a domain expert, or by spending the validation phase learning the domain before building anything.

Market sizing done bottom-up

Top-down TAM is theatre. "The global healthcare software market is $X billion; if we get 1%…" tells you nothing about whether anyone will buy your product, and every investor has heard it. Bottom-up sizing counts customers you could actually reach and multiplies by a price they would actually pay. It takes 30 minutes and it changes decisions.

Worked example (idea A)

All counts below are assumptions for illustration; in real use, each line needs a source or a stated method (for example, counting companies in a public directory, job postings mentioning the technology, or members of a community).

BOTTOM-UP SIZING: Postgres migration safety checker
 
Price assumption:   49 USD per team per month
                    = 588 USD per year  (all figures USD)
 
TAM  All software teams running Postgres in production
     Assume 200,000 teams worldwide        x 588 = 117.6M/yr
 
SAM  Teams of 2-20 engineers, English-speaking, deploying
     via CI, no dedicated DBA
     Assume 20,000 teams                   x 588 =  11.8M/yr
 
SOM  Share won in 3 years through content, dev communities,
     GitHub marketplace: assume 1% of SAM = 200 teams
                                           x 588 = 117,600/yr
 
Reading: a decent indie business, not a venture-scale one on
its own. Decide which one you want BEFORE validation. If
venture scale: test whether the price can be 5-10x higher for
larger teams, or whether it expands into a broader product.

What bottom-up sizing tells you that top-down doesn't:

• Whether you can name the customers. If you can't say how you'd count them, you can't say how you'd reach them.
• Whether the price makes sense. 200 customers at $588 a year is a salary, not a company; 200 customers at $12,000 a year is a company.
• Which channel you'd use. The counting method (a directory, a community, a marketplace) is usually the first acquisition channel.

Competition analysis

Graham, in the same essay: "better a good idea with competitors than a bad one without." And: "Worrying that you're late is one of the signs of a good idea." He argues that startups are rarely killed by competitors, and that a crowded market is fine if you have a thesis about what everyone in it is overlooking.

COMPETITION SCAN (45 min per idea)
Alternative        | Who uses it | Price | Loved for | Hated for
-------------------|-------------|-------|-----------|----------
                   |             |       |           |
Our insight: what are they all overlooking? ____________________
Why they can't / won't copy it quickly:   ____________________

Sources: search engines, app and extension marketplaces, G2/Capterra-style review sites (sort by the 2- and 3-star reviews), Reddit and Hacker News threads, dead startups on the same idea, job postings mentioning the workaround.

The "why now?" test

Sequoia's guide Writing a Business Plan (opens in a new tab) includes a "Why now?" section: "The best companies almost always have a clear why now? Nature hates a vacuum—so why hasn't your solution been built before now?"

If you can't name a specific change, the answer to "why hasn't this been built?" may be "it has, and it failed", which sends you back to the tarpit check.

Writing the problem hypothesis

The Phase 0 artifact. One page, written as hypotheses to be tested, not facts.

PROBLEM HYPOTHESIS                     Idea: ________  Date: ____
 
1. PROBLEM STATEMENT
   [Customer segment] struggles to [job / outcome] because
   [obstacle]. Today they [current workaround], which costs
   them [time / money / risk] every [frequency].
 
2. TARGET CUSTOMER (one segment)
   - Who (role, company size, context):
   - Early adopter: people who ALREADY try to solve it, e.g.
     built a script, pay for a bad tool, complain publicly
   - Where they gather (communities, events, directories):
 
3. CURRENT ALTERNATIVES
   - Direct tools:
   - Workarounds (spreadsheets, scripts, people):
   - Do nothing - and what that costs:
 
4. WHY NOW
   - Specific recent change:
 
5. RISKIEST ASSUMPTIONS (ranked: most lethal x least evidence)
   1.
   2.
   3.
   For each: what would I have to see to believe it's false?
 
6. BOTTOM-UP SIZE (one line each): TAM / SAM / SOM + method
 
7. KILL / CONTINUE CRITERIA FOR VALIDATION (set now)
   - Continue if: e.g. >= half of 10-15 interviewees raise the
     problem unprompted AND >= 3 give a real commitment
   - Kill if:
   - Timebox: validation ends on (date):
 
8. PEOPLE TO TALK TO (20 names, not "people like")
   Name | How I know them / how I'll reach them | Booked?

A good problem statement, filled in for idea A:

Engineers at 2–20 person SaaS companies struggle to ship Postgres schema changes safely because nobody on the team is a database specialist. Today they rely on a senior engineer eyeballing migrations in review, which costs a few hours a week and, a few times a year, a production incident from a table lock.

Bad versions, and what's wrong with them:

When to kill an idea

Killing early is a skill, not a failure. Kill (or park) an idea during ideation if any of these is true:

Parking is fine: keep a "parked ideas" file with the score and the reason. Many good companies come from the second or third idea, informed by what the first one taught you.

Friction points in ideation

Exit criteria and handoff to Phase 1

PHASE 0 EXIT CHECKLIST
[ ] Idea list (30+) and scoring matrix done; weights set first
[ ] One idea chosen; others parked with scores and reasons
[ ] Tarpit and made-up checks passed (or answered in writing)
[ ] Problem hypothesis one-pager complete (template above)
[ ] Riskiest assumptions ranked; top 3 named
[ ] Bottom-up TAM/SAM/SOM with a counting method
[ ] Competition scan, including workarounds and "do nothing"
[ ] Specific "why now"
[ ] Kill/continue criteria for validation written, with numbers
[ ] 20 named people to talk to; >= 5 interviews booked
[ ] Landing page v0 live on the walking skeleton (optional
    but recommended; see the playbook day plan)

Handoff artifact: the problem hypothesis one-pager and the list of 20 people. Validation starts by taking the riskiest assumptions from section 5 and turning them into interview questions and smoke tests. If validation kills the idea, return here with the parked list and what you learned.

References

• Paul Graham, How to Get Startup Ideas (opens in a new tab) (November 2012): organic vs made-up ideas, "notice", live in the future, wells, schlep and unsexy filters, competition
• Paul Graham, Schlep Blindness (opens in a new tab) (January 2012): the Stripe example; "A company is defined by the schleps it will undertake"
• Paul Graham, Frighteningly Ambitious Startup Ideas (opens in a new tab) (March 2012): seven very large idea spaces
• Jared Friedman, How to Get and Evaluate Startup Ideas (opens in a new tab) (Y Combinator Startup School, 2022): ten evaluation questions, common mistakes, recipes for ideas; see also the YC Startup Library (opens in a new tab)
• Dalton Caldwell and Michael Seibel, "Avoid These Tempting Startup Ideas" (Y Combinator, 2022) and Tarpit Ideas: The Sequel (opens in a new tab): tarpit ideas
• Kevin Hale, How to Evaluate Startup Ideas (opens in a new tab) (Y Combinator Startup School): an earlier YC lecture on evaluating ideas
• Sequoia Capital, Writing a Business Plan (opens in a new tab): the "Why now?" section
• Peter Thiel with Blake Masters, Zero to One (Crown Business, 2014): secrets and contrarian insight; summarized on the peter-thiel sheet
• Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan, Competing Against Luck (Harper Business, 2016): Jobs-to-be-Done framing
• Ash Maurya, Running Lean (O'Reilly, 2012) and the Lean Canvas (opens in a new tab): problem, segment, existing alternatives, riskiest assumptions