product management

toolbox with feedback tools

How to get the most valuable feedback from your customers and prospects

Feedback is how you refine your product, shape your messaging, and uncover blind spots. But not all feedback is created equal. The most useful feedback doesn’t just confirm your assumptions or point out flaws, but it reveals intent, context, and patterns that help you make better decisions.

So how do you get that kind of feedback from customers who are busy and prospects who aren’t yet invested?

Let’s take a look. 

Ask why

Too many feedback forms and surveys stop at surface-level questions:

  • “Did you like this feature?”
  • “Would you recommend us?”
  • “What didn’t work for you?”

While feedback that comes out of these questions can be useful, you may get even better insights by focusing on the why.

Ask:

  • What were you trying to accomplish?
  • Why did this feature help, or fail to help, you do that?
  • Why did you choose us over other options? Or why didn’t you?

You’ll uncover underlying motivations, not just reactions. And that’s what drives product clarity and positioning.

But a word of caution: how you ask why matters. If it comes off like you’re challenging the validity of someone’s feedback, especially if they’re voicing frustration, they may get defensive. Worse, they might double down on a perception that your product lacks something crucial, even if it’s a misunderstanding or misalignment.

Instead, approach with genuine curiosity and a tone of collaboration. Frame it like, “I want to make sure I fully understand so we can get better at solving that problem.” That keeps the door open to dialogue and positions you as a partner, not a skeptic.

Talk to the extremes

It’s tempting to focus on your “average” customer. But the most valuable insights often come from:

  • Your biggest fans: They can articulate your differentiators and help you understand your true value.
  • Your toughest critics: They reveal gaps you’ve ignored or underestimated. Remember Bill Gates’ comment ““Your most unhappy customers are your greatest source of learning.”
  • Your lost prospects: They tell you where you missed the mark and what mattered most in their decision.

Build regular cadences to talk to all three. Exit interviews with lost deals are especially underrated. 

How to get lost prospects to talk to you

Reaching out after a deal is lost can feel awkward, but when handled with the right tone, it can actually build long-term goodwill.

  • Lead with humility and transparency. Try:
    “Thanks again for considering us. We know you made the best decision for your team. We’d love to learn how we can improve for the future. Would you be open to a short conversation?”
  • Offer value in return. For example:
    “We’re refining our onboarding process and messaging. If you’re open to sharing your thoughts, we’ll send you a preview of what we’ve changed based on customer feedback.”
  • Keep it low-effort and non-salesy. Clarify upfront:
    “This isn’t a sales call, just a chance to learn from your experience.”

How to get to the real reasons

Often, the reason prospects give (“pricing,” “missing feature”) is just the surface. To uncover the deeper drivers, use open-ended prompts like:

  • “Walk me through your decision-making process and what mattered most to your team.”
  • “Were there any trade-offs you had to make?”
  • “Was there anything that gave you pause about our product?”
  • “If you could have changed one thing about our offering, what would it have been?”

Don’t be afraid of a little silence. Often, the most honest feedback comes after the first, more “polite” answer.

Observe behavior

What people say they want and how they actually behave often diverge. This is especially true in SaaS. 

Let’s say you launch a new page builder in your CMS. During interviews, both developers and non-technical users express excitement.

But once it’s live, your data shows that power users continue making update right in the HTML, non-technical users still submit help tickets for formatting issues, or bounce rates from the feature documentation are high. 

That’s a red flag: behavior doesn’t match enthusiasm. Why? Maybe:

  • The interface wasn’t intuitive enough.
  • They weren’t confident using it without training.
  • It didn’t accommodate the custom components your developers already rely on.
  • Governance concerns are forcing users back to IT for review anyway.

This kind of insight won’t surface through surveys alone. It shows up in click paths, support logs, and feature adoption data.

So instead of just asking, “Do you find the page builder helpful?”, combine that feedback with behavioral signals:

  • Are users completing their tasks independently?
  • Are certain roles ignoring the feature altogether?
  • Is usage consistent across departments?

