Episode 119: Answering Questions About Scaling Product Teams When You Are the Leader, How R&D Helps the Product Team, and How to Effectively Transition From a Consultancy Into a Product Company

In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about how to stay on top of what is going on in a scaling team when you are the product leader, how R&D differs from product management, as well as how you can transition from a consultancy into a product company.

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

Q&A:

Q: Dear Melissa, I took on my first head of product role two years ago at a company that was going through steady growth. Last year, the company restructured and my department grew to 150 people across engineering and product, which also saw more products being added to my remit. Some of these products are very different from others. So we set separate annual goals. However, I find it hard to keep up to speed on a day-to-day basis for things like achievements and new functionality we're planning to add. Do you have any advice on how I can keep up?

A: This is definitely a problem for many leaders in a scaling situation. At first, you’ve got a couple product managers under you, you can drop by their desks and see what's going on. You probably know what's on the roadmap. But then, bam, we got 150 people. So my first question to you is, do you have those product managers all reporting to you? Or do you have a mid-layer like a Director of Product level or VP of Product? I think, if you're overseeing both product and engineering, you're going to want to think about hiring people to oversee those product managers because you can't have all of them reporting to you. So now your job, though, in that case, is transitioning more into what we think of with the CPO role or a VP of Product/Head of Product role, which means that you're overseeing the entire portfolio, you're not responsible for the day-to-day. So naturally, in any situation like this, a product leader is not going to know everything that's going on constantly.

Q: Dear Melissa, product management is always advocated as a trifecta of engineering design and business. However, what if the company also has an R&D department or a research department? How would you set them up for success in this model, if at all? The R&D department works more with academia. They write academic papers, and present at science conferences, but they barely contribute anything to the app itself besides some algorithms here and there. Unfortunately, the leaders of the company think that this is where innovation is coming from for the product. And it's a must-have department. In my humble opinion, there is no dedicated R&D department needed if you empower your engineering team the way it's meant to be in a modern product company.

A: I've seen R&D in many different organizations, but there are different ways that they show up. One side of R&D is that they're content experts. So, in this case, they're like experts on the content that's going into the system, but also the market perspective. So they're out there being forward-facing people in academic circles or in places where they're providing the science, let's say, behind what your application does. So, I'll give you a good example. In healthcare, if you're building a product that has high pharmaceutical components or something like that, you might hire some pharmacists who are really prominent in the industry. And they might advise on how you do your work and innovate around it and the trends that are coming out. They're not usually building the software, they're more like advisory roles. So I've definitely seen R&D in those situations. I've seen them in education, for instance, when they're brought in more as educators who have taught those subject matters before, and maybe they're doing content development. So they're creating the way that you teach courses. And the product management team is teaching us to figure out how those surface up through software. So the R&D team here is more content experts. They also might be a little market-facing. So they might be going out and studying, as well, where the opportunities are in the market. In all those cases, I think R&D is a really bad name for them. They're not necessarily just R&D. They're more like content experts, subject matter experts. And I think it's better to put some labels around them. That's more about product marketing, market experts, or content experts. They're highly technical people that are more like data scientists and experts from a technical perspective on building the algorithms on doing the data science behind it on building the tech, let's say. And in those situations, they're kind of a little bit more like a platform team. They're not just R&D over here, doing some sciencey stuff. And when I do see R&D being siloed in these organizations, what happens is that they're not connected back to the customer value piece.

Q: Dear Melissa, my employer hired me as a product manager in a team of project managers who have been focused on delivering the software, which is AI computer vision modules to big companies on strict deadlines, meeting high standards of quality as needed rapidly. How do I convince them to incorporate customer interviews and think like product managers when they don't even get to control or decide how these big companies will use their models within their own apps or systems? They also want to build their own B2C apps, but are worried that these big companies would cancel their license with them for doing something similar and selling to customers directly.

