# How to Get Brutal Feedback From Makers Before You Launch Publicly
> A practical playbook for solo makers to collect honest product feedback from other builders before a public launch—without a big audience or launch-day theater.

```yaml
url: "https://makerhunt.io/studio/how-to-get-brutal-feedback-from-makers-before-you-launch-publicly"
markdown: "https://makerhunt.io/studio/how-to-get-brutal-feedback-from-makers-before-you-launch-publicly.md"
title: How to Get Brutal Feedback From Makers Before You Launch Publicly
type: studio_article
category: Growth
tags: "growth, feedback, makers, launch"
featured_image: "https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx93gxZjV1duKC2cTLjUHtkW4FmRlen8BZa9JpY"
published_at: "2026-09-24T09:54:00.000Z"
updated_at: "2026-09-24T09:55:53.950Z"
```

## About this studio article

A practical playbook for solo makers to collect honest product feedback from other builders before a public launch—without a big audience or launch-day theater.

## Article

You finally show the product to someone. They smile. They say “looks great.” They ask when you are launching. You leave the call feeling validated — and still have no idea if the product actually works for anyone but you.

Polite praise is expensive. It burns the weeks before a public launch on confidence that was never tested. Then you ship to silence: a few courtesy clicks, zero retained users, and a comment thread full of “congrats” with no one who can describe the job your product does.

This playbook is for solo makers who want brutal, useful feedback from other builders before a public launch week — without a big audience, without theater, and without rebuilding the whole product every time someone has an opinion.

## Why most early feedback is useless

Not all feedback is equal. Most of what you get before launch is designed to protect the relationship, not the product.

- **Friends and family** do not want to hurt you. They compliment the logo, the landing page, and the “hustle.” They skip the hard path through the product.
- **Social likes** reward a clean screenshot, not a finished job. A like is not a user completing the core workflow without you narrating it.
- **Vague praise** — “cool product,” “this is interesting,” “would love to try later” — has no decision value. You cannot ship a fix for “interesting.”
- **Feature shopping** — “can it also do X?” — feels energetic, but it often comes from people outside your ICP who will never pay.

Useless feedback shares one pattern: it never names a stuck point, a missed outcome, or a moment where the product failed a real job. Brutal feedback does. Your job is to design for that kind of honesty on purpose.

## Who to ask (makers who feel the pain)

Ask people who already live inside the problem — not people who are nice to you online.

### Good candidates

- Makers who publicly complained about the exact workflow you claim to fix
- Builders who shipped a related tool and still do the job manually for clients
- Indie hackers in your ICP who recently launched and are still close to the pain
- Two “almost ICP” users on purpose — they expose confusing positioning fast

### Skip for now

- Anyone who only wants early-access bragging rights
- Friends who will soft-pedal because they know how hard you worked
- Random followers who never described the problem in their own words
- Competitors fishing for roadmap screenshots

A useful rule: if they cannot finish this sentence before seeing your product — “Right now I waste time when I try to ___” — they are not ready to give product feedback. They can still cheer. Cheer is not the goal.

## How to ask so you get brutal honesty

People default to kindness. You have to make honesty the easier social move.

### Frame the ask

Lead with permission to be blunt, a tight time box, and a clear job for them to attempt:

> I’m not looking for encouragement. I need 20–30 minutes of honest product feedback before I launch publicly. Can you try to [core job] without me guiding you, then tell me where it broke or felt fake? Brutal is useful. Polite is not.

That sentence does three things: it lowers the social cost of criticism, it defines success as completing a job, and it makes “looks nice” feel off-brief.

### Scripts that work

**Cold-ish DM to a maker who posted about the pain:**

> Saw your note about [pain]. I built a rough tool for that. Not launching publicly yet — looking for 3 makers who feel this weekly to try the core flow and roast what’s broken. 25 minutes, no screenshots required. Interested?

**After they agree:**

> Here’s the link. Goal: [one sentence job]. Please don’t ask me questions until you’ve tried once. Then tell me: (1) what you expected, (2) where you got stuck, (3) whether you’d pay for this job today — and why not if not.

**After a soft session that stayed polite:**

> Thanks — one more push. If a friend asked whether to use this tomorrow for [job], what would you warn them about? Be specific.

### Constraints that improve signal

- Cap sessions at 25–30 minutes so people go deep on one path
- Ask them to complete one job, not tour every screen
- Record (with permission) or take timestamped notes — memory lies
- Offer a small thank-you (credit, free month, or a reciprocal review) so the ask feels fair
- Never defend the product live. Write “noted” and keep watching

## Where to find makers who will tell you the truth

You do not need 10,000 followers. You need 8–15 honest makers.

