Episode 135: Answering Questions About Structuring Product Management Teams and Pivoting from Sales to Product-Led Growth

In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about structuring product management teams for complicated portfolios such as medical devices and having software digital products, moving from sales-led to product-led, and capacity planning for teams.

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

Q&A:

Q: So this one is about MedTech. How do you set up the teams for product management?

A: When you're working in a complex portfolio, like something that has hardware and software, we do have different life cycles in those products, and the way they get built as well is going to be very different. For example, with a hardware product, we're not going to be using the same type of experimentation techniques we might be using in a software product. But when we think about integrating these things, I think there are a couple of different factors you want to think about when structuring your product management team. Do you have stand-alone applications versus devices?

Q: What approach would you take if a company is prioritizing business problems over customer problems?

A: This is a really common scenario. Lots of companies out there are sales-led. When you start to introduce software components as we have in the last twenty years in these modern companies, that starts to change because our avenues for growth are not just about, hey, let me go sell this or sell the hell out of this, right, or let me go do the best marketing campaign in the world. It's also about things like product-led growth, people discovering the products, getting in there, unlocking new features, and being able to upsell them in those ways as well. So let's think about how we get people to move from sales led to a product-led one.

Q: Dear Melissa, we have quite a large application that is a mixture of EAM, ERP, and CMMS even more. This used to be a service company that evolved into a product company. Or so they say it did. Anyway, there are now six people managing the application, and I was asked to lead that team. I have a question about the product structure at this time. The structure is based on how we sell it, but the workload is wrong. Some of the products are new and have less work, and others are old and very big with about 1400 workflows, and they have one PM. So, how do you structure your team around this to make for a successful story?

A: Here is the thing. We do not structure teams around how we sell things. Instead, we structure them around strategy and around our products. It's a little combination of both. We want to make sure that we have enough coverage over different things, But we also want to make sure that we are prioritizing the stuff that needs the most work to reach our goals.

Resources:

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com | CPO Accelerator

Intro - 00:00:01:

Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.

Melissa Perri - 00:00:37:

Hello and welcome to another episode of Dear Melissa. This week we are back from vacation and we're kicking off with three great questions for you. So the first one is going to be about how do we structure product management teams for complicated portfolios such as medical devices and having software digital products. Another one is going to be about moving from sales led to product led. And then our last one is going to be about capacity planning for teams. So we got lots of great questions there for you and I want to remind you that you can write me in all of your questions as well. Go to dearmelissa.com, let me know what you're thinking about with product management. No question is too big or too small and I'll be sure to answer it on an upcoming episode. All right, let's dive into our first question. We are going to those phone lines for a phone and caller.

Speaker 2 - 00:01:31:

Dear Melissa, greetings from Barcelona. I'm working in the medtech industry and we're commercializing solutions for patients and healthcare professionals that combine devices and digital products. We need to ensure that we deliver a seamless experience for the entire integrated solution. How would you set up the teams to maximize your overall value considering the different product life cycles? And what about product ops? Should we harmonize it or try to keep it simple and specific? Thank you very much. Looking forward for the answer.

Melissa Perri - 00:02:00:

Alright. When you're working in a complex portfolio, like something that has hardware and software, we do have different life cycles in those products and the way that they get built as well is going to be very different. For example, with a hardware product, we're not going to be using the same type of experimentation techniques we might be using in a software product. So we're not going to be doing things like Concierge testing or A/B testing or things like that. And that's okay. That's the nature of a hardware product. We can still do things to limit risk there by doing prototypes and testing things that way. There are a lot of hardware components out there that do that, so make sure that you are still testing. But when we think about integrating these things, I think there's a couple different factors you want to think about when structuring your product management team. One, do you have standalone applications versus devices? So for example, like my sister has a glucose monitor. You can think of a glucose monitor as in your arm. There's no real user interface. You just kind of like shove that thing in there and then it hooks up to your phone. In this case, we want to make sure there's a strong pairing between what the information is on the glucose monitor that's being sent over to the phone, but we don't really have a team that's working on the interface for the monitor. We might have a team that's figuring out what size it should be, how it should be crafted, how it could be medically up to standards, but we're not going to have the same type of, let's say, product team as we would with a software interface because we're not in there so much. So in this case, you might have a person running the development of those hardware components of that actual medical device. You might have a head of medical devices and you might have a head of the digital products and they may be collaborating very closely together about the information they send back and forth, but it's probably not super dependent on the actual glucose monitor right there having the same exact management as a digital health component of it, the things where you go into your app and start looking through it. So in these cases, it's more like we need a team to actually look at the medical devices.

