Latent Demand: What It Is and How to Find It

Latent demand is demand that exists but has nowhere to go. The want is real, and the market has not met it yet, usually because the thing is unavailable, unaffordable, or unknown to the person who wants it. That is the dictionary definition, and it is accurate. It is also hard to act on, because it tells you what latent demand is without telling you where to find one.

Boris Cherny, the creator of Claude Code at Anthropic, has the operational version. On Y Combinator's Lightcone podcast he called latent demand "the single biggest idea in product," and then made it findable:

people will only do a thing that they already do. You can't get people to do a new thing.

That one sentence changes the search. You are not hunting for an unserved want floating somewhere in the market. You are hunting for something people are already doing, by hand, badly, at a cost they are quietly absorbing. The demand is latent because the cost is being paid in time rather than money, so it never shows up as a purchase.

Cherny is a useful person to take this from. He joined Anthropic in September 2024 after several years at Meta as a principal software engineer, wrote O'Reilly's Programming TypeScript, and turned a throwaway terminal script into Claude Code. His claim on the Lightcone is that after the first CLI, essentially every part of that product came from latent demand rather than from a roadmap.

What latent demand means, and what it is not

Latent demand is one of several demand states, and most product mistakes come from confusing it with a neighbor. The distinction that matters is what you can observe.

Demand state	What you observe	What it tells you
Latent	People doing the job by hand, with workarounds, at their own cost	A real want exists, and no product has absorbed it yet
Stated	People asking for a feature, in surveys, calls, or tickets	What people believe they want, which may not survive contact with a price
Effective	People buying an existing product at the going price	Demand already served, so you are entering a competition
No demand	Nothing, until you explain the idea	You are asking for a new habit, which is the expensive bet

Three things keep demand latent, and they map to three different fixes:

• It is unavailable. Nothing on the market does the job, so people improvise. This is the founder's opening, and it is where Claude Code's memory file came from.
• It is unaffordable. Something does the job, but not at a price this buyer can pay, so they substitute their own labor. Falling costs, including the cost of intelligence, convert this kind of latent demand into a market.
• It is unknown. A product exists and would work, but the buyer has never heard of it. That is a distribution problem wearing a product costume, and building more product will not fix it.

The idea is not confined to software. Forrester's analysts make the same point about buyers in ordinary markets in Demystifying Latent Demand: the want is real and measurable before any purchase happens. A concrete non-software version: before food delivery apps, people called restaurants, wrote the order on paper, and drove to collect it. Nobody described that as demand for a marketplace. It was demand for dinner, expressed as forty minutes of unpaid labor. The labor was the signal.

That is the practical test. Latent demand is not a gap you argue for on a slide. It is a cost someone is already paying, in a form you can watch.

What Cherny's rule actually says

Cherny's version has two halves, and founders usually only hear the first.

The first half is the permission: "If people are trying to do a thing and you make it easier, that's a good idea." Take an existing job, remove the friction, ship.

The second half is the constraint, and it is where most product plans die. If people are doing something and you try to get them to do a different thing instead, they will not do it. His conclusion is deliberately unglamorous: "you just have to make the thing that they're trying to do easier."

Notice what this rules out. It does not rule out ambitious technology. It rules out asking for a new habit. You can put a frontier model, a new runtime, and three years of research behind the product, as long as the user's side of the interaction is a job they were already performing. The novelty goes in the engine, not in the behavior you require.

The same rule also points at where the openings are right now. Cherny describes the current moment as an "insane feeling of product overhang," meaning the models can already do far more than shipped products let people do with them. Product overhang plus latent demand is a specific instruction: the models got good at things people are already doing manually, and almost nobody has connected the two yet.

Two features that came straight out of latent demand

Two Claude Code features show the rule working end to end.