In the CMS world, watching how content is actually created, updated, and published is often more revealing than what users say about the tool.

Ask open-ended questions

Instead of asking “What do you like about our product?”, ask:

  • “Tell me about the last time you used our product to solve a problem.”
  • “Walk me through how you currently manage [X] and where you get stuck.”
  • “Walk me through a workaround that you use just to avoid a specific feature.”
  • “What’s the process like when someone new joins the web team. How easy is it for them to get up to speed?”
  • “How does the system support (or hinder) collaboration between departments?”
  • “If your system disappeared tomorrow, what would you miss, and what wouldn’t you?”
  • “What’s something you wish your system could help you do that it currently can’t?”
  • “Can you tell me about a moment when using the tool made you look like a hero internally?”

Stories provide context. They help you see how your product fits into real workflows and where it falls short. They also help you uncover language you can use in your own messaging.

Make feedback-giving easy and low-risk

Don’t expect people to write a novel or get on a one hour call with you. Offer simple ways to share:

  • A single question in a pop-up: “What’s one thing that would have made this page more useful?”
  • A quick check-in email: “Mind hopping on a 15-minute call to give us some honest feedback?”
  • Embedded tools like Hotjar or FullStory that let you capture input as users interact.

Also, avoid making feedback feel like a trap. Let people speak freely, anonymously if needed, and make it clear there are no wrong answers.

Quick tip: While I’m generally not against having an AI notetaker on my calls, I try to read the room, and when I feel that I would get more honest feedback if it was just me and the customer “off the record”, I turn it off. You can also just ask if the customer would feel more comfortable without the notetaker. 

Separate the signal from the noise

When you start collecting feedback at scale from users, prospects, support tickets, user groups, and internal stakeholders, it can get noisy fast. Everyone has ideas, and everyone has “must-haves.” Obviously,  trying to implement everything leads to a bloated product that loses focus.

Imagine you start getting feedback like this from multiple content contributors across departments:

“We need more design flexibility on our pages.”
“Users wants more layout options without going through the web team.”

This can quickly trigger alarm bells:

  • Should we allow drag-and-drop layouts?
  • Do we need to revamp the entire templating system?
  • Should non-technical users have full control over design?

But before diving into solutions, pause to ask: What are they actually trying to do?

You conduct a few interviews and review support tickets. This could look like this:

  • Most users aren’t asking for pixel-perfect design control. They just want to add a call-to-action or rearrange content blocks.
  • Others are frustrated because they don’t understand how to use existing layout options that are available but maybe not easy to find.
  • A few are working around limitations by pasting formatted content from Word or Canva, which breaks accessibility standards.

The signal may be “Non-technical users want to feel empowered to make their content look professional, but the current tools are hard to find or unintuitive.” But the noise could be “Requests for total design freedom, when in reality, that would lead to governance chaos.”

This separation will provide more clarity and lets you implement the right set of features and enhancements without overcorrecting or deviating from your product philosophy.

In summary:

  • Look for patterns: What themes come up repeatedly across roles and industries?
  • Use jobs-to-be-done thinking: What core problems are people trying to solve?
  • Prioritize based on impact vs. effort and alignment with your strategy.

Great feedback isn’t just a list of requests but set of clues that need to be interpreted carefully. 

Close the loop

The easiest way to encourage feedback? Show people it matters.

  • Let users know what changed based on their input (these are huge wins for you and them!)
  • Thank them personally when their insight led to a fix or improvement.
  • Involve your customers in early access programs and beta testing.

Picture this. A customer filed a support ticket for a use case that your product could not support at the time. Now, months later, you have a new feature that can help the user do what they need to do. You send them a personal message, thanking them for their feedback and informing them that this new feature is now for use in beta. Ask them to test it and let you know how it works dor them. Who knows, this may even result in a user story for your next blog post or webinar as a real world example of how customer feedback drives your roadmap.

Be curious, not defensive