A: So my question here is, are you a consultancy, or are you a product company? Because it sounds like you're a consultancy. I don't know if you mean to be a consultancy, but from the last part of here, where you're considering building your own apps, it sounds like you're a consultancy. So let's start there. It sounds like you're a development consultancy that puts product management inside a company. That's your client, and they're just dictating to you what to build. So, if you're going to switch that dynamic, you have to reset expectations with your customers. If that dynamic is not set in a consultancy, that's incredibly hard to change. And it also depends on what did your clients hire you for? So I think you need to suss that out first because if you come in there and just be like, hey, we need to change the way that we work. There's actually a lot that goes into that when you run a consultancy. The second part is whether you can actually build B2C stuff. And maybe that's why you were hired as a product manager to help think through those apps. If so, that's where I think you should spend a lot of your time trying to figure out what you could sell from it. As long as you're not directly competing with what these companies sell, you're okay.

Resources:

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com | CPO Accelerator

Transcript:

Melissa - 00:00:00:

You 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 will 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 Dear Melissa. Today I've got three questions for you. First up, we're going to be talking about how do you stay on top of what's going on in a scaling team when you're the product leader? Then we're going to talk about what is R&D, and how is it different than product management? And then lastly, we're going to talk about how you can transition from a consultancy into a product company and what do you have to do to change some of those mindsets. Before I dive into those though, I want to remind you that I'm here to answer your questions. So go to dearmelissa.com. Every two weeks, I'm answering all product management and technology related questions that I can. So go there and let me know what's up. Let me know what you're thinking about. I'm happy for you to go into detail about your specific situation. I'm here to answer those so dearmelissa.com and leave me a voicemail while you're there. I love to hear your beautiful voices. So without further ado though, let's dive into this week's topics.

First up, Dear Melissa, I took on my first head of product role two years ago at a company that was going through steady growth. Last year, the company restructured and my department grew to 150 people across engineering and product, which also saw more products being added to my remit. Some of these products are very different from others, so we set separate annual goals. However, I find it hard to keep up to speed on a day-to-day basis for things like achievements and new functionality we're planning to add. Do you have any advice on how I can keep up?

Okay, so this is definitely a problem for many leaders who are in a scaling situation. At first, you got a couple of Product Managers under you. You can drop by their desk, see what's going on. You probably know exactly what's on the roadmap, but then, bam, we got 150 people. So if you're talking like two pizza teams here now, you probably got over 20 ish Product Managers maybe just a little bit less. That's still a lot of people. So my first question to you though is, do you have those Product Managers all reporting into you or do you have a mid layer like Director of product level or VP of product? I think if you're overseeing both product and engineering, you're going to want to think about hiring in people to oversee those Product Managers because you can't have all of them reporting into you, obviously. So now your job, though, in that case is transitioning more into what we think of with a CPO role or a VP of Product, Head of product role, which means that you're overseeing the entire portfolio. You're not responsible for the day to day.

So naturally, in any situation like this, a Product Leader is not going to know everything that's going on constantly. And that's really what you shouldn't be paying attention to your job anyway. What you want is the roll up and that's where those Director of Products come in. So technically, they should be going to the team, figuring out what they're doing on the day-to-day and rolling those up into a roadmap that hits you at the level where you can make decisions, which is kind of at like the initiative level, the big initiative level. Not really the epic level for the teams or the story level, but the initiative level. And you want to be able to look at that and say, hey, are these reaching our goals? Are we on track for these things? And you want to make big trade-offs, if you have to, at your level of the organization. So this happens. This is a natural course of action and it can feel really overwhelming if you don't have transparency into what's going on.

So what does that transparency look like? It's about getting the systems in place for you to be able to see and keep track of those initiatives or dive deeper onto an issue if you actually see it. So this is where Product Operations comes in and why I'm so passionate about product operations. So you should be looking to put this team in at your size. It's beneficial to get it in a little bit earlier, but that doesn't mean that you're too late. It's still going to help you like crazy. So you want to think about hiring a product operations person who's going to start putting this reporting in place so that you can look at the dashboard and know what's going on. So you're going to tell that person what you want to see. I want to be able to see the insight into the initiatives. I want to see a progress roll up of how we're working towards our OKRs and our overall goals. I want to see what's next coming up on deck as big initiatives and I want to see any issues and then whatever else that you actually have to look at.

