Intercept Demand, Don't Create It

There are two ways to get a stranger to use your product. You can persuade someone who wasn't looking, advertising, content marketing, social, outbound. Or you can be there when someone who is already looking goes looking.

The first requires a budget, because attention that isn't already directed at your problem has to be bought. The second requires only that you exist at the moment of search.

This is the whole reason the case in this book worked without advertising, and it constrains what you can build. If nobody is already searching for the thing you make, nothing else in this book will help you. That is a real limitation and you should test for it before you write code.

The test, in one afternoon

Step 1: Write down the words, theirs not yours.

Not your category name. The literal string a person types when they have the problem. People do not search for "document workflow optimisation." They search "merge pdf online free." They do not search "expense reconciliation platform." They search "how to categorise business expenses in excel."

If you cannot write ten of these without inventing them, that is your answer.

Step 2: Confirm humans type them.

Google's autocomplete is a free, honest volume signal. If it completes your phrase before you finish, people type it. "People also ask" gives you the adjacent questions. Keyword Planner and the free tiers of Ahrefs and Semrush give you numbers, but autocomplete tells you the phrasing, which matters more.

Step 3: Look at who ranks, and how good they are.

Open the top ten results. You are looking for one of two situations:

Step 4: Count the sub-problems. This is the step that decides everything.

Almost nobody does this and it is the single highest-value hour in the process.

"PDF" is not one query. It is merge, split, compress, convert, sign, redact, rotate, unlock, watermark, OCR, extract, compare, organise, and each of those splits again by file type, by device, by intent. The case in this book found sixty distinct, individually-searched jobs under one umbrella.

That number is not a detail. It is the difference between a business and a landing page. Chapter 3 explains why sixty was necessary and why fewer would have failed, for a reason that is not the obvious one.

The uncomfortable part

The founder of the case study has no personal interest in documents. The product is named after disliking them.

I think "build what you're passionate about" has quietly damaged a lot of first attempts. The argument for passion is that it sustains you when nothing works. But look at what actually sustained this project: month five had zero commits, the work stopped entirely, and the traffic grew 61% anyway (Chapter 14). What kept the project alive was not enthusiasm. It was that the numbers were going up.

A working feedback loop sustains better than passion does. Passion without traction burns out faster than indifference with traction. Choose the problem with demand; the feelings arrive later, when it starts working.

The three ways this test goes wrong

1. You write the queries you wish people typed. The most common failure, and it is invisible from the inside because your phrasing feels natural to you. You know your category; you have absorbed its vocabulary. Your customers have not.

The check: did this phrase come out of your head, or did you observe it? Autocomplete, People Also Ask, a forum post, a support email. Those are observations. Anything you invented at a desk goes in a separate list marked unverified, and you do not build against that list.

2. You confirm demand for a problem you are adjacent to rather than the one you solve. "How to compress a video" has enormous volume. If you build a document tool, that volume is not yours. Adjacent demand is the most seductive trap in this chapter because the numbers look wonderful and the traffic converts at nothing.

The check: could someone who typed this phrase complete their task on the page you would build? If not, the volume is decoration.

3. You find real demand you cannot reach. Chapter 4 is the whole treatment, but it starts here: a query with 100,000 monthly searches and ten well-resourced incumbents on page one is not an opportunity. Volume you cannot reach is worth zero, and confusing the two is how founders spend a year on a term they were never going to rank for.

What "existing demand" looks like when it is real

Four properties. You want all four; three is workable; two is a warning.

The counter-case: when to ignore this chapter

Intercepting demand is the right strategy when you have no budget and a searchable problem. It is the wrong strategy in three situations, and it would be dishonest to present it as universal.

When the category genuinely does not exist yet. Nobody searched for "ride sharing" before it existed. If you are creating a category, search is downstream of the awareness you have not built, and this playbook cannot help until later, though it becomes very useful once the vocabulary settles.

When your buyer does not search. Enterprise procurement runs on relationships, referrals and analyst reports. A CTO does not Google their way to a six-figure contract.

When the problem is high-value and low-frequency. Some things are searched once a year by very few people, and each one is worth a fortune. That is a sales business, not a distribution business.

The honest framing: this book describes one strategy that works under specific conditions. Chapter 1 is the test for whether those conditions apply to you. If it says no, the rest of the book is interesting rather than useful, and I would rather you find that out on day one than in month seven.

About this book

Intercept Demand, Don't Create It is chapter 1 of How to Grow Your SaaS to 100K Users Without Spending on Ads, a playbook on taking one product from zero to 100K+ users on search alone, with nothing spent on advertising. Every claim in it is checked against the real data, including the three findings that contradicted the author.

Continue reading

Free tools that implement this book