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.
Live in the future & build what is missing
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.
The friction-log method
The single highest-leverage habit is keeping a friction log. Log every minor annoyance or hack daily, then cluster them to find patterns.
Scattered Prompt History
Prompt history is scattered across multiple browser sessions and is completely unsearchable.
Style-Guide Mismatch
Generated code lacks context about the team's internal conventions and style guides.
Slow PR Reviews
Review of AI-generated Pull Requests takes longer than human PRs because reviewers cannot tell what was generated.
Pick a Frontier
Choose a frontier you already inhabit daily (e.g. AI-assisted coding, modular platform infrastructure, modern data flows).
Log Every Friction
Every time you say “this is annoying” or create a custom helper tool, write down the timestamp, context, and current workaround.
Cluster and Filter
Group the log entries. Friction that recurs multiple times weekly is a strong candidate, especially if peers also face it.
Pressure Test
Filter candidates for the buyer, the price, and the distribution channel. Without all three, you have a science project, not a business.
Worked example
Here is how a real-world friction logs filters down to a commercially viable SaaS product.
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.
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 angle. IdeaTwister runs fifteen angles in parallel against your seed, each scored across five commercial dimensions (segments, pricing, channels, defensibility, and unbundling).
Find My Best Startup OpportunityFAQ
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.