Many tech organizations have a process (or processes) to bring product feedback from front-line customer-facing teams to the teams that build the solution.
These processes are often cumbersome and time-consuming and don’t leave any team–or customers–feeling satisfied.
Here’s the dirty secret, most of that effort goes nowhere. We will talk about a better, more pragmatic way to ensure that the valuable perspective and knowledge of customer-facing teams actually become a driving force in product strategy and building decisions.
- The common failings of customer feedback systems
- How to re-set expectations between Customer and Product Teams
- How Customer insight should drive technology decision-making via validation
[Transcript] Your Product Feedback Won’t Change Anything; your Validation Will
The next speaker is actually a friend of mine, we worked together at Hootsuite, and now he’s VP of Product at Personio. He’s going to talk about feedback and how feedback impacts and changes the product, and how validation is as important, if not more. Welcome, Alex Grant.
Ciao Massimo, it’s great to be with you and share my perspective, my hot take as part of this event. So thank you all for tuning in, and I’m really excited to share my perspective.
As Max mentioned, I’ve been in product management for basically my entire professional career, and I have accumulated a couple of hot takes along the way. And so when asked to share my perspective on something maybe a little bit controversial, the thing that came to mind was feedback.
How do we bridge this gap between the customers and the customer-facing teams of a piece of software and the teams that are designing, strategizing, and building it?
And so my hot take, my talk, is entitled that feedback won’t change the product. That’s the spicy bit, but validation will. And so I’m excited to share that perspective based on my experience.
So a little bit, just very quickly, about me. My accent is North American. And I’m originally from the US I grew up in West Lafayette, Indiana, which is home to the world’s largest drum, which I hit as a child.
But I’ve been in Europe; I’m based now in Munich, working for Personio SE, an HR tech company, which is a kind of people operating system. I’ve been in Munich for the past two and a half years, and before that, I spent about three and a half years working closely with Masimo in Milan.
So my role at Personio and the kind of roles that I’ve had in the past are really related to product leadership, leading other product managers, getting my hands dirty, and working directly with engineers, designers, and customers to build software.
I’ve been on both sides of this equation since my career originally began working with customers as an account manager. So one of the dynamics that I’ve seen play out over my career is pretty consistent.
And so I’ve just seen this tension that exists between the user experience side of the product or the implementation side of the product and then trying to get that information to make better product-building decisions.
And so the terms and the kind of sentiment that I’ve heard expressed repeatedly is from a customer-facing team perspective, is that there’s this black box, that they communicate feedback, that they try to connect people with different types of information, but ultimately the roadmap is the product of some black magic that they don’t understand.
And it’s really challenging for them to continue to put feedback into a system that they don’t know how it’s being leveraged; this loop is never closed.
On the other side, I see product teams every day that are overwhelmed by noise, and they’re unable to discern valuable signals from that noise.
And so more feedback is coming in, and they’ve reached a saturation point where it’s not effective at altering kinds of priorities. Priorities that might take weeks or months, or even quarters to shift and adapt to.
And so, what does this end up in?
Well, what ends up happening is that inertia built and that product teams continue to do the thing because they’ve always done it. And that customer-facing teams continue to input feedback, but it gets lower and lower quality.
And the outcome of this, and this is a real tragedy, is that there is incremental progress across a wide area versus focusing on places that are really relevant right now and making a real difference inside of the product at that moment, really like taking a signal, and acting on it.
So what are we gonna do about this problem?
Well, the answer is certainly not, at least from my experience, building the perfect feedback mechanism because the perfect feedback mechanism just does not exist. All of the kind of taxonomy that you can create, all of the kind of perfect loop signaling, it just is gonna break down at scale.
But there are things that can be done, concrete things that can be done to improve this connection between customer needs and the product team.
And I want to talk about a handful of them.
So the first is that this motion of pushing feedback into a product team that is saturated will never result in positive outcomes.
What needs to be flipped is that product teams need to feel it is their responsibility to pull information that validates their decision. That they are really not in a decision-making capability on their own. They earn that privilege; they earn that right by being connected to the signal that comes.
And so this is about a product manager having an idea, having a sense of a priority, and then pulling validation on that idea. And that pulling then can maybe take them in other directions. But that is much more actionable than this processing motion of receiving feedback push to them.
The other thing and this is important for product teams I’m speaking directly to product folks out there, is that all of your decisions have to begin with evidence. That there is no kind of gut feeling, “I think that this should go” I mean, evidence also needs to be robust.
There’s no like, “Well, you know, I was talking to this customer last week, and they want me to do this,” or even worse, “I’m doing this because I’ve always done it. I came into this team, and this was the priority, and now it just continues to be.”
So product teams have to have an opinion on where that value is, and that opinion needs to be driven by evidence.
And then, finally, that validation, as I mentioned, directs the conversation. It biases the team towards action. If you’re coming up with an idea that you want to do something about, the only answer outta that conversation is, “Yes, I’m gonna go and do that thing,” or, “No, I’m gonna go do another thing,” which is much more active than processing feedback passively.
Hot Takes Live
Catch the replay of Hot Takes Live, where 30 of the top SaaS leaders across Marketing, Sales, and RevOps revealed some of their most unpopular opinions about their niche.
These leaders shared what lessons they learned and how they disrupted their industry by going against the grain (and achieved better results in the process).
So in practice, how have I seen teams successfully move into this kind of motion?
The first thing is that you need to understand that garbage in is garbage out. So do invest in aligned taxonomy that can help different parts of the business speak the same language about a particular area of the product.
You’d be amazed at how much signal and productivity gets lost because one part of the organization is thinking about something called Inbox, and another is thinking about it, calling it The Central Hub. These things just get lost, and it’s really difficult to figure out signals.
So invest in a taxonomy, whether it’s that kind of simple example or something a bit more structural like your data taxonomy, to ensure that all of your organization’s information can be structured and available in the same way.
The second thing is that you can make this lift lighter, and there are many tools out there that can take everyday sales activity and then turn that into data that can be parsed for making valuable product decisions.
So there’s a lot of technology out there that just kind of sits on top of normal everyday activities and then turns it into the evidence that then Product can use to create ideas that then they, in turn, bring for validation.
And then, finally, this is something that someone at Hootsuite told to me once, and it really has stuck with me, which is that we all reserve the right to wake up smarter.
So start a practice, see how it feels, and then just improve on it, get better, and know that doing something more productive or more valuable than what you have today is better than not doing anything at all, even if it’s not the perfect thing.
So the key takeaway when I was thinking about how to sell all of this up into a pithy quote resonates with the Socratic method and with Socrates, which is that when you accept that you don’t know anything, and this is, I think, a hard lesson that a lot of product managers learn, you’re actually on the road to true wisdom.
So I think curiosity is really important here. Curiosity and vulnerability. Sometimes bringing an idea for validation takes more courage than just receiving feedback, but it results in stronger outcomes.
And then, just to throw a little cultural reference in there, Ygritte from Beyond the Wall also has some knowledge that is aligned with Socrates and her advice for Jon Snow.
So thank you very much. I hope that this hot take resonated with some of the folks in the session. And I’m happy to take any questions.
Awesome, thank you, Alex. This was super insightful. I think a hot topic in every product team. I’ll start with a quick question.
You mentioned feedback from the sales team, which, of course, on one side is probably more interesting because it’s more open-minded; often, the user has not seen the product, and they tend to describe better what the ideal state would be.
In your experience, what’s more valuable? The feedback from prospects or the feedback that is coming from success and support.
I love that question. It’s exactly as you say. I think that the prospects who do not have an opinion about your product will be more relevant for directional information about your overall market. In contrast, signals from your existing customer base will inherently be conservative.
The existing customer base is the dirty secret; the larger your kind of customer base is, the more headwinds you have toward innovation because these customers want incremental improvements to the software. They already have trained built-in bias for the existing patterns they use. Hence, it depends a little bit on what you’re trying to optimize for in terms of the signal that you’re collecting.
I think any good product organization needs a mix. Still, as you point out, Max, you need to be very thoughtful about what kind of bias exists in each source, and certainly, prospects, I think, tend to have a wider pulse on things that are more generally in your space. Still, then maybe they’re not as relevant to the pains that your customers have today.
If you go and solve prospects’ problems and you bring them into a product that customers can’t use, you’re optimizing for the wrong thing.
Sure, nice. And how do you validate product decisions on things that don’t exist? It’s just qualitative, or can you do something to get more quantitative feedback on a totally new feature before you jump into that six-month product development cycle that might not bring in any value.
There are a couple of different ways.
I think that what I’ve seen is just being biased toward collecting some kind of signal in action because, inevitably, you’re going to learn pretty quickly whether there’s a ‘there’ there or if it’s not something that’s going to resonate.
The concrete tactical methods that I’ve seen work well is, you know, you can do things like design sprints where you actually purposefully set out with progress to build some type of lightweight prototype and then bring that kind of new concept to a selected user base, to somebody that you think is relevant; that is a certain level of investment.
Another form of validation is just building options like “Hey, we could go and focus on this problem, or this problem, or this problem” and just getting some quick signal from a handful of customers to say, “Yes, I would go in that direction” or “No, I wouldn’t.”
I think those are a handful of methodologies, but there’s a bunch out there, Dual Track, Agile, where you’re constantly awaiting ideas and progressing them through; I’ve seen a bunch of different teams use those.
Awesome. One thing that I always found challenging about the big new stuff that prospects ask is very often, it’s more creative, it can open new and interesting directions, and potentially you can expand the business.
On the other side, very often is more an idea of what they want, and you know they ask about the latest shiny object they think they need.
Maybe it’s still valuable because during a sales conversation having that kind of feature has that wow effect that helps you close the deal, but then when you look at product adoption of that feature, it’s not there.
Yeah, that dynamic plays out frequently, and I think there’s a certain aspect of experimentation that comes in there, where it sometimes kind of allows a customer to experience something and see if it actually is generating value. Still, then there’s also this exercise always to try and dig into the problem.
Like this request is in service of some type of need and certain circumstances, the ability to drill down into that need and say, “Hey, this need sounds like this, that sounds like this, that sounds like this,” and try and group it together, teams that can do that rapidly can sometimes shortcut that process.
Awesome, Alex. Thank you so much for joining us and sharing your thoughts. It was a pleasure.
It’s a pleasure, Max. Thank you for having me