That product operations piece is critical for you now because you do need a handle on 20 different Product Managers or people in all this different organizations, 150 engineers running around like you need a handle on what's going on. And you need the insights that roll all that up into something manageable. Because you can't be expected to read 8000 Jira tickets, and that is not worth your time. Your time and why you were hired was to go out and do product strategy. In order to do product strategy, you need to know what's currently happening and who's over those scopes. Having a tool in place where you can dive deeper and figure out what's going on that's going to make everything feel a lot better. So I really suggest you start to put that in place so that you have the transparency at the right level. Jira is not going to cut it for this. You're going to have to look at other roadmapping tools, other portfolio management tools that can really help you with that. So that's what I would suggest, and I think you're going to feel a lot better once you see all those things. All right, next question.

Dear Melissa, product management is always advocated as a trifecta of engineering, design, and business. However, what if the company also has an R&D Department or Research Department? How would you set them up for success in this model, if at all?

Okay, so I've seen R&D in many different organizations, but there's different ways that they show up. One side of R&D is that they're content experts. So in this case, they're kind of like experts on the content that's going into the system, but also the market perspective. So they're out there kind of being forward facing people in academic circles or in places where they're kind of providing the science, let's say, behind what your application does. So I'll give you a good example. In healthcare, for example, if you're building a product that has high pharmaceutical components or something like that, you might hire some pharmacists who are really prominent in the industry, and they might be advising on how you do your work and how you innovate around it and the trends that are coming out. They're not usually building the software, they're more like advisory roles. So I've definitely seen R&D in those situations. I've seen them in education, for instance, when they're brought in more as educators who have taught those subject matters before. And maybe they're doing content development. So they're kind of creating the way that you teach courses. And the product management team is teaching, is figuring out how those surfaces up through software.

So the R&D team here is more content experts. They also might be a little market facing, so they might be going out and studying as well, where the opportunities are in the market. In all those cases, I think R&D is a really bad name for them. It's just what I've seen people name R&D people before. They're not necessarily just R&D. They're more like content experts, subject matter experts, and I think it's better to put some kind of label around them that's more about either product marketing or market expert or content expert, stuff like that. But I have seen them labeled R&D. It's interesting. So you kind of want to piece through what does that actually mean then in other organizations, which I think is what you're getting at, they're highly technical people that are more like data scientists and experts from a technical perspective on building the algorithms, on doing the data science behind it, on building the tech, let's say. And those situations, yeah, they're kind of a little bit more like a platform team. They're not just R&D over here doing some sciency stuff. And when I do see R&D kind of be siloed in these organizations, what happens is that they're not connected back to the customer value piece. They're kind of given like free rein to just experiment or do academic type technology work. Typically these companies too are started by somebody who's heavy in the technology space in that kind of R&D scientific academic approach. So they give them a room to go research and come up with new things. But there's usually a strategy disconnect between what we actually want to bring to customers and what those teams are prioritizing and doing.

So I always advocate for giving teams some space to do some of that work, to do some of that research work and bring those into the algorithms. But you're correct in this way. I think that we should be treating them more like part of the platform team. And the platform team does so much scientific thinking about how do we build better algorithms, we just need to give people some space for that. So one, it sounds like they're a little bit of an evangelist role and they're trying to promote technology at your company and promote the way that you build technology, which is great, that's a fantastic role to have, but I don't think they're super separate or special compared to other engineers on the team. And I do agree that you want to empower the rest of the engineering in the organization as well. So if I'm in your company, what I think you want to make apparent here is that there could be a disconnect between what the R&D team is doing and what we actually have to launch to customers to make money.

So we want to make sure that we're prioritizing all of our work around what the customer value is and bringing that back into the work that the R&D team is doing because they might be kind of spinning their wheels or doing a bunch of work that's not going to help you achieve business value. Some of that work might be great down the road, but I think you have to ask yourself where your product leader has to ask themselves, how much time do we actually want to spend on that and how big are we, right? If I'm a small company, I might not be able to afford a ton of time on that scientific research stuff. But if I'm a big company like Facebook, you could have multiple teams doing that, you could have tons of people. It's not going to break the bank. What size are you? What size are you? How do we incorporate R&D? How are they actually connected to the customer value flow? Those are some big questions to bring up and that's what I would be asking if I was the leaders in your company. All right, last question.