We need them to collaborate very, very closely with the software components of it to make sure that there's a strategy as a whole. I'd also say the executive team in this case needs to be working together really closely to make sure that we are in line with how we want to develop this and what's going to win for this product in the market because it's not just about the iPhone app winning, let's say. It's also about, is this monitor something small, easy to wear, something that doesn't bother people, things like that. We need to work in harmony here, but the strategy for the product needs to be in sync. The way that we develop the product is going to look very different. In some cases, I do see this where we don't have, let's say, one overarching head of product over these two different teams. The hardware team is allowed to work separately from the product management team, but we do have touch points and collaboration where we are making sure that we're sending the right information back to the digital apps to make sure that people can actually monitor it. So, that might be one situation. In other situations, you might have to more tightly work with a couple medical devices and the product management of the digital experience, things where we have an interface, things where you might be using it differently or signaling somebody to use something differently, things where you have to get the user experience actually involved in the monitoring or the actions that you need to do for their health. In this case, you want to think about, is there an overarching strategy? And are these two things so tightly coupled where we need one strategy of how it all works together? And a lot of times you will have that strategy over there, but you want to think about what are the different touch points? If there are frequent touch points between go back to the device, go back to the app, go back to the device, go back to the app, those are things that you're going to have to think about with the strategy a lot more tightly. So in this case, maybe we have a one Head of Product who's looking at both the success of the hardware component and the software components, but we might have different teams underneath them where we have a VP of hardware and we have a VP of software. And that Chief Product Officer on top of them is really making sure that they are thinking about the strategy of these things, but the teams independently work on the life cycles of their products underneath those two VPs. Now, in this case, you could have them also tightly working together.

You need to make sure that collaboration is really working here, and you need to make sure there's a combined strategy about the user journey and how we go back and forth between these things. But your hardware cycles are going to be a lot longer than your software cycles, and that's okay. It's okay to have different teams concentrating on different things. It's okay to say, hey, this is how software works, and these are our touch points in there. Things like Agile don't really work very well for hardware companies. You're not going to be using Scrum cadences when you're managing a actual physical product. That's just not how we operate. Agile was working for software. It's not working for hardware. So you're going to have to look at these two roadmaps to manage those life cycles and make sure the leaders between these two things are working really well together and collaborating around when these things are going to go live, how we're actually going to roll it out, how we test the prototypes, and how they actually go in sync. So you want to think about how you foster those collaborations between those teams. And I said the word collaboration like 18 times here, and I want you to remember that that's key. It's okay not to have one team or one leader on top of everything, as long as people collaborate. And as long as we figure out how do we get people to discuss their life cycles, discuss their roadmaps, make the strategies together. If you make the strategies in sync and then you take off to go do your work and then frequently get together to discuss it, you're going to find that it becomes a lot easier to work through these things. But this is something that a lot of companies have worked with before. We had a great episode with Yasi Baiani, who was working with Fitbit, who talks about how they managed the hardware side and how they did the software side. And it is similar to what I'm talking about, where they had two different leaders over those areas, but they collaborated very tightly together. So think about what's going to work best in your case. Think about how you set that strategy together.

Now, when it gets into product operations, it depends what you need. Remember, product operations is about enabling the product management team. If you both need data on the hardware side and the software side, which I'm sure you do, and your leaders need that data as well, maybe you have one centralized product operations team that works between the two. If the hardware team has very different distinct needs from the software team, maybe you can either embed teams there or think about how you streamline those and centralized services. If it's going to be beneficial for everybody. So really, this comes down to thinking through what do people need and how do I purposely build an organization of product operations around that. It's not just about, hey, let's just have one team. It's about what do those teams need. So Denise and I are getting very close to finishing our book on product operations. It should be out hopefully in October. We are rushing to make this a thing, and I hope you pick it up and read it and that it helps you with some of these questions as well. All right, so that's it for medical devices for now. And again, check out that episode that we had with Yasi Baiani because I think that might help you think through hardware and software as well.

Voiceover – 00:09:48:

Facilitation is a skill I see as a fundamental difference between good and great product managers. Yet it's often overlooked. Great product managers focus on guiding clear conversations and steering stakeholders to the best outcomes. You can develop these facilitation superpowers in Voltage Control's Facilitation Certification Program. Ready to unlock your greatness? Apply today at voltagecontrol.com/product. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product shops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations.

Melissa Perri – 00:10:47:

All right, next question, we're going back to the phone lines.

Speaker 2 - 00:10:51:

