Nobody Wants Your Survey.
Here's What To Measure Instead.

01 / Why does every founder have a version of the same story?

You finish the MVP. You send it to ten people you trust. You ask: would you pay for this? Nine say yes. One says probably. You ship it. You send the launch email. You watch the conversion dashboard.

Nobody pays.

Not one of the nine. Not the one who said probably. You follow up. Three respond warmly. Two say they've been meaning to try it. One says they'll forward it to someone who might be interested. None of them convert.

This is not an unusual story. It is the most common story in early-stage product development. And the founder's instinct, almost universally, is to conclude that something is wrong with the product. The price is too high. The onboarding is confusing. The landing page isn't converting.

These things might be true. They are not the problem. The problem is that the research method produced false signal before a single line of product code was written. The nine yeses were never real. The survey didn't fail. It worked exactly as it was designed to. It collected what people said, which has never reliably predicted what people do.

The MVP was not the experiment. The survey was. And the survey was the wrong experiment to run.

02 / What is the politeness problem and why does it make surveys useless?

Humans are social animals. Telling someone their idea is bad is uncomfortable. Telling someone you wouldn't pay for what they just spent months building, to their face, in a conversation where they are clearly invested, is something most people will not do.

So they say yes. Or "that sounds interesting." Or "I could definitely see myself using that." These phrases feel like validation. They are social lubricant. They mean nothing about future behaviour.

The politeness problem is the tendency for people to tell founders what they want to hear rather than what is true. It is not malicious. It is the default social response to someone who is excited and vulnerable about something they created. The person saying yes is being kind. The founder taking it as signal is making a category error.

The problem compounds in surveys because surveys remove even the weak accountability of a face-to-face conversation. There is no social consequence for clicking "yes, I would pay for this." The respondent does not commit to anything. They answer the hypothetical and move on. The founder adds another tally to a column that means nothing.

This is not a new finding. It is one of the most replicated results in consumer psychology: stated intent and actual behaviour diverge significantly, especially when the stated intent carries no cost. The gap between "I would buy this" and "I bought this" has been documented across categories for decades. Founders rediscover it personally, one failed launch at a time.

Surveys measure what people are willing to say. That is not the same thing as what people are willing to do. The gap between those two things is where most early-stage products die.

03 / What is the validation trap and how do you know you're inside it?

Surveys are the most visible version of a broader pattern. The pattern has a name.

The validation trap is the mistake of collecting feedback that feels like signal but contains none. Positive survey responses, enthusiastic coffee chats, complimentary emails from people who never become customers, social media likes on a product announcement: all versions of the same trap. They create confidence without creating evidence.

Founders inside the validation trap feel like they are doing research. They are not. They are collecting comfort.

The diagnostic is simple. For each piece of feedback you've collected, ask one question: did this cost the person giving it anything real? Time they could not easily spare. Money they cannot get back. Effort that required them to change something they were already doing. If the answer is no, the feedback is not signal.

What the validation trap looks like in practice:

• Ten interviews where everyone loves the idea but nobody asks how to buy it
• A waitlist with 200 signups and 3 percent conversion when you open access
• A survey where 80 percent of respondents say they would pay, and 2 percent do
• A beta with 50 users and no one who would notice if you shut it down tomorrow
• An investor who says "interesting, keep me posted" after your deck

Each of these feels like validation from the inside. None of them is. The common thread is that they all required nothing of the person responding. No money. No switch. No real commitment of any kind.

Validation that costs the validator nothing is not validation. It is optimism with a spreadsheet.

04 / What is behaviour under friction and why is it the only signal that matters?

Remove the hypothetical entirely. That is the move.

Instead of asking what someone would do, create a situation where they have to actually do it. Put real cost on the action. Make the commitment concrete. Then watch what happens. The result is not an opinion. It is data.

Behaviour under friction is what people do when an action costs them something real: money, time, effort, or the loss of something they already have. It is the only category of signal that reliably predicts future behaviour, because it is not a prediction. It is the behaviour itself, observed under conditions that mirror the real purchase decision.

The friction does not need to be large. It needs to be real. A ten-euro deposit is enough to separate genuine interest from polite curiosity. A required referral before waitlist access filters for people who care enough to act. Asking someone to cancel a competing subscription to use your product tells you more in one data point than fifty survey responses.

What friction does is remove the social dimension from the decision. There is no politeness problem when someone is alone with a payment form. Nobody is being kind to the checkout button. The action is either taken or it isn't. That binary is information. The nuanced survey response is noise.

The question is never what someone would do. It is what they will do right now, when it costs them something.

05 / What are the five friction signals and how do you read them?

Stop collecting opinions. Start designing situations where the only way to respond is to do something. Here are the five situations that matter.

