Before You Ask for Product Feedback, Name the Decision

Before you ask for product feedback, write down the decision you need to make. Then ask the right person to try a specific task or describe a real experience that could change that decision.

“Any feedback?” gives someone a lot of work. Should they review your landing page, test your signup flow, suggest features, or tell you whether they need the product at all?

A smaller question gives them a useful place to start. It also gives you a way to decide what to do with the answer.

Start with the choice in front of you

Suppose you’re building a tool that imports customer records from a spreadsheet. This is a hypothetical example, but the decision is familiar: should you build automatic column matching, or improve the instructions for the importer you already have?

“What do you think of my app?” won’t settle that choice. A specific task might reveal whether people understand the current flow:

“If importing customer spreadsheets is part of your work, could you try bringing this sample file into the demo? Tell me what you expect to happen and where anything becomes unclear. Please use the sample data.”

Notice that the request doesn’t tell the person which button to press. The UK government’s guide to usability testing recommends realistic tasks with a clear goal and neutral instructions that leave participants to work out the steps.

Match the question to what you need to learn

Watching someone complete an import can reveal confusing labels or a missing error message. It doesn’t establish that they need another import tool.

For that, ask about their current work: when did they last import a customer file? What did they use? Where did it become difficult? How did they finish?

The UK government’s interview guidance recommends open questions, follow-ups, and concrete stories from people’s experience. Apply that here before pitching the feature you hope they’ll want.

A founder who doesn’t handle customer records can still spot a broken button. Their opinion about whether to buy an importer answers a different question from the one your likely customer can answer.

Decide how you’ll interpret the answer

For the importer example, keep three possible outcomes separate:

• They need help understanding the labels. Revise the wording and test the same task again before committing to automatic matching.

• They understand the flow, but mapping columns creates repeated work. Investigate that work with more likely users and test a simpler mapping approach.

• They rarely import files and already have an easy workaround. Find out whether you’re speaking to the intended customer and whether the problem deserves more investment.

These are possible next steps, not findings. One session can expose a problem worth investigating; it doesn’t tell you how common that problem is across your market.

Give your next feed post one clear job

Include who you want to hear from, what you want them to try, and what you’re trying to decide. For example:

“I’m deciding whether to improve the instructions in our CSV importer or redesign column mapping. Looking for founders who regularly import customer records. Could you try the sample file and tell me where you hesitate? I’ll share what changes after testing.”

Keep an open invitation for anything unexpected, too. A focused test shouldn’t make you ignore a problem you didn’t anticipate.

When you follow up, explain what you changed and which questions remain. That gives the people who helped a visible result and gives your next request some context.

What’s one product decision you’re trying to make this week, and what would you need to learn to make it?