Episode 111: Answering Questions About Slow Product Development, the Difference Between SMEs and PMs, and Working With a Customer Success Team

In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about how to respond when people say product development doesn't go fast enough, getting the business to understand that subject matter experts are not the same as PMs, and how to work with a customer success team.

Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.

Subscribe via your favorite platform:

Q: I have often heard … stakeholders saying, ‘Product development doesn't go fast enough. Your product team spends too much time thinking; can we do less thinking and more doing?’ This usually comes from tech leaders who are more used to IT as a service, and salespeople who always feel we are one feature away from winning our new client. I have learned that trying to evangelize about product discovery is usually a lost battle. …Sometimes discovery, once done, looks obvious and when we avoid the risk, it's hard to prove. …Also, sometimes product people get too deep into discovery, try to validate too many hypotheses. …What do you think here?

A: This is a great question and something I do run into a lot with companies. I have also been in the position where people are like, ‘Oh, we don't need discovery or we don't need to do that.’ I have realized over time that there is a balance. Here's one thing that might actually help you in this situation.

Q:  How do you shift the business perspective when they tend to view a subject matter expert as the ideal product manager? As such, the primary value they want is to write contextualized stories for the scrum team. They don't have knowledge of the rest of the discipline and don't want teammates that can go outside that box. That role is typically reserved for the business general manager who is the true CEO of the product

A: People don't really understand the role of a product manager and in your case, it sounds like they are definitely operating like product owners and not full product managers. A lot of times people think that product management is like 100% subject matter expertise. …Product managers do need to have some subject matter expertise, but they don't need to have all of it. Here’s what I think you should do.

Q: My company operates in the B2B space and has grown a lot in a short space of time. In the early days, the product team had daily contact with our customers and dealt with all kinds of customer requests and feedback apart from commercial queries, which were handled by an account management team. As we scaled, the company has created a customer success function, as we recognize that product couldn't handle all inquiries from customers. The customer success team is great and provides fantastic insights on our customers and their needs. However, it can sometimes be difficult to tell where to draw the line and responsibilities of the teams. What is the best way for us to work together collaboratively but with clear distinction of responsibilities? 

A: Customer success is the nature of a growing team. You'll always have some kind of customer success, sales team, account management, all that wonderful stuff in a B2B space as you grow. And those teams are actually gold. You know why? Because they deal with all the customer inquiries, all the questions that you can't deal with as you start to scale and as you come up with more and more things that you need to build. Here’s what I would do to solidify the team, so everyone knows what is and isn’t their responsibility.

Resources

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com | CPO Accelerator

Transcript:

Melissa:

Hello and welcome to another Dear Melissa. And happy almost spring. I know a lot of you're going through daylight savings or just went through it. Hopefully all your calendars are synced up across time zones. I remember one year I was supposed to give a talk for a meetup in Brighton and I started to get emails. I was like, Hey, are you coming to this talk? I was like, yeah, it's in an hour. And they were like, no, it's right now. I was like, are you kidding me? And I looked and it was daylight savings in the UK and not in the US and this was before Google Calendars actually synced <laugh> and thought of all those things. So I will never make that mistake again and I hope you are not making that mistake this week either. So this week on Dear Melissa, we've got three questions for you.

One is about how do you respond when people say product development doesn't go fast enough? Two, how do you get the business to understand that subject matter experts are not the same as PMs? And then three, how do you work with the customer success team? So without further ado, let's dive in. First question Dear Melissa, I have often heard in different companies I've worked for stakeholders saying product development doesn't go fast enough. Your product team spends too much time thinking, can we do less thinking and more Doing this usually comes from tech leaders who are more used to it as a service. And salespeople who always feel we are one feature away from winning our new client. I've learned that trying to evangelize about product discovery is usually a lost battle. Instead of spending time understanding the value of the methodology, it becomes my opinion of how we should work.

Verse your opinion. Should I just accept that? There will always be people saying think less and do more. Be patient and explain each time why we need to decrease the risk of building something which won't be used. Give concrete examples. Keep improving our way of doing discovery and don't pay too much attention to the critics. Sometimes discovery once done looks like obvious and when we avoid the risk, it's hard to prove it is easier to put out a fire and look like a superhero. Also, sometimes product people get too deep into discovery, try to validate too many hypotheses, even those that are not that risky. Wanna use the latest techniques like AB testing when there are still too few users and involve too many people in ideation workshops. What do you think here? Alright, this is a great question and something I do run into a lot with companies.

