पाठशाला Pathshala · विचार Vichār, The idea · Lesson 01 · Start

How to tell a problem from a complaint

Every customer will complain. Very few have a problem they are already paying to solve. The difference is four questions, and most startup ideas die because nobody asked them.

Pathshala, The Founder Library · 10 October 2026 · 7 min read

Ask a room of small-business owners what frustrates them and you will not get out for an hour. Ask the same room who has paid someone this month to make one of those frustrations go away and most hands stay down. The first answer is a list of complaints. The second is a list of problems. Companies are built on the second list, and founders spend years on the first because it is so much easier to collect.

This lesson gives you the distinction in a form you can apply to a single conversation, a worked example from an Indian market, the three traps that make good founders choose complaints, and a weekly ritual that turns conversations into a ledger instead of a feeling.

Complaints are free; problems are paid for

A complaint is a statement about how the world ought to be. “GST filing is a headache.” “Hiring is impossible in Tier 2 cities.” “Nobody pays on time.” All true, all widely felt, and none of them tells you whether a person would change their behaviour or open their wallet for a fix. People complain about things they have decided to live with. The complaint is the sound of that decision.

A problem has evidence attached. It happened on a date the person can name. It happens again on a schedule. It costs something the person can count, in hours, in rupees, in a lost customer. And, most tellingly, the person has already done something about it: hired someone, built a spreadsheet, started a WhatsApp group, paid for a tool that half works. Rob Fitzpatrick’s The Mom Test puts the rule plainly: talk about their life instead of your idea, ask about specifics in the past rather than generics or opinions about the future, and talk less. The specifics are where the evidence lives. Opinions about the future are where complaints live.

Paul Graham’s How to Get Startup Ideas makes the same cut from the other side. The best ideas, he argues, are problems the founders have themselves, and the ones to avoid are what Y Combinator calls “made-up” or “sitcom” startup ideas: things that sound plausible in a pitch and that nobody actually needs. The difference between a sitcom idea and a real one is exactly the difference between a complaint and a problem. One is plausible. The other has a receipt.

The four tests, and the fifth

Recency. Can they describe the last time it happened? Not “all the time”; a specific occasion, what went wrong, what they did next. If no incident comes to mind, the thing has not cost them enough to remember, however loudly they describe it.

Frequency. How often does it recur? Weekly problems support habits and subscriptions. Monthly problems support software that lives in a calendar. Annual problems support services, and a product has to be re-sold every year to a customer who has forgotten you.

Cost. Can they put a number on it? Push for the number. Three hours a week. Two days at month end. ₹2,500 to a chartered accountant. One lost order in ten. A problem with no number is a problem the customer has not yet thought about seriously, which means the customer will not think seriously about your solution either.

Workaround. What have they already tried? This is the question that separates the lists. A person who has hired, bought or built something to cope has demonstrated with money or time that the pain is real. The workaround is also your real competitor, and its cost is the ceiling on your price.

The fifth test is about the person, not the problem. Budget and authority. Does the person in front of you control the money or the hours a fix would cost? Eric Migicovsky’s Startup School lecture on talking to users tells founders to ask for numbers on what the problem costs, how often it occurs, and whether the person has the budget and authority to solve it. A real problem felt by someone who cannot pay is a problem you will be asked to solve for free.

A worked example: GST, as heard in Delhi NCR

Suppose a founder spends two weeks talking to thirty small traders in Delhi NCR about compliance. Every one of them says some version of “GST is a headache.” Thirty for thirty. It feels like a market.

Run the tests. Twenty-two of the thirty cannot describe a specific recent incident. They file through an accountant, the accountant handles it, they resent the fee and move on. That is a complaint, and the accountant is the market’s answer to it. Six describe the same specific scene: the last three days of every month spent chasing suppliers for invoices because the input tax credit does not reconcile, a WhatsApp group with their four largest suppliers created for exactly this purpose, and ₹2,000 to ₹3,000 a month to the accountant on top. Recent, monthly, costed, worked around. Two more describe the pain vividly but it turns out their brother-in-law does the filing and would decide on any tool.

Thirty complaints have become six problems, in a segment that can be described in one sentence: traders with more than a handful of suppliers whose input credit does not match. That is a smaller market than “everyone who files GST”, and a much better one, because the six have already shown you what they will pay and what they currently use. Graham’s image is the right one: it is better to dig a hole that is narrow and deep, like a well, than one that is broad and shallow, and to make something a small number of people want a large amount.

Three traps that make good founders pick complaints

The loudness trap. Complaints are expressed with emotion and problems are often described flatly, because the person has already dealt with them. A founder hears the emotion and scores it as demand. Score the receipts, not the volume.

The schlep trap. Graham’s essay Schlep Blindness describes how a founder’s unconscious refuses to even see ideas that involve tedious, painful work, and gives the example of payments before Stripe. Many real problems in India sit behind a schlep: a licence, an integration with a bank, a thousand distributor visits. Complaints rarely do. If every idea on your list is clean, you are probably looking at complaints.

The job trap. Clayton Christensen and his co-authors, in Know Your Customers’ “Jobs to Be Done”, argue that customers hire a product to do a job, and that the job is never simply about function. A complaint usually names a feature of the world. A problem names a job the person is trying to get done and failing. “The app is slow” is a complaint. “I need to confirm the order while the customer is still on the phone, and I cannot” is a job. Ask what they were trying to accomplish when the pain arrived; the job is the thing you build for.

A complaint is what someone says about the world. A problem is what they have already paid to change.

What to do when the answer is “complaint”

Do not argue and do not pitch. The conversation is still useful if you change the question. “Tell me about the last time that actually happened” converts a surprising share of complaints into incidents, and an incident can be scored. If no incident appears, ask whether anything would change the cost: a new rule, a bigger team, a festival season, a large customer. Problems often live one step away from the person complaining; what is an annual irritation for a shop is a weekly crisis for its distributor.

Then record the conversation anyway. A ledger of complaints that never became problems is a map of where not to build, and it is worth having when the next plausible idea arrives wearing the same clothes.

A weekly ritual: the problem ledger

Keep one sheet. One row per conversation. Five columns: last incident (date), frequency, cost (a number, with its unit), current workaround (and what it costs), and whether the person decides. Score each column one or zero. A row scoring five is a problem. Three or four is a problem for someone adjacent, or a problem waiting for a trigger. Two or below is a complaint, filed and left alone.

Every Friday, count the fives. Before any code is written the target is ten fives that describe the same incident and the same workaround in roughly the same words; that is a segment, and it is the first thing an investor will ask you to prove. If three weeks pass without the count moving, the idea is a complaint wearing a problem’s clothes, and the honest move is the next idea, not a better pitch.

Nothing here is a substitute for the conversations themselves. The sources below are short; Graham’s two essays and Fitzpatrick’s book take an evening between them, and will save you a year.