Organizing and synthesizing feedback and research is critical for us.
In the last post, I mentioned that each product team at MURAL has an “Icebox” of ideas, opportunities, and observations from which Product Managers find patterns and spot trends about what seems to be the most important underlying themes we should focus on.
An Icebox mural of a product team looks something like this:
Product Managers organize the different iceboxes during the quarter and use them when deciding what to build next.
Where do ideas come from?
At MURAL, we’re careful to not fall victim to the availability heuristic: (https://en.wikipedia.org/wiki/Availability_heuristic). Just because something can be immediately recalled doesn’t necessarily mean it’s more important. We are always finding ways to prioritize better, to really get to a place where we’re working on the most relevant things.
We’ve come up with a simple process in which we take customer input, synthesize it, and end up with a draft prioritization to be used during the planning phase.
- Get input from different sources
1. Get input from different sources
Although we do tons of quantitative analysis, and we consider ourselves a company that pays attention to data, we pay even more attention to qualitative side of research. We get rich qualitative data from various sources, including:
- Contextual inquiries: We do customer visits, in which we observe and interview customers on-site while working. Understanding the context of usage is critical. Observing a live collaborative session is revealing.
- Interviews: We also do tons of customer interviews via Zoom. Most of our product team is in Buenos Aires, Argentina, but that doesn’t stop us from running interviews each week. Sometimes we just want to talk to someone who sent us interesting feedback. Other times, we proactively contact customers using Intercom or via Customer Success to co-create or get early feedback.
- Usability tests: We’ve done around 50 usability tests in the last year. Each time we do one, we find new things to work on. We do usability test of our product and also of our competition.
Each Usability test has a debrief, and it’s later shared in Slack….
- NPS surveys: Every 3 months we ask 1/3 of our active users the NPS question. We’ve been using it as a benchmark against ourselves. But, the most important part of the question, is the open response. When we get an answer to the Why? question, it is posted directly to Slack. If there’s a response that seems interesting to one of the PMs, we contact the customer and dig deeper.
We also organize the different NPS responses from our detractors into categories.
- Internal Stakeholders’ feedback and ideas: This is obvious. Everyone at MURAL has ideas on what we should be doing. We use our own product, so we constantly have suggestions and ideas. These are also captured. A designer might be using MURAL while doing a design studio, and a new idea might be captured. Product Managers have tons of ideas they want to try out. They are all captured.
- Sales and Customer Success feedback: Sales and Customer Success reps have daily conversations with customers. Their feedback is critical for us. We have a weekly sync with sales and another one with CS, but they are constantly sending us feedback from the different touch points they have with users and buyers.
- Customer Support tickets: Support tickets are a great source of customer feedback, and are great opportunity to have conversations with customers. A support ticket might escalate into an interview that provides us with plenty of insights.
It’s critical to understand the underlying need or context when we get new input. We need to dig a little deeper to make sure we understand the situation.
Just to give you an example: When someone from our customer support team receives a ticket via Zendesk, they’ll first try to understand whether what they are reporting is a bug or not. If it’s not a bug, but rather a suggestion, request or idea, customer support always asks for more context to understand why customers are saying what they are saying.
Why do you need to do this?
Could you tell us more about this idea?
What were you doing that made you ask for this?
…are common questions we might ask.
Since Slack is our communication tool of choice, we think it’s easier to collect feedback that way, too. Just to continue with the example from above, once our CS reps get to understand the goals of our users, they’ll paste the request/feedback suggestion into a Slack channel we call #usability-research.
Product Managers read that channel on a daily basis, but we don’t act upon the feedback we get immediately. Maybe we’ll be able to use it for what we’re designing this Q, maybe not; but having all the information centralized in this channel helps us make that decision more effectively (and avoid that availability heuristic).
Getting feedback via Slack is already great. However, Slack acts like a feed for PMs. We need other ways to process and make sense of every input.
What happens to something posted in #usability-research? Well, we have a Zapier integration that converts every entry in #usability-research to a cell in a spreadsheet. This way, we end up centralizing input. Some PMs prefer to read this spreadsheet on a weekly basis, rather than going though Slack.
It contains every piece of feedback we get from our multiple sources. Each source is represented by a tab in the spreadsheet.
MURAL PMs read this spreadsheet weekly, pick out the different pieces of feedback relevant to their area, and take them to their respective icebox murals to synthesize the information.
Here’s where the magic starts. We get a lot of feedback and suggestions, we’ve found that MURAL is a great tool (hehe) to see the forest and the trees, spot patterns and synthesize findings.
PMs can synthesize the information, affinity cluster the data, and thus see patterns that start to emerge. The more our PMs go through the process, the more habitual it becomes to notice current patterns. With these patterns, we can put together a cogent, insightful list of priorities for when we’re deciding what to build next.
These artefacts enable communication among product team members and with external stakeholders. They give us clarity and direction.
Visualising the whole process
This flowchart illustrates the information flow from steps 1 to 5. At a glance, you can see how the information travels from the different sources to a place where we can readily make sense out of it.
This is what we currently do, and there’s probably a lot of room for improvement. If you have suggestions or want to share how you handle customer feedback at your company, please let us know!
Special thanks to Celeste Olivieri and Mary Halling.