I have also been in the position where people are like, oh, we don't need discovery or we don't need to do that. And I have realized over time that there is a balance. So here's one thing that might actually help you in this situation. There are probably a lot of things that the company already knows that is fact and is not a risky assumption. You wanna make sure that you're not doing discovery around those things. Now this sounds really basic and I'm sure your first reaction's gonna be like, oh we're not doing that. Like we definitely don't know these things, but I have fallen into the trap of believing that myself. So here's maybe some way to approach a kickoff of an initiative or any of these things. Go around to the rest of the company, look in your databases, look into the information that you have and pull out the information that you know to be fact.

For example, if sales has like notes and recordings and all of these things that are really basic and there's not a lot of risk around it that say that customers want specific features and that's literally why they're not coming to you, that gives you like a huge headstart to then go figure out exactly what type of feature and what the solution is there and dive more into the problem. You don't need to start from generative research, right? You need to get into more of a evaluative research at that point. So you wanna make sure that you are actually utilizing as many forms of feedback in your company as possible to get to the right answer and really looking at what do you know and what do you not know. So maybe with your teams is something to look at too. There is no shame in harnessing the information you already have and some of those things that you already have, like I said, could be fact, could be duh, we just have to do that and that's okay.

You don't need to do discovery over every single little thing. And also if you are gonna do discovery over things, sometimes you can skip the first 80% of answering questions cuz you know enough to get to the last 20% of answers that you need and then make a decision. So these are some approaches I think that might help here. One with your teams, make them start to put out all their assumptions and really talk about how risky they are. If they're looking at a feature to build, and let's say it's gonna take the team a sprint to build, is it really that risky? Do you need to do four weeks of research on it? Probably not. Could you just build it and then test it with customers in a, I wouldn't say an AB test, but like in a little beta test to make sure that it's good?

Yeah, so maybe you do something like that and you teach them that the more effort you put into discovery is for the things that are really risky, the things that are gonna take a very long time and are super expensive and have a lot on the line for your company to win. That's the time that we spend discovery. That's the time that we wanna spend on discovery. We wanna make sure that we really de-risk those belittle things. Like sometimes it's actually faster to build it and test it in a small, you know, in a closed off way. I'm not saying make a big launch, but like test it and see what they think if it doesn't take that much time. So what I like to do with teams is make them write down all the things that they believe to be true already. Make them write down all the things they, they don't know what are the questions that we have?

Then maybe encourage 'em to go talk to other people in the company to answer those questions first or get some leads into how to answer those questions. You may have other research that's been done by a different product manager that answers those questions and they don't know, you know, get that research, get those things and make sure you don't know it before you do the actual discovery. So this does happen a lot where sometimes teams do weigh too much discovery and they wanna test every little thing. Like I said, I've been guilty of it. When I first started experimentation, I loved it and I wanted to experiment around everything and it was not worth it and it kind of paralyzed the team. It didn't move us forward in a quick way and we didn't get stuff out the door cuz we were testing things to the nth degree and looking at these numbers that weren't moving much because it wasn't that big of a deal around what I was testing.

So you know, and at that point you should just built it, put like a big push on built it, you know it was quick enough, get the results and then figure out what to do. I think you have to teach them degrees of risk to get your team out of this mentality of we have to do discovery or copious amounts of discovery let's say on everything. That's not to say that discovery's not important, but you do discovery to do risk ideas. So I'm on board with you about doing discovery and now let's talk about your colleagues. Everybody's always gonna ask product development to go faster and be like, you need to just think less and do more. That's not how it works. So we actually need more people I think to think in companies rather than to do like we need doers but we do have to remember to stop and think and make sure we're going in the right direction.

So that's important. Now when you get into raging Wars about process with your counterparts, and I could see that you're a VP of product with your counterparts at a VP level, it never works. So instead of talking about discovery and process, instead let's change a conversation and talk about the outcomes they're trying to achieve and why. And also let's think about the sales team, right? Head of sales, let's take them for example. If they are yelling at you think let's do more. I have to get one feature away from winning a client. Maybe you need to set up a process with them to go over what's a win loss ratio that we have going on? What's your sales strategy? What types of customers are we hearing this feedback from? And make it a way where they can get their feedback to you in a little bit better of a fashion so that you can look at it quicker and make decisions off of that.

So instead maybe involve these salespeople in your discovery process. Maybe bring them in and say, hey, we know that you have the first line to the customers and you're probably gonna be able to get us through this discovery phase a lot faster. So we're gonna work with you on this to really get the information we need so that we can move faster. Bring them into the mix, let them be a part of it, let them give them the information that they're getting from their customers to you faster so you can close this loop because maybe this salesperson has been hearing about this feature that they need for the last year and a half, but it hasn't made its way to your team. And that happens a lot as well where sales is like, I've been talking about this for a year and a half, but there was no good mechanism and you're just hearing about it now.

