Most successful product stories are told as a triumph of vision. We celebrate breakthrough ideas that seem to appear fully formed. But behind nearly every durable product is a quieter, more disciplined force: A small group of users whose feedback shaped the product long before it ever reached the market.
In Building a product roadmap: From high-level vision to concrete plans, I explored how strategy becomes real only when it is translated into execution. This next chapter focuses on an equally critical step: Ensuring what you execute solves real problems for real users, as opposed to theoretically building for the general market.
User feedback is not a checkbox, a beta program or a late-stage validation exercise. When done well, it’s a conviction-building mechanism. It sharpens product direction, surfaces hard trade-offs early and dramatically reduces the risk of building something impressive — that nobody needs. The devil is always in the details, and this article is about how to get those details right
Feedback is about conviction, not consensus
There is a persistent myth in product development that great products emerge, fully formed, from the mind of a visionary. Occasionally, that may be true. But even the most iconic product leaders experienced failure, misreads of the market and costly course corrections.
Most of us are not building products for the ether. We are building them for specific people, inside specific organizations, with real constraints and pain points. Conviction — the confidence you’re solving the right problem — has to come from somewhere. You either derive it from deep, lived experience as a user yourself, or you earn it by working closely with customers who are willing to tell you when you’re wrong.
This is where many teams stumble. They collect feedback broadly, but shallowly. Surveys go out. Advisory boards are assembled. Dozens of opinions are gathered — and yet, clarity remains elusive.
This is because early-stage feedback is not about volume. It’s about quality. A handful of deeply engaged users who care about the outcome of your product will teach you more than 100 passive respondents. These are not “testers,” they are development partners — people who want to help you succeed, because the problem you’re solving matters.
Finding the right feedback partners
The hardest part of leveraging user feedback is not the inability to listen. It’s finding the right users to listen to.
In my experience, the optimal number of early feedback partners for high-value B2B products is surprisingly small. Three to five is often enough. Anything more tends to produce diminishing returns. Anything less usually lacks sufficient perspective to validate direction.
This number will vary by product type. Consumer products or highly user-centric platforms may require a broader group. But for complex enterprise software, especially products with high switching costs or long sales cycles, a small, high-quality group is far more effective than a large, loosely engaged one.
What matters most is not whether these users will eventually buy your product, though that is ideal. What matters is their willingness to engage deeply and consistently. You want partners who are noisy, opinionated and invested — the ones who will challenge your assumption and push back when something doesn’t resonate.
Equally important is being selective. Not all customers are good feedback partners. Some are too busy, while others are too polite. Others want you to build only what works for them, regardless of broader applicability. Choosing partners who are excited to collaborate, and understand trade-offs, is critical.
If your leadership team is focused on quantity, it’s necessary to push back. Early-stage feedback works best when quality is rewarded over scale. If that mindset doesn’t change, focus your own time and energy on the most valuable partners, rather than trying to satisfy everyone. Appeasing stakeholders may feel safer, but long-term product success ultimately falls on you.
Early in my career, I didn’t push back when stakeholders pushed for working with “more” customers. I went along with it, and the result was a product that worked well once running but took weeks to set up. In a later role, I challenged that instinct and limited launch customers to just three. The outcome was a more robust product that was far easier to get started with. While the products were different, fewer customers meant deeper engagement, higher-quality feedback and better results.
Using feedback — before you build anything
One of the most overlooked opportunities in product development is using customer feedback before any meaningful development begins.
Too often, teams wait until they have something to show. By then, engineering effort has already been spent, architectural decisions have been made and emotional attachment has formed. Course correction becomes painful.
The most valuable feedback happens earlier — when ideas are still malleable. Sharing the strategy, roadmap and even the uncertainties with a small group of trusted users can dramatically reduce wasted effort. These conversations are not about asking users to design your product for you. They are about validating whether your framing of the problem resonates.
Research from Harvard reinforces this point, showing early customer involvement reduces the likelihood of large-scale pivots later in the development by identifying misalignment before costs compound.
At this stage, the goal is directional validation. Are you solving something meaningful? Are you prioritizing the right pain points? Are you ignoring constraints that matter deeply in real-world environments? If you cannot get a small group of users excited about your direction before you build, that’s a signal worth taking seriously.
Building with, not just for, your users
Once development begins, feedback shouldn’t taper off. It should intensify.
Your early partners should see your product regularly, even when it’s rough. Especially when it’s rough. Demos, prototypes and incremental releases provide opportunities to validate assumptions and adjust your roadmap in real time.
This requires discipline. It’s tempting to shield customers from unfinished work. But early-stage products are supposed to be incomplete. What matters is whether each iteration delivers incremental value aligned with the problems your partners care about most.
Listening well also means being transparent about constraints. Good partners understand that trade-offs are inevitable. They may not get everything they ask for, but they want to know why decisions are made. That transparency builds trust and keeps feedback constructive, rather than transactional.
Importantly, this does not mean trying to satisfy everyone. Building for too many users too early is a fast path to complexity and dilution. Focus on the core pain points shared by your small partner group. If those are real, they will generalize later.
Turning feedback into a stronger roadmap
User feedback is only valuable if it influences decisions. That influence should be visible in your roadmap.
Feedback-driven changes don’t have to be dramatic. Often, the most important insights are subtle: Reordering priorities, simplifying workflows or delaying features that initially sounded compelling but lack real urgency.
This is where feedback and roadmapping intersect. As discussed in my last article, roadmaps should balance near-term accuracy with longer-term direction. User input helps determine which milestones matter most in the near term — and which ideas can remain aspirational for now.
According to McKinsey research and timelines on product development effectiveness, companies that integrate customer feedback continuously into planning cycles are more likely to meet product objectives and timelines.
Feedback also helps prevent a common failure mode: Building for a theoretical future user while neglecting today’s realities. There are times when visionary bets are appropriate. But unless there is extraordinary confidence in existing market foresight, grounding a roadmap in real, current user needs is usually the safer path.
Keeping partners through launch, and beyond
Ideally, feedback partners become your first customers. That does not always happen. Helping build a product isn’t the primary job of these partners — and circumstances change. Still, products should be designed with that outcome in mind.
Incentives matter. Early partners should be rewarded for their time and candor. Preferential pricing, early access or contractual flexibility are common and effective approaches. At launch, growth matters more than maximizing margins. A strong initial customer base is worth far more than short-term profit optimization.
Value also must be delivered along the way. If partners feel their feedback disappears into a void, engagement will fade. Show progress. Acknowledge contributions. Make it clear how external input shaped the product.
Above all, remember products are ultimately built for people, not personas. These people have real problems and limited patience for solutions that miss the mark.
Why this matters now
There’s never been more product theory, tooling and capital available to builders. And yet, many new products struggle to gain traction. The gap is not vision. It is execution grounded in reality.
Too many teams fall in love with ideas before validating demand. They over-invest in internal alignment and under-invest in external learning. By the time feedback arrives, it is too late to adapt without significant cost.
User feedback, when treated as a strategic asset rather than an afterthought, changes this equation. It provides clarity early, focus during execution and confidence at launch.
Conclusion
If there’s one contrarian takeaway, it’s this: Don’t build for the ‘market.’ Build for a handful of real customers who care deeply about the problem being solved.
If these customers can be delighted, then you’ve created something worth scaling. If they can’t, no amount of vision or marketing will compensate.
Product success is rarely about guessing right the first time. It is about listening well, learning quickly and having the discipline to let real users shape the path forward.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?