Right now, a corner of founder Twitter is genuinely frustrated about Claude’s context window. People are building Obsidian vaults, writing context-engineering primers, charging for prompt-management tools.
But by next year (or maybe next month), when a new model with higher token window and better memory ships, most of that work will be obsolete. Not because the frustration wasn’t real but because the frustration was temporary.
Most founders often confuse the two, and it’s the biggest filter between people who build for two years and people who build for ten.
This was one of the main mistakes I made. Which is why I know that the question you should ask isn’t whether a problem exists. It’s whether the problem has gravity.
Jeff Bezos has a question he asks alongside the famous “what will change in 10 years”: what won’t change? “You can build a business strategy around the things that are stable in time… the energy we put into those things will still be paying off dividends for our customers 10 years from now.” Lower prices. Faster delivery. Wider selection. Those aren’t trends. They’re gravity. Your job as a founder isn’t to find problems. It’s to find problems that have gravity.
Here are five questions to find out if yours does.
Q1: If the most obvious workaround gets 10x better, does your problem disappear?
This is the platform-shift test. If your product exists because a current tool is inadequate, you might be building a patch, not a company.
In 2014, dozens of companies were building Gmail plugins like Boomerang, Mixmax, and Clearbit to fix specific email annoyances. Rahul Vohra looked at the same landscape and asked a different question. A global workforce of 1 billion people spending 3 hours a day on email equates to 1 trillion hours of lost productivity a year. If Gmail shipped 10x better threading, search, and scheduling tomorrow, those plugins die overnight, but the 3-hours-a-day pattern doesn’t budge, because that pattern isn’t caused by Gmail being bad. It’s caused by email being slow to process at human speed. So Vohra didn’t build on top of Gmail. He rebuilt the client from scratch around keyboard-first speed, every action in a few keystrokes, no mouse, sub-100ms response time. The plugin builders were betting Gmail would stay annoying. Vohra was betting that even a perfect Gmail would still be too slow for the people whose job is to send and read emails. Eleven years later, those plugins are mostly dead but Superhuman is still operating.
How to use it: Write down what would have to be true for your problem to vanish. If the answer is “a model update” or “a new feature from a Big Tech incumbent shipping next quarter,” that’s your signal.
Q2: Is the pain caused by technology limits or by human behavior?
Technology limits get patched. Human behavior doesn’t. Meetings. Email. Procrastination. Decision fatigue. Comparison-shopping. None of these have a software update.
When Sarah Pinner was building Beni, she found something most product builders would have missed. 93% of shoppers were open to buying secondhand, but only about half actually did. The gap wasn’t caused by a lack of resale inventory or bad search. It was behavioral. People wanted the outcome (cheaper, more sustainable) but not the behavior change (rummaging across 20 resale sites). That’s the intention-action gap, and no platform update closes it. Beni doesn’t try to teach people to shop differently. It meets them where they already shop and surfaces secondhand alternatives inline.
How to use it: Ask, “Will a 25-year-old in 2035 still have this problem?” If yes, you’re building against behavior. If no, you’re patching a temporary tooling gap.
Q3: Who is structurally blocked from solving this, and why?
Every durable problem has an incumbent who should obviously be solving it but cannot. If you can’t name who is blocked and why, the problem probably isn’t deep enough, or it’s about to be solved for free by someone with more resources than you.
GitHub Copilot existed before Cursor did. Four MIT grads still decided to fork VS Code, because they’d identified exactly who was losing under the existing setup: developers who got autocomplete but couldn’t get AI to do anything more ambitious. Copilot was constrained by VS Code’s extension API: autocomplete, inline suggestions, a chat panel, and not much else. Microsoft had no incentive to break that ceiling because Copilot was a feature inside their stack, not a product competing against it. Worse, if Microsoft rewrote VS Code’s core to let Copilot do agentic multi-file edits, every other extension in their ecosystem would break, and the extension marketplace was the moat that made VS Code win in the first place. They couldn’t follow Cursor without burning down the thing that made them dominant. Cursor wasn’t smarter than Microsoft. Cursor was unblocked. They reached $1B ARR in 24 months, the fastest B2B SaaS company in history.
How to use it: Name the incumbent who should obviously be solving this. Then write one sentence on what they’d have to give up to do it. If the answer is “nothing, they just haven’t gotten to it yet,” you don’t have a moat. If the answer is “their core revenue model,” “their distribution,” or “the thing that made them dominant in the first place,” you have a structural opening.
Q4: Has this problem existed for at least 10 years in some form?
New problems are often features in disguise. Old problems with new constraints are where the real opportunity tends to live.
Quibi is the cleanest case study. Jeffrey Katzenberg and Meg Whitman raised $1.75 billion (yes you read that number right) on the thesis that people wanted premium short-form video for their commute.
They were wrong.
Not because the market was too small, but because the problem wasn’t real. Social media and gaming had already solved the “in-between moments” problem, better and for free. The frustration Quibi was trying to address was a hypothesis that lived inside one team’s worldview, not a behavior anyone was actually suffering through. Six months after launch, it was done.
How to use it: Name one company that tried to solve this before 2015 and failed. Why did they fail? If the answer is “the technology wasn’t ready yet,” the problem might have gravity. If the answer is “people didn’t actually want it,” you’re Quibi.
Q5: What is the customer’s current ugly workaround?
The strongest signal that a problem is durable: people are already paying for it in time, money, or duct-taped solutions. The deeper the workaround, the more durable the underlying need.
When Phoebe Gates and Sophia Kianni were researching Phia, they didn’t hear “I want an AI shopping app.” They saw the workaround: tabs open across a dozen sites, comparison spreadsheets, screenshots of Instagram posts of items people couldn’t identify, hours lost on something that should take a minute. That stack of manual effort was the demand signal, not what users said they wanted. After launch, Phia hit the top 25 in the App Store within 48 hours and crossed 300,000 downloads in two months. People were already willing to spend hours on the manual version of the outcome; compressing it into one tap was the company.
How to use it: In your next five customer conversations, don’t ask what people want. Ask what they did last week to deal with the problem. If they spent more than 15 minutes on it, you’ve found something worth building toward.
Here's the meta-test
If your honest answer to "why now?" is "because [recent platform/model/trend] just made this possible," ask one more question: did people want this before the tech existed?
Instagram worked because people wanted instant photo sharing for decades before smartphones made it possible. AI-generated bedtime stories don't, because nobody was lying awake in 2015 wishing they could generate one.
If the want predates the capability, you have gravity. If the capability invented the want, you have a feature wave.
Take what you're working on and run it through these five questions. Two failures means you might be building a patch. Three means the customer discovery work isn't done yet.
This essay was written using a tool I’ve been quietly building. It’s for solo founders who want the leverage of AI agents without having to build one from scratch. I’m running a private beta. If you want in, message me.
Really liked the "problem has gravity" framing. And also, the Cursor vs Copilot part stuck with me - "they weren't smarter than Microsoft, they were unblocked." made me think about a few things I'm working on differently.
Thanks for writing this