How Do I Know If Customers Actually Want This Before I Build It?

You have an idea. It feels obvious to you. You can picture exactly how it would work, and every time you describe it to a friend, they nod along and say it sounds like a good idea. So you start building.

Six weeks later you launch it, and almost nobody uses it.

This is one of the most common and most expensive patterns in early stage products, and it rarely happens because the idea was bad. It happens because the founder skipped a specific, learnable step between having an idea and building it, and mistook a friend's polite nod for actual market validation.

Talking to people who love you is not research

The friend who nodded along has a built in bias you cannot design around. They like you. They do not want to discourage you. And critically, they were never asked to spend actual money, so their enthusiasm cost them absolutely nothing.

Genuine validation requires putting a real cost on the other side of the conversation, even a small one. Would this person actually pay for it. Would they change a current habit to use it. Would they be disappointed, not just neutral, if it did not exist. A friend telling you an idea sounds good is not the same signal as a stranger telling you they already have this exact problem and have tried, unsuccessfully, to solve it themselves.

Understand the job, not the feature

One of the most useful ideas in product thinking is that customers do not actually want your product. They want to make progress on something in their life, and your product is simply the tool they are hiring to do it. This is often called jobs to be done thinking, and it comes from a famous observation about people buying milkshakes during their morning commute, not because they loved milkshakes specifically, but because they needed something filling, one handed, and interesting enough to make a boring drive feel shorter.

Before you build anything, get specific about the actual job your future customer is trying to get done, separate entirely from your proposed solution. What are they doing right now instead. Are they using a clunky spreadsheet, an entirely different product, or just tolerating the pain because nothing better exists yet. If you cannot describe this job clearly without mentioning your own product at all, you likely do not understand your customer well enough yet to know whether they actually need what you are about to build.

An MVP is a test, not a smaller product

A common and costly misunderstanding treats a minimum viable product as simply a stripped down, lower quality version of the eventual full product. This framing quietly leads founders to build something with fewer features but the same fundamental assumptions still baked in, untested, at the very core of the idea.

The actual purpose of a minimum viable product is to test your single riskiest assumption as cheaply and quickly as possible, before you invest in building anything more. If your biggest open question is whether people will actually pay for a solution to this problem at all, your first test should be built specifically to answer that question, even if it means faking parts of the actual delivery behind the scenes. Some of the most useful early tests involve a founder manually doing, by hand, what the eventual product would automate, specifically to learn whether anyone genuinely wants the outcome before investing a single hour into building the automation.

Purchase intent is not purchase behavior

If you do ask people directly whether they would buy something, take the answer seriously, but do not take it literally. A well documented pattern across product and market research is that people consistently overstate how likely they are to actually buy something when there is no real money and no real commitment on the table in that exact moment.

Someone telling you they would definitely buy your product in a conversation or a survey converts to an actual paying customer at a meaningfully lower rate once real money is genuinely involved. This does not mean the signal is worthless. It means you should treat a strong verbal response as encouraging but not sufficient on its own, and look for a stronger, more binding signal wherever you reasonably can. Will they put down a small deposit today to reserve early access. Will they give you their card details for a trial that actually converts to a real charge if they do not cancel. A genuine dollar, even one dollar, tells you more than an enthusiastic paragraph ever will.

Validate the market before you validate the product

There is a subtle but critical distinction between people wanting your specific solution and there being an actual, sizable market for the underlying problem at all. You can build something that a handful of people genuinely love and still fail, if the total number of people who share that exact problem badly enough to pay for a fix is simply too small to build a real business around.

Before falling in love with early positive signal from a small number of enthusiastic early users, take a step back and ask a market level question. How many people genuinely have this problem. How are they currently solving it, even badly. What are they currently spending, in money or in time, to work around not having a good solution. A product with passionate fans in a market that is fundamentally too small is a much harder business to build than a product with lukewarm early reception in a market that is genuinely large.

Discovery is not a phase you finish

A particularly damaging habit is treating customer research as a box to check once at the very beginning of a project, then moving into building mode and never really returning to it until something has already gone wrong. The strongest product teams treat discovery as a continuous, ongoing practice, running in parallel with actual building, not as a single gate you pass through once.

