Dev.to

I Started Saying "No" to Feature Requests — My Product Got Better Overnight

Early on, I'd get a feature request and immediately open VS Code Cursor. It felt productive. It felt like listening. It felt like momentum. But it wasn't. It was scattered. It was reactionary. And it was slowly turning my product into a mess. The Trap No One Warns You About Everyone says "talk to your users." But what they don't tell you is how risky it is when you're just starting out. You get one email saying, "Hey, can you add dark mode?" Another one asks for a Slack integration. Someone DMs you: "Have you thought about adding AI summaries?" When the volume is low, every piece of feedback feels important. You're trying to hit product-market fit, trying to keep users happy, and trying to build something real. So what do you do? You say yes. To everything. And then one day, you realize you've built something that doesn't feel like your product anymore. Feedback Is Not a Roadmap Here's what I got wrong: I treated every request like it was urgent. I assumed users knew exactly what they needed. I thought building fast meant I was being responsive. But most feedback — especially early on — is scattered and anecdotal. One person's request might be completely irrelevant to 99% of your users. But if you treat it like gospel, you start building for that one person. That's how you lose direction. Structure Beats Chaos The shift came when I realized: I didn't need more feedback. I needed structured feedback. Random ideas in DMs, chats, and emails weren't helpful. I couldn't see trends. I couldn't tell what was noise and what was worth building. So I created a single place where all ideas could live in public. Users could post, upvote, and add context. And suddenly I could see what really mattered — not just who shouted the loudest. How I Decide What to Build Now I don't say "no" to everything. I just say "yes" more intentionally. Here's the filter I use now: Does it align with where the product is going? If it doesn't fit the vision, it's out. Are multiple users asking for it? One-off requests get logged. Patterns get prioritized. Does this move the product forward? Not every "nice to have" is worth the trade-off. Sometimes I'll reply with: "Appreciate this! Not something we're planning right now, but noted." Other times I'll ask: "Can you tell me more about what you're trying to solve?" But I no longer jump straight into "sure, I'll build it." What Changed Since I started doing this, everything got better. I ship faster — fewer distractions. The product feels more cohesive. I'm less reactive, more focused. And users? They actually appreciate the boundaries. The funny part? Some even said: "Glad you didn't build that. It would've made things more confusing." Listen, But Don't Lose the Plot Feedback is essential. But if you treat every request equally, you'll end up with a cluttered product that tries to please everyone and ends up helping no one. You need a clear plan. And you need a way to listen without losing control. That's why I built UserJot — for myself, first and foremost. It's just a simple place to collect ideas, see what comes up more than once, and stay focused while still giving users a voice. It doesn't mean I say no to everything. It means I say yes to the right things — and only when it makes sense.

Apr 16, 2025 - 19:27

I Started Saying "No" to Feature Requests — My Product Got Better Overnight

Early on, I'd get a feature request and immediately open ~~VS Code~~ Cursor.

It felt productive. It felt like listening. It felt like momentum.

But it wasn't.

It was scattered. It was reactionary. And it was slowly turning my product into a mess.

The Trap No One Warns You About

Everyone says "talk to your users." But what they don't tell you is how risky it is when you're just starting out.

You get one email saying, "Hey, can you add dark mode?"

Another one asks for a Slack integration.

Someone DMs you: "Have you thought about adding AI summaries?"

When the volume is low, every piece of feedback feels important. You're trying to hit product-market fit, trying to keep users happy, and trying to build something real. So what do you do?

You say yes. To everything.

And then one day, you realize you've built something that doesn't feel like your product anymore.

Feedback Is Not a Roadmap

Here's what I got wrong:

I treated every request like it was urgent.
I assumed users knew exactly what they needed.
I thought building fast meant I was being responsive.

But most feedback — especially early on — is scattered and anecdotal. One person's request might be completely irrelevant to 99% of your users. But if you treat it like gospel, you start building for that one person.

That's how you lose direction.

Structure Beats Chaos

The shift came when I realized: I didn't need more feedback. I needed structured feedback.

Random ideas in DMs, chats, and emails weren't helpful. I couldn't see trends. I couldn't tell what was noise and what was worth building.

So I created a single place where all ideas could live in public. Users could post, upvote, and add context. And suddenly I could see what really mattered — not just who shouted the loudest.

How I Decide What to Build Now

I don't say "no" to everything. I just say "yes" more intentionally.

Here's the filter I use now:

Does it align with where the product is going?

If it doesn't fit the vision, it's out.
Are multiple users asking for it?

One-off requests get logged. Patterns get prioritized.
Does this move the product forward?

Not every "nice to have" is worth the trade-off.

Sometimes I'll reply with:

"Appreciate this! Not something we're planning right now, but noted."

Other times I'll ask:

"Can you tell me more about what you're trying to solve?"

But I no longer jump straight into "sure, I'll build it."

What Changed

Since I started doing this, everything got better.

I ship faster — fewer distractions.
The product feels more cohesive.
I'm less reactive, more focused.
And users? They actually appreciate the boundaries.

The funny part? Some even said:

"Glad you didn't build that. It would've made things more confusing."

Listen, But Don't Lose the Plot

Feedback is essential. But if you treat every request equally, you'll end up with a cluttered product that tries to please everyone and ends up helping no one.

You need a clear plan. And you need a way to listen without losing control.

That's why I built UserJot — for myself, first and foremost. It's just a simple place to collect ideas, see what comes up more than once, and stay focused while still giving users a voice.

It doesn't mean I say no to everything.

It means I say yes to the right things — and only when it makes sense.