How to Get Feedback That's Actually Useful

A founder showed me twelve pages of feedback last month and asked why it wasn't helping him decide anything. He had talked to fifteen people about a tool for managing recurring client invoices. Fourteen said they'd use it. Nine said they'd pay. The notes were full of nodding, and he still had no idea whether to build it, because none of it told him what anyone actually does today.

Here is the short answer: you get feedback you can build on by asking about past behavior, not future intent. "Would you use this?" and "would you pay?" produce polite yeses that feel like signal and are noise. "What did you do the last time this happened?" produces a fact.

The past already occurred — it can't bend to flatter you or spare your feelings.

So you stop asking people to predict themselves and start asking them to report themselves, and you design every question around the one thing that would kill your idea, looking for evidence that it's already dead.

Why future questions always lie to you

When you ask someone whether they'd use a thing that doesn't exist yet, you're asking them to imagine a version of themselves who has a problem urgent enough to change their behavior. Nobody is good at that. Worse, there's a social cost to saying "no, that sounds useless to me" while a hopeful person sits across the table. So people answer the easy version of the question — "does this sound like a reasonable idea in the abstract?" — and the honest answer to that is almost always yes.

Reasonable ideas are cheap. Yes is free.

I learned this the expensive way with CheckMVP, an AI tool I built in 2024 that analyzed startup ideas and got used on more than 500 of them. It generated tidy reports on buyers, risks, and next steps. The early GPT models underneath were too agreeable — they produced encouraging, plausible validation for whatever you fed them.

Founders read a report that told them their idea was sound and felt, genuinely, like they'd received feedback. They hadn't. They'd received a very well-written yes.

That was the moment it clicked for me:

Feedback that flatters is indistinguishable from feedback that informs, right up until you build the thing and nobody shows up. Killing that product is what pushed me toward the approach I use now.

Find the one concern that would sink the whole thing

Before you write a single question, name the assumption that has to be true or your idea is dead. Not a list of risks — the single most dangerous one.

For the invoicing tool, it wasn't "will people like a cleaner interface." It was: do these people actually lose money or clients because of how they invoice today, or is it a mild annoyance they've lived with for years? If it's a mild annoyance, no interface saves you. That's the concern. Everything you ask should be built to find evidence against it — evidence that the pain is real and already costing something.

This is the part most founders skip. They gather general feedback, get a warm feeling, and never point their questions at the thing that could actually end the project. General feedback is easy to collect and impossible to act on, which is exactly why twelve pages of it decided nothing.

Rewrite the question so the past has to answer

Take the invoicing example. The future-intent version is "would you pay for a tool that automates your recurring invoices?" Here's the same curiosity, rewritten so only behavior can answer it:

• Walk me through how you sent your invoices last month. What did you actually do, step by step?
• The last time a client paid late, what happened — did you chase them, and how?
• What are you paying for right now to handle this? A bookkeeper, a spreadsheet, an accountant, nothing?
• How long did invoicing take you last week?

Notice what these do. None of them can be answered with a polite yes. They force the person to describe a real event that already happened, and the details give you the ceiling you were about to build over.

If the answer to "what do you pay for this today" is "nothing, it takes me ten minutes on the first of the month," your concern just confirmed itself — the pain is mild, and no product fixes mild.

If the answer is "I pay a bookkeeper 400 dirhams a month and still missed two payments last quarter," you have found a real cost, a real budget, and a real failure. That's a fact you can build on.

The rewrite is mechanical once you see it. Any time a question points at the future — would you, will you, do you think you'd — drag it into the past. Would you use a scheduling tool becomes show me how you booked your last three appointments. Would this save you time becomes how much time did it take you last week. The tense change is the whole trick, because the future is where people are generous and the past is where they're honest.

Listen for the doing, not the liking

When you run the interview, most of what people say is opinion, and opinion is the polite noise you're trying to get past.

Your job is to catch the moments where someone reports an action and dig into those. "I really like that idea" is nothing. "Last week I copied the numbers into a spreadsheet by hand because the export was broken" is everything — it's a person spending effort on a workaround, which is the clearest signal a problem exists that money exists to solve.

Follow the workaround. People don't build workarounds for problems they don't have.

Two things to distrust. Enthusiasm that isn't attached to a past action — someone can be thrilled about your idea and have never once done anything about the problem it solves. And hypotheticals the person volunteers about their own future — "oh, I'd definitely use that every day" is them being kind, not them reporting data. When you hear either, don't argue and don't celebrate.

Ask what they did the last time the situation came up, and let the answer correct the enthusiasm.

What useful feedback actually looks like

You know the feedback is usable when you can act on it without having to trust anyone's prediction. "Eight of the ten people I asked already pay someone to do this and half of them still miss payments" is a decision — build it, and here's the price ceiling and the failure to fix. "Everyone said they'd love it" is not a decision, no matter how many people said it.

The difference isn't the number of people. It's whether what they told you already happened.

I spent months of my career building things that people had agreed sounded good. Agreement is not evidence. The past is. Design your questions so the only thing a person can hand you is what they've already done, aim them at the one concern that would kill the idea, and the polite noise falls away on its own — because you never gave anyone a comfortable future to say yes to.