This does not require a formal research department. It can be as simple as a standing habit of talking to a small number of real or prospective customers every single week, even briefly, specifically to test a current assumption rather than to make conversation. The goal is not to gather compliments. It is to actively try to find the place where your current thinking is wrong, before that wrong thinking gets baked into another few weeks of engineering work you will eventually have to undo.

Watch what people do, not just what they say

The gap between stated preference and actual behavior extends beyond purchase intent into almost every part of product research. People are frequently poor predictors of their own future behavior, not because they are lying to you, but because predicting your own behavior accurately is genuinely difficult even with the best intentions.

Wherever possible, design your validation to observe actual behavior rather than relying purely on what someone tells you they would do. A landing page that measures whether people actually click a signup button is a stronger signal than a survey asking whether they would be interested. A waitlist that people have to actively join, ideally with a small piece of friction like providing an email or answering a qualifying question, is a stronger signal than a poll asking for a thumbs up. The friction itself is doing useful work, filtering out the polite nod from the genuine interest.

A concept test does not need to be fancy

Founders often assume that testing a concept before building it requires a working prototype, a design team, or expensive tools they do not have access to. In practice, a concept test can be a single clearly written paragraph describing the core benefit and how it would work, shown to a handful of the right people, with a specific question attached to it.

What matters more than the fidelity of the test is the honesty of the language used in it. A common mistake is writing the concept description using the same excited, persuasive language you would eventually use in a marketing campaign. This tends to generate an inflated positive reaction to the writing itself rather than to the underlying idea, since polished, aspirational language can make almost anything sound appealing on the page. A more useful test describes the idea plainly, in the same tone you would use explaining it to a colleague over coffee, and asks a direct question afterward: would you use this, and specifically why or why not. The plainer the description, the more trustworthy the reaction to it actually is.

Diagnose the specific reason, not just the reaction

When an early concept test comes back lukewarm, it is tempting to read that as a verdict on the entire idea and either abandon it or push forward on instinct alone, ignoring the feedback. A more useful response is to figure out specifically which part of the idea failed to land, because different specific problems call for genuinely different fixes.

A lukewarm reaction because the idea was unclear calls for better explanation, not a different product. A lukewarm reaction because the idea does not address a need the person actually has calls for a real rethink of the underlying concept, not just clearer marketing copy. A lukewarm reaction because the person does not believe your specific claims calls for stronger proof, not a louder pitch. These are three completely different problems that happen to produce a similar sounding no on the surface, and treating them identically wastes the exact signal you went looking for in the first place.

One clear no is worth more than ten polite maybes

There is a strange comfort in ambiguous feedback. A room full of people saying maybe feels less discouraging than one person saying no clearly, so founders sometimes unconsciously seek out the vaguer response and avoid the sharper one. This instinct works directly against you.

A clear, specific no, especially one that comes with a reason attached, is genuinely valuable information. It tells you exactly where your current thinking breaks down, while a polite maybe tells you almost nothing you can act on. When you are running early validation conversations, resist the urge to soften your own questions to avoid an uncomfortable answer. Ask directly, and treat a direct no as a gift rather than a rejection, because it is doing exactly the job you asked it to do.

Building the discipline, not just the instinct

None of this requires a dedicated research team or a large budget. It requires a specific set of habits: separating the underlying job from your proposed solution, treating stated intent as a weaker signal than actual committed behavior, sizing the real market before falling for early enthusiasm, and treating discovery as continuous rather than a single phase you complete and move past.

These are exactly the disciplines covered in depth in both our Product Management and Market Research courses. If you are earlier in figuring out what to build and why, Product Management is the stronger starting point, since it covers frameworks like jobs to be done and structured prioritization directly. If you are specifically trying to design a rigorous way to test demand, whether through surveys, pricing research, or concept testing, Market Research goes deeper into exactly that. Either way, the goal is the same: replacing a friend's polite nod with something you can actually trust before you spend another six weeks building.