Hi Melissa, love the value your show brings to product folks like me. I'm currently working at a Fintech. I started the product team two years ago after convincing the CEO that product management was needed in order to maximize the engineering team's value. Luckily things are going great product development wise, but my goal is turning the company from sales led to product led. And since the whole process of product management has had a positive short-term impact solving state-clothered problems. There's a lot of resistance to prioritizing customer problems over business unit problems. So my question is, what approach would you take on this?

Melissa Perri - 00:11:28:

All right, this is a really common, common scenario. Lots of companies out there are sales led. And I think I'm starting to figure this out for myself and find out why, right? If you think about it this way. We have had a couple different ways to actually grow companies in the past. It's been marketing, it's been direct sales, it's been those types of levers. When you start to introduce software components, as we have in the last 20 years in these modern companies, that starts to change because our avenues for growth are not just about, hey, let me go sell this, or let me go do the best marketing campaign in the world. It's also about things like product-led growth, people discovering the products, getting in there, unlocking new features, and being able to upsell them in those ways as well. Many people that have come to software organizations have learned the growth levers only being from a sales-led or marketing-led organization. They don't understand what product-led actually means. And the way that we teach people in business school, the way that we teach people in life or in business and all these different organizations, a lot of it's sales-led. It's not about driving product. So this is fairly new, right? This is fairly new for the world to think about. So it's a pretty big shift if we think about going from sales-led to product-led, because now we have to relearn different engines for growth. And the companies that get this, you can see they're already product -led. They were natively product -led. The companies who don't get this are usually because people haven't operated this way before. And it's a fairly new thing, as I said. So let's think about how do we get people to move from Sales-led to Product-led. One, it's about recognizing that it's not just about selling whatever we can. It's about growing sustainably. And that's what software allows us to do. It allows us to grow sustainably. It allows us to increase our margins, put things out to customers faster and create better experiences there. A lot of our lives are taking place on screens, on phones, on browsers, for better or for worse. I know a lot of people do not like that. But that's the truth. It's how we work. It's how we get our jobs done in most of the time. And we need to be thinking about how are people interacting with those things. It's not just about overwhelming them with features. It's about giving them the right stuff in the right way with the right experiences. So when we think about moving towards customer problems instead of business problems, the way that I like to think about it is, we look at our business goals as a lens for which customer problems we want to prioritize. So it's still important to look at how much you want to grow, right? Especially if you have venture capital money, everybody's going to have like this exit plan in the back of their mind, probably like five to six years from now. How much do we want to grow? What should our ARR be? All those different metrics. You've got that.

Now you want to start to think about which customer problems can we solve to get us there. So that's what I really think about as a business problem lens. It's not just one or the other. We still need to solve our business problems as well. But your business problem should help you prioritize what are the most impactful customer problems we can solve to reach those goals, to help us grow this business. So it's a lens. It's just a prioritization metric on top of it. If you start talking this way, this helps kind of punch those fears of, oh, we're only looking at customer problems. Nobody cares about the business or the other side. You know, everybody cares about the business. Nobody cares about customers. Like we've had this war for the last 20 years. It's about looking at them both and thinking of a system of metrics. And that's how we can start to approach these problems. When you start to think about... If we need to grow by $50 million in ARR, let's say, in the next five years, what's going to help us do that? There's a lot of different levers to actually pull on that. You could go up market, go down market, but then you start in a million different other ways. We have a blog post on 16 strategies for growth on produxlabs.com. If you really want to know different strategies for growth, go check that out because it's great. But you can think through all of these different strategies and start to say, What problems do we need to solve for our customers to actually be able to go up market, to go down market, right? You start to tie it back to those business strategies. And that's what focuses people on customer problems. And that's what makes up your roadmap.

So have the conversation about in order to reach these business goals, what do we need to do for our customers to be successful in these strategies? That's what's going to start to get that conversation going, but that needs to start the executive team, and then it needs to make its way down to the rest of the teams. And if you start to change the language, I think it's a really good first step into getting your company to start thinking about customer problems more. There's a lot more that goes into actually transforming an organization from sales-led to product-led, but I really do think it starts with the mindset of why are we here? And that's to solve customer problems. Start there, start with the executives getting in line with that, telling that story, and then the rest becomes logistics about how we set up our product management teams, our operations and different things like that. Sales teams shouldn't be dictating the roadmap. Instead, it should be coming from a place of strategy, of growth strategy, hopefully. Trickling back down into what customer problems, and sales is a part of that, right? Sales will come in and give their opinion and tell you what you heard, but it needs to start from the strategy, not just from customer requests, not just from internal ideas about what will work. It's about what those customer problems are that will allow us to achieve those growth levers. So I would really start there and try to shift that conversation if it's not happening right now. That's going to start you off, I think, with the most impact to get to a product-led organization.