CLAUDE.md. Before there was a memory file, Anthropic engineers were doing the work by hand. In Cherny's account, "one thing that we saw is people started writing these markdown files for themselves and then having the model read that markdown file." The signal was not a request, it was the workaround itself: engineers were already maintaining the memory and pasting it in every session. The product move was to name the file, load it automatically, and stop charging people the manual step. Much of what is now taught as context engineering for AI agents starts from that same observation.

Plan mode. Same shape. Users were prompting the model to think an approach through without writing code yet. Some did it casually, some wrote elaborate specs, but Cherny says "the common dimension was do a thing without coding yet." He found it on a Sunday night reading GitHub issues and an internal Slack feedback channel, and by his account "I just wrote this thing in like 30 minutes" and shipped it that night.

The detail that matters most is how small the feature is. Plan mode, Cherny says, is mostly a prompt change: "it adds one sentence to the prompt that's like please don't code."

The value was never in the engineering. It was in noticing that a lot of people were typing a variation of the same sentence, and had never been given a button for it. That is what latent demand looks like from the inside: a cheap fix to an expensive habit.

Where latent demand shows up in your product

Cherny names three places to look, and none of them is a survey.

1. What users build for themselves around your product. Scripts, spreadsheets, saved prompts, templates, naming conventions, copy-paste rituals. Every one of those is a user paying for a missing feature with their own time. The markdown files that became CLAUDE.md were exactly this. If your users have a shared doc of tricks, read it as a product spec.

2. What they argue about in public. Issues, support tickets, your community. Cherny's example here is instructive because it cuts against him. He tried removing verbose bash output internally and the reaction was immediate: "everyone just revolted." Later the team compressed file reads and searches, dogfooded it for a month, shipped it, and GitHub users pushed back. They added a verbose mode, and people still were not happy. His read on that: "my favorite thing in the world is just hearing people's feedback and hearing how they actually want to use it."

The signal in a complaint is rarely the fix people propose. It is the workflow the complaint reveals they already have.

3. Watching people work. Cherny describes the lowest-tech method available: "I'll just walk around the office" and stand behind colleagues to see how they actually use the tool. Watching beats asking, because a workaround is precisely the thing nobody thinks to mention. It is the same instinct behind Paul Graham's do things that don't scale, applied to discovery rather than sales.

One addition from the security side, since this is where founders get surprised later. When you watch users work around a gap, watch what data moves. Somebody pasting production credentials, customer records, or a whole contract into a chat window is telling you two things at once: a feature is missing, and a control is missing. Ship the feature and the control together, because the workaround you productize is also the data path you are now responsible for.

Why TypeScript is the clearest example of latent demand

Cherny spent years in TypeScript before Anthropic, and he draws the parallel himself.

TypeScript is a typed superset of JavaScript: existing JavaScript stays valid, and types are added on top. That design choice is the whole story. The team, led on language design by Anders Hejlsberg, had to get types into large untyped codebases without asking developers to change how they wrote code. As Cherny puts it: "They're going to write code the way they're going to write it."

So the type system was built around existing practice, including patterns a purist would call unsafe. His summary of why the design ended up with features nobody in academia had proposed: "It purely came out of the practice of observing people and seeing how JavaScript programmers want to write code."

The lesson generalizes past languages. The winning design is often the one that absorbs the mess of how people actually work, rather than the one that requires them to work correctly first. Latent demand means designing for how people already work, not for how they should work.

The counter-rule: what to build is not how much

Latent demand tells you which job to attack. It does not tell you how much product to put around it, and getting that second question wrong is expensive in AI specifically.

Cherny's team keeps a framed copy of Rich Sutton's The Bitter Lesson on the wall, and the operating principle he draws from it is short: "never bet against the model." Every piece of code that is not the model is scaffolding. Cherny's own estimate is that scaffolding lifts performance in a specific domain by 10 to 20 percent, and then the next model release erases the gain. So each feature is a trade: engineering effort now for a capability the model will probably have on its own in a few months. Claude Code's own codebase turns over fast for exactly this reason, and the team deletes scaffolding once the model no longer needs it.

