How to get product feedback before launch without drowning in politeness

To get useful product feedback before launch, put the working product in front of about five people who actually resemble your user, ask them what they did rather than what they think, and then grade what comes backinstead of just feeling good about it. Most pre-launch feedback fails not because founders don't ask, but because they ask the wrong people the wrong questions and then have no way to tell a compliment from a finding.

Every other guide on this query hands you a list of methods — surveys, focus groups, card sorting, diary studies — written for a product team that already has users and a research budget. That advice quietly assumes the hardest part is collecting feedback. It isn't. For a solo founder two weeks from launch, the hard parts are finding anyone honest enough to give it and knowing which of it to act on. This guide is about those two, and it ends with the rubric I use to score every piece of feedback out of 100.

Why founder feedback beats user surveys pre-launch

Before launch, feedback from a few founders who ship products beats a survey of a hundred prospects — because pre-launch you have a product problem, not a market-research problem. A survey tells you what people say about a description of your product. A founder who has shipped six things will open your app, get stuck in the same place your real users will get stuck, and tell you exactly where — because they've watched their own users get stuck there.

There's a second reason, and it's about incentive structure. Feedback quality tracks how much the giver has at stake in being right. A stranger filling in a survey has none. A friend has an incentive to be kind. A founder who wants you to look at theirproduct next has a direct incentive to give you something good enough to be worth reciprocating. That's not cynicism — it's the only reliable way I've found to buy candor without a budget.

Why what people say and what they do don't match

People are unreliable narrators of their own behavior, and that is the single biggest reason pre-launch feedback misleads founders. Nielsen Norman Group put a number on it decades ago and it has aged perfectly: in their research on why you shouldn't simply listen to users, measured task performance and stated preference correlated at only 0.44 — meaning you can predict about a quarter of how well a design actually works from how much people say they like it. Three distortions do the damage: people answer to match social expectation, they misremember what they did, and they rationalize their behavior after the fact.

The practical consequence for a pre-launch founder is blunt: "Would you use this?" is not a research question. It's a politeness prompt. So is "what do you think?" The way out is to stop asking about the future and start asking about the past — what they've already tried, what it cost them, where they gave up. That's the central move in Rob Fitzpatrick's The Mom Test: ask questions that even someone who loves you couldn't comfortably lie in response to.

The other consequence is about sample size, and it's good news. You don't need a hundred people. Jakob Nielsen's classic finding on testing with five users is that five participants surface roughly 85% of a design's usability problems, and that several small rounds beat one big study — fix what you found, then test again. For a solo founder, that reframes the whole task: you need five good sessions and the discipline to run them three times, not a research panel.

Who to ask for feedback (and who to never ask)

Ask people who have context and no reason to flatter you. In practice, that's three groups — and one group you should politely route around entirely.

The founders-who-ship group is the one nobody writes about, because most feedback guides are written for companies, not for one person with no users. It's also the group that scales, because the exchange is symmetric: you review their product, they review yours. That reciprocity is the same engine behind launching a SaaS with no audience — you borrow other founders' attention by giving yours first.

That's the specific job of the structured-feedback action on Favors.dev. Favors.dev is a founder marketing co-op with a points economy: you earn points by giving another founder detailed feedback on their product, and you spend points to get detailed feedback on yours. The submission is graded before points move, on the four dimensions in the rubric below, and it pays out 300, 400, or 500 points depending on how it scores. A one-line "looks great" earns nothing — which is exactly why what comes back to you isn't a one-line "looks great."

The questions that surface real objections

The best pre-launch questions ask about behavior that has already happened. Here's the short list I actually use, and what each one is really digging for:

• "What did you try to do first?"— Reveals whether your landing page and first screen agree with each other. If their first move isn't the move you designed for, your positioning is off, not their instincts.
• "Where did you stop, and what were you expecting to happen?" — The single highest-yield question in the set. The gap between expectation and behavior is where every conversion problem lives.
• "How are you solving this today, and what does that cost you?" — Tests whether the problem is real. A problem nobody currently spends time or money on is a problem nobody will pay you to solve.
• "What would have to be true for you to pay for this?" — Surfaces the actual blocker (trust, a missing integration, a price ceiling) instead of a courteous "maybe later."
• "Who is this obviously not for?" — People will criticize your targeting far more freely than they will criticize you. This is the safe-harbor question that gets you honest negatives.

Two mechanics matter as much as the questions. First, watch them use it — a live screen-share where you stay quiet for sixty seconds after they get stuck will teach you more than any written response. Second, never defend. The instant you explain why they misunderstood the button, the session is over; they've learned that disagreeing with you costs them something.

How to grade feedback: the 4-dimension rubric

Grade every piece of feedback on four dimensions — specificity, actionability, depth, and effort — worth 25 points each, for a score out of 100. This is the rubric our AI grader runs on every feedback submission on Favors.dev, and it works just as well on a pasted Slack message. The point isn't the number. It's that scoring forces you to notice when a paragraph that felt encouraging contains zero information.

Add the four together and you get a band. What you do next depends entirely on which band it lands in:

Structured feedback beats vibes for a reason that has nothing to do with rigor for its own sake: it protects you from the two failure modes that actually kill pre-launch products. The first is acting on a confident opinion from someone who never used the thing. The second is discarding a quiet, awkward observation from someone who did — because it arrived without enthusiasm. Score both, and the ranking usually inverts.

One warning about the rubric: it grades the quality of feedback, not whether the person is right. A 90-scoring critique can still be wrong about your market. The score tells you what deserves a serious hour of your attention. You still have to decide.

Turning feedback into a pre-launch crowd

Everyone who gives you real feedback before launch is a launch-day supporter you already have. This is the step most founders skip: they treat feedback as an input to the product and forget it's also the beginning of a relationship. Someone who spent twenty minutes inside your unfinished app is far more invested than someone who saw a tweet — and they're the easiest person in the world to tell "I shipped the thing you told me to fix."

So close the loop, out loud. Tell each person what you changed because of them, by name, before you launch. Three things follow from that one habit: they show up on launch day, they're primed to write you an honest testimonial because they watched the product improve, and you get a genuinely good thing to post about — which is the entire substance of building in public. "Here's what five founders told me was broken, and here's what I fixed" outperforms any progress screenshot.

There's a 2026 tail on this too. Reviews, testimonials, and community discussion are exactly the source types answer engines reach for when they synthesize an answer — Similarweb's research on generative-AI citation patterns shows Wikipedia and Reddit at the top of ChatGPT's most-cited domains, ahead of most brand sites. Feedback conversations that happen in public — in a community thread, on a product's directory page, in a review — keep working long after the launch spike is gone. The private DM version helps your product; the public version helps your product and your discoverability.

The sequence, then, is short enough to hold in your head: get five people who resemble your user, ask them about what they did, score what comes back, fix the highest-scoring complaint, tell them you fixed it, and invite them to launch day. That's the whole pre-launch feedback loop. Everything else is instrumentation.

Frequently asked questions