All right, last question. This one is a write-in. It's about capacity planning for teens. Dear Melissa, we have quite a large application that is a mixture of EAM, ERP, and CMMS. Even more! This used to be a service company that evolved into a product company. Or so they say it did anyway. There are now six people managing the application, and I was asked to lead that team. I have a question about the product structure. At this time, the structure is based on how we sell it, but the workload is wrong. Some of the products are new and have less work, and others are old and very big, with about 1,400 workflows. And they have 1 PM. So how do you structure your team around this to make for a successful story?

Okay, congratulations. You are pretty much now the head of product over these six product managers. When you're capacity planning, you do not do it from how you sell it, but you want to think about what your strategy is. So the most important thing for you is to figure out how the EAM, ERP, CMMS, all of these different acronyms that you threw at me, go together. And where do you want to invest and what needs to be improved? So you're going to look at what the strategy should look like for the next couple of years at a very high level. I'm not talking about getting really nitty gritty. I do not want to see you in backlogs. You don't even need a roadmap for the whole three years. It's just, how is it going to morph? How is it going to evolve? What big problems do we want to solve? Where do we want to end up in the future? You set that vision. Now you go backwards and you start to think about how do I fund each one of those things. So if you've got six people, you don't have a lot of people to work with here, but I'm hoping there's some other people working on these products as well. If so, fantastic. If not, you might need a little bit bigger team because this sounds a little crazy. You want to look at which pieces of this portfolio, if it's EAM, ERP, or whatever it is, all these acronyms, which ones need to be improved, which ones need the most work to help you reach those visions, and then your capacity plan against that. Now these teams should stay fairly stable year to year. This is a long haul thing. This is not like a project -based thing. You want to make sure that you have teams around each one of these components, and then you want to make sure that you are just fluctuating slightly the size of the team or the amount of money that they have year to year, depending on how much work needs to go into it. So that's where the stable product teams come from. So you probably have these six people managing each part of the application. Hopefully they have teams underneath them. Those teams are not going to fluctuate once you set the strategy year to year as much as you actually think they would because it takes a long time to deliver on it. So, what we want to do is talk about our investment. How much do we want to invest into the EAM? What do we think it could do? How can it grow our business? What's happening right now is it sounds like you're structuring off of how you sell it.

Now that could mean two things. It could mean that you are doing a go-to-market product landscape where you're bundling things or you're overseeing stuff in the way that you sell it instead of the way that you build it. You need a combination. You need somebody looking at the product architecture. And if it's bundling those different things, you're going to have somebody else looking at the go-to-market on top of that. So maybe there's a leader looking at the go-to-market on top of those different product architectures. But the way you build it versus the way that you sell it does not need to be one-to-one. You need to make sure there's enough coverage and there's enough people looking at how people use each one of these components to make that happen. So I take a step back. I would really align on that strategy. And then I would go into how do I get enough coverage, enough boundaries for each one of these product leaders to look at their product and say, I can do the roadmap for this, I understand how it goes into the strategy, and then I can align with somebody who's looking at this go-to-market strategy, the way that we bundle and sell, and figure out how we fit into that. That's really what I would be looking at for here. So capacity planning cannot happen without a strategy. You cannot do it. Please don't try. It's going to be a pain in the butt. You really want to focus on that first, and then you want to go back in and start to capacity plan around the teams and around the products. You're probably going to want to draw out a product architecture map as well, nice little diagram of what the different products are. And that doesn't necessarily need to be how they're sold. It could be what the big jobs to be done are around there, what are the boundaries of the product, and who has coverage over them. And then you're going to want to finagle that depending on where the vision is going. So that's where I would start with this. It is a big job. And usually when you start on something like this and there's a lot of people and a lot of legacy, 1400 workflows, it's going to take some time. So tease through it and try to figure out what's important, what's not important, what might I deprecate, what might I keep, and where is that going to go for my vision in the future? Then go back and capacity plan around it.

All right, that's it for Dear Melissa this week. I hope you enjoyed this episode, and if you did, make sure you subscribe to our podcast so that you never miss an episode. We are out every Wednesday on all of your podcast platforms and YouTube. We look forward to seeing you next week when we'll be back with a guest, and remember to get your questions in at dearmelissa.com. See you next time.