When someone tells you your product didn’t work for them, or that they chose a competitor, it’s tempting to explain or defend. Resist the urge.

Instead, get curious, dig deeper, and ask more questions

The most valuable feedback doesn’t stroke your ego. The best products are built by people who know how to listen with open minds and strategic intent.

sticky notes with yes and no written on them

Why saying no by default is not a strategy

Saying no can be liberating. It’s a word that leaders, product managers, and founders often use as their shield against scope creep, burnout, and loss of focus. Yet, I wonder if the real art isn’t about defaulting to a firm no. It’s about knowing why you’re saying no, understanding the impact, and being open to other paths when possible. What if we can shift from knee-jerk rejections to meaningful, strategic decisions that serve both our business and our customers.

Why revisiting our no matters

It’s been years since I explored why we shouldn’t shy away from saying no to projects, features, or deals that don’t align with our vision. But time and experience have shown me that “no” is not a free pass out of tough conversations. Nor does it automatically mean you’re operating in the best interests of your team or users. The nuance lies in the decision-making process and the honesty behind it.

With over a billion results for “saying no to a feature request,” the topic is far from new. Yet, many teams still struggle to move beyond a templated refusal, missing out on growth, innovation, and customer goodwill in the process.

Identify the real reason behind your no

Be honest with yourself

Before saying no, dig deeper. Is your answer rooted in what’s truly best for your product and customers? Or are you being swayed by something less objective, like risk averseness, internal bandwidth issues, or personal bias? Sometimes, a quick refusal feels safer than challenging assumptions or pushing your team outside their comfort zone.

Tracking your decisions helps. Document every no and, more importantly, the reason behind it. This reflection gives you valuable data, helping you spot patterns like resisting new ideas, underestimating team capacity, or playing it too safe. You might discover that your “no” is occasionally more about your own limits than your customers’ needs.

Separate product needs from personal preferences

Maybe a feature request sounds wrong simply because it’s not what you’d want as a user. Or maybe a contract term feels risky, but you haven’t weighed the potential upside. By being transparent, you open up space for objective analysis.

Here’s an idea. Start an internal “no log.” When you turn down a request, capture what was asked, why you’re declining, and the true business reason. After a quarter, review for trends or missed opportunities.

No doesn’t always mean never

Consider no, but add “but”

The word no doesn’t have to be a conversation-ender. Sometimes, a flat rejection is appropriate. More often, a “no, but…” unlocks better dialogue and creative alternatives.

  • Contract terms: Maybe you can’t agree to everything the partner asks, but could you offer a concession elsewhere?
  • Feature requests: If a proposed feature isn’t feasible, could an integration with another tool help your customer achieve the same outcome?
  • Project proposals: Resource-constrained? Suggest a partnership with a trusted contractor instead of rejecting the project outright.

Whenever you deliver a “no,” challenge yourself to also offer a workaround, a timeline for revisiting, or a different way forward. You’ll build trust and demonstrate that you’re listening.

Weigh the consequences of saying no

Balance ROI with opportunity cost

Rejecting a new idea or feature is rarely risk-free. Of course you should ask, “What will this bring us?” But you must also flip the question: “What could we lose by turning this down?” Each no closes a door, possibly for good.

  • Could refusing a feature be the difference between keeping and losing key customers?
  • Is turning down a contract leaving money and future partnerships on the table?
  • Will a pattern of no responses become a reputation risk over time?

For example, a SaaS platform might skip a small feature to focus on core improvements. But if that feature is critical to a cluster of customers in a lucrative segment, the opportunity cost could outweigh the savings.

With every major no, write a short post-mortem. Review both the intended gains and potential losses, and discuss as a team before finalizing.

Stay flexible as context changes

Adapt your no to the times

Business climates evolve. That means your “no’s” should, too. Maybe last year you avoided broad integrations because of limited resources, but now, economic shifts or new partnerships demand a more open approach.

  • Are current market or global trends changing customer expectations?
  • Has a new law or regulation made your earlier decision irrelevant?
  • Could tighter budgets mean you revisit previously shelved ideas that now look more viable?

