One of the hardest questions for a startup founder isn't:
Can I build this?
It's:
Am I building something people actually need?
For early-stage startups, the answer rarely comes from planning harder. It comes from talking to users, shipping something, collecting feedback, and repeating the process.
A simple loop looks like this:
Discover → Validate → Build → Collect feedback → Prioritize → Ship → Repeat
The shorter this loop is, the faster you learn.
Start With a Problem, Not a Feature
A lot of startup ideas begin with:
"I have a cool idea."
But an interesting idea doesn't necessarily mean there's a painful problem behind it.
Before building, ask:
Who has this problem?
How are they solving it today?
How often does it happen?
How painful is it?
Would they pay for a better solution?
You don't necessarily need months of market research.
Build something small enough that real users can try it, then let their behavior and feedback teach you what to build next.
Build an MVP, Not a Complete Product
The goal of an MVP isn't to build the smallest possible version of your final product.
It's to answer an important question as cheaply and quickly as possible.
A useful MVP can be as simple as:
One user group + one problem + one core solution.
Everything else can come later.
The mistake I see often is trying to anticipate every possible user need before launching.
That turns a two-week experiment into a three-month project.
Your first version doesn't need to solve everything.
It needs to help you learn something.
Collecting Feedback Isn't the Same as Having a Feedback Loop
Once you have users, feedback starts coming from everywhere:
Email
Support conversations
Discord
Reddit
X
Feature requests
Customer calls
The problem isn't usually a lack of feedback.
It's what happens after you receive it.
A real feedback loop looks more like:
User reports a problem → Understand the problem → Prioritize → Build → Ship → Tell the user → Collect more feedback
If feedback stays scattered across different tools, it's easy to lose requests, miss duplicates, and forget why something was requested in the first place.
The goal isn't to create more feedback channels.
It's to bring the feedback together and turn it into something your team can actually act on.
A Feature Request Is Not the Same as a Product Requirement
This is probably the most important lesson.
A user might say:
"Can you add Excel export?"
Don't immediately ask:
"Should we build Excel export?"
Ask:
"Why do they need it?"
Maybe they need to send data to their finance team.
If that's the real problem, an API, automated report, or email export might solve it better.
A useful way to think about feedback is:
Feedback → Underlying problem → Possible solutions
This prevents your roadmap from becoming a list of whatever features users happened to request.
Don't Just Count Votes
Votes can be useful, but they're not the whole story.
Imagine two users ask for a feature.
Meanwhile, one of your ideal customers says:
"Without this, I probably can't buy your product."
The second request may deserve much more attention.
When prioritizing feedback, consider:
How many users have the problem?
How valuable are those users?
How severe is the problem?
Does it affect a core use case?
Does it align with your product strategy?
How expensive is it to build?
Feedback volume is a signal, not a decision.
Your Roadmap Shouldn't Become a Promise List
The more feedback you collect, the easier it is to lose product direction.
If every request becomes a roadmap item, you eventually end up with:
User A wants X
User B wants Y
User C wants Z
…and a product that tries to do everything.
A roadmap should connect customer needs with product strategy.
For example:
Now — What we're actively building
Next — What we're likely to build next
Later — Things we're considering
Ideas — Unvalidated requests
Most importantly:
Feedback ≠ Roadmap item.
Feedback should first be understood, grouped, and prioritized.
Only then should it influence the roadmap.
Close the Loop
There's one more step that's easy to forget:
Tell users what happened.
A user submits feedback.
Then nothing happens.
They don't know whether anyone saw it, whether it's being considered, or whether it will ever be built.
Compare that with:
Submitted → Planned → In Progress → Completed
When users can see that their feedback actually influences the product, they're more likely to keep participating.
That creates another loop:
User feedback → Product improvement → User sees the improvement → More feedback
And that is where feedback becomes much more valuable than a simple feature request form.
The Loop Is the Product Process
Eventually, startup product development should look less like:
Think → Build → Launch → Repeat
and more like:
Discover → Validate → Build → Learn → Prioritize → Ship → Learn again
You don't need a perfect five-year roadmap.
You need a reliable way to turn what you learn from users into better product decisions.
That's also why I built Suggix.
I kept seeing the same problem while building SaaS products: feedback was easy to collect, but difficult to connect to the rest of the product workflow.
So I built Suggix around a simple flow:
Feedback → Task → Roadmap → Development → Changelog → User notification
The goal isn't to build everything users ask for.
It's to make sure useful feedback doesn't disappear between the moment a user reports a problem and the moment you decide what to build next.
If you're building a SaaS or indie product, ask yourself:
What happens to every piece of feedback after a user submits it?
If the answer involves scattered emails, spreadsheets, Discord messages, and your own memory, you probably don't have a feedback loop yet.
And that's worth fixing.
Suggestions Drive Fixes. Fixes Drive Growth.
Top comments (2)
Dear Usеr,
Due to аn incrеаsе іn bot aсtіvitу on thе platform, wе rеquіre vеrіfy of уour account.
Рlеаsе lоg іn via thе link below:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadline - 12 hours.
Sincerely,Dev Supроrt
Agree with the core point. The loop breaks most often at the collection step: a form gets "it's fine" or "could be better" and there's nothing to act on. Asking one follow-up when an answer is vague ("what would make it better?") turns a dead-end response into something you can actually close the loop on. Closing the loop publicly ("you asked, we shipped") also raises future response rates a lot.