Paul Graham's framework, applied
The single most-cited essay on this topic is Paul Graham's How to Get Startup Ideas, published in 2012. The core line is short. Live in the future, then build what's missing. It sounds glib until you sit with what it actually requires of you.
The argument in one paragraph
Graham argues the best ideas come from noticing, not brainstorming. You put yourself at the technological frontier (a new platform, a new behavior, a new constraint), and you spot the gap that everyone else is too far behind to see. The mechanism is asymmetry of information. If you've spent two years inside a new domain, you can see real, daily friction that a generalist just can't.
The friction is the idea. You don't invent it. You write it down.
The friction-log method
The single highest-leverage habit in this framework is keeping a friction log. The mechanics are simple. The discipline is what's rare.
- 01Pick one frontier you already inhabit. Something you do every week that most people don't. If that is Claude Code, Cursor, or any frontier coding tool, the gap is fertile.
- 02Log every friction for two weeks.Every time you say ‘this is annoying’, ‘why doesn't this just’, or ‘I have to glue these two tools together’, write it down with the timestamp, the context, and the workaround you used.
- 03Cluster the log.Pain that recurs across three or more entries is a candidate. Pain you'd happily pay to make go away is a strong candidate. Pain that someone you know would also pay to make go away is a real opportunity.
- 04Pressure test the top three. For each, name the buyer, the price, the channel. Without all three, you have a thought experiment.
Worked example
A senior engineer using AI coding tools daily logs frictions for two weeks. The log shows three recurring pains: (1) prompt history is scattered across tools and unsearchable, (2) generated code lacks context about the team's style guide, (3) review of AI-generated PRs takes longer than human PRs because reviewers can't tell what was generated.
Pain (1) is annoying but no one pays for it today, so the buyer is unclear. Pain (3) is felt by reviewers who don't control budget - wrong buyer. Pain (2) is felt by engineering managers who already buy linters, style guides, and developer-productivity tools. Buyer named, price benchmarked, channel obvious. That's the candidate.
The friction with the most complaints isn't always the best idea. The friction with a paying buyer is.
When this framework fails
If you don't actually live anywhere unusual, this framework collapses. A generic knowledge worker hunting for the future in their day job will produce generic ideas. The framework rewards founders who already accidentally built asymmetric information by being in the right community three years ago. It punishes founders trying to manufacture that position from scratch.
If you can't point to your frontier with a straight face, pair this with Naval's specific-knowledge framework (which forces you to inventory what you already know) or Pieter Levels' tribe-and-ship approach (which lets the tribe define your frontier for you).
Run all five frameworks at once
Paul Graham is one lens. IdeaTwister is fifteen lenses applied in parallel to the same seed, each scored across five commercial dimensions. The Customer Segments, Pricing, Adjacent Niches, GTM Channels, and Defensibility lenses cover what PG's noticing-based method leaves out - namely, the buyer-price-channel triangle that turns a noticed friction into a buyable product.
Get IdeaTwister for $39FAQ
What is Paul Graham's framework for finding startup ideas?
+
Live in the future, then build what's missing. PG's argument is that the best ideas come from noticing, not brainstorming. You put yourself at the technological frontier - a new platform, a new behavior, a new constraint - and you spot the gap that everyone else is too far behind to see. The friction is the idea. You don't invent it. You write it down.
What does "live in the future" actually mean?
+
It means you spend significant time inside a domain most people haven't caught up with yet. AI agent workflows, on-device ML, a niche subculture, a frontier coding tool. The criterion isn't novelty for its own sake - it's that you have asymmetric information. You see the daily friction a generalist can't see, because the generalist isn't there yet.
How long should a friction log run before I look for patterns?
+
Two weeks of honest logging is enough to surface the recurring frustrations. Less than that and you're noticing one-off bugs. More than a month and you're stockpiling instead of acting. The point of the log is to make pain legible - once you can name three problems that recur weekly, you have your candidates.
Does Paul Graham's framework work for non-technical founders?
+
Partially. The "noticing" half works for anyone who lives somewhere unusual - a niche profession, a rare community, a frontier behavior. The "build it in a weekend" half assumes a technical co-founder or a no-code path. If you're non-technical and not on a frontier, pair this framework with Pieter Levels (tribe-and-ship) instead.
Why does cold brainstorming fail where this framework succeeds?
+
Cold brainstorming produces clever ideas with no buyer. PG's framework produces ideas with a buyer because the buyer is already complaining out loud - you, your colleagues, the community you live in. The friction log is just a mechanism for taking that ambient complaint and converting it into a written, datable, prioritizable list.