So if we open up those lines, which is a lot of what we do in product operations to bring that information in, we'll know about it faster and we can act on it faster. So with the conversation with tech leaders and with sales leaders, level it up, talk more about the work, talk more about, hey, if you don't think we should be doing discovery, what data do you have that shows that this is true and this is what we need to build? Ask them who provide some of the data for you? Maybe it's stuck in databases somewhere, maybe it's coming in from different clients. Put some of the risk onto them too. You are not the only one who owns the outcomes here, they own the outcomes too. Try to level this up and be like, hey, we're all responsible for these outcomes here, so let's talk about what we believe to be true, what questions we have.

And if you have answers to those questions and you can point me to cold hard facts like great, that means that I don't have to go start from scratch. That means I can start from where you are and just refine my questioning a little bit so that we can get this out faster. But I think you need to approach this rather than a discovery is important. I agree with you, discovery is important. They don't care. They're gonna tune that out instead of purchase from, I agree, we all need to move a little bit faster. So this is how we're gonna do it. I'm gonna have conversations with you on this type of cadence. I want you to bring me this information. If we can get these things from you, we can move faster because we'll have the answers that we need and we can go this way.

So instead of just talking about how your team works, make them work with your team, bring them in and I think that should probably help you a little bit. So it's a hard battle. You have to really kind of weigh answering as many questions as you can and then acting. But you have to also know, and I think your team needs to know that you can't answer every single question before you actually build it. And that's okay. We're never gonna be a hundred percent certain and if you're looking for a hundred percent certainty, you aren't gonna find it before you actually built something. So at a certain point we have to say good enough on the discovery, let's try it, let's test it, let's make our beta group, let's get the feedback and let's iterate from there.

All right, second question Dear Melissa, how do you shift the business perspective when they tend to view a subject matter expert as the ideal product manager? As such, the primary value they want is to write contextualize stories for the scrum team. They don't have knowledge of the rest of the discipline and don't want teammates that can go outside that box. That role is typically reserved for the business general manager who's a true CEO of the product. Ooh, this is a fun one. So <laugh>, when people don't really understand the role of a product manager in, in your case sounds like they're definitely operating like product owners and not full product managers. A lot of times people think that product management is like 100% subject matter expertise. How could somebody who doesn't know the subject matter possibly be able to make decisions on our business? And product managers do need to have some subject matter expertise, but they don't need to have all of it.

I think you need to find a case here where you are showing, and this is what I do tend to see with subject matter experts where you're showing that they don't understand the whole vision of the product and they're not putting it together. So if they're only writing contextualized stories for the scrum team, there will come a point and there always does, where the developers are gonna be asking them 87 questions and they're gonna get frustrated and they're gonna be like, why do they keep asking me questions? There's gonna be a point where higher ups are asking them what they're building and they can't actually put a full story together. There's gonna be a point where management goes, Hey, we released a bunch of stuff I think, but like what do we actually do? I don't see the business improving, I don't see these things happening.

And the reason that none of those things are happening is because there's not a cohesive product vision that puts everybody towards the same path that has a great outcome that's associated with outcomes and we're not measuring it at that point. That's when you can go into the subject matter expertise and say, Hey, you didn't build like a full holistic vision for the developers to work on and you didn't tie that back to the outcomes we actually wanna achieve. That's part of product management. How do you do that now in a case like yours, subject matter expertise can continue on this path for quite a while. I've seen it like where companies just go down this path for a couple years and they don't realize that they need more, but then it starts to break and it's kind of hard to get people to change until they see it break in this situation, which is hard.

But you can start asking some questions to managers, maybe this general manager to the product managers, to all these people that can kind of get them steered in the right direction and start to bring up some of the issues that you're seeing like, hey, that's a great idea. I love that feature that we're just like specking out there. So when we release it, what do we think is gonna change? What's that gonna do for our clients? What's that gonna do for our business? You know, what outcomes are we actually expecting? Oh cool, that's it. Okay, I'm gonna write that down and then we'll go back and actually like look at it and make sure it did that right? You could do this in a non-threatening way. I know it just sound, it sounded like super sarcastic when I said that, please don't talk like me when you go to talk to them.

