TL;DR:
Validation is not an opinion poll. Positive feedback on a prototype means nothing without testing the economics.
Test your prototype using real user data, not polished demos.
Ask questions that reconstruct past behavior, expose perceived alternatives, and measure true willingness to pay.
What are product validation questions?
Product validation questions are targeted questions asked during concept or prototype testing to measure a solution's business viability. As a later-stage subset of customer development questions, they shift the focus from discovering the user's problem to testing their actual willingness to pay, usage frequency, and perceived alternatives.
You show a polished prototype to a prospect. They click through the screens and smile. "This looks great," they tell you. "I would definitely use this." You end the call, feeling validated.
You just collected a polite lie.
The prospect liked the design. But you never asked what tool this replaces. You never asked how often this workflow actually happens. You never asked who holds the budget, what happens if the problem stays unsolved, or if they would take out a credit card today. You tested your own belief, not the buyer's reality.
Validation questions shift the conversation from "do you have this problem?" to "would you pay for this solution?" While discovery proves the pain exists, validation tests if your proposed solution is valuable enough to buy. You can learn more about this distinction in our guide on lean product discovery for B2B. For more on structuring these early conversations, Rob Fitzpatrick's The Mom Test offers excellent advice on how to talk to customers.
Economics Over Mechanics
When founders test prototypes, they often look for usability friction or UI reactions. A prototype can pass a usability test and still fail validation if users do not see business value. You should absolutely fix friction and workflow fit, as detailed in our product discovery UX guide for founders. But do not stop there.
You need to know how this fits their actual workflow, what they compare it to, and if they will pay. Steve Blank covers broader strategies on customer development, but when you do have a prototype, economics are everything.
The Prototype Validation Call Script
Do not test your concept using a famous-company demo or a tidy dataset. Have the user run their own messy, real-world data through the prototype. Watch what the system actually does for them. NNGroup breaks down user interviews well, emphasizing the need to get real context.
Here is the script to run when you show a concept:
Test workflow fit: Instead of asking "Does this make sense?", ask "Show me what happened the last time you tried to do this." Watch where they pause or mistrust the output.
Test perceived alternatives: Instead of asking "How do you like this feature?", ask "What do you use today to handle this?" This uncovers your real competition and category.
Test usage frequency: Instead of asking "Would your team use this?", ask "How often does this exact workflow happen?" This tests if the pain supports a subscription model.
Test willingness to pay: Instead of asking "Would you pay for this?", ask "What does your current workaround cost you?" This determines the monetary value the product creates.
Test commitment: Instead of asking "Can I follow up when we launch?", ask "What is the concrete next step to get this into your workflow next week?" This tests if the pain is urgent enough to act on now.
You can build these questions into a broader system to turn answers into clear pass/fail criteria. See our product validation plan guide for details.
Category Framing Determines Price
When you ask users what alternative they compare your concept to (as shown in the script above), you uncover your category. If a buyer thinks of your product as a software tool, they expect to pay software prices. If they see it as a replacement for human services, the perceived value jumps. Framing the right category is the difference between charging $10 and $100.
Warning: Avoid Opinion Polling
Founders often overcomplicate product validation questions by asking hypotheticals. "What do you think?" and "How do you like it?" produce polite feedback, not actionable data. Useful questions focus on hard economics and past behavior. Always test on realistic target companies, not massive brands that do not represent your actual buyer's reality.
FAQ
What are the best product validation questions to ask?
The best questions reconstruct past behavior and test economics. Ask: "Show me what happened the last time you tried to do this," "What do you use today to handle this?", and "What does your current workaround cost you?" Avoid hypothetical questions like "Would you use this?"
How do I avoid polite feedback during prototype testing?
Stop asking hypothetical questions like "Would you use this?" or "What do you think?" People will lie to spare your feelings. Replace hypotheticals with questions about past behavior and hard economics. Ask them to show you the last time they tried to solve the problem and how much the current workaround costs.
Should I test my prototype with large, famous brands to get better validation?
No. Test on realistic target companies that match your ideal customer profile. Large brands often have unique workflows and massive budgets that do not represent the actual use case for your primary market.
What if the user loves the product but only needs it once a year?
You have validated the pain, but you have likely invalidated a monthly subscription model. Usage frequency dictates your pricing model. If the task happens annually, you need to charge a large one-time fee or find a different use case to support recurring revenue.
