The below question on managing customer feedback got my attention when I was going through one of the product management forums, mostly because I totally feel their pain:
“How do you manage feedback? Is everyone else tired of spreadsheets?“
When I worked in support, it was so hard to give my product manager the right information, and usually, it all came down to trying to understand a spreadsheet dump. So let’s kick this off by saying yes – there absolutely is a better way, but I’d like to take a step back first and break this down into different buckets of information.
Do Not Call Customer Feedback “Feature Requests”
This is your opportunity to change the conversation. What you’re receiving is feedback on how you might improve your product and what your customers are struggling with. A “request” implies you will have to work on every item that comes in, whereas feedback gives you more flexibility as to how you handle things. Whether it’s positive or negative, it’s then up to your product team to manage this customer feedback and handle things appropriately.
Gathering vs Tracking
I like to separate the concept of gathering vs tracking. Gathering is something you should do with as many tools as possible – don’t limit yourself. Whether it’s through social, email, conversations, or your different customer-facing teams – open up as many channels as possible. This makes it easier for people to actually want to engage with you. There certainly isn’t a lack of tools that will help you do this.
Tracking is a separate step of the process, and in my opinion the most important part, as it will determine how things impact your product backlog and eventually how items get prioritized. For this, we built and use ProdPad. Why? Because customer feedback is what helps validate your product backlog, so having it in a separate tool makes absolutely no sense. You need to understand the qualitative and quantitative aspects of it.
Responding
Saying thank you is a first great step. But for every piece that comes in, we make sure the person handling understands how to respond – that is, always asking why. Why do they feel they need this feature they’re asking for? How might it help them do their job? This is significant in two ways: one, it trains our team member in understanding what the product needs and how the product works and two, it lets the customer know we’re not just taking the piece of feedback and dropping it off to be lost, but that we actually want to (and need to) understand what they’re struggling with.
Post-implementation Comms
This is a biggie as it closes the feedback loop. Just answering and saying “thanks” isn’t where it ends, you then need to get back to the customer and close the feedback loop once the idea is implemented. This will give you the opportunity to bring back lost leads, but also create an atmosphere of trust. Just getting back to someone and thanking them for making a difference in your product makes them feel like it matters. Again, we use ProdPad for this. All feedback links back to a contact who we can then reach out to when the item is released. We generally include a quick thank you note as well as either a video or a how-to doc as to how the feature works. Boom, you’re a superhero.
Managing your customer feedback in a system (not a spreadsheet) that allows you to understand who the feedback came from, why, and how it’s impacting your product backlog, is not only making things easier for yourself but for your team. Your customer-facing teams will have an easier time speaking to your customers, you’ll have a better way of understanding and prioritizing feedback, and you’ll be on your way to building great products.
How do you manage customer feedback? Drop us a comment below and let us know. Or why not book yourself in for a demo with one of our product experts to learn how ProdPad can help you overcome this problem.
In a recent roadmap clinic, I spoke to a product person in dire straits. He was a mid-level PM, and was sensing that things weren’t right at the company, but wasn’t sure how to broach the subject.
What he described to me sounded like the business was walking that fine line between being a product company yet playing the agency card; as in, taking in client projects and commitments in return for cash, though hoping to build long term residual value out of a product. This would have been fine, except for the fact that it was leading them into some of the same traps that happen for companies in their position all over the world: taking on delivery focused work means that they had less time for discovery, and pre-existing relationships with VCs meant that they were expected to be scaling like a product company, not just making ends meet month-to-month.
This is a dangerous situation for companies, and often a slippery slope. After all, it’s easy and tempting to follow the scent of client invoices, even though they lead you away from solving the bigger, juicier problems that will launch your product considerably further. Oftentimes, companies, and the people running them, don’t even realize how dangerous this route is, until it’s too late. I know, as I’ve worked for one before.
It’s always hard to tell how self-aware a company is from a conversation with just one person in the team, but it was clear that these conversations about the problems in the business model weren’t being discussed openly. Our PM here was just expected to shut up and deliver on the promises being made to clients, rather than being brought in on the bigger picture as to how the company planned on getting itself out of this pickle.
He was facing a real “emperor has no clothes” moment.
My advice was to hold it up to the business, and make sure the execs within the organization saw and understood the full picture. The best time to have the tough conversation is now, when you sense something is wrong. Worst case scenario, you get laughed out or sneered out of the room, and you realize it’s actually a toxic company with deep seated problems… but at least you know early on, and can start thinking about how you get yourself out.
A more realistic case is that you end up raising an alarm, and can start helping to solve the company problems at hand. By bringing it to the forefront, you might actually be the catalyst for change that the business needs. This could work wonders for you personally, if you get to offer advice and play a hand in tackling real business challenges. Imagine what your LinkedIn profile will be able to tout in a few years time, if you helped spot problems and take preventative measures.
Best case is that the business is actually fine. Perhaps there isn’t a problem and your execs are able to enlighten you on why they see the business plan as perfectly viable, and how you and your product will play a role in that. Speaking up will give you a chance to put your name forward to help in new ways outside the product team, and to deeper understand how the business operates and makes money, and you’ll be respected for your ability to ask the tough questions.
Being a product manager is tough. You’ve got to understand your customers and your market. You’ve got to understand the tech and what’s feasible. And you’ve got to understand the business and how it profits. This last bit is hugely important but often the weak link. Sometimes product people end up working for companies that are only viable because they’re heavily funded, not because they’ve got core metrics or an actual business model figured out. Sometimes product people end up working for companies that essentially operate as agencies or solution houses, never investing enough in discovery or the product side to realistically get the growth they envision. It’s only by asking the tough questions and getting a word in with the exec team that many product people ever realize just what kind of company they work for.
If something doesn’t add up, if the business model doesn’t make sense to you and it’s leading to questionable product decisions and tensions, speak up. You’ve got little to lose and everything to gain, as a product person, and for your whole team.
Looking for a little dose of product-shaped business advice, too? My DMs are open, so let’s chat.
When I joined ProdPad, one of the first things I asked about was our user personas, and pretty much everyone I spoke to gave me the same answer: “They’re a mess… I wouldn’t bother, we need to start again.”
Let’s face it, user personas have a poor reputation, namely due to poor personal experiences. Their purpose is to create a shared understanding of your users, to represent their needs, to help you and your team know and understand who you are building for. They help you step outside yourself and recognize what your users need. So why do they fail?
I personally do not believe user personas to be flawed, I just think how they are created usually is. I believe that they can be and are a useful asset to help align teams and improve collaboration – but only if you get the parameters right. User personas fail for many reasons, so let’s look at some of the common trends and mistakes in creating and using them and then look at how I went about successfully reintroducing them at ProdPad.
Fictional or not?
We all know that “personas should be a fictional representation of your users”. This line was even used by our CEO, Janna Bastow, in her article: How to Work With User Personas When You’re a Product Manager. But unfortunately it’s a line that can be easily misconstrued. People often just make up a character based on their own thoughts and say they have a user persona.
But for user personas to be truly valuable they must be based on real data – a summary of all your research and interviews. So while they should not be a real person they should be based on real data from multiple people, they’re a way to encapsulate and make that data easier to digest. To make user personas valuable, you need to speak to your users, learn about them, and turn that information into a persona type that reflects a real user.
It’s the work that goes into creating the user personas that truly matters.
Unimportant user persona details
People adopt a “real person” to make their fictional representation come to life, or to make user data easier to digest, but this is where most of my issues with user personas lie.
Giving the user persona a name makes it easier to remember, but how will knowing their age, sex, ethnicity, maritial status and whether they drink tea or coffee help me (or our designers) to create a better experience for them? As soon as you add such information into a user persona you leave it open to interpretation, assumptions and unintentional bias. Does it really matter what they drink or whether they are married?
Demographic factors like age, ethnicity and marital status should only be included if they have meaning for your product or if they affect the interaction with your product. Does it matter if your user persona is married? Does the info you include have deeper meanings and invoke more questions about your user? Ultimately demographics and stock photos just don’t matter that much (unless they have meaning to your product) – people spend hours deciding these small details or finding an image to use, when most of that information is useless. Unfortunately, most people fail to look beyond demographics which is where the key information lies.
Different persona types
There are many other types of personas: marketing and buyer, to name a couple. I often see that the lines between them are blurred, as people try to create a one-size-fits-all approach that ends up not being useful to anyone. They are distinct for a reason. Each of these personas or users has a very different goal, so you should keep them separate.
This is what had, unfortunately, happened to our personas at ProdPad – they had become a mish-mash of marketing and user personas, and it meant they were no longer useful to our product work.
Created and never touched
“The important part about personas is to remember they are meant to be living documents. As you learn more, update them so they don’t become outdated assumptions, but realistic representations of your users.”
Janna Bastow, CEO and Co-founder of ProdPad
I couldn’t agree more. Time and time again, user personas are created to only be stored in some GDrive folder and never used. At best they’re presented to the wider team, turned into beautifully printed artifacts and stuck on a wall, never to be touched again.
The “never to be touched again” is the key issue here. At ProdPad we had fallen into this trap. User personas should be driven by your users. Just as your product matures and grows over time, so does your user base. We’re all in the habit of updating our product regularly as we learn more about our users and their needs, but the user personas are forgotten. There is no point building for your user base of five years ago – it will look very different from where you are today and the direction in which you’re headed.
How can user personas become a useful asset again?
If user personas fail, it’s usually down to the way that they’re implemented. There are a few tricks and must-dos that can turn them into a valuable asset, not only for your day-to-day product process, but for the whole organization, improving collaboration and understanding across teams.
It’s all in the groundwork
The key is in the groundwork – learning and listening to your users. I’m a big believer in all PMs having regular face time with their users (as Teresa Torres outlines in this post about continuous discovery) but I am also well aware that this can be a luxury. If you’re a PM who can’t get face time with users, then speak to your customer-facing teams. They will have a wealth of customer calls and demos that you can draw on to learn all about who your users really are, and you can use that as your baseline. If you haven’t talked to anyone, then you can’t rightly create a persona to represent them.
I’ve been in the fortunate position of being able to speak to our users every week for the last six months (and it’s something I will always do) so I had a huge base of data and insights to draw from when it came to reevaluating ProdPad’s.
Better together
User personas on their own are just one facet of your user base. They are at their most powerful when combined with other data available – namely customer and market segment data. There are so many dimensions to a user. If your user base is anything like ours then you’ll have behavioral personas (hopefully) as well as role types, plan types, industry types, team size and many more. All of these other data points are very valuable in understanding a persona’s context, but with such a broad user base, they often can’t all be given equal importance at once. User personas, combined with customer and market segments, can really help you drill down.
Dimensions of a user in ProdPad
At ProdPad, I created a matrix that outlined all the different dimensions our users can have, helping me to make sense of the characteristics and contexts that I’ve come across in my research. Just knowing and splitting out behaviors and contexts was enough for me to create a persona. I didn’t then need to weigh it down with extra details in an effort to make it more human – the traits I had identified could belong to anyone, regardless of demographics.
I then mapped initial behaviors and contexts to some of our customer data so I could look at the types of account and job roles that would be likely to inhabit those behaviors.
The customer team buying into the user personas set by the product team
You’ll notice that there are comments in the above gif. This is where our product and our customer team came together to chat through my mapping. It meant that everyone bought into the user personas, and they became useful beyond the product team and across the organization.
It’s about behaviors and scenarios
In my opinion the “fluff” that surrounds user personas won’t help you to design a better experience, unless it’s critical to the product you’re building. Thinking about how your users behave and what they are trying to accomplish is the core of what you need to help you and your team align their needs. Kim Goodwin has written extensively about this.
An example of the simple scenarios that were added to behavioral types
This was the final part in the creation of our new ProdPad user personas. We added a very simple scenario to each behavioral type – for example, what are they trying to do when they come to ProdPad? That, combined with their role and behavior, has given us a strong grounding for our next set of user personas.
What’s next?
You’ll notice that our user personas don’t have names, stock pictures, or any demographic details. For ProdPad, the main difference between them comes from their activities and contexts.
ProdPad’s user personas
We’ve now added these user personas to ProdPad. They’re useful to my work every day, allowing me to see trends on where feedback is coming from, what matters most to them, and where the holes are. More importantly, it’s given the product team and our customer team a shared language. We now have a set that we believe truly represents our current user base. When you’re building a product that must meet the needs of a diverse audience – with different use cases, goals, and scenarios, not different ages or ethnicities – your product needs to work, make sense and deliver a good unified experience to each of those different users. Having a shared language with the customer team means we can be aligned on whether we address all equally, or zero in on a primary audience first. That, for me, is where the power in user personas lives.
Someone asked on the Mind the Product Slack group the other day for suggestions on frameworks for prioritization.
The thing is, there are a million different frameworks for prioritizing ideas. Whether you’re into RICE, Impact vs Effort, Hierarchy of Purpose, or whatever else, but the reality is, all of these can be ineffective and misleading if they are leant upon in the wrong way.
Everyone gets really caught up in the minutiae of these frameworks, and so where everyone else tends to recommend their favorite framework, I suggested that they took a step back. I’ll share my advice here as it might be useful guidance for others.
What I pointed out was that idea prioritization frameworks are rarely helpful in themselves. Instead, teams should use objectives and roadmapping to prioritize at the problem level, and the right ideas/experiments to work on will fall into place.
I shared this guide on product management approaches from my colleague, Liz Love, as it shows how teams can work from a broader perspective and be more effective in their prioritization.
In essence, idea prioritization by itself is a bottom-up approach. The best product teams employ a mix of top-down and bottom-up approaches to figure out exactly what to build next. It basically means spotting what the main problems/objectives are first, and making sure those are clear and aligned with the vision, and then doing bottom-up prioritization within those problem spaces to figure out which solutions/experiments/ideas should be tried first.
ProdPad helps teams avoid falling into the bad habit of only prioritizing at the idea level, as it creates the space and paves the path to prioritize at the problem level. It asks questions like what the product vision is, what the company objectives are, and what initiatives will help tackle those objectives. ProdPad gives you lots of ways of seeing how your ideas might then fit within those wider priorities, but the tool itself isn’t bound to restrictive idea scoring methods that tend to lead teams astray.
How about you? How does your team do prioritization currently, and what methods do you find work or don’t work? Share in the comments below!