Probably won't be a great reaction but, but if you can come from like a humble, curious place and ask questions like that, you might start surfacing up things that people weren't really thinking about and it might get them to think, oh yeah, actually I don't know about that. Let me write that down. Or actually that's interesting. Let me go figure this out. So a lot of those things kind of come into play, but I will say the subject matter expert thing, it runs out eventually and it's because they will ship things that don't go together. And I, I kind of talked about this in my product thinking keynote at Agile 2022. So I'm gonna give you a great example of this. So like pretend you're a chef, you went to culinary arts school, you can Julian your vegetables, you can cook a fantastic steak or piece of meat, you can make the best types of sauces, but if you put the wrong things together, let's say you like cook fish in a sauce that's made for like a red meat and then you throw pasta on top of it and there's no pasta sauce, it's just a bunch of olive oil.

I dunno, maybe somebody can make that taste good, but in most cases that's gonna be an awful meal. That whole product at the end of the day, which is your meal, is gonna be gross. And that's what happens when we don't have product thinking layered into our product managers who are building these visions. So instead your stories become each one of those ingredients and they don't go together to create a cohesive vision and you don't get the outcome you're looking for. So that's why we need the product thinking in there. But what's really gonna shift them is you know when they get that dish and it's gross and unfortunately that's the case in many of those situations. But like I said, maybe start asking some of these questions about the vision about what we're building about those stories. Ask them to management too because those are the people who are gonna be asking those questions.

They're gonna be like, but what did we do? How are we actually doing? How are we achieving our goals? Ask those questions and it might start to get them to think. All right, last question. Dear Melissa, my company operates in the B2B space and has grown a lot in a short space of time. In the early days, the product team had daily contact with our customers and dealt with all kinds of customer requests and feedback apart from commercial queries which were handled by an account management team. As we've scaled, the company has created a customer success function as we recognize that product couldn't handle all inquiries from customers. The customer success team is great and provides fantastic insights on our customers and their needs. However, it can sometimes be difficult to tell where to draw the line and responsibilities of the teams. What is the best way for us to work together collaboratively but with clear distinction of responsibilities?

So customer success is the nature of a growing team. You'll always have some kind of customer success, sales team, account management, all that wonderful stuff in a B2B space as you grow. And those teams are actually gold. You know why? Cuz they deal with all the customer inquiries, all the questions that you can't deal with as you start to scale and as you come up with more and more things that you need to build. So when it's early days, there's a lot of figuring out what you need to build. So you need to have that close customer contact. And that doesn't mean that the close customer contact needs to go away, but as you start to scale, they're gonna come up with other issues, other bugs, not know how to use things, stuff you wanna be aware of, but also stuff that might not be priority number one for your product managers to solve today.

And that's where account management teams are great. They can also do training, they can also make sure that they're using it effectively and they are a wealth of information. So in a good partnership between customer success and product management, you're building these lines of communication. We kind of talked about in the question number one between the account management team back to the product managers. But it's nice because they like sift through all the stuff that you don't need to know and bringing you the things you should know. So you get to not handle all the questions where you're like, yeah, it's right in front of you, or this person just doesn't know how to use this cuz they don't know how to use a computer. They can handle those types of things, but they can bring you the important stuff that you need to know.

Now, you should keep an open line with the customer success team, be meeting with them constantly. I'd say like once every other week, at least once a month to hear the most pressing issues that they're finding. Ask them what types of customers they're coming from. So level set on what types of personas you're solving for before this because then they can start talking in the language that will resonate with your team as well. Now make sure as well that customer success is taking really good notes in some kind of software where you can get that feedback too. So if they are on something like a Zendesk or whatever they use, make sure that your team can get some of the exports for it so that you can get reports about like what's impacting certain personas or certain types of customers. And you can start to see the trends and sift through that, which is a great form of discovery.

Also, this doesn't mean that a customer success team is a replacement for user research. What it's doing is helping point you in the right direction for where problems are and it can, they can also help you get in touch with those customers a lot easier than maybe just like emailing them cold. But they're helping to jumpstart your user research. They're not finishing your user research for you. They're telling you where to look, they're telling you where to point, where to concentrate, and they're making it so that you don't have to sift through tons and tons and tons of research or feedback. You're condensing it into the most important things. They're actually a really great benefit to a product management team and you have to use them correctly. So think of them like that. Think of them just as the front lines, getting a lot of the feedback, bringing it back to you so that you then know where to go out and do your user research and do all of your discovery work. And you'll also have some identified clients to do it with too. So that's how I really would think about that. All right, that's it for dear Melissa this week. A reminder, if you have questions for me, please go to dear melissa.com. Let me know what you're thinking and please leave me a voicemail. I love to hear all of your lovely voices. We will be back with another product thinking episode next Wednesday. We'll see you then.