Put the two rules together and you get a usable filter:

• Latent demand says: anchor to a job people already do by hand.
• The bitter lesson says: solve it with the least scaffolding that works, and assume the scaffolding is temporary.

The features that survive both tests are the ones that remove a step from the human's workflow rather than compensate for the model's weakness. This is the practical form of building for the next AI model instead of this one: the user's habit is stable, the model's limitations are not, so put your durable investment on the habit side. That split between what is durable and what the model will eat is the through line of the AI for startups pillar.

Cherny extends the same logic to developer tools with a line worth stealing whole: "The way I would frame it is think about the thing that the model wants to do and figure out how do you make that easier." Latent demand, pointed at a non-human user.

Four ways founders misread latent demand

Treating a request as latent demand. A request is what someone says. Latent demand is what someone does. The strongest signal is not a person asking for a feature, it is a person doing extra work every day and never mentioning it. Requests are worth reading, but weight them by the behavior behind them, not by how loudly they arrive. That weighting is the hard half of product discovery, which is the job AI for product managers covers in full.

Waiting for the behavior to be big. Cherny's evidence was a handful of engineers on one floor and a scattering of GitHub issues. Latent demand looks small by definition, because the cost of the workaround keeps most people from attempting it at all. The people doing it anyway are the ones who care most, which is also how picking an ideal customer profile usually starts.

Confusing easier with broader. Making the existing job easier is the rule. Adding four adjacent jobs is not the same move, and it usually resets you to asking for new behavior. Ship the narrow version first and let usage tell you where to widen.

Assuming you need users first. If you have none, you are still allowed to run the rule. Watch the adjacent behavior: what the target user does today with a spreadsheet, a contractor, or a chat window. Cherny's first prototype came from him trying to learn an API, and the first outside signal came from an engineer sitting across from him who was already using the two-day-old dogfood build to write real code. When Cherny objected that "this thing isn't ready. It's just a prototype," the colleague kept using it anyway. That is the signal, at a sample size of one.

What to do this week

1. List every workaround you know about. Open your support inbox, your issues, and your community, and write down each thing users are doing by hand that your product could absorb. Do not filter yet.
2. Watch three sessions. Screen share, no questions, no prompting. You are looking for the moment someone leaves your product to get something done.
3. Find the repeated sentence. In your logs, prompts, or tickets, find the phrasing users type over and over. Plan mode was a sentence before it was a feature.
4. Pick the smallest one and ship it. Rank your list by how often the behavior happens and how little code it takes to absorb. Start with the cheapest item on the list, not the most impressive.
5. Audit your scaffolding. List the parts of your product that exist only because the model is not good enough yet. Put a review date on each one and delete the ones the model has caught up to.
6. Check the data path. For every workaround you productize, write down what data now flows through your system that did not before, and who is allowed to see it.

If you want the full operating system around this, from product selection through shipping with agents, that is what I teach in AI Operating System for Startups.

Sources

• Inside Claude Code With Its Creator Boris Cherny, Y Combinator's Lightcone podcast, the interview this article distills. All quotations attributed to Cherny are from this episode.
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next, Sequoia Capital, supporting source on product overhang.
• Background on Boris Cherny: his LinkedIn profile (creator and head of Claude Code at Anthropic; joined September 2024; previously principal software engineer at Meta; author of Programming TypeScript) and Gergely Orosz's Building Claude Code with Boris Cherny in The Pragmatic Engineer.
• Definition of latent demand: Cambridge Dictionary and Forrester's Demystifying Latent Demand.
• The Bitter Lesson by Rich Sutton, the essay framed on the wall of the Claude Code team's area. Sutton's own site is intermittently unavailable; his Wikipedia entry covers the same background.
• TypeScript design background: the TypeScript handbook on its typed-superset design and Anders Hejlsberg on Wikipedia.
• Do Things that Don't Scale by Paul Graham, on getting close enough to users to see what they actually do.