As leaders, we need to widen our lens to include industry shifts, economic downturns, and even global crises. What was a hard no yesterday might be a qualified yes, a “maybe” with caveats, or a “no, but” today.

Regularly revisit your default responses. At your quarterly strategy review, ask, “Is our no still the right answer given what’s changed?”

Align the best for customer and company

There’s nothing weak about turning down a customer, a feature, or a contract term. What matters is that your decision aligns with long-term goals for both your company and the people you serve. These interests are not opposing forces. The sweet spot is where they overlap.

  • Make decisions with transparency.
  • Communicate your reasoning.
  • Demonstrate that you’ve weighed impacts on all sides.

When your team and your customers see that your no’s are principled instead of arbitrary or reactionary, they’re far more likely to stick with you.

Let’s rethink our relationship with “no.” The next time you’re asked for a feature, project, or partnership, pause before defaulting to a refusal.

  • Track and analyze your decisions for hidden patterns.
  • Look for “no, but” opportunities wherever possible.
  • Evaluate both the costs and opportunities of every no.
  • Stay alert to shifts, from market sentiment to legislative changes.
  • Be transparent with your reasoning, building credibility inside and out.

Saying no is an essential leadership tool. But it’s a scalpel, not a sledgehammer. Use it to cut out what’s unnecessary, not to block growth, innovation, or trust.

What about you? How have your views on saying no changed as your context has evolved? 

When your behavior doesn’t match reality

In order for you to achieve both your short term and your long term business goals, you have to have a deep understanding of who you are as an organization. It’s imperative to have ambitions and to envision what you ultimately want your company to be and to look like, and it’s just as important to understand where you are currently and to act accordingly. Failure to understand the current reality or to have a false sense of self will make it much more challenging to get to where you want to be in the future. Here are a few examples.

Automating too much

If you count on customer service to be a key differentiator, ensure that you are giving your customers the individual attention they deserve. As you are growing your customer base, there might come a time when your team starts to think too much about scaling up, prematurely, and doesn’t focus on the personalized service they should be delivering. If you spend more time on automation than on actual service, reconsider your approach. Don’t automate yourself into indifference, but instead analyze how much personalized outreach and attention you want and should give each customer and find a way to make it happen. 

Delegating too much or too little

As a manager, you may worry about delegation. Are you delegating too much? Too little? Once again, it comes down to critically assessing who and where you are as a company. This is particularly important when it comes to interacting with customers. As a company with several hundred enterprise customers, do you think upper level management should engage with individual customers? I do. But the threshold is, of course, different for each organization. The key is to act according to your reality and not your aspirations. Does your VP of Product need to be involved in certain levels of UX decisions, or would it make sense to empower team members to make the call? If it’s the latter, what do you need to do to make it so?

The “I shouldn’t have to” trap

Another example of potential incongruence between your reality and your thoughts can be found in the “I/We shouldn’t have to trap”. If you catch yourself thinking “I shouldn’t have to tell them to make calls”, “We shouldn’t have to tell them that this issue needs to be resolved immediately”, “I shouldn’t have to remind them how important response times are”, or “We shouldn’t have to postpone the release” (you get the picture), stop for a minute to re-think, because clearly, you have to right now. Instead of an internal eye roll, accept that you are not where you want to be, analyze the reasons for it, and identify the steps necessary to improve the areas that are causing you heartburn.

Misreading your culture 

Your company culture can be one of your biggest, if not your biggest, assets. It’s how people feel after interacting with one of your team members. It’s where the company handbook leaves off and how people act when nobody’s watching. A great culture spawns a sense of pride, and rightfully so. It’s only natural to brush off things that aren’t quite perfect, or to overestimate or underestimate certain parts about your team. Your team may be such an integral part of you that you may be blind to certain shortcomings, but if you are, you don’t empower yourself to help them improve and become even more successful. 

