Before and after reaching product-market fit (PMF), the same "customer feedback" needs to be handled differently. This article covers how a pre-PMF product should approach customer feedback.
Feedback serves a different purpose before and after PMF
Once a product has reached PMF, a meaningful number of customers already recognize its value and keep using it. Feedback at that stage is mostly refinement material, input for prioritizing improvements and extensions.
Before PMF, you're still validating who the product is for and what problem it actually solves for them. Feedback at that stage isn't just improvement material; it's evidence for testing whether your assumed target and problem hypothesis were right. You might be looking at the same list of requests, but the question you're asking of it is different.
What happens when you try to satisfy everyone
Pre-PMF, the total volume of feedback tends to be low, which makes every request feel worth acting on. But if you respond broadly to requests before your target segment is settled, you risk accumulating features that are each a little underbuilt for everyone, because none of them were built with a single, sharply-defined user in mind.
Building something for a user outside your intended segment doesn't directly help you validate PMF, even if the feature itself works fine. You don't need to dismiss those voices, but it's worth asking, every time, whether a given piece of feedback is actually coming from inside your target segment.
Reading a small number of voices as signal
Because the absolute number of requests is low pre-PMF, prioritizing by volume mostly doesn't work, waiting for ten similar requests to show up before acting means missing the window to validate anything.
That shifts the weight toward reading each individual piece of feedback closely: who's affected, what situation they're in, what's frustrating them, and why they want a particular feature. Capturing that context carefully, one request at a time, is what compensates for low volume. We touch on this in "Counting Feature Requests Won't Tell You What to Build Next", and the argument applies even more strongly before PMF.
Investing in follow-up questions pays off more pre-PMF
Asking a follow-up question after someone submits a request, something like "what were you doing when this became a problem?", is a nice-to-have for a mature, post-PMF product. Pre-PMF, it's closer to a step that directly affects how accurate your validation is.
Feedury builds this follow-up step into the collection flow: after a post is submitted, AI can optionally surface a quick-pick question shaped by the product's stated background (who it's for, what problem it solves). The more weight a single piece of feedback carries, which is exactly the situation pre-PMF, the more that kind of follow-up tends to pay off.
Judging whether something actually landed
One of the harder calls pre-PMF is figuring out whether a feature you built actually landed well. With low request volume, raw vote counts alone are often too thin a signal to lean on.
In practice, two things are worth tracking: whether the customer who asked for it keeps actually using it, and whether other customers with the same underlying problem independently raise similar requests afterward. Watching what happens after you notify customers that a status moved to done is a useful extra data point here.
Wrapping up
For a pre-PMF product, customer feedback is validation material before it's refinement material. Reading each request closely, rather than treating low volume as a reason to skip that work, matters more before PMF than after it. If you want to see how a feedback collection flow like this actually works, take a look at the demo board.