We often hear from product teams looking to consolidate all their user research and feedback scattered across email, Intercom, Zendesk, Evernote, Asana, Slack, Google Docs, spreadsheets, and any number of other tools. From design research to feature requests, they want all these product inputs in one place.
In fact, we needed this ourselves! That’s why we built productboard’s Insights board. It serves as an inbox for product inputs automatically streaming in from other systems, as well as a repository where you can author and save your own research, like notes from routine calls with prospects and customers.
But consolidation is really just the first step. How do you keep the Insights board from becoming just another impenetrable pit of feature requests and user interview notes, threatening to swallow all those who’d dare seek the insights buried in its midst?
After all, the real goal is to put all this information to use! But this requires some processing to ensure those insights best support your work as a product manager.
In particular, processing research & feedback will set you up for success with regard to three core jobs that are central to the work of every product manager.
- Validate existing feature ideas and add color to known user needs. (In order to decide what to build, and make sure you’re designing and developing it in the right way.)
- Uncover new user needs (In order to update your mental model of the problem space your product is addressing.)
- Surface trends in feedback and route certain types of feedback to specific members on your team. (So that colleagues can review the subsets of feedback that are most relevant to their work.)
Added benefits come in the form of three additional jobs that successful product teams perform.
4. Coordinate follow-up interviews with users who’ve expressed some need or requested a feature you’re beginning to work on. (So you can be sure you understand their underlying need and are designing the optimal solution.)
5. Notify users, prospects, or churned customers when features they’ve requested are delivered. (That way they’ll know their needs were heard. It also ensures they get maximal value out of your tool.)
6. Reference past research/feedback for a certain customer before meeting with them. (That way they’ll know you understand their needs. You’ll also be able to jump right into deeper topics during your time together.)
By processing your research & feedback according to the best practices that follow, you’ll be best equipped to leverage productboard to understand users’ needs, connect with your customers, and deliver a widely admired product.
Preparing to prioritize, design, and launch new features
As new research & feedback streams in, one of your primary goals is to process it in a way that allows you to resurface it at just the right time down the road. The first thing to verify is who provided the feedback.
When a new research note arrives on the Insights board, start by ensuring the Said By field is filled in.
Said By represents the end user who originally provided the feedback that is being logged. In the case of research & feedback loaded from integrations with tools like Zendesk, Intercom, or email, this field will likely be filled in automatically. But if you’re manually logging customer feedback that was relayed to you by a colleague (e.g. a sales rep who collected feedback from a prospect), you might be wondering which person you should add here.
We recommend always deferring to the end-user (customer) rather than using the name of the colleague who relayed or logged the feedback. That’s because doing so will set you up to see, on your Features board, which features matter most to which users. And it’s more interesting to know a feature is highly requested by SMBs in your target market than it is to know it was once suggested by Bob the sales rep.
Tip: Select the name of the person in the Said By field to assign them to a company/user segment. Later, this will allow you to roll up individual user data to understand broader patterns in your data.
Link insights to related needs/feature ideas
The next step is to highlight insights you find while reviewing the contents of each research note. Insights are golden nuggets — details that help you better understand what needs a user has, or what feature ideas would be best address their needs.
For example, you might highlight a user’s feature request so you can link it to a related feature idea on the Features board.
Here you can also indicate how pressing this need is to the user in question. While you might have to infer an approximate value based on the information you have at your disposal, a ballpark understanding of the feature’s importance to each user will go a long way in scoring features’ importance during prioritization.
And what if some insight represents a user need you’re coming across for the first time? You can either create a feature idea to link that insight to on the fly, or create a new user need (component) as a placeholder! That way you can see if other users share the same need before you commit effort to generating feature ideas that would address it.
For more on why we recommend using productboard components to represent user needs, see this article.
While linking insights, any new needs/features you create will appear within the product hierarchy on your Features board. There you can add additional data columns to aid in prioritization, such as auto-calculated scores based off the number of insights that have been linked to each need/feature.
You can also drill in for more qualitative details. Select a need/feature to open its details pane and see every person who’s ever made a related request.
Now that you have a full list of users who’ve requested each feature idea, you can easily follow up with individual users for design interviews or solution testing.
You can also notify users when their top-requested features go live. If you’ve ever followed up with users based on their past requests, you’ll know how appreciative they are when you show you were really listening.
Surfacing trends and routing feedback to the right colleagues with tags
As you’re processing new research notes, you may come across feedback that has product implications but does not relate to any specific user need or feature idea. For example, imagine a user who has struggled getting started with your product:
In these cases, it can be most useful to prepare feedback for retrieval at certain intervals by certain teammates. The best way to do this is by grouping them with tags.
- usability ?? — highlight usability complaints or user confusion with the product so PMs and UX can review and plan improvements
- love ❤️ — save positive feedback and compliments from users that PMs and PMMs can return to later when looking for customer references & testimonials
- performance ? — track performance complaints to help PMs, architects, and engineers identify sluggish areas of the product
- pricing ? — identify areas of confusion; log feedback that indicates pricing is too high/low
- bug ? — track bug reports
- churn-alert ? — track feedback from customers who are struggling with the product to help customer success plan interventions and inform product prioritization
- loss-analysis ? — track feedback from prospects who decided not to become customers to inform PMs’ prioritization decisions and PMMs’ product marketing decisions
- [source] ? — track feedback that came from particular sources/events (customer advisory board meeting, Q2 user interviews, etc.) so teammates can review this feedback all at once
- [sentiment] ? — track emotional response of users (joy, frustration, etc.) so PMs can look for patterns over time and better understand users’ perception of the product
- [competitor-name] ? — track users’ comments on other products in your space to inform competitive research and product positioning carried out by PMs and PMMs
On regular intervals, colleagues can search for research notes with tags that relate to the work they do.
You can use this search interface to retrieve other subsets of feedback as well, like just that feedback Said By a top-tier customer who you’re about to meet with. That way you’ll head to your meeting with all your ducks in a row. ???
Someday not far off, we’ll be able to process many product inputs automatically. For example, natural language processing can help link incoming feedback to related feature ideas and adjust the feature’s prioritization score accordingly. But for now, we‘ll continue relying on product team members to regularly process incoming feedback. It certainly helps that you can now invite customer-facing colleagues from sales and customer success to input and process research as contributors.
Since processing research is a collaborative activity, it’s important to develop team-wide habits for sharing this responsibility. We’ve seen that the most successful teams brainstorm what use cases they’ll have for retrieving feedback and plan their tags accordingly. They also norm on tag naming so that different members of the team aren’t using unique terminology for similar concepts (e.g. “UX” vs. “usability”). We recommend planning these systems early on. It may take some careful thought, but the payoff of painless prioritization around a clear product strategy will make the added effort on the front-end well worth your while. ?