Pre-payment. Someone pays before the product is finished. This is the strongest possible signal. It means the pain is acute enough to pay to solve before they have seen a solution. Run a landing page with a payment link and a delivery date before you build anything. If nobody pays, you have not validated the problem. If people pay, you have a customer list and a deadline. Both are useful.

Waitlist commitment. A waitlist with no friction is an email collection exercise. It tells you people were curious enough to type their address. Nothing more. A waitlist with a required referral, a small deposit, or a stated commitment tells you something different: these people want access badly enough to do something for it. Track not just how many join, but how many clear whatever friction you set. That ratio is the signal.

Tool switching. Someone cancels a paid subscription to use your product instead. This is the clearest market signal available to an early-stage product. The user is not speculating about whether they prefer you. They have already decided and acted on it. Every tool-switcher in your early cohort is worth more as a data point than a hundred survey responses.

Unprompted return. Send no re-engagement email for the first two weeks after a user signs up. Measure who comes back without being asked. The retention number this produces is harsh. It is also the only retention number that means anything. Users who return unprompted have built your product into their lives. Users who only return after an email have not. The difference between those two groups is everything.

Complaint dependency. When something breaks and a user contacts you about it, write down the feature. The things people complain about when they stop working are the things they depend on. Dependency is a stronger signal than satisfaction. A satisfied user might churn silently. A user who complains when something breaks will not leave until it's fixed. That is the user who is building your roadmap.

The five friction signals are: pre-payment, waitlist commitment, tool switching, unprompted return, and complaint dependency. Each one costs the user something real. That cost is what makes it a signal.

06 / When should you talk to users if not to validate?

User interviews are not useless. They are misapplied.

The mistake is using them to answer the wrong question. "Would you pay for this?" is the wrong question. "How are you currently dealing with this problem?" is not. The first asks for a prediction about imagined future behaviour. The second asks for a description of actual past behaviour. One is speculation. The other is data.

Talk to users to understand the shape and texture of the problem. Not to confirm that your solution is good. The questions worth asking:

• What do you do right now when this problem comes up?
• What have you already tried to solve it, and why did those things not work?
• What does it cost you when this goes wrong, in time, money, or effort?
• Who else in your organisation or life feels this pain?
• What would have to be true for you to change what you're doing today?

Notice what these questions have in common. They are all about the past or the present. They are all answerable with specific facts rather than intentions. They do not ask the respondent to predict their own future behaviour, which humans are structurally bad at.

What to avoid: questions that begin with "would you," "could you imagine," or "how much might you pay." These are hypothetical by construction. They produce the politeness problem on demand.

Use interviews to build a map of the problem. Use friction signals to validate that your solution to that problem is worth paying for. These are two separate jobs. Running them at the same time with the same instrument produces noise.

Talk to users to understand the problem. Measure behaviour to validate the solution. Never confuse the two.

07 / How do you validate without surveys?

Five steps. Each one replaces a zero-friction research method with a friction-based one.

Charge before you build. Put up a landing page with a payment link and a delivery date before the product exists. Write the copy as if the product is ready. Price it at what you intend to charge at launch. If people pay, you have validated willingness to pay and collected your first real customers simultaneously. If nobody pays, you have saved yourself months of building the wrong thing. Both outcomes are wins. Silence from a survey is not.

Run a waitlist with a commitment cost. A friction-free signup form is not a waitlist. It is an email list of curious people. Add a cost before access: a referral, a deposit, a short application. Track the ratio of people who attempt to join versus the number who clear the friction. A low ratio is a signal. A high ratio is a signal. An untested free signup is neither.

Ask users to switch from something they already use. Make the product comparison explicit in onboarding. Ask: what are you currently using for this? What would have to be true for you to stop using that and use this instead? Then make that thing true and watch whether the switch happens. The ones who switch are your real early adopters. The ones who don't are telling you something important about what's missing.

Measure return without prompting. After the first session, go dark for two weeks. No onboarding emails. No nudges. No check-ins. Just measure how many users open the product again without being asked. The number will be lower than the number who opened a re-engagement email. It will also be more honest. That number is your real week-two retention. Build from there, not from the inflated version.

Track complaints as dependency signals. Build a system for logging every bug report, support request, and user complaint by feature. Sort by frequency. The features at the top of that list are the ones your users depend on. Those are the features you protect first, improve first, and price around. The features nobody complains about when broken are the features nobody depends on.

None of this is faster than a survey in the short term. It is dramatically faster than building a product nobody uses and spending six months trying to understand why. Once friction signals tell you what works, the next question is how to position it sharply enough that the right people find it. That is the angle problem, covered in the final post in this cluster.

A week of friction-based testing tells you more than six months of surveys ever could. Start with the test that costs the user the most. That is the test that tells you the truth.

08 / Frequently asked