How to Run a Product Survey Before You Build (2026)

To run a product survey that actually validates an idea: pick one clear question you need answered, ask about real past behaviour rather than hypothetical opinions, keep it to five to seven questions, send it to people who fit your target user, and test willingness to pay before you read a single "I would love that." The survey is a filter, not proof; treat strong answers as a reason to talk to those people, not a reason to start building.

I have shipped 7 apps over 8 years, and the surveys that helped me were short, behavioural, and aimed at the right people. The ones that wasted my time were long, full of "would you use this" questions, and answered by whoever happened to be friendly. Here is how to run the first kind.

Table of contents

• When a product survey actually helps
• How to run a product survey in six steps
• The questions to ask (and the ones to skip)
• How many responses you actually need
• Where to run it: survey tools at a glance
• Where Lighthouse fits
• FAQ

When a product survey actually helps

A product survey is good at one thing: getting structured answers from a lot of people quickly, so you can spot patterns. It is bad at depth, nuance, and catching the thing you did not think to ask. So a survey helps when you already have a specific question and a group of real users to ask, and it hurts when you use it to decide whether an idea is worth building at all.

A 20-minute conversation with one real user beats a 50-question survey filled out by fifty strangers. Use the survey to find who is worth that conversation.

The classic mistake, straight out of Rob Fitzpatrick's The Mom Test, is asking people about your idea. People are kind, so they lie. They tell you they would use it and they would pay, and then they do not. Surveys make this worse because you cannot ask a follow-up. The fix is to ask about their life and past behaviour, not your idea, which is the whole point of the next two sections.

How to run a product survey in six steps

1. Write down the one decision the survey will inform. Not "learn about users" but something like "decide which of these three problems to build for first." If you cannot name the decision, you are not ready to send a survey.
2. Pick who you are asking. Answers from the wrong people are worse than no answers, because they feel like data. Aim the survey at people who have the problem now, not a general audience who might one day care.
3. Draft five to seven questions, mostly about behaviour. Ask what they do today, what it costs them, and what they have already tried or paid for. One open-text question at the end catches what you missed.
4. Test it on two or three people first. Watch them answer if you can. You will catch confusing wording, leading questions, and broken logic before it reaches the whole list.
5. Send it where your users already are. A relevant subreddit, a Slack or Discord community, your waitlist, or a few direct messages beat a cold blast every time. Tie it to a signup so you keep the people who respond.
6. Read for patterns and willingness to act. Look for a problem that keeps coming up and for people who took a concrete step, not just those who said nice things. Then go talk to them.

The questions to ask (and the ones to skip)

The best product survey questions ask about real, past behaviour. The worst ask people to predict their own future, which they are terrible at. Here is the swap, side by side:

For pricing, do not ask "would you pay $9 a month." Use the four Van Westendorp questions instead: at what price is this too cheap to trust, a good deal, getting expensive, and too expensive? Those four answers give you a believable range instead of a yes or no you cannot trust.

If money has never changed hands, you have a compliment, not validation. The strongest survey answer is "here is what I already pay for this."

How many responses you actually need

Fewer than you think, if you ask the right people. You are looking for a clear signal, not statistical significance. A common rule of thumb for early validation is that you want at least 40% of the people you ask to describe the problem as real and recurring; below that, the signal is too weak to build on.

• 30 to 50 targeted responses is usually enough to see whether a problem is widespread or just yours.
• Quality of respondent beats quantity. Twenty answers from people with the problem tell you more than two hundred from a random audience.
• Watch the willingness-to-pay answers hardest. A problem lots of people have but nobody pays to solve is a hobby, not a product.

Where to run it: survey tools at a glance

Almost any tool can hold a survey. The real question is what happens to the answers afterward. If you also want to keep the people who responded so you can follow up, that narrows it down.

For a deeper comparison of the form builders, see my Typeform alternatives for indie founders rundown. For a pure one-off survey, Tally or Google Forms is the simplest place to start.

Where Lighthouse fits

Lighthouse is built for the case where the survey is step one of getting your first 100 users, not a one-off form you export and forget. You attach survey questions to a waitlist signup, so every answer arrives attached to a real person you can email later, and the responses become segmentable data instead of a spreadsheet.

• Validation and audience in one pass. The same signup that captures the survey answer also captures the email, so the people who told you what to build are the people you launch to.
• Segment by answer. Email just the people who said they already pay for a workaround, without exporting and re-importing a list.
• Flat pricing. Free to start, $19/mo Starter, $29/mo Pro, with an API on Pro to send in-product survey answers straight into the same dashboard.

If you only need a quick standalone survey, use Tally or Google Forms and move on. Lighthouse is the better fit when the answers are meant to build a list, not just a chart.

Watch: validating before you build

A survey is only as good as the thinking behind it. Short context on validating an idea and asking the right questions before you commit months of work:

Frequently asked questions

How many questions should a product survey have?

Five to seven is the practical ceiling for a validation survey. Every extra question lowers your completion rate, and you can always follow up with the people who matter. Keep one open-text question at the end to catch what you did not think to ask.

Are surveys good for validating a startup idea?

Only partly. Surveys are good for spotting patterns and ranking problems among people who already have them, but they are weak for deciding whether to build at all, because people answer hypothetically. Use a survey to find who is worth a real conversation, and treat willingness to pay as the only answer that counts.

What is the best free tool to run a product survey?

Google Forms for a plain free survey with no response cap, or Tally for a more polished public-facing one, also free. If you want the answers tied to a waitlist you can email later, Lighthouse does the survey and the list together.

How do I ask about pricing in a survey?

Skip "would you pay X." Use the four Van Westendorp price questions (too cheap, good value, getting expensive, too expensive) to get a range, and weight it against what people say they already pay to solve the problem today.

A good product survey will not tell you to build something. At best it points you at a real problem and a handful of people worth talking to, and it filters out the polite "sounds great" noise. Keep it short, ask about what people actually do, watch the money, and treat the results as the start of a conversation rather than the end of one.

Lighthouse lets you run a survey inside a waitlist, so the answers and the people who gave them land in one place, free to start. From an indie dev, for indie devs and makers.