Some of the best changes I’ve seen founders make on BuildHop started with “no, this is dumb.”
Anonymous feedback lands on their product, and they have thoughts. The person didn’t get it. That’s not who the product is for. They’d really just like a chance to explain.
Then, sometimes a couple of weeks later, a quiet update in the feed: “I ended up making that change.” And it works. Sometimes really well.
I love that moment. I’d also love for it to show up a lot sooner.
Meet the Defender
The Defender is a composite of a pattern I see a lot. Any resemblance to you is purely coincidental, unless you’re a founder who has ever received feedback.
I’ve been the Defender too. Months of work up against two sentences from a stranger is a rough matchup. You know every decision that went into the product. They know what happened when they tried to use it. It’s easy to start filling in everything they missed before considering what their experience might tell you.
Early on, people told us anonymous feedback couldn’t work because there was no way to follow up. So we built follow-up into the feed. Founders can respond there, and the person who left the feedback can reply while staying anonymous.
In the conversations I’ve had, wanting to talk directly was often less about a specific question and more about wanting a chance to explain why the feedback was wrong. I understand the impulse. Sometimes the feedback really does miss the point.
But if someone missed the point, I want to understand how that happened. Something I think is obvious might only be obvious because I built it. Before explaining what they should have understood, I can ask what gave them the impression they came away with.
That doesn’t commit me to making a change. It gives me a better basis for deciding.
Meet the People Pleaser
The People Pleaser has already agreed to make the change. Someone spent time with their product, and they want that person to know they listened.
There’s something generous about this instinct, but it can make a product difficult to steer. If every suggestion becomes a task, you eventually end up with a collection of requests and an increasingly fuzzy sense of what holds them together.
When someone asks for a dashboard, they might need one. They might also have struggled to find a single piece of information. Building the dashboard could solve that problem, but so could making the information easier to find.
The request gives you somewhere to start. You still need to understand what the person was trying to accomplish before choosing a solution.
You can appreciate someone’s feedback and take a different approach. You can also decide to leave things as they are. Listening doesn’t create an obligation to implement.
Meet the Detective
The Detective wants to understand what happened. They ask what the person was trying to do and where the experience stopped making sense.
This is a mode I’d like to spend more time in. A good follow-up can turn a vague reaction into a problem you can actually examine. It also gives you a chance to check your assumptions instead of building an explanation around them.
The trap is staying in the investigation after you have enough information to try something. There’s always another question you could ask, and a little more certainty would always be nice. Meanwhile, the confusing page is still confusing.
At some point, it helps to ask what small test you can run with what you already know. Changing a headline and asking someone new what they think the product does might teach you more than another round of discussion.
Meet the Experimenter
The Experimenter has shipped the change before everyone else has finished discussing it. I love that energy. Being willing to revise something you worked hard on is a real strength.
But a busy update feed doesn’t necessarily tell you whether the product is getting better. If you change several things at once, it can be hard to know what helped or why.
Before an edit, it helps to say what you think it will accomplish. “I think this change will help people understand who the product is for” gives you something to check afterward. You can put the new version in front of someone and see whether they understand it more clearly.
That small pause gives the work a purpose. It also makes the next round of feedback more useful, because you know what you’re trying to learn.
Meet the Preservationist
The Preservationist is keeping things as they are. Sometimes that’s good judgment. A suggestion might pull the product away from the people it’s meant to serve, or fixing the problem might require a tradeoff that isn’t worth making.
Founders need to be able to make those calls. But sometimes “it’s intentional” is covering for attachment or reluctance to revisit work we thought was finished.
I’ve been there too. Once you’ve invested time in a decision, reconsidering it can feel expensive before you’ve even looked at what would need to change. It can also be hard to admit that something you were proud of isn’t working the way you hoped.
What helps me is asking what keeping that choice does for the person using the product. If I have a clear answer, I can stand behind it. If my explanation is mostly about how much effort I’ve already put in, the decision probably deserves another look.
We can be all five in one afternoon
These are patterns, not permanent identities. You can defend your onboarding and immediately agree to a feature request. You can be thoughtful about one part of your product and deeply attached to another.
Naming these reactions helps me notice when they’re influencing a decision. Once I recognize the impulse to defend or agree, I have a better chance of returning to the experience the person described and considering what it means for the product.
Sometimes that leads to a change. Sometimes I need to ask a follow-up question, and sometimes I decide to keep going as planned. I want to arrive at that decision with a little more honesty about why I’m making it.
Better feedback gives founders more to work with
There’s another person in every one of these stories: the person leaving the feedback. The more clearly they describe their experience, the easier it is for a founder to do something useful with it.
“This is confusing” tells someone how you felt. “I clicked Pricing because I wanted to know whether I could afford it, but I couldn’t find a price” gives them a specific moment to examine.
You don’t need to design the solution or write a long review. Explain what you were trying to do and what happened. If it affected your decision to keep using the product, say how. One concrete observation can give a founder plenty to work with.
Positive feedback benefits from the same care. “I love it” is encouraging, but “the example helped me understand who this is for” tells someone what’s working and gives them a reason to preserve it.
Being specific also means you don’t have to make criticism harsher to make it honest. A plain account of your experience is enough.
A little sooner
That quiet “I ended up making that change” update is one of my favorite things to see on BuildHop. I don’t expect founders to skip the first reaction. I’d like to get better at noticing mine before it makes the decision for me.
So I’m trying to ask myself sooner whether I’m doing what’s best for my product, or for how I feel about my product.
If you’re building something, join BuildHop and put it in front of fresh eyes. And when you try someone else’s product, leave a specific observation they can use. You might help them make their next good decision, even if their first response is “no, this is dumb.”
