Building for Demand That Already Exists

The product principle behind Claude Code, Facebook Marketplace, and the App Store

Most lasting products weren’t dreamed up in a vacuum. They were stumbled upon: found in the gap between what users need and the crude workarounds they’ve already built to get it.

Users misusing your product, building elaborate hacks on top of tools that were never designed for the job, bending features in directions you didn’t expect — these aren’t edge cases. They’re the strongest signal you have about what to build next.

Boris Cherny, the creator of Claude Code at Anthropic and a former principal engineer at Meta, argues on Lenny’s Podcast that latent demand is the single most important principle in product development. He's right.

---

1. Latent Demand

Here’s the thing: most product teams operate as if their job is to create demand. They brainstorm new behaviours, design new workflows, and try to convince users to do something they’ve never done before. The implicit assumption is that innovation means invention.

Latent demand flips this entirely. It starts with a simple observation: the demand you’re looking for probably already exists. Users are already trying to do the thing. They’re just doing it badly, inefficiently, or by misusing tools that were never designed for the purpose.

Cherny’s definition is precise — latent demand means identifying what users are already trying to do, often by repurposing existing tools in ways nobody intended, and building a product that makes that existing behaviour frictionless.

This is not the same as user research. Discovery interviews ask users what they want — latent demand ignores what they say and watches what they do. People struggle to describe what they need in the abstract, but they're remarkably honest with their behaviour.

The evidence isn't theoretical. eBay made the classified ad scalable. Craigslist moved bulletin boards online. Airbnb productised informal home-stays that travellers had been arranging for decades. None of them invented demand. All of them built a better surface for behaviour that already existed.

The strongest product signals come from what users are already doing despite your product, not because of it.

---

2. Hackable Surfaces

So if latent demand is everywhere, how does it reveal itself? Cherny's second principle is the mechanism: build products that are open-ended enough for users to adapt for unintended use cases. He calls them "hackable" products: tools flexible enough that users can repurpose them in ways you never planned.

This is how Cherny approached Claude Code. Developers were already trying to use AI models as autonomous agents — hacking together scripts, chaining prompts, building crude pipelines to make LLMs do real engineering work. The behaviour existed. Claude Code didn't create the demand, it gave that behaviour a proper surface.

The pattern didn’t stop with developers. As Claude moved into broader use, Anthropic noticed users were already trying to get the model to create charts, diagrams, and interactive visualisations within conversations — bending a text interface toward something visual. Custom visuals in chat formalised that behaviour into a feature. Same principle, different surface.

Think about the products that have survived every wave of disruption. Spreadsheets never assumed they knew what you wanted to do with them — they don’t have an opinion about whether you’re building a financial model or running a small business from a single tab. That radical openness is what makes them the ultimate latent demand detector, because every creative misuse is a product waiting to be built.

Leave deliberate openness at the edges — the kind of flexibility that lets a power user surprise you with a use case you never anticipated. Those surprises are your richest source of latent demand.

The best products create a surface where users discover problems you never anticipated.

---

3. The Observation Gap

If latent demand is sitting in plain sight, why do most teams miss it?

The answer is structural, not intellectual. Every PM has heard the advice to “observe your users.” The problem is that most teams treat observation as a phase — something you do during discovery or shaping and then move on. Latent demand doesn't work on a schedule. It emerges continuously, in the gap between what you built and what users actually do with it after launch. And the signals live in places that most product teams never look.

Think about where latent demand hides in practice. It’s in the support ticket where a customer describes an elaborate workaround they’ve built on top of your product. It’s in the operations team’s internal tools, the ones they hacked together because the product doesn’t quite do what they need. It’s in the “creative misuse” that a power user demonstrates on a call, the thing that makes you say “wait, you’re using it for that?”

These signals are abundant, but they live in the wrong meetings. Support teams see them daily but report them as bugs or feature requests rather than strategic signals. Operations teams build workarounds and never surface them to product because nobody asked. The data exists. It just never flows back to where decisions get made.

Cherny’s process makes this explicit: observe how users interact with what exists, find the latent need buried in their behaviour, and build for that specific behaviour. The key word is observe — not imagine, not hypothesise, not brainstorm. Observe.

The teams closest to your users are seeing latent demand every day. They’re just not calling it that.

---

4. Examples: Facebook Marketplace / Apple’s App Store

By 2016, Facebook Groups had become an unexpected commercial hub. More than 450 million people were visiting buy and sell groups each month — people posting photos of furniture, electronics, clothing, with prices in the descriptions and “DM me” in the comments. No listing format, no payment infrastructure, no search. Users had hacked a marketplace out of social infrastructure using nothing but posts and direct messages.

Facebook observed this behaviour that already existed and gave it a proper surface. Marketplace launched in 2016 with a simple premise: take the commerce that was already happening at scale and build a new product around it — structured listings, local search, category filters. By 2020, the Marketplace product had reached 800 million monthly active users.

The iPhone tells a remarkably similar story. When it launched in 2007, Steve Jobs was adamant: no third-party apps. The iPhone would run Apple’s software only. Developers were told to build web apps instead.

Users disagreed. Within months, a jailbreaking community emerged — developers hacking past Apple’s restrictions to install their own software. First utilities, then games, then productivity tools. The behaviour was unmistakable: people wanted to put their own software on this device, and they were willing to work around Apple’s explicit restrictions to do it.

Jobs tried to resist the demand, but when your users are literally hacking your product to do the thing you told them they couldn’t, the signal is hard to ignore. Apple launched the App Store in July 2008, and within its first weekend, 10 million apps were downloaded. Nine months later, that number hit one billion. Suddenly your phone was a tape measure, a guitar tuner, a way to identify any song playing in a bar, a fake pint of beer you could pretend to drink. The app ecosystem, not the hardware alone, is what made the iPhone dominant.

Two products, two platforms. Both succeeded by building a surface for something people were already doing.

---

How to Apply This

1. Notice what users and teams are building around you:
Pay attention to the workarounds. The tools your operations team hacked together. The creative ways users are bending your product to do something it wasn't designed for. These aren't failures of the product — they're signals about what to build next.

2. Design with open edges:
When scoping a feature, notice where you're constraining users to predefined paths versus where you're leaving room for them to do something unexpected. The more closed the feature, the less it can teach you. The gap between the path you designed and the path users choose is where latent demand reveals itself.

3. Watch how different cohorts use the same product:
A power user and a first-time user will bend your product in completely different directions. Pick two or three distinct segments, shadow them, and map how your product actually fits into their workflow. Not how you designed it to fit. The gaps between cohorts often reveal latent demand that a single-persona view would miss.

4. Make it a standing signal, not a one-off exercise:
Latent demand signals shouldn’t be a quarterly research project. Build a channel where support, operations, and customer success can surface patterns continuously, and make those patterns a standing item in your product review. The signals are already there. You just need to make sure they reach the people making product decisions

---

The Bottom Line

The best product decisions you'll make this year won't come from a brainstorm. They'll come from something a user is already doing, with tools that were never designed for the purpose, that you haven't noticed yet.

Keep iterating,
— Rohan

→ Connect with me on LinkedIn or reach out via email.

---

Thanks for reading! Found value in this? Two ways to help:

1. Like, Comment, or Share - Help increase the reach of these ideas.

2. Subscribe for free - Receive my future posts direct to your inbox.