Being realistic about where you are and who you are is a necessary step towards moving towards your goals. Be sure to always take inventory, self-reflect, and make adjustments, not just when the results don’t match your expectations.

What about you? Can you think of situations in which not being brutally honest about your reality could adversely affect your company?

How to obtain useful feedback from your customers

As you are building your product roadmap, you want to ensure that you have as much insight as possible into your customers’ needs. And not just their current needs – you also need to anticipate what types of challenges will be on the horizon for them. After all, customer success is the be all and end all, and that’s why we place so much value on our customers’ input, of which there is no shortage, luckily. The key is to extract the most useful feedback and to act on it. Here are some thoughts on how to do that. 

Provide multiple feedback channels

In order to get useful feedback, you start by getting feedback in the first place. Make it easy for your customers to voice their opinion and to solicit their ideas, and accommodate each individual’s preferences with regard to communication. Some people prefer written communication, others may provide input in passing as they’re interacting with your team, while others might be more than happy to have dedicated feedback sessions with you. For instance, we have an Idea Portal, where customers can submit their feature requests and vote on ideas. In addition, all customer-facing team members, such as Support, Services, Training, and Customer Success, write down feedback that they’ve received and submit it to Productboard, which is where we house and process all input and plan out our roadmap. Furthermore, our Head of Customer Success and I have many, many feedback sessions with our customers throughout the year. Finally, we’ve hosted focus groups during our user conferences. Be sure to identify those customers who are willing to answer follow-up questions, and respect their time and their communication preferences for follow-ups as well. 

Focus on the outcome, not the specific feature 

Henry Ford once famously stated “If I had asked people what they wanted, they would have said faster horses.” Don’t get me wrong – our customers have approached us with many amazing ideas for new features. However, in order to make sure that we get the most useful feedback, we always try to focus on the desired outcome rather than a feature. We want to have a clear understanding of what our customers are looking to accomplish so that we can find the best possible solution for them, and we certainly don’t just want to copy something that a competitor is doing. In order to innovate, always focus on the desired result, not the functionality. 

Ensure diversity of feedback providers

Some customers are easier to get ahold of than others, which is why I’ve seen companies only receive feedback from the same core group of champions – a dangerous mindset! Instead, make every effort possible to solicit input from a broad variety of clients, including those who tend to be quiet. Another pitfall is to only reach out to your main contact at an organization. It’s simply not sufficient, for example, to only talk to a technical user(s) and not the non-technical end users, or to focus on the needs of the IT department when Marketing and Communication departments are the primary users of your product. Connecting with multiple people at each organization takes a lot of effort, but it’s absolutely mandatory if you want to get the most useful feedback in order to deliver the best products.

Crank out those prototypes

Once you’ve decided to move forward with new functionality, continue communicating with your customers (and your internal stakeholders). Since most of them are visual, you can increase your chances of getting actionable and quality feedback if you can show them prototypes. One word of caution: don’t try to perfect the prototype. It doesn’t have to look pretty, and it doesn’t have to include everything that a feature could possibly do. With prototypes, speed is most important. When sharing them with stakeholders, explain what you’re looking to get out of the feedback. In most cases, it likely boils down to “would you use this?”, “what would be the impact of this feature on you and/or your users?”, and perhaps “would you pay for this?”, rather than “Should this button be on the upper left?”. 

Give thanks and credit

In order to obtain a continuous stream of inspired feedback, make sure that your customers know that you not just value their opinion, but that you are putting your money where your mouth is by actually acting on the feedback that you receive. Share with them the impact that they’re having. For instance, when you present your roadmap, mention the number of votes that a certain piece of functionality had received on the Idea Exchange. Give shout-outs to customers who initiated the exploration of a specific feature. Most importantly, thank your customers for their thoughtfulness, their time, and their willingness to collaborate with you in order to help you create the optimal solutions for them. 

