How to ask for startup feedback you can actually use

01. Name the question before you choose the forum.

“Any feedback on my startup?” leaves readers to choose the problem for you. One person may critique the logo while another proposes a different business. Both can be sincere and still leave your next decision unresolved. Begin with a sentence that names what you are trying to learn and what you might change as a result.

Separate three kinds of request. A clarity request asks what someone understands from an explanation. A usability request asks what happens when someone attempts a task. A problem-discovery request explores how someone currently handles a situation. These are useful editorial categories for preparing the conversation, not a comprehensive research methodology.

For clarity, you might ask a reader to describe the intended customer after seeing the opening of a page. For usability, you might ask someone to try a defined action and describe their expectations. For discovery, you might ask about the last relevant situation they experienced. Choose the request that fits your uncertainty instead of collecting an assortment of reactions.

02. Match the person to what they can help you learn.

A founder peer can question your explanation or suggest an approach they have tried. A designer may help you inspect an interaction. Someone who does the customer’s actual job can explain the context in which your idea would need to work. Record which perspective you are hearing before treating the reply as evidence about your intended buyer.

For example, a general startup community may be a reasonable place to ask whether your product description makes sense. It is less direct evidence about how a specialist team handles its daily work. You can still learn from the discussion, but the next step may be speaking with someone who does that work rather than adding the most requested feature.

Our editorial view is that one well-matched conversation is often a better next task than distributing the same vague request across many communities. This is a judgment about focus, not a claim about response rates. A focused request can still receive no answer, and a helpful reply still needs to be interpreted in context.

• Clarity: ask what the reader thinks the product does and who it is for.
• Usability: give a relevant participant a task and observe what happens.
• Discovery: ask someone with relevant experience to describe a real situation.

03. Check the community’s current format before posting.

A venue’s rules determine whether your request belongs there. The r/startups Feedback Friday thread inspected for this guide asks contributors to use its template and seek feedback rather than general promotion. It also asks people to provide context instead of dropping a link. Use the current thread’s instructions when you post; this dated example is not permission to post the same request anywhere on Reddit.

Show HN serves a different purpose. Its official guidelines describe work other people can try, and exclude landing pages and fundraisers from that format. An idea description and a working product therefore need different submission decisions. Check the full current guidelines rather than treating every launch community as an interchangeable place to advertise.

The preparation note below is deliberately format-neutral. Use it to collect the substance, then adapt it to the venue’s required fields. If the requested information is not appropriate to share publicly, change the scope or seek a suitable private conversation. Never include credentials, private customer material or another person’s details just to make the example look complete.

FEEDBACK REQUEST PREPARATION

What I am building: [plain-language description].
Who it is for: [specific audience].
Current stage: [idea, demonstration or working product].
What someone can inspect or try: [shareable material].
The decision I am working on: [one concrete uncertainty].
The question I want help with: [focused, neutral question].
Relevant experience I am hoping to hear from: [person or perspective].
What I am not asking you to assess: [boundary].
My connection to the project: [honest disclosure].
Before posting: adapt this note to the community’s current required format.

Sources: r/startups: Feedback Friday thread and required format ↗ Hacker News: Show HN Guidelines ↗

04. Ask about the experience without supplying the answer.

Nielsen Norman Group explains that leading questions can influence participant feedback by suggesting the answer the interviewer expects. A request can sound friendly while still doing this. Review the wording for assumptions about the problem, the person’s feelings and the benefit your product is supposed to deliver.

Compare “Would our simple dashboard make your reporting easier?” with “How did you prepare the most recent report?” The first supplies a positive description and asks for a prediction. The second asks for an account you can explore. If the participant is trying the dashboard, ask what they expected at the point they paused instead of announcing that the navigation confused them.

Keep critique and discovery distinct. Asking an experienced founder to review your positioning is a request for their judgment; that can be valuable. Asking a potential customer about a recent workflow seeks a different kind of information. Label the conversation honestly, then resist turning either answer into a promise to buy.

• Ask the person to explain the situation in their own words before you summarize it.
• If they suggest a feature, ask what happened that made it important to them.
• When they describe a task, ask what they tried and what happened next.
• Leave room for an answer that challenges your preferred explanation.

Sources: Nielsen Norman Group: Avoid Leading Questions ↗ GOV.UK Service Manual: Using in-depth interviews ↗

05. Turn a broad reaction into a question you can investigate.

Imagine a fictional founder building a handoff tool for independent bookkeepers. She asks a general founder group to read her product description. A reader says the concept looks useful but wants a mobile app. This is an illustrative example, not a Solution customer story or a report of research findings.

The founder could interpret the comment as demand for a mobile build. A more careful record would say that a community reader understood something about the concept and suggested mobile access; their bookkeeping experience and reason for the suggestion are unknown. The useful follow-up is to ask what task they would want to complete away from a desk.

Suppose the reader replies that they are a software developer and personally prefer mobile tools. That supplies context for the suggestion, not evidence about bookkeepers. The founder can keep it as an idea and investigate the workflow with an intended user. Suppose instead the reader describes a recent handoff they handled while visiting a client. That is a specific account to explore, still not proof that a mobile product will sell.

In both cases the original reply helped identify a next question. The mistake would be losing the distinction between a suggestion, a relevant account and observed use of your product. Keep that distinction visible when you share what you learned with a cofounder or advisor.

06. Sort the replies before changing the product.

Read each useful reply for the perspective it represents, the concrete detail it supplies and the uncertainty it leaves. You can use the note below without assigning a score. It is our editorial aid for keeping evidence and interpretation separate, not a validated measure of product-market fit.

When replies conflict, first check whether the participants were answering the same question. A newcomer evaluating your headline and an experienced user describing a daily workaround may both be accurate. Different roles, stages and contexts can call for another conversation rather than a vote on which comment to obey.

Decide whether the reply supports a small revision, a clearer question, direct observation of a task or no immediate change. Thank people for their time and explain what you learned when appropriate. A public exchange does not imply permission to quote someone as an endorsement or subscribe them to updates.

FEEDBACK READING NOTE

Request we made: [the question and material shown].
Perspective: [relevant role or experience, or unknown].
Concrete detail: [what was actually said or observed].
Kind of information: [opinion, recent account, observed action or other].
Our interpretation: [what we currently think it means].
What remains unknown: [the gap this reply does not close].
Next investigation or change: [one action and its reason].
Public use: [whether permission is needed before sharing identifying details].

07. Use your network to reach the next relevant conversation.

Your next task may be finding someone with the experience the thread lacked. State that need plainly: you are exploring a particular workflow and want to understand how it is handled today. Avoid presenting a request for advice as a disguised sales approach or implying that someone has agreed to a longer relationship.

Solution is a social network for the startup ecosystem, including founders, mentors and operators. Exploring relevant people may help you identify a useful perspective. The app does not establish that a person is your target customer or that their feedback validates demand. Bring a specific question to the conversation and keep the limits of the answer visible.

Sources: Solution: The Hub For Startups ↗