In our most recent Product Stack webinar, I was fortunate to join Dan Podsedly from Pivotal Tracker and Greg Goodman from ProductPlan to discuss some real world examples of aligning product strategy with customer feature requests—a topic that we all run across on a weekly, if not daily, basis in our jobs.
During the webinar, Dan spoke about the difference between simply hearing versus actually understanding customer feedback. Greg highlighted ways to balance the needs of what to build next. And I ran through key metrics you and your team can track to make better decisions around customer feedback.
Throughout the webinar (which can be watched in full below), we also received dozens of excellent questions—some of which we didn’t have time to address. (You can hop into our Slack group and reach out to us directly, if you like.)
So I’d like to respond to one that came up from a couple different folks:
What are the strategies to integrate client feedback into a larger product vision?
This is definitely a challenge that all teams have to juggle and struggle with. The key metrics I speak about in the webinar are obviously one such strategy, so I do recommend watching the video. But there are a handful of other ways to integrate feedback into your product vision and decision making process.
Run “safe to fail” experiments
When a feature request comes in, there is typically some inherent risk associated with it. “Should we build this? Will other customers use this? How much will it cost to build and maintain?” I’m sure these are just some of the questions that run through your head.
So what is one to do? Build a culture focused on running experiments and set the tone early that it is ok to fail.
Experiments should be thought of as iterative, non-binding, and low-effort approaches to learning more about the biggest unknowns related to a feature request.
The experiment can take many forms. It can be a simple survey that you share out with your most vocal customers looking for validation on a use case. It can be a paper prototype or wireframe used to walk customers through well before any code is actually written.
And since experiments can look different for each situation, it is important to be consistent in one key area: always make sure you have a clearly defined objective for the experiment and actionable next steps (even if that next step is to shelf development).
Send company reports from your Customer Success team
Sometimes the biggest hurdle faced in getting the team to buy-in on customer feedback is an issue of visibility. Depending on the organization of your team, the value of, or real need behind, a feature request can be lost in translation as it travels from your customer success team to your business analysts to your product designers and to your developers and then back up the chain to your marketing team.
Encouraging your customer success team to keep organized documentation of all requests that come in on a weekly basis and making sure they are accessible company-wide is a simple exercise that results in direct insight into feature requests for everyone on the team.
Once everyone has a better understanding of the root cause and can relate to it on a personal level, more creative (and sometimes simpler) solutions often rise to the top.
It’s very lightweight and your team can get started on it today. We organize the feedback with a folder in Dropbox Paper, and every Friday a new doc is added and sent out in our #stand-up channel in Slack.
When it comes to making changes to product vision, there is another straightforward way to make sure everyone on the team has a seat at the table: literally gather everyone around a table and discuss feature requests.
At Notion, we call these Product Parties. We’re small enough that we can gather the entire company, but if you are at a larger company try to at least have one representative from each department.
The objective of these parties (don’t call them meetings!) is to make sure there are no surprises if a shift in product direction occurs and to give everyone an opportunity voice their opinions or concerns about any changes.
No one on the team likes being kept in the dark only to later find out that the product vision is changing as a result of customer feedback they knew nothing about.
Transparent roadmap planning
Similarly to Product Parties, having a transparent roadmap with your team and involving everyone (or representatives from each department) at planning meetings is the last strategy I’ll talk about.
ProductPlan is a great tool for this and we use it at Notion. Once a quarter, we try to bring the whole team together again and review upcoming features and walk through the benefits and risks of each one. It’s a great way for the dev team to learn about customer signal, as reported by the support team. And it’s a great way for everyone outside of the dev team to understand the dependencies or scope challenges of a feature that may explain why it gets pushed back.
The outcome of these meetings isn’t a set-in-stone list of features to build in order. Rather, it provides the entire team with visibility into all the moving pieces that go into the decision making process that will ultimately fall on the product managers to decide.
Regardless of the tool you use, what is important is to make sure everyone has visibility into the process. That way, when customer feedback comes in and it feels like an immediate, must-act-now response is what is desired, you can push back and remind everyone that there is a process in place and it needs to be evaluated against everything else that has already filled up the near-term roadmap.
Hopefully you’ve found at least one of these strategies to be actionable for your team. We’d love to hear if you have any more! Here’s a link to our Slack channel.
If you're looking for even more help knowing how to incorporate customer feedback into your product strategy, check out these posts from ProductPlan and Pivotal Tracker that answer even more of your webinar questions.
And as promised, here is the full webinar from the Product Stack team.