While not every idea will should make it into your roadmap, it is vital to collect as much feedback as you can, to ask lots of questions, and to focus on desired outcomes. The better a partner you are to your customers, the easier this process will be.

What about you? How do you get the most useful feedback from your customers?

Product roadmap: 4 things to avoid

Managing an agile product roadmap is no easy task. You have to find the right balance between planning ahead and foreseeing trends and at the same time being flexible enough to adjust your course when new opportunities arise. It requires smart hiring in order to ensure that your team has an agile mindset and good internal and external communication skills. Today, let’s take a few minutes to look at some things that you might want to avoid in your product roadmap.

The ‘demo’ feature

You’ve been there. You want your product to not just be the best on the market for your customers, but you want to wow prospects at first sight. No matter how confident you are in your product, you feel the need to implement a certain feature because it would demo really well. Be careful. Resist the temptation to put something into your product for the wrong reasons. Critically assess the following:

  • Is this feature really going to move the needle for your customers?
  • Are your customers really going to have the resources and processes to use this feature?

A gimmicky feature can have several negative outcomes. For instance, your prospects might immediately catch on and question the soundness of your overall product roadmap. Or they might be excited about it, but once they’ve become a customer, they realize that the feature that “sold them” on your product isn’t really all that useful. Disappointment inevitably sets in. In addition, building a feature solely for the purpose of demos can be somewhat demoralizing for your developers, as they are committed to building the most helpful features, not necessarily the most “salesy” ones.

Build for a particular prospect

The following scenario is especially common in the startup world. You’re hungry for new customers in order to gain traction as quickly as possible. And here they are: a big fish prospect. Getting them onboard would be a game changer. But – there’s a but: The prospect is asking for a new feature. Hopefully, they make the commitment to purchase your system if you accommodate their request. Take a step back. There are very few instances in which this approach is advisable. Yes, there are cases in which the requested feature just makes a lot of sense, but veering from your roadmap in order to make individual customers happy can be treacherous and is not scalable as your product matures and your user base grows. Ask yourself:

  • If and how the requested feature would fit into your overall roadmap
  • What impact would this feature have on other parts of your system?
  • Would this feature benefit the vast majority of your customers?
  • Is the complexity of this feature going to prevent you from working on more impactful ones?

Copying the competition

In one of my previous posts, I talked about the futility of being overly concerned with your competitors. If you’re doing your homework, staying connected with your customers, and staying on top of emerging needs and trends, you shouldn’t have to spend too much time worrying about your competition. That being said, it always hurts to lose a deal to a direct competitor, and if your sales reps tell you that it was because you didn’t have feature X, it’s only natural to reflect whether it wouldn’t make sense to just go ahead and build your own version of said feature. Again, stop to think about the following:

  • Is there a realistic use case for it? We’ve actually faced this situation several times with Hannon Hill’s flagship product, Cascade CMS. One of our competitors came out with a few features for which there really didn’t seem to be real world use case. Yet, they resonated with prospects during the demo process. We opted not to replicate the features and instead, to focus on the things that we identified to be more useful for our customers.
  • What is the problem that this feature is intended to solve? It’s always best to first talk about the goals that a user is looking to achieve and the problem they’re trying to solve before implementing a new feature. Before you emulate what your competitor has built, think about the best ways to solve the problem you’ve identified.

Always keep in mind that every minute you spend copying your competition is a minute you could spend innovating.

Too much complexity without validation

Speaking of innovation, there’s also a risk in going overboard by building a highly complex feature that has not been vetted. Des Traynor, co-founder of Intercom, once used the analogy of building a cupcake before you build a wedding cake. This is very fitting when it comes to creating something brand-new without knowing if your customers will adopt it. When you’re trying out something highly innovative, start small, get frequent feedback, and adjust quickly. Don’t go down a rabbit hole. That being said, if your product is an enterprise system, this might present a challenge because your users likely expect very robust and complex functionality from your product.

What about you? What are some of the things that you avoid with regard to your product roadmap?