In one sentence
The best way to get startup ideas is to become the kind of person who naturally notices important unsolved problems: live at the edge of a rapidly changing field, build what seems missing, and let market scope emerge from real user demand.
Overview
Graham contrasts organic ideas with “made-up” ideas generated on command. Made-up ideas often sound plausible but solve problems nobody urgently has. Organic ideas arise from personal experience, technical capability, and exposure to a changing environment. The founder notices a gap, builds an initial version, learns from users, and discovers whether the niche has a path to broader adoption.
Core ideas
Look for problems, not startup ideas
Starting with the label “startup” encourages fictional, market-shaped concepts. Start instead with something broken, missing, tedious, or intolerable—especially a problem you personally experience. Personal involvement is evidence that the problem exists and helps you judge solutions.
Strong demand is often narrow and deep
A promising initial market may look like a well: few users, but intense need. Ask who wants the product immediately, even if version one is crude and made by an unknown two-person team. Narrowness is useful when it reflects depth of demand, not when the market is merely small.
Find a path out—but do not require certainty
A niche must plausibly expand into adjacent users or products, as Facebook moved from Harvard to other colleges and then the general public. But Graham stresses that founders often cannot see the full path initially; Airbnb’s broader market emerged gradually.
Become a prepared mind
Good ideas commonly result from an external stimulus meeting accumulated knowledge. Technical skill, deep use of a product, or immersion in a changing industry makes certain opportunities visible to you before they are obvious to others.
“Live in the future and build what’s missing”
The central operating principle is to move toward a frontier—often through programming, a new technical field, or an unfamiliar domain—and notice which tools or workflows do not yet exist. Building is preferable to merely speculating because use reveals the real problem.
Turn off premature filters
Do not initially reject an idea because it seems too small, unsexy, competitive, or unlikely to become a huge company. First establish whether users urgently need it. Apply scale and competition tests after finding a genuine beachhead.
Use adjacent domains to find overlooked problems
Combining expertise in one field with immersion in another can expose problems insiders have normalized and not solved with software. For a programmer, working in biology, restaurants, healthcare, or another non-software domain may be more fertile than studying entrepreneurship abstractly.
If necessary, use disciplined substitutes
When an idea is needed immediately, inspect your own unmet needs, complaints from previous jobs, and other people’s tedious work. Talk broadly, act like a consultant for a real user, and do not dismiss unglamorous or labor-intensive businesses. These methods imitate the evidence supplied naturally by organic discovery.
Practical takeaways
- Spend sustained time at the edge of a fast-changing field; a year of preparation may be more valuable than a weekend brainstorming session.
- Keep a background list of anomalies: missing tools, repeated workarounds, frustrating processes, and things people say should exist.
- For every idea, identify the first specific users and why they would use an imperfect first version now.
- Build the smallest useful version quickly and let user behavior—not your theory—test whether the problem is real.
- Prefer problems you understand well enough to judge. Expertise improves your filter; unfamiliar domains invite plausible but poorly grounded ideas.
- Explore intersections between your skills and another domain. Look especially for workflows still managed manually.
- Treat the initial idea as a starting question, not a fixed business plan. Expect the product, market, and business model to change.
- Do not confuse competition with impossibility. A competitor matters mainly when it has strong lock-in or when your product lacks an urgent advantage.
Caveats and counterpoints
- The essay is optimized for technology startups and especially software founders; its advice is less directly applicable to businesses constrained by regulation, capital intensity, distribution, or physical supply chains.
- “Build what seems interesting” can overemphasize founder curiosity. Interesting work still needs validation that users have sufficient urgency to adopt and pay.
- A narrow, enthusiastic user group is not automatically a large opportunity. The expansion path may be invisible or nonexistent, and the essay offers no reliable formula for distinguishing the two early.
- The claim that competitors rarely kill startups is context-dependent. Network effects, regulation, switching costs, incumbent distribution, and capital requirements can make competition decisive.
- Learning to program is presented as a broadly sufficient route to a frontier, reflecting the essay’s 2012 technology context rather than a universal requirement.
- The essay favors organic discovery over explicit ideation, but acknowledges that deliberate search can work when guided by domain expertise and unusually disciplined filtering.
Questions worth revisiting
- What recurring problem do I personally encounter that others have accepted as normal?
- Which users would feel the pain strongly enough to try an unfinished solution immediately?
- What manual workflow or workaround exists because the available software is inadequate?
- What field is changing quickly enough that today’s missing tool may become tomorrow’s infrastructure?
- If the first niche succeeds, what adjacent users, use cases, or products could follow naturally?
- Am I rejecting this idea because demand is weak—or because it seems unglamorous, difficult, or competitive?
- What would I learn by acting as a consultant for one real user before building a generalized product?
Return to this when…
Return to these notes when brainstorming feels forced, when evaluating a clever but unvalidated concept, or when choosing what to learn or build next. The key reminder is: do not manufacture a startup idea; cultivate the knowledge and proximity that make important gaps visible.