- **Weekly launch communities** — people already in “ship and try” mode. Browse what’s live on [MakerHunt launches](https://makerhunt.io/launches), comment usefully for a few days, then DM makers whose products sit next to your ICP.
- **Maker directories and hunt sites** — places where builders submit and test each other’s work. The [MakerHunt homepage](https://makerhunt.io/) is built for that rhythm; use it to find active shippers, not to beg for upvotes.
- **Submit your own early build** when you want structured attention from makers who browse new tools — the [MakerHunt submit flow](https://makerhunt.io/submit) is for shipping into that crowd, not for replacing private feedback sessions.
- **Niche Slack/Discord rooms** where people already compare workflows
- **Indie Hackers threads** where someone described your exact pain — reply helpfully first, then ask privately (community norms matter; see [Indie Hackers](https://www.indiehackers.com/))

Warmth beats volume. Five sessions with makers who feel the pain beat fifty polite replies from strangers.

## A 10-day feedback loop before public launch

Use this as a closed loop. Adjust to 7 days if the product is tiny; stretch to 14 if support load is heavy. Do not invent a third week of “just one more feature.”

**Days 1–2 — Write the job and the kill criteria**

Write one sentence: “A [role] should be able to [job] in [time], without me, and get [outcome].” Then write kill criteria: if fewer than X of Y testers finish the job by day 8, you delay public launch. Put both sentences somewhere you cannot ignore.

**Days 2–3 — Recruit 8–15 makers**

Send 20 personal asks to land 8–15 yeses. Batch them. Prefer makers who already named the pain. Share the job sentence in the invite so cheerleaders self-select out.

**Days 4–6 — Run sessions, ship only top blockers**

Do 2–3 sessions a day max. After each day, list blockers. Ship the two changes that would have unblocked the most people. Announce fixes to the group in one short note. Do not add a new feature branch while testers are mid-loop.

**Day 7 — Midpoint truth check**

Count: invited, started, finished the core job, said they would pay (or named a clear price objection). Interview three finishers and three stallers with the same three questions: expected vs actual, first stuck point, pay-or-not reason.

**Days 8–9 — Interpret, then cut**

Group feedback into: clarity bugs, workflow holes, positioning misses, and wishlist noise. Fix clarity and workflow. Park wishlist. If positioning is wrong, rewrite the first screen and the one-sentence job before you touch the backend.

**Day 10 — Go / no-go**

Public launch only if your kill criteria cleared and at least a few makers can explain the product’s job in their own words. If not, you still won — you avoided a silent launch week. Extend the loop or narrow the ICP. Read more maker-facing playbooks in the [MakerHunt Studio](https://makerhunt.io/studio) when you want adjacent shipping tactics.

## How to interpret feedback without rebuilding everything

Brutal feedback can still send you in circles if you treat every comment as a roadmap item.

1. **Count frequency, not volume.** Three people stuck on the same empty state beats one passionate essay about a niche edge case.
2. **Separate “broken” from “missing.”** Broken means they tried the promised job and failed. Missing means they imagined a different product. Fix broken first.
3. **Watch behavior over opinions.** If they say “I love it” but never finish the job, believe the incomplete job.
4. **Price objections are data.** “Too expensive” without a finished job is usually value clarity. “I’d pay $Y if it did Z” is a prioritization clue, not an order.
5. **One change at a time.** If you ship five fixes between sessions, you learn nothing about which one mattered.

Keep a simple board with four columns: Clarity, Core workflow, Positioning, Later. Most pre-launch weeks should stay in the first three.

## Weekly checklist (run this until launch)

- Rewrite the one-sentence job if testers describe a different product than you think you built
- Book or confirm at least three honest maker sessions this week
- Run sessions with the “no guiding until first attempt” rule
- Log stuck points with quotes, not paraphrases
- Ship at most two blocker fixes before the next batch of sessions
- Ask every finisher: would you pay for this job this month — why or why not?
- Protect kill criteria; do not move the goalposts because a launch date is on the calendar
- Thank makers publicly only with permission; private credit is fine

## Close the loop before you open the curtain

Public launch is a distribution event. Feedback is a product event. If you mix them, you get applause without learning — or criticism too late to use.

Get a small set of makers who feel the pain. Make honesty cheap. Watch them try the job. Fix what blocks the job. Ignore the rest until the core path is boringly reliable.

When strangers show up on launch week, you want them to hit a product that already survived people who were willing to tell you it was wrong.

![image](https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx93P4C3R1duKC2cTLjUHtkW4FmRlen8BZa9JpY)![image](https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx9KUL9UV0h7ago5xuVX3wrym1lZ9DEkY8UWezC)

## Links

- Article (HTML): https://makerhunt.io/studio/how-to-get-brutal-feedback-from-makers-before-you-launch-publicly
- AI-friendly Markdown: https://makerhunt.io/studio/how-to-get-brutal-feedback-from-makers-before-you-launch-publicly.md

## Explore

- [Studio index](https://makerhunt.io/studio)
- [Blog](https://makerhunt.io/blog)
- [Browse projects](https://makerhunt.io/projects)

_HTML version: https://makerhunt.io/studio/how-to-get-brutal-feedback-from-makers-before-you-launch-publicly_