How to Balance Customer Feedback and Your Own Vision When Shaping Your Product Roadmap
We all know it's not easy to be a product manager — juggling between your customers' requests, keeping your team's morale high and creating an amazing product along the way.
But the hardest of all? Figuring out which features should you build next.
Should you listen solely to your customers or rely on your gut instincts to shape the vision of your product? Or maybe the trick is balancing both?
We asked 8 experienced product managers to answer one question:
How do you balance customer feedback and your own vision for the product when you're shaping your roadmap?
1. Seema Lakhani, Head of Core Products at Wattpad
Everything starts with a vision.
The vision does not belong to me or any of the product managers, though. Typically a vision starts with the founders and is adopted by every single person in the organization. It's what we all live and breathe and gives us purpose around why our product should even exist. The vision doesn't tell us what to build, though. A good vision never spells out the solution or the product. It focuses on higher level impact.
From the vision, we can create a set of product principles that speak to the values of our organization (a reflection of the values of our founders). These reflect great important truths of our product that help guide individual product managers with difficult decisions.
The company also has business needs and goals, shaped around a strategy, that we need to achieve to be able to fulfill the vision. These can be about reach, growth, revenue or other key metrics. Regardless they help keep everyone focused on what matters most and the order in which we need to achieve them. They can be broken down into objectives and key results (OKRs) which help us make sure that our product efforts are outcome driven as opposed to output driven. We want to make sure that any work we do on the product is driving the business outcomes we care about and isn't just about how much we ship.
Thus our roadmap itself becomes outcome driven. We lay out what outcomes we want to drive over what period. None of this is proscriptive on what will change in the product itself or how we will achieve that outcome.
So what guides the product decisions that will produce these outcomes? Where do customers/users fit in? That is what lives with the individual product managers and their cross-functional teams. It is the product manager (and their team) who must understand the needs of the users deeply. The best way to achieve business objectives is to solve real user problems and build a product that is valuable, usable and feasible.
Talking to users on a regular basis is key. And of course, it's not simply collecting their product ideas and implementing. It's going deeper to understand their pain points, figure out the scope and size of the needs, validating the user problems themselves, then working with talented designers and engineers to develop and test solutions. Great ideas for the product come from a very strong understanding of user problems and needs. And they are not exclusive to product managers. Ideas can come from anywhere.
So going back to the question, it isn't really about balancing customer feedback with a personal vision for the product. And neither of those really end up in a roadmap. Customer understanding drives the product ideas which can fulfill a vision. The roadmap itself is about the key outcomes we need to achieve to reach the vision, not specific ideas for the product and when they will be shipped. That gives the product manager the room to understand the user problems better, solve the problem through real validation to achieve business outcomes, which will support the overall company vision.
2. Sarah McCasland, Product Manager at ModusCreate
The most important piece of building a product is solving a problem. Customers usually know what the problem is to solve, but not how to execute the best solution.
As a product manager, I use customer feedback as well as stakeholder and developer feedback to decide how to prioritize the product roadmap based on needs, wants, and cost analysis.
In the end, sometimes it is hard to realize your initial vision didn't necessarily match what the customer wanted, but constantly adapting and responding to change helps alleviate this. Trying to find a problem for your solution is a much tougher sell than providing a solution to a problem that already exists.
3. Cyril Codron, Product Manager at Mention
We always begin with our own vision. We have a set of improvements we’d like to integrate into Mention over the next 6 months - our roadmap. We look ahead to new problems we want to solve, and the roadmap helps the product evolve according to our company values and business strategy.
Our customers help us define the priorities in our roadmap. We collect feedback through the app and our sales and customer success teams. Most of the time, we’ve already identified customers’ issues and penciled them into our roadmap (or not, if they don’t fit the vision). But, based on customer feedback, we might change the schedule to prioritize new features or upgrades to our product.
Once we’re sure about the problem we want to solve, we can begin to shape the solutions. First, our designers think about the UX and how to integrate the new additions in our product. Then we open the project up to feedback from the whole Mention team. Once we’ve settled on the exact parameters of the new feature, our designers finish their sketch.
Before we build the feature completely, we share it with some of our most active customers to see what they think. We always try to put the features in our customers' hands as soon as possible, so that we learn more about their use cases and iterate from their reaction. Overall, the vision and values of our company come first. But we shape these based on our customers’ views because it’s their problems we’re trying to solve.
4. Andrea Saez, Head of Customer Success at ProdPad
Check out Andrea's Twitter.
Customer feedback is incredibly important to us - we even have a Slack channel that funnels in feedback so everyone at our company can see it.
But rather than take it at face value, we group similar feedback together and investigate the root of the problem. More often than not, customers write in with symptoms of the same problem. It's our job to understand the underlying issues and parse their concerns into a cohesive theme, so when we do tackle a problem, we're working on a solution that benefits as many customers as possible.
5. Richard Esplin, Senior Product Manager at Alfresco
Check out Richard's personal site.
As a product manager at Alfresco, I get the opportunity to guide an enterprise software product with an open source strategy.
In addition to customers, partners, and internal stakeholders, we also have to consider the impact our roadmap has on our community of contributors.
People who want to influence the product roadmap can implement their changes without our permission or assistance. Then, of course, they often insist that we publish their changes publicly.
Due to the investment of our contributors, it is often difficult to turn down their requests. However, implementing these changes is not always easy — we have to review them, often improve them, test them, and provide long-term support. I have to be careful to weigh these suggestions against their applicability to the whole user base, our product vision, the current business priorities, and our product's architecture. But I also recognize that every contribution is a useful data point indicating that a particular change is necessary.
We try to make it as easy as possible for contributors to talk to us before they start working on their contributions. That way we can guide them towards implementations that are mutually beneficial or help them build their changes as an external module to our system.
We try to be as transparent as possible with our roadmap, and when possible quickly respond to let people know when we will not be implementing their ideas. In practice, I have found that people appreciate having a definite answer early on so that they can make other arrangements and get back on track fast.
One of the most energizing parts of my job is collaborating with external contributors who care about our product enough to invest their own time and energy to improve it.
6. Radostina Ermenkova, Product Manager at pCloud
Customer feedback is crucial when setting up a roadmap, but I don’t think product managers should aim to achieve a balance between customer ideas and their own vision for the product.
One of the most important lessons each product manager should learn is also the hardest — to let go of your personal ego when reviewing those ideas and be able to extract only what is most valuable for the product. Sure, anyone would love to see their own ideas becoming live features, but it’s the product manager's job to stay unbiased and set up a product roadmap based on research, not a personal favoritism.
As a product manager, you should be relying on analytical data, conducting tests, market research or even acquiring additional user feedback when necessary. Based on the knowledge you want to receive, there are different tools you could use for that.
Determining a feature’s potential value is only the first step. The second one is to make a raw estimation, usually with the help of your project manager and development team, how long it will take and do you have the required resources to execute the change/feature? That said, you should set up priorities in your product roadmap, based on value and available resources. There are these amazing ideas that are highly demanded by your customers and could boost your product’s profitability … but require half of your development team to be entirely dedicated for the next few months on each one of them. There are also less time demanding fixes that could improve overall customer satisfaction, but probably won’t be a real game-changer to the cash flow.
Oh, and there are also these bugs that annoy the hell out of some customers and not fixing them ASAP might hurt your product’s reputation and revenue.
There is no "one size fits all" solution to this, and the product manager must always work in close collaboration with all team members involved. So, if I have to summarize everything so — focus on thorough research and reasoned prioritization, trust your gut, but avoid decisions based on personal preferences.
7. Antonio Nuño Sánchez from Spribo
Check out Antonio's LinkedIn profile here.
Customer feedback should always be an important part of a product vision. It is one of the multiple sources of requests and new ideas.
To shape your product roadmap, you always have to balance customer feedback and your product strategy, always trying to deliver the greatest possible value to the customers.
Assuming that you have already a product strategy in place and that you understand what your key goals are, there are different scenarios in which you should consider customer feedback, for example:
-
Try to add customer feedback to your roadmap as soon as possible if it helps you to understand better something important that you want to learn and it is related to the objectives and key results that you are trying to achieve at a certain moment.
-
Take customer feedback into consideration to formulate new challenges to be tackled in the future if it has nothing to do with the current state of your product or if it is not related to the problems that you need to tackle at that moment, but you think that it's aligned with your long-term vision.
-
Last, you should probably need to review your product strategy or consider it as an opportunity to create new products if customer feedback has nothing to do with your long-term vision at all, but you think it's a great indicator of new trends or that you could deliver high customer value if you start building solutions around it.
8. Jessica Lynn Ellis, Product Manager at Magoosh
These are the questions I ask myself when evaluating customer feedback as it relates to our product vision and roadmap:
Are you my customer?
First, it is important to identify what kind of customer feedback it is. Not all customer feedback is created equal and not all customer feedback is representative of a true problem. It's important to be able to identify feedback that is coming from just a few loud voices and may not be representative of your core customer base. Overtime, you develop an understanding of your user pain points and can quickly categorize something as being part of a problem, or something that is a one-off. If the feedback fits into a bigger picture, then it may be worth addressing.
Is this relevant right now?
The second factor that I think about when deciding if we should consider building something in response to a piece of customer feedback is: Does it fit into a theme that we are currently working on? If it does not, it will not be prioritized. At Magoosh, we are hyper-focused on executing towards our quarterly goals and so it is important to feel comfortable saying "no" to something that is a distraction for the team. If customer feedback doesn’t fit a theme, it doesn’t mean it gets ignored entirely, but it may be pushed until later when we are working on that product or particular problem. I never tell a customer, “no”, more often it is “not yet”.
What is the problem, really?
And last, before deciding to address customer feedback, and often as part of my "not, yet" response to feedback, I always ask for more information. Not only does that make the customer feel heard, but it is also important that I don't assume that I know everything about the customer and their opinion. I always come at a problem, even if I think it is one that I have seen a thousand times before, with a beginner's mindset. I'll reply by saying that I'd like to really understand what they are saying and ask: "Can you tell me about a time when this came up? Why was it a problem for you?" Oftentimes a customer will recommend a specific solution, which, if you dig deep enough, reflects a problem that they are having. I try to get them to describe their experience more so that the problem space becomes more defined. This helps me and my team develop a fuller understanding of the problem, with more context, rather than getting hung up on any one solution. While the customer knows the problem really well, there are normally a number of ways that it can be solved.
A note on solicited feedback
Finally, it is worth recognizing the difference between unsolicited and solicited customer feedback. These same questions listed above still apply to solicited feedback, but seeking input on a concept as it is in development is very different than managing a diverse stream of comments on a wide variety of products or features. When working on a product, I keep the roadmap loose with the end goal always in sight. This is because we are constantly and continuously asking our users for feedback on prototypes. I bring users into our office, I travel to meet them outside of the office and I post in our various communication channels (Facebook, Slack etc.) to get input from those who are remote. This kind of customer feedback is integral to steering us in the right direction.
9. Nikolay Todorov, Co-founder Swip
The never ending dilemma between founder's vision and customer feedback dates back to the first products created around 100 000 BC. The stories say that a neanderthal wanted black boar skin and not brown because brown is so mainstream - Wikipedia (not really).
With all seriousness, this is a challenge that every founder or product guy faces on a regular basis. Several methods provide a framework on how to build products by iterating your customers wants and needs, the most famous being the Lean Startup. If you follow the method, strictly, you may recognize customer feedback as a guiding start. However, there is a thin line between just following the process blindly and building something that your customers really want. Because let's face it, we are customers ourselves and many times we don't really know what we need.
When helping our clients introduce and implement Lean in their companies, we always recommend them to tap on an existing framework but customize it for their needs. Prioritizing customer feedback is one of these things that you have to find the balance in yourself. We at Swip have several criteria that take into consideration when evaluating whether a customer feedback should be considered or not:
1. The Vision
We’ve built Swip with one thing in mind, and one thing in mind only - Provide the tools and guidance teams need to be running Lean. This is our end goal, and every decision we make takes this into account, no exceptions. It's the north start of our team. That is why our customers trust us and know that we won't quit on our promise. Having a long-term vision and direction is really helpful not only in terms of positioning your product but also in terms of product strategy and filtering the really good product ideas from those that will harm you in the long run.
2. Know your customers — but really...know them...
Talk to your customers on a regular basis; this means every day. Empathy is key when building a product or a service and being able to walk in your customers' shoes is what will help you understand their problems and challenges better. Best case, go to their office, spend some time with them. The synergy you are going to build couldn't be matched by any other form of communication. Many times the user feedback has deeper roots than what's on the surface, really knowing your folks will help you find what's hidden behind it.
3. Take into account the repetitiveness of the customer feedback.
Basecamp has a great rule when it comes down to a new user request. They say that at least 10% of the users have to ask for a given feature before they implement it. Although the exact percentage really depends on the user mass, this is a really good approach to reviewing requests. If only one user provides feedback that a given feature could be improved, there might be something, but it is not quite enough, while if 1000 request it — well there is something there for sure.
In the end: Balancing between customers' feedback and your own product vision is a craft on its own, and there isn't a right or wrong way in my opinion.
We all have our different view about how we should approach this dilemma, and it is pretty safe bet to say that none of us are 100% correct. Always keep in mind that the people that pay for your product are doing it because they bought your vision. Being true to yourself is what builds great companies, teams and attracts great people. What I’m trying to say? Be human.
Conclusion
What about you? How do you balance customer feedback and your own vision for the product when you're shaping your roadmap? Share your thoughts with us in the comments below.