This transcript (and the audio interview it is taken from) has been edited for clarity, and for length.
In this episode of The Supportive: data…dahta? I've been working with the Americans and Europeans for so long I think I've lost complete track of how Australians normally pronounce it.
Also do I say skedule or shedule?
This is all beside the point.
I'm just gonna say data.
In this episode of The Supportive: Data, DJs, Product Managers, Hygiene, Support…will they blend?
_____
SaaS support teams are absolutely full of good ideas.They talk to customers all day long. They see their confusion, their delight. They listen to their requests and suggestions.
They share their pain points.
Support teams know and feel what is causing problems for customers and what should be fixed and what should be added to the product. How to make customers happy.
So it can be confusing and frustrating when it feels like nobody wants to listen to the support team.
When those ideas are shared with the company, but nothing happens.
Especially when they have to go back to the queue and help even more customers deal with the same old problems. And often there's a specific person or a team who seem to be most responsible for this lack of progress. It's the product managers.
They stand right in between support and all the engineers and the designers who could make those changes like a massive nightclub bouncer…although one who is surprisingly good at using PowerPoint.
And yes, I know that's not a fair characterization of product managers. I mean some of them have hair.
But they're usually the people who are deciding what gets worked on and in what order and when and therefore they are the people that support teams need to work with and to convince if they want to get things done.
So for this episode I decided to talk to a product manager to see if we can learn more about how they work and how support might work with them more effectively. Specifically this product manager; my fellow Australian and former colleague two times over.
Mr. Ben “Hendo” Henderson.
Ben:
Yeah, g’day.
Hey, my name's Ben Henderson - I'm the chief product and technology officer at Fair Supply, an Aussie ESG analytics startup.
Mat:
I saw recently that you were also doing some DJ work.
Ben:
Yeah, I say that I've been in product for a long time but DJing was something that I got into when I was at uni. Actually up your way in Wollongong.
Mat:
Wollongong Australia's 10th largest city, just down the coast from Sydney.
It's the home of coal mines and steelworks, Izzy from neighbors…and me. #LoveTheGong
Ben:
Yeah, I think it was at the time a perfect mix of my love of technology and drinking, probably.
I was not a very good musician per se so it was either drums or DJing I think was then the options for me and I chose DJing, which was really fun. I probably did that properly for about 10 years as a side hustle.
Really, really fun and I learned a lot. This isn't one of those LinkedIn posts like “20 Things I Learned about B2B from DJing!”
Mat:
“#7 Make them wait for the……………….drop. Building anticipation for your upcoming products is vital.”
Ben:
But certainly about running a business and also just brand and reinvention. Creativity. It was a really interesting space to be involved in for a while.
I think it definitely fed into a few of my later career approaches.
Mat:
And at Help Scout…Director of Product Management.
Was that your role?
Ben:
I think so.
Yeah, I think that was the title.
Mat:Yeah, but you were also a product manager at Campaign Monitor where we both previously worked - where I was the head of support at the time. But my first question on product managers is: do you like playing Tetris?
Ben:
Ah, yes, and as my wife will tell you one of my favorite pastimes is boot Tetris.
Mat:
Or trunk Tetris, which is more pleasingly alliterative.
Ben:
When it comes to packing the car. You know when you're going on a trip I really relish that opportunity because it is quite a fun challenge to see just how perfectly you can get everything to fit together without it actually moving around when you're driving.
So yes, I do love Tetris and yes, I can absolutely see the analogy with product management.
Mat:
I cannot believe that he spotted my clever analogy before I even pointed it out.
What is the job of a product manager?
Ben:
You know to put it in really simple terms.
It's really about just understanding the intersection between what customers want and how you can solve that problem with technology.
It's kind of like combining those two things together in some way that is effective and unique and solves the problem or the unmet need in an effective way. I won't even say new and interesting because I feel like that's a little bit over baked. It doesn't have to be exciting and I think often actually effective application of technology is pretty boring. So I think that in essence is the core of product management. What a product manager does varies organization to organization significantly.
In essence I think it's being able to (in somewhat of a creative way) find the intersection between those two things: The problem and the technology solution.
A good organization is an organization where everyone kind of owns understanding those problems. I think it's fundamental or critical to being able to market effectively, it's fundamental to being able to build products, it's fundamental to being able to sell them.
Mat:
So it would make your job easier the more that the rest of the company understood “who are our customers and what are they trying to do?”
Ben:
I think it's very usually very clear when you're getting requests - demands perhaps in some cases - from sales or support or CS or whomever it might be.
It's like “oh the customer needs X feature! They're gonna leave and go to you know, I'll use a Help Scout relevant reference, Zendesk.”
Yes, that's all helpful feedback, but it's not really helpful in the sense that it's not helping you understand the problem. If people have a good way of digging into that then it becomes infinitely easier to do the product management job, which is complicated at best.
Mat:
The day-to-day of the job.
What are you often doing?
Ben:
You know the day-to-day really looks a lot like gathering the insights. User research is obviously a really important part of product development.
It's largely product design activity, but I think the customer understanding piece is something that the product manager should really be owning. A lot of product managers spend a lot of time going out and talking directly to customers which is obviously a very very helpful and good thing to do.
But what I found to be really effective is that there's lots of people within the organization who do that every day as part of their jobs. So one of the things that I would like to spend a lot of time doing is engaging not just with the customers but with the support team, sales teams, marketing teams.
A lot of those conversations are part and parcel of the day-to-day. Then turning those conversations into something… a summary or an insight. Really core to the product manager's job is producing something from those conversations.
Rather than diving straight into “Let's build this thing”...actually Nick Francis [ Help Scout CEO] was one of the people who was best of this at Help Scout - creating the product brief and crafting a really effective summary of the problem to be solved.
Mat:
A brief at Help Scout is where every product feature starts. It's a document that articulates a specific customer problem, and then it presents a hypothesis about the impact of solving it.
And it also includes research and evidence that's been collected about the problem. But it doesn't try to define a specific solution, it's intended to help leaders decide where they should invest the time and the energy of the business.
Ben:
So crafting that brief (which is essentially a summary of what you've heard from support teams and customers) - if you spend 50% of your time doing that then the product that comes out at the end will be exponentially better .
And then the rest of the time is just working with the design and engineering and all the other teams that are actually delivering and producing the stuff that you've done all of the thinking on.
Mat:
Of course, there are plenty of other competing demands on the time of product managers as Ben went on to say.
Ben:
I think product managers classically get pulled into a lot of meetings.
They're responsible for a lot of stakeholder management. Usually managing up but also managing out. We get dragged on to customer calls to explain why we don't have this particular feature, that kind of stuff.
I think that's part of the job…is key to the job, but also can detract from your ability to do a great job on all of the other stuff as well.
Mat:
Product managers are always dealing with more demands than they could possibly fulfill and it must sometimes be tempting to just stop listening. So I asked Ben about that.
Ben:
My opinion has evolved over time on that - I think when you're a bit earlier in your career the natural inclination is to be “Oh, this person doesn't know what they're talking about, I'm the product manager, I'm in the weeds with the team and talking to customers”
But actually some of the best ideas have come through those channels. They may not always be the best articulated but I think there is an element of, from a product management perspective, you have to be open to all like inputs and that includes the founders or the executive team or the Head of sales or whatever because they all do have that different perspective.
There's always a little bit of push-pull. They have a core sense of what customers need. So it's listening to that and knowing when to push hard back and say “No I don't think this is the most important and when to be like, oh, no, you know what? They're right”
But the real the real way, if you strongly disagree, if it falls into that bucket of “Hey I don't think this should be a priority”: Data is the ultimate deal breaker. Deal decider. Whatever the right word is there.
Mat:
Oh, he says dayta!
Is that right?
I mean, he's Australian. Am I wrong?
I'm sticking with dahta.
Ben:
Because a well-reasoned counter-argument with data behind it that's somewhat objective, whether that be qualitative data from customers saying “This other thing is most important” or quantitative data showing that “oh actually this feature just isn't getting used at all - why are we going to invest like money into it? And here's the things that the data shows are more important.”
I think for me that's always been the most effective way where you do want to push back, where you think it's important.
Even if you're a more junior PM, I think that most founders, leaders, will always kind of listen to the data more than they will listen to an opinion.
Mat:
So that ties in I think with support people - a question that a lot of them will have is how can I be more effective at getting my point across to the people who are deciding what to build and what not to build?
Ben:
Often customer teams are in possession of a lot of that data.
Often when I'm trying to get data on a particular problem the first people I will go to will be the customer teams. So if you're in a customer team and you're trying to influence the product roadmap, or feel a sense of conviction about a certain idea, leveraging the data that you have to tell that story is key.
There's two parts - So that's the first part [ leveraging data ] and then I think the second part is framing it up in terms of the problem that you think needs to be solved for either for the customer or for the business. You want to focus everyone's attention on the problem to be solved, and not have it be more like come across like just like an idea or a feature request.
Mat:
Now here Ben's getting at an important distinction: The difference between a problem and a particular solution, because the same problem could be solved in many different ways. He shared an example of a customer that wanted to integrate an app with another product, but the more he dug into that request the biggest pain point that he found was really about how the data import worked.
Ben:
Well, what is the problem that the customers are actually trying to solve?
“Well, they're having to manually upload the data into the system.”
…Okay Well, that's not that difficult. It's not that much data.
“Oh, yeah, but actually to do that, they need to get it into our system. They need to be formatted in a very specific way and it takes them actually four weeks after they've exported the data to actually get it in.”
So instead of building a Xero integration, maybe the first thing we need to do is just make it easier for them to put the data in, in the format they are getting it out of the system, because that actually might be easier for them than integrating with a whole other platform.
Mat:
This is a key point for customer support teams to consider. Maybe building a whole integration is just impossible because of the lack of engineering time or knowledge. But tweaking an importer to work with a different format, maybe that would be totally doable by one person who has a spare couple of days.
If the product manager doesn't have the data, that understanding of where the pain is actually happening, they're just not going to be able to make that call. And you might not need tons of data either, just enough.
Ben:
And you can tell me that “50% of our customers have requested this” - I mean that's probably even overcooking it. Even just like 5 qualitative examples of customers with very clear articulations of that specific problem is enough.
That's actually often more data than we have to work with to make other decisions.
Putting it in those terms so that it makes it easier, to to your point earlier, to do that translation into a product priority And line it up against all the other things in the backlog - I think that's really key.
Mat:
But of course even if you have data up the wazoo and a heart-rending customer story that's presented as an incredible Interpretive dance you still might not get the answer you want.
Ben:
Often the answer is no or maybe not no, but not now. Maybe, going back to your question at the start, the core of the product manager's job is essentially Tetris. It's the prioritization of the things and so often when you get a request 99% of the time it's a “not now”, because the “Now Roadmap”, you know, it goes for like 3 months and we can't possibly fit another thing in.
But I think for support teams and other teams in business who like are making those requests that can be really challenging because it feels like shouting into the void.
But it's not really intentional, it's just the reality of forward prioritization and planning. You know that you're usually planning like a quarter ahead at least if we're doing it properly.
And I think the best thing you can do is just keep the drumbeat of feedback around that thing with the data. Don't get disheartened by the fact that your Xero integration didn't get prioritized for the next sprint - it almost never will - but just keep the drumbeat of feedback and data coming through.
Every couple of weeks, be like, “oh, hey here's another 3 customers!”
If I'm hearing repeated patterns of feedback and data from customers or from elsewhere that are telling a story in my head, then when it does come to the next wave of prioritization or planning the roadmap that's going to be front of mind for me and I'm gonna be like, “oh there is there, there's something in this because I keep hearing it from different customers and different people.”
If it is truly a problem to be solved then it should keep bubbling up and it's your responsibility to keep telling that story.
What actually happens is you have a Jira board or Trello board or something where people from within the business can put the feedback or requests and stuff just keeps getting put in and then eventually people think “Well nothing's ever happening with this stuff” and then they stop putting it in.
That's actually a terrible scenario because then - unless the product manager is explicitly going out and having those conversations - the feedback loop is shut.
Mat:
So don't give up unless you have been told definitively that it's a “forever no”.
Ben:
So it is a really important muscle for an organization to build and there is a “no, not now” because otherwise that will dry up and then the PM will be “oh I don't feel like I'm hearing from customers, I don't know why!” …well, you know that that's why.
Mat:
We finished up by talking about Hendo's best advice for support teams. How can they be more effective and give their needs a higher chance to be met?
Number one was acting like a toddler - just keep asking “Why!”
Ben:
The most consistent and effective tool that I've seen anyone use, regardless of their role, is the 5 Whys. That's the quickest way to consistently get to a deeper understanding of the problem. Ask the next question: Oh, but why is that a problem?
What are you trying to achieve?
Why is it so hard?
Why are you doing this in the first place?
Ask why and keep asking why until you feel like you really understand the problem and then that's what you're trying to capture.
Mat:
He had a couple of other suggestions, too.
Ben:
Yeah I think having someone who's accountable within the Success or the Support teams for that relationship, who can also be the person that the product manager or managers know to go to when they have questions. That's really key.
And then I think quite practically on the data side.
Just having good data hygiene more than anything. As much as possible, a small number of tags or segments of feedback to put stuff in, so that it's anytime the product manager is looking for insights like they can actually go and self-serve as well and understand.
So I think that kind of data hygiene, for want of a better term, is really important for support and success teams. Maybe the last piece is don't be afraid to throw stuff away. Backlogs build out over time and it's easy just to keep stuff there just in case you need it.
It's like the anti-Marie Kondo effect…but actually there's a reason why she was so popular and that whole thing was popular. One of the best things both product and support teams can do is actually clean the house regularly so that you don't have all this noise sitting around.
“Yeah sure okay, we've had a hundred requests for Xero integration, but that's over the last 5 years and actually in the last 6 months we've only had one customer who's said something about that”
I think that probably the most effective way of keeping good data hygiene is not being afraid to clean the house andgGet rid of the stuff you don't you don't love anymore .
Mat:
They say thank you for your service backlog item, but now it's time for you to leave.
Ben:
That's right. Start fresh.
It's a good feeling for everyone but I think it's actually really effective at helping everyone understand what are really the most important things for our customers now, because customers change.
Mat:
Customers do change and also as a company your ideal customer profile will change over time And this is an area where a lot of support teams struggle. You get so used to helping your long-term customers and meeting their needs. Sometimes you have to face the reality that you will need to build a product that appeals to people who aren't already your customers. And your product might be moving away from the people that it first attracted.
I think one of the key aspects of product management that we didn't really talk about is setting the vision and the product strategy - more so in terms of being really really clear on where we're going. Because I think that really helps prioritization when it comes to the problems today.
If you don't have a clear view of where you're going from a product perspective, and who those customers are that you're working towards, then it's easy to just say “oh, yeah cool like this customer, you know”
The other piece is having a strong vision for the product and strategy that includes who that ideal customer is, or what are the core problems they are trying to solve?
And then every decision - all the Tetris, you know - really should be focused on that. I think the communication of the vision and the strategy - if everyone in the company knows what that is and they know what problems we're trying to solve, I guess like taking it right back to the start of this conversation - then that should be a much easier conversation because salespeople or you know marketing or success or support should know “okay like I hear you, but…” and they can guide the customer or the prospect or whatever in the right direction. So if everyone's really clear on that then it makes all of those conversations a lot easier.
Mat:
Huge thanks to Ben Henderson for taking time out of his day to talk to me. The key points I got from this chat were:
Backup your request with data - and you might not need as much of that as you think.
Be data hygienic - Keep the tagging simple, make it self-service for product teams if you can.
Use the 5 Whys as a simple way to develop customer insights.
Have a go-to person for the product manager to talk to on the support team.
Make sure you understand that product vision and the company's strategy. Try to align your request to that vision.
Keep up to date on the ideal customer profile that you're supposed to be helping.
And don't forget the life-changing magic of cleaning up that request backlog.
That's it for this episode of The Supportive. Thank you so much for listening! If you've got any comments or questions or suggestions, email thesupportive@helpscout.com that'll come right to me, and if you like what you hear please do take a moment to rate and review us or to share the show with a colleague.
See you next time!
___
According to my analytics most of you listening now are not Australian so while I had Ben Henderson on hand I thought it was a good chance to do some real cultural exchange And I started by asking him which Aussie phrase he liked to use the most.
Ben:
“No wuckers” is probably the clear favorite. “No wuckers” in essence means no worries.
Mat:
Here's how it works.
“No f***ing worries” becomes “no wuckin furries” becomes “no wuckers”. We are a rich and complex culture
Ben:
No worries in general I think is always a good philosophy for Aussies - especially when you're working in industries like tech or places like that which can get a little bit serious.
Mat:
Now here's an Aussie slang challenge that I presented to Hendo, but that you might want to have a go at, too. Here it comes, listen up.
“So I was chucking a uey in me ute, so I can get to the servo because I've got to get me rego check before I hit up the nasho”
What do you think it means?
Press pause now email me your best guess to thesupportive@helpscout.com before you listen to the answer. I would love to know what you thought!
Ben:
Yeah, so chucking a uey would be making a What 180 degree turn on the road 180.
A u-turn.
Chucking a uey in the ute I think you said, which is an Australian kind of vehicle. A utility vehicle or a flatbed truck as I think they would call it in the U.S.
To the servo - being servo station. I think that's a very helpful contraction of the two words So rego check is an easy one.
So I'm gonna go get my registration on my said vehicle checked. The nasho, I'm not sure that I…
Mat:
Too local for you.
Yeah, you would have been close when you were in Wollongong - the National Park.
Ben:
Oh of course. Yeah, I know my best guess was like a pub whose local reputation I wasn't aware of but yeah the National Park it makes perfect sense.
But thanks for that.
That was really fun