Dear Melissa, my employer hired me as a Product Manager and a team of Project Managers who have been focused on delivering the software, which is AI computer vision modules, to big companies on strict deadlines, meeting high standards of quality as needed, rapidly. How do I convince them to incorporate customer interviews and think like Product Managers when they don't even get to control or decide how these big companies will use their models within their own apps or systems? They also want to build their own apps B2C, but are worried if these big companies would cancel their license with them for doing something similar and selling to customers directly.

So my question here is, like, are you a consultancy or are you a product company? Because it sounds like you're a consultancy. Now, I don't know if you mean to be a consultancy, but from the last part of where you're considering building your own apps, it sounds like you're a consultancy. So let's start there. It sounds like you're a development consultancy that put the product management inside of a company that's your client and they're just dictating to you what to build. So, one, if you're going to switch that dynamic, you have to reset expectations with your customers, right? You have to kind of come in there and say, hey, this is how we want to work. You tell us what problem you're solving, we're going to help you come up with a great idea on how to solve that through software. So if that dynamic is not set, though, in a consultancy, that's incredibly hard to change.

And it also depends on what did your clients hire you for. Like, did they hire you to solve problems or did they hire you because they know how to solve their problems and they want to dictate it to you, which could be where these AI computer vision models come in. So I think you need to suss that out first, because if you come in there and just be like, hey, we need to change the way that we work, there's actually a lot that goes into that when you run a consultancy. I've run a consultancy before. It is very hard work and resetting expectations with your client is incredibly hard. But you can make that transition if you want to. It might be more successful with other clients down the road. So that's where I would start figuring out, what does the company really want to be? And if they did bring you in as a Product Manager, it sounds like they want to move more in that direction. But I think you're going to have to line up all the things you're going to need to change in order to move there and make that very transparent for the co-founders.

The second part is asking about could you actually build B2C stuff? And maybe that's why you were hired as a Product Manager to help think through those apps. If so, that's where I think you should be spending a lot of your time is trying to figure out what you could sell from it. Now I think as long as you're not directly competing with what these companies sell, you're okay. And that's how I would think about this. Lots of companies got started using consultancy-type work and using their clients as the first proof points for things they want to sell broader or move into a SaaS product. This happens all over the place. This is a very common tactic to get used to finding problems and figuring out what you can actually build out of there. So tons of companies have done this. That's a normal pattern. But I think where your big companies are going to get iffy is if you're building something that they're building from a perspective of they want to sell it and now you're competing with them. So I would stay away from that.

If you want to build your own B2C apps, think about what are the patterns I've seen? Maybe like, what are the patterns you've seen? Even with these companies, you want to build B2C apps. But what about B2B apps, right? Could you start to standardize or automate the stuff that you're doing for these bigger companies and then sell it to them? Great way to break into a B two B market. That's how I would be thinking there. If you want to sell B2C stuff, as long as it's not your customer's product, it's not a carbon copy of it, I don't think they would really care if it is a carbon copy of it. I could see them canceling the license and then probably suing you. So I would really stay away from that. And again, you're going to want to reset expectations. If you do want to go that B to B route, even if you want to do some B2C work as well, I think you might want to think about how you disentangle yourself from consulting and then move straight into software if that's a route you want to go. So having 1ft in the software door and having 1ft in the consultancy world will work for a little bit, but it's not going to work forever.

So I think you have to be really clear about what you want for the company at the end of the day, and then you can go back and start to change the mindsets about what you need to get there. So if you're a leading product really sift through, what is the problem we are trying to solve here as a company first, that's going to help you a long way with dealing with management and the co-founders and your clients.

All right, that's it for Dear Melissa this week. Again, if you have any questions for me, please go to dearmelissa.com. Drop me those questions. Drop me a line. I am very curious to hear what you are thinking about. And then next week, we will be back with another guest on the Product thinking podcast. Stay tuned.