Making Product Friends and Influencing the Roadmap

During my time building enterprise products, nothing was more valuable than getting feedback from customers and the highest quality feedback consistently comes from sales. I hear the same thing from nearly every product manager I speak with, yet I often see much of that feedback never making it to product teams or not being acted on.

This often leads to the feedback not being passed on by sales and customer success teams or it encourages those teams to go to engineers or others to try to get changes made.

This guide aims to be a guide for sales and customer success on how to make product friends and influence the roadmap to best help your customers. It is written from the perspective of product leaders you are trying to influence.

Bug vs. Feature​

The reaction to a bug, something that is intended to work but doesn't, is very different from a problem that the product isn’t designed to solve yet.

Generally product teams will have a ticketing system where bugs are put and prioritised. Sometimes finding the right team or component can be overwhelming, but even if they are filed in the wrong place or you need to ask on a team slack channel, true bug reports should always be welcomed. Don't try and sneak in feature requests as bugs or you risk becoming the person who cried bug.

Screenshots or screen recordings and as much detail about the context (steps to reproduce, customer who had the issue etc.) will help get the issue resolved quickly. A good quality bug report is significantly more likely to be solved than one missing half the details.

If it’s a feature request then that’s a little more tricky and is the source of most of the challenges. The next few sections set up how you can make a repeatable process for feature requests to get the most impactful changes to the product made.

Share the Problem and your Knowledge​

Product teams love feedback on the product, the fundamental thing they seek to understand is what problems need to be solved and why those problems are important.

Feedback on what problems customers are having or are stopping them from adopting the product are key to answering those questions.

Customers are nearly always right about the problem, nearly always wrong about how to solve it. A big part of sharing their feedback is changing what they said to you into the form of a problem, often they will say I just want it to have this or that. Try to get what the underlying problem is directly from the customer or attempt to reverse engineer it from the solution they suggest.

It is also worth sharing what the customer themselves said or asked for, but that shouldn’t be the headline. A request for faster transportation between a and b is going to be a lot more useful than one that says make horses faster.

Secondly share the context on why this is important, I used to break this down into 3 parts:

1. Severity. Is this blocking them using the product at all through to is this just a nice idea someone had
2. Who is having this problem? Industry, size, how they pay us are, what is the role of the person impacted are all useful pieces of context
3. Revenue or strategic impact aka why does this matter. Is this a huge customer who we think we can expand, is this an amazing logo or is this a customer in an area we are trying to expand into.

Dealing with the Feedback Tsunami

Now you have good quality feedback flowing to product teams which are using it to prioritize the roadmap, you are probably seeing growth! That means more sales people, more customer success and more feedback!

This very quickly means there is a tsunami of feedback and a lot of it is going to get dropped on the ground or a very non-optimal approach will be used to make decisions based on it. I have seen this arms race where personal relationships, who can yell the loudest and bribery are used to try to get their feature requests on the roadmap.

What is needed is a simple process to create an evergreen list of the most impactful problems to be solved.

1. A way to report an instance of a feature request. This is what we talked about in the section above
2. A way to group those instances together into a parent issue. One master issue which has or links to all the individual reports
3. A way to score or prioritize. When I have built these processes I generally had a rule which was for each report on a specific issue multiply the severity (a 1-5 scale divided by 5) by the the customer revenue/size (a 1-5 scale divided by 5) and then add an certain amount of points (0-1) if the customer was strategic. I would then sum off the reports together for a parent issue and rank them based on points. Each company will usually add different weighting to revenue or severity to fit their needs.

These processes are generally implemented using ticket tracking tools the product teams already use or dedicated feedback tools that connect with them.

Now you have a list of the most impactful problems to solve that is constantly updated. This means everyone from sales, customer success and product can see what the biggest problems are and where the focus should be.

Turning a List into Product Changes​

Sadly having an amazing prioritized list of problems doesn’t instantly solve them. A couple of problems usually crop up at this stage:

1. People forget about the list
2. People don’t know what on the list is being acted on, so they lose faith that contributing feedback actually helps get things done
3. Product teams don’t understand enough about some of the problems to solve it

To solve these problems I recommend:

1. Sharing the current top 10 biggest problems and how many reports have been made at least once a month if not weekly
2. Having sales and customer success present to product teams on the top issues to add colour and get everyone excited about solving them during a normal planning cycle
3. Product teams sharing what problems they are tackling next along with the reasons why they are tackling them

The last part is particularly important to keep everyone accountable and show that the process is worth the effort. It does highlight that once a list exists people expect that things must get worked on from top to bottom and then are surprised and sometimes upset when that doesn’t happen! It is good for the reasons why to be played back so the people giving the feedback don’t feel ignored.

Conclusion​

Everyone wants what is best for your end users and I hope this guide has helped layout a way to help turn the amazing insights heard by those closest to the customers into solved problems.

I hugely appreciate all the feedback that has been shared with me and followed up on by the amazing customer success and sales teams I have worked with over the years and I am sure that your users and the product teams you work with will appreciate it too!

If you are looking for ways beyond feedback to understand your users and use that knowledge to find the best opportunities to convert them to paying customers, keep them from churning or find opportunities to grow their team then check out Upollo. It gives you a prioritized list of the best opportunities and insights on why this user is ready for a conversation.

PS: If you have any feedback on this article or Upollo, let us know and I promise to read every word of it!