Episode 98: Dear Melissa- Answering Questions About Product Teams, Scaling Pitfalls, and Product-Led Companies
In this Dear Melissa segment, Melissa answers subscribers’ questions about overlap between roles, pitfalls companies fall into while scaling, and to what extent a company should be product-led.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: What overlap do you see between the role of Product Manager and UX Designer?
A: I believe it’s the product team's job, and by product team I mean UX designers, product managers, developers, researchers - everybody who works to deliver that product - to understand the user really well. When it comes to who does the work to get that done, that's where we start divvying it up. Tune in to hear how that’s done.
Q: What pitfalls have you seen companies fall into while they were scaling? What are the main principles to get right in this exciting yet challenging stage of company's growth?
A: One issue that I see when companies are scaling is that they just hire too many people and they don't think about what work those people are going to do. A lot of times they hire too many junior people and not the midlevel people. Listen to learn why this negatively affects a company, and how to avoid it.
Q: To what extent should a company be product-led? Assuming that a company relies both on services and products, are there variances to what product-led means for such companies? Or does product-led mainly apply to companies where the product is the center of the business?
A: When I say product-led, I’m talking about whatever it is you sell. If you sell steel, you want to think about how steel leads the way, what people do with that steel, and how to provide the best experience around it to make sure your customers are happy. Here are some things to consider when automating your business.
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to another episode of Dear Melissa. I've got three questions for you today. One on the difference between a product manager and a UX designer as it comes to roles. Another one about what pitfalls companies fall into when they're scaling. And then our last one about being product led in a company that is not doing software product. But before we get there, I wanna just thank you for taking the time to listen to us all of this year. We just had Thanksgiving here in the United States, so I wanted to take a moment and say I'm thankful for all of you for hanging in there with us and helping us grow this podcast. I love being able to see what you are thinking about through the Dear Melissa episodes. It's been amazing to have all of these guests on here talking about product management, but I believe that we can further our craft as product managers and help the domain of product management succeed if we all work together and learn from each other.
So big things ahead for 2023. But I am so thankful that you've been here with us in 2022 and helped share the podcast, helped get it out there, helped listen to us every single week. That makes such a huge difference. So I'm very thankful for you and as we're also approaching the end of the year, um, I wanted to do a little plug, so please forgive me on this cuz I'm typically bad at telling people that I have an online school <laugh>, so I'm not, not the best at marketing that. But I do wanna tell you that if you have training budget to use before the end of the year, we'd love to see you at Product Institute. I created Product Institute back in 2016 as a way to scale online learning and product management. So we have a lot of really great courses there or that are go at your own pace designed for the, um, entry level product manager or you've been in a couple years in the role.
And, uh, I'm looking forward to getting some more advanced courses out there next year. But this year, if you are looking for product management training, uh, please head to product institute.com. We have a great sale going on. If you put code holiday in there, um, it'll take $200 off our product management foundations course. And then also you can bundle that with two of our deep dive courses in things like metrics, tech fundamentals, UX design for product managers, or user research for product managers or market research. You can choose two of those courses and you'll get 40% off those courses as well. So it's the only time we're gonna let you bundle these discounts together. Usually it's a one time, one discount type thing. Um, but we're looking forward to having more of you join us for next year and we'd love to have you learn with us.
So, uh, please take a look at that. If you are looking for training before the end of the year, we would love to have you at Product Institute and I'm excited to get some more stuff out there for next year. We're making a big push, but for now, let's go to the phone lines or the write-ins <laugh> this week we have write ins. Let's talk about those first one.
Dear Melissa, what overlaps do you see between the role of product manager and UX designer? We have UX team members that are told it's not their role to talk to users, it's their role of the product manager. We have other UX team members as well as user research team that are tasked with the learning everything about the user and then educating the product manager. I see it as a partnership with product UX research, learning about the users with slightly different needs in mind.
What are your thoughts and how might we bring clarification to all parties? This is a really, uh, important question and a popular question, and I do think people get, you know, every, every team seems to have a different definition about who talks to use to the user when it comes down to product managers and UX designers. So let's talk about how I look at it. I believe it is the product teams job. And by product team, I mean UX designer, product managers, developers, researchers, everybody who works to deliver that product to understand the user really well. Now, when it comes to who does the work to get that done, that's where we start divvying it up. And I don't think it's a very cut and dry line here. Um, I typically see product managers, UX designers and user researchers all talking to customers or users, but we do it with different lenses and we also do it depending on what kind of time we have.
Uh, typically we have user researchers that are more centralized team. I haven't seen many instances where there is a user researcher on every scrum team. That's totally fine. Um, one common distribution that I do see here, and again, this is not a hard line, hard line, but this is usually where, how do we use people more effectively? We have a user research team that's doing more generative research that's around a problem or understanding the users and the customers as a whole.
So for instance, if we're kicking off a new initiative and we're trying to explore problems better, um, but we don't really know where to start, they're going out and casting a really wide net on user research and trying to synthesize that down into some trends and topics that they can bring back to the product managers or back to higher level, um, product people in the organization to inform their strategy and decision making. So we see a lot of user researchers doing that. We also see user researchers keeping an eye on the market, um, and then going out and doing routine research over and over again with users and with customers. It might not be around a super specific product and it might not be around a super specific feature, and that's okay. Now, it doesn't mean that user researchers can't help with actually getting into specific products or features.
Another way we've seen user research teams used is when, um, we don't have the capacity to go out and do a big user research push. So, um, for instance when uh, we were onboarding new CPOs into organizations, they would wanna know like what are the most common problems people have? Uh, who are my users? What's my personas look like? And if that work wasn't done first, we'd take the user research team and go out and do that. So that looks like talking to, you know, 12 to 20 different users and customers, um, watching them use the product, doing some usability testing to figure out like where are they struggling hearing about the gaps on the product.
Um, so this is kind of casting a wide net on what is like who are my users, how do I break them down into personas? And then what are the individual problems that these personas have? So definitely used user researchers for that type of work too. Now, product managers and UX designers, where does that come in? The way I see it is product managers and UX designers both to user research. Now UX designers are usually gonna be advocating for the user constantly, whereas product managers bring this bridge of marrying business objectives into product objectives, like user objectives too. And they're kind of balancing that. They're making sure that we get our business goals out of what we're doing for the users. So both of them have to talk to users, uh, but we're, the way I see it is they divvy up when that happens and how that happens.
Typically, if you're starting a new product and you're kicking off, you know, a discovery phase, let's say, uh, the product manager and UX designer are gonna be joined at the hip, they're gonna partner on this and they're gonna break down for everybody, uh, what's going on with the users. So they're gonna go out and they're gonna say, all right, I'll take five users. You take five users, let's go out and do research, let's come back together and, um, put it back together. And they're gonna be forming these questions together. They're gonna be writing out what they wanna learn together, they're gonna be doing shared objectives, but they might just split up the work as the product keeps going. Maybe the UX designers are doing a lot of usability tests. Maybe they're recording it for the product managers to show them what the, you know, specific areas of interest are.
Um, maybe the product managers are going with the UX designers to hear more about the feedback, to hear more about those. It doesn't really matter here as long as you come to an agreement on who's gonna lead and how are you guys gonna all get the information. So I believe this is a partnership. Um, sometimes the user experience designers just have more time to do some user research and get feedback. When you get into the thick of designing the, the product, putting it out there, getting the feedback on it, um, sometimes the product managers can't go to those meetings as often because they're doing internal meetings or they're doing other customer meetings or they're being pulled by stakeholders into other things. Product managers should be out there talking to customers as frequently as possible.
But it's okay if you're not doing this every single day as a product manager. Uh, this is why you have a team so that you can distribute work amongst the team members. So that's what I would say about that. I don't think you can have a user research team and a UX team solely be the ones talking to customers and educating a product manager. If product managers are not seeing the users use this, they're not empathizing with the user, they're only going to sway then towards the business because they don't have the user in mind. So while I don't think product managers need to be doing user research every single day, um, if they are not able to empathize with the user, if they have not talked to users for a while and they have not talked to customers for a while, they need to get out there and talk to them so that they can see firsthand what's going on.
So I really do not love that type of separation. Also, you may have UX designers who are more design heavy rather than research heavy. So again, this is maybe where you want the user researchers helping you at the discovery phase before you get into the design phases, um, to make sure that you're actually asking the right questions and getting into what you need to learn. I see user research as well as a team that can advise the product managers, UX designers and the rest of the team on how to run really good research. So they're not just doing the research, they're also there as advisors to make sure you're learning the things that you need to learn. Because user research at the end of the day is a skill and it's a hard skill and if you do it wrong, you don't get the right answers.
So when we get into talking about like product manager versus UX designer versus user researcher and who's allowed to talk to users, the answer at the end of the day is everybody. But you can only go talk to users if you know how to talk to users. So I do believe it's a user researcher's, um, responsibility to make sure that they bring best practices to the product and UX teams so that they can get answers to what they need, but we need to be able to see them, those user researchers as enabling the product and UX teams to go do user research and not blocking them from it.
All right, second question Dear Melissa, from your wealth of experience, what pitfalls have you seen companies fall into while they were scaling, specifically in terms of setting up and then iterating on their systems, practices and processes to handle increasingly complex product delivery involving multiple product teams? What are the main principles to get right in this exciting yet challenging stage of companies growth. All right, one issue that I see when companies are scaling is that they just hire too many people and they don't think about what work those people are gonna do. And a lot of times they hire too many, too many junior people and not the mid level people. So I was just talking about this with the CPO friend of mine, um, about an hour ago before I recorded this. And uh, it's a com it's a really common thing that we see at scale ups in growth stage companies.
You're thinking about how do I save the budget? So you go out and you hire a bunch of cheaper product managers, which are junior product managers who've never done it before, but then you don't have any senior product managers who can help lead set the visions at the strategy and coach those junior product managers. So this is the biggest pitfall I see. Um, nine outta 10 times I walk into a company and I'm like, wow, you have 18 very junior people and zero senior people and the junior people don't know how to do their job and you have nobody here to coach them. It's only gonna slow you down. It's worth the investment of trying to figure out how do I get some senior talent in there and have the right distribution of senior versus junior talent. So I'm not saying don't hire any junior people whatsoever.
I'm just saying you do need to hire senior people, especially if you're starting to scale. So make sure that you have the right distribution of team members around your organization and then also think about are they in the right place, um, for their skills now that we're scaling? So you're getting into more complex product delivery, you are doing multiple product um, teams, you've got probably complicated products going on there. You are doing different business challenges. Uh, some people who maybe were leading at the earlier stages on like mid-level roles or even senior roles, they might not be up to the task for the next stage of growth. And you really do need to come to terms with that and think through that. So do we have the right people in the right places at the right time? That's what we need to look at. Now when we talk about systems, practices and processes, another big pitfall I see is not enabling your products to get you the right data that you need to make decisions rapidly when you start scaling, you need to make decisions really, really fast If you don't lay the groundwork to get the user data, to get the market data, to get the feedback from financials, um, to get the usage data, all of those things, if you don't set that up early, uh, usually you're rushing to catch up while you're scaling, you're already moving really fast from a product perspective and now you gotta move really fast from a data perspective but you're slowed down because you can't make decisions.
So do that early, get that system set up early about how are you gonna get feedback funneled into the team? How are you gonna get feedback from sales funneled into the teams? How are you gonna get usage data? Do we set it up up correctly? Do we have a process for putting that in place every time we release something? So definitely think through that. Another big pitfall is lack of communication. It sounds so simple, but is every stage company, but especially when you're scaling now you're scaling, you've got more people, you've got more teams. You can't just like lean over and be like, Hey, what are you working on? You've got to actually put into place ways for you to communicate. And a lot of the ways too should just be like dropping by and asking people questions. That's totally fine, but what do you have that makes it transparent what everybody's working on?
Like what system are you using for that? Are you using a roadmap mapping tool? Are you using some kind of um, kaban tool to track work or Jira or whatever it is? But like, can we all see the priorities of the other teams? Can we see what they're working on and do we know who to go ask questions of? And then how do we get together as teams and talk through these really complicated things over and over and over again? So these cadences become incredibly important because you need to make sure that the stream, the stream of communication doesn't falter as you start to scale. It's really easy to just stay into your team and like, you know, nestle into it and just say, oh, we're just gonna stay here and work on what we're working on. But as you get more comp, uh, complex in your product delivery, you have to talk more to other people.
So that's definitely important as well. Uh, the other thing too, and I think this is the biggest pitfall of them all, is don't keep doing what worked for you at the first stage When you are in startup stage, whether it's for a product or for a company. You did a bunch of processes and you did a bunch of practices that worked really well for you. Um, longer discovery cycles, maybe shipping things really fast and not caring if they blow everything up. Um, different communication styles working on smaller teams. Whatever it is, think through what everything looks like right now before you start scaling and go, why did it work for us in the discovery phases in those early stages? Um, what about it was characterized for the right context of that stage? And what about it is not right for scaling, right? What are the characteristics of scaling?
So think through that. What are the characteristics of scaling? Um, bigger teams, more complex portfolios. Uh, usually a bigger sales team, you're now further from the customers than you were as a product team at an earlier stage because you usually have a big, big well thought out sales team if you're b2b, which is fantastic, like great, um, there's more risks now when you release to customer because uh, you could fail in astronomical ways if you have bigger customers now too. Some of those don't wanna take risks. So how do you release, how do you communicate to them? How do you make sure everybody's good? You don't wanna put a strain on your support staff because you now have, you know, x thousands of customers when you used to have four <laugh>. So you need to think through all of those things and start thinking through what worked for us back then.
Uh, that's not gonna work for us now because of the characteristics of a scale up, um, constantly growing, constantly adding new features, more complexity in your tech stack. Also get ahead of your tech stack too. Where are we gonna fail? When does support fail? When does sales fail? When does product fail? When does, uh, tech fail? Think through that. At what size of customers and how many people and usage on your site before you get there and plan for the future. Uh, we're also gonna be looking a little more longer term. When you are in a startup phase that's like highly discoverable, rapidly iterating, you usually are not planning five, six years in advance. And I'm not saying like planning down to what you're gonna release in five to six years, it's just visioning. You don't know what the vision should be. You're still figuring that out, you're still figuring out what works.
But once you figure out what works, now you gotta start planning a little bit more longer term, a little more into the future cuz you have a stable base. You've got people who are really interested in your product and you don't wanna let that go. So now retention is incredibly important. So you do have to think about what's coming next, how do I get ahead of this and how do I think a little bit more long term? So as you're scaling, remember that retention is number one. Once you land retention and it works, then you can think about expanding. But that's another thing about scaling. Make sure that you focus on retention. Hopefully that helps. There was a bunch of stuff I just rattled off, but those are the things that come to the top of my mind when I think about scaling, which is a really fun stage and I love it.
It's super exciting, but yes, it's challenging. So I wish you luck with that. All right, last question Dear Melissa, I just read your book and found the example with the insurance company, very interesting. Page 51 to 52 because it reminded me of a company where I work, we sell steel. To what extent can a company be or should a company be product led assuming that a company relies both on services and products? Are there variances to what product led means for such companies? Or does product led mainly apply to companies where the product is the center of the business? So when I say product led to, I'm not talking about like software or product led, I'm talking about whatever it is you sell. So if you sell steel, uh, you wanna think about how does steel lead the way and what people do with that steel and how do we provide the best experience around it to make sure our customers are happy.
So can you be product led in this instance? I think yes. Um, I don't think that means that services doesn't have to be, you know, services doesn't exist or anything like that. I think what that means is look at the way that we sell steel, look at the way that people use steel. What could we do to automate and grow that through our products, our software products through productized services too? So I do think you can make products outta services and upsell them, but you'll still have human beings doing that. And there are businesses where you just need a human being and you're never gonna automate it fully. And I totally understand that and I think it is an advantage to a lot of companies to have that human touch, to have that person there. And that's why some companies win. So if you win through services, great, but if you're not winning through services, that's when you start to think about how can I productize these things?
Not through human beings, through automation or through software. If you are winning through services, then you wanna think about how do you scale that and how do you productize it so it's easy for people to buy, um, it's easier to scale and we can manage it in a way where we can package those things with our product and with our software or the other products that we sell like steel. So when I talk about the insurance company in the book, um, you know, they sell insurance products. So they're never gonna be 100% software. The the product that they sell is still insurances. But that doesn't mean that they're not looking at how do I enhance the value of this product through software. And I think that's what we have to think of with being product led.
So will you ever function completely like a software company that only does SaaS, like software as a service and that's it? Probably not. And that's okay. That's totally fine. No bank is ever gonna get there. No steel company I think is ever gonna get there. That's all right. Like you don't need to be one to one for a SaaS company. But what I do think you need to do is look at these other SaaS companies and the ones building software and look at how they increase the value of their products with software, right? So they're just primarily software, but what are they doing that's innovative that you could borrow, cut that piece.
But what I do think you need to do is look at the other companies using software SaaS businesses or companies that maybe were newer but not a SaaS business. Like a great example in the insurance business is like lemonade, lemonade is an insurance company, but it's a kind of start bee company that started with a software focus. How are they using software and to enhance the value of their insurance company in ways that other people aren't because they didn't start with software. That's what I think being product led means is really looking at your products and just figuring out what are all the ways that we can add value to this but do it at scale, right? It's about scaling the value of your cust uh, of your company and your products to customers in ways that work really well and that are like margin enhancing.
So that to me is what product led means. It doesn't necessarily mean product management led, it doesn't mean software led products can be steel, they can be software, they can be insurances, but like what are you wrapping around those products? Like what are you doing to enhance the experience of actually getting that product, buying it and using it for your customers. That's what product led means. So I do think you should be focusing on that. What are all the ways we could be doing that? And if services again are where you win and where you're competitive and it's an important core of your business, just figure out how to amplify that but also figure out how to scale that. I think some people just do one off services or at consulting, but they don't think strategically about how can they grow that, how can they add that more into the product and how can they marry that with the product that they're actually building.
So it's not just about like getting rid of services and only doing software, it's about really figuring out why do we do services and where does this win compare to software and if it's not winning then how do we make this better or automated or put it into software. So that's kind of how I would think about it with other companies and I really hope that helps. So that's it for dear Melissa this week. If you would like to get a dear Melissa in and ask your question, please go to dear melissa.com, leave me a voicemail or write me a question and I'd be happy to answer it on a future episode. In the meantime, I hope you finish out 2022. Great. We'll be back next week with another guest on the Product Thinking podcast. So if you have not subscribed, hit that subscribe button so that you never miss an episode and we will see you next Wednesday.