Melissa answers listeners’ questions about product operations, how to structure teams in an organization cross-functionally, and knowing when it’s time to scale your product.
Show Notes
In this Dear Melissa segment, Melissa answers subscribers’ questions about product operations, how to structure teams in an organization cross-functionally, and knowing when it’s time to scale your product.
Q: What is the problem product operations solves? What does success look like for these teams? How should these teams be structured? Who should these teams report to?
Q: How do you know in advance when your product is ready to scale and how do you prepare from a roadmap funding perspective?
Q: Can you provide some sample product and design team organization structures that you’ve seen work well? Where do product and business analysts sit in the organization? Do designers, assuming they're part of the product management team umbrella, have assigned PMs to partner with? Do you see product directors who manage product managers as stronger in the company domain, or great PM craft practitioners?
Resources Melissa Perri on LinkedIn | Twitter MelissaPerri.com
Episode Transcript
Hello, and welcome to an episode of Dear Melissa, from the Product Thinking Podcast. The lines are now open, and we're ready to answer your most pressing product questions. Which prioritization framework would you recommend and why? Hi, Melissa. Do you have any suggestions on developing a product strategy?
Whoa, whoa, whoa, whoa, whoa, that's a lot of questions. All right, let's dive in. Hello, and welcome to another episode of Dear Melissa. Today, we have questions all about scaling, which I'm really excited to dive into. So we're going to talk a little bit about product operations, which is a hot topic for everybody these days.
We'll talk about how to structure teams in an organization cross-functionally. And then we're also going to talk about when you know you're ready to scale your product. So lots of great questions. And as a reminder, if you would like your questions answered, please submit them to DearMelissa.com.
I do this every other Wednesday. I love hearing all your questions, hearing what's top of mind. It could be about something specific or something general, but go ahead and submit it at DearMelissa.com. So let's dive into our first question. Dear Melissa, we keep hearing about product ops, product operations, that is, but it doesn't seem that there is a consensus on what the reason to exist is for these teams.
Some questions I'd love to hear your thoughts on. What is the problem product ops solves? What does success look like for these teams? How should these teams be structured and who should these teams report to? This is a great question. I'm really into product operations these days, and I'm going to answer this right after this message.
All right, we're back and we're talking about product operations.
So product operations, this is actually something that my team at Products Labs was doing a lot of when we were consulting, was really setting up these product operations teams inside large organizations. I think the one thing to know is that this is needed at scale, but if you're an early stage startup, you're not really going to need a product operations team because the problem that it solves, to answer your question, is that it helps product teams scale and get the information that they need to be able to work rapidly. So if you think about the job of a product manager, right, it's to be able to figure out with the team, their development team and their design team, what should we be building, right?
So I've got this responsibility to figure out, how do I set the goals? How do I figure out problems from customers? How do I mock up what we're going to be building? What do I do with the designers to get into the wireframes? What are the details of this? How do I launch it? How do I make sure it's successful?
How do I test it with my users? How do I work with my developers to scope it, and how do I do all these roadmaps? It's a lot.
For all those product managers out there listening to this, like, I'm sure you're sitting there being like, yeah, my job is tough. I have a million different things that are on my plate. But one of the biggest issues that I've seen that adds to all of those things for product managers is things like, I can't get the right data.
So now I've got to go write SQL queries and dig through a database to figure out how to pull some data. Or I need to figure out how to get in touch with my users, but I spend like maybe 10 hours a week just trying to recruit them, line them up, get them ready for things. Or general questions for product teams as well.
How do I build a roadmap? How do we have a standard roadmapping process throughout the company? What format do I use? How are we setting goals? When are we actually reviewing the goals? This is what product operations solves. It's those things that are not purely product management. It's the operations of your product team that it actually goes in and helps to standardize and helps to scale.
And if your team starts scaling, now you've got 10 PMs, soon you'll have 20 PMs, you'll get to 350, maybe you have a couple thousand, like you need product operations. So it does not take the work of product management away from the product managers, but it makes their lives easier. And it's basically there to help enable the product management team to set things like product strategy, review if they are on track to hitting their goals, if they're building the right things.
And then also to help communication across the organization so that we can keep updating people about what's coming up, we can refine it, and we all have a standardized process. So when I think about product operations as well, I kind of break it down into three different groups. One, I look at internal business metrics.
So product operations in this area is pulling things like revenue per product line, cost per product line, users, cohorts, and stuff like that, segmenting it in these different ways. And they're pulling all these internal business metrics that we can look at to help set product strategies.
So this is data that lives within the company, right? This is not external data. This is the data that lives within the company. And we need to be able to review this in order to make sure we're on track. We want to be able to compare what we're doing now and the goals that we're hitting towards where we want to go with our product strategy and the goals that we set.
That's something that product operations helps with, helps build those dashboards, it helps get that data, it helps install those pipelines. We also want to make sure that we're updating product strategy and roadmaps for the board. So we want to be able to start segmenting things to set product strategy, things like what customer segments use this product the most and where are their gaps.
That will let us go see why there are gaps in those customer segments that don't use it the most. Is it fit for purpose? Are we missing things? That type of information is a lot to pull. And a lot of times systems are not set up well in organizations because we don't start off building our actual company thinking about those things.
Those are things that become really pertinent when you start to scale and when your product strategy gets a little more complicated.
So this product operations team with the business metrics and insights here, they're looking at that type of stuff. They're pulling all the information out of the systems that we have internally. They're putting it into good charts and visuals for a chief product officer and a product team to look at so that they can make decisions about product strategy.
So that's the business insights piece. Then usually we look at having a part of the product operations team focused on external outreach to customers. So for instance, another big thing that I hear from product managers is I spend so much time having to recruit customers that maybe I just go back to the same customer over and over and over again.
Well, if you have a good product operations team to do this, they can set up things that will help make it easier to get in touch with the customers. At one company that I was at, we built an entire database of all of our customers. We had asked them if they'd be willing to opt into user research, experimentation, different things like that.
We classified it in that database, and then we also tracked who had talked to who so we don't bother them that much.
And the product managers had access to this, and then that means that they could reach out to the customers themselves, and it cut down extensively on their time. So things like that really help with us being able to do external outreach. Also managing the tools for things like that, right? Like if you're using some kind of A-B testing framework, if you are doing some kind of surveys, the product operations team can make sure that we have standardized tools to actually do that.
And then lastly, the thing that they also see is around things like governance and processes. So very specifically on the product side, now I say processes and people go, oh my God, but this is Agile. We got to like worry about them. I'm not talking about the Agile stuff. I'm talking about the roadmaps.
I'm talking about the cadence of meetings that we have to actually review the roadmaps. So if I am a chief product officer or product leader, when do I get together with the rest of the executives to go over what the product strategy is and how far away we are from reaching it?
If I'm working with my teams, when do I meet to look at their roadmaps? When do we do cross-functional planning? All these different things comes down to governance, right? And we're looking at the product operations team to help with the governance of product management. So that's really what those teams are and what we look at for them and how we think about structuring them and how I think about structuring them.
So what does success actually look like for those teams is the next part of this question. This one is interesting. It's all about enablement, right? So the metrics and the success of product operations is, am I enabling the product management team to do their jobs better? That's what I would really look at.
And you want to have some kind of product mindset when you're in here because you don't want to do all this stuff manually. Hopefully you're creating your own systems, you're creating your own software, you're building things that work together to be able to produce these things.
For instance, you might take like a data platform like Tableau and plug in your NetSuite, your Salesforce, I mean, all your other metric things that you pull the metrics out of, and then use that to help generate reports, right? You don't want to go through all of that data by hand every single time. I'll tell you, because we've done that a million times, it takes a very long time.
That's like two months worth of work. So you want to start thinking about automating and replicating this stuff so that it becomes very useful for the teams. And then the next question on here is how should those teams be structured? Well, there's a lot of different ways to do it. I typically think about it along those three lines that I just talked about with the business insights and the internal data teams, the external customer research type teams, they're not doing the research, they're just enabling it.
And then also the governance, right? You may have different people with different skills on each one of those teams. Typically, we're all going to report into some kind of director of product.
When I scaled this at a really large organization, I'm talking 5,000 developers, 350 product managers. One of the ways we structured it is we had a VP of product operations. And then we had a product person, a product operations person aligned to each director of product. And that product operations person was focused on the business insights piece.
And they were responsible for helping that whole team in that whole section get the information that they needed. So that's one way to do it. We also had a team that just reported into the VP of product ops that also worked on the customer research stuff. And then we had a person reporting into the VP of product ops that did the governance things and the processes.
We also had a couple product coaches there because that's what this company wanted and needed. So they aligned under the product operations person. And all of those people reported into the chief product officer, which is exactly where product operations should report. So even though this type of work that they're doing helps all of product development, they're usually aligned into the chief product officer reporting into a VP of product operations, bigger companies.
If you're just starting out with this, you might just need one product operations person if you're a smaller growth stage company. If you're starting to scale, you're starting to get bigger, maybe hire a director of product ops and then eventually, hopefully you have a VP of product ops. So it's a long answer about product operations, but we have a lot more information out there on our blog at productslabs.com.
I'll let you know too, there's a lot of companies that do product operations, Pendo, Stripe, Trisentis, Gainsight, Optimizely, Uber, Calendly, Amplitude, SalesLoft, all of those companies have some kind of product operations team. This is the way that we think about it. I'm actually excited to tell you as well that I've been working on a product operations book, a new book.
Oh my God, why am I doing this again? But I'm working with Denise Tills. We are writing a product operations book based on all the work that we did at products labs, helping to set this up in teams. It will be coming out sometime next year, but it is in the works.
And if you are interested in learning more about that, go to productoperations.com, sign up for our mailing list, and we'll trickle out more information as we have it. And you'll be the first to know when it's out. All right, on to our next question. Dear Melissa, I'm a senior product manager in a large e-commerce company and currently own the roadmap to build a chat platform.
From the beginning, our approach was to move fast and start learning as much as possible, which translated into design choices and sacrifice scalability for speed. But now that I've proven the product works, I'm being challenged to scale quickly and expand to different countries. Unfortunately, the product is not ready for that.
So I'm seeking additional funding, tech and non-tech related. I wish I could have anticipated this as I would have planned my roadmap differently, especially since leadership is already bought in. My question is, how do you know in advance when your product is ready to scale? And how do you prepare from a roadmap funding perspective?
Thank you. All right, so first off, I'm seeing this little conflict in here.
It sounds like, you know, the first pressure was get something out there and make sure it works, which is great. That's what we're supposed to do, right? Like build something that doesn't scale to test it and make sure that people like it. And now everybody turned around and said, my God, you got to scale tomorrow.
That's not how it works, right? Like that's really not what we do with product management. So one, it seems like your company doesn't quite understand the whole like move fast and put something out there to see if it actually works concept and that we're not going to be building it for scalability. This is not on you.
Like you can't know in advance when your product is ready to scale until you actually test it. So that's not on you. That's just how the world works. So I think the one issue that you had is that you built a roadmap before you knew the product was going to work, right? So now we're in a really weird spot.
So let's take a step back and actually think about this. First of all, roadmaps are living things. So it's not worth it to build an entire roadmap for something that you don't know you want to scale yet.
That should just be clearly outlined on a roadmap that's like this is a discovery. We're launching an MVP for this thing. We're going to test it and make sure it works. And then we're going to go back and figure out what we need to do to actually scale it. Once you have that, now you go back and you say it's working.
This is fantastic. How do I solidify it? So now you guys start asking your questions about is this solid? Are we bug free? What's the feedback from the customers who are actually using it? Are they happy? Is it solving a problem for them? How long has it been out there in the world? Once you have this solid product, right, that you've built really, really well, then you can start to think about how do I scale it for expansion?
And I would start to look at that and figure out what do we need to do and what are the gaps we need to fill to be able to go into these different markets. So step one is you can't have a roadmap for scale for something that you don't know is even good yet. So that's not on you. And I think that's something that you have to communicate to the rest of the company.
Everybody's bought in.
I'm very happy that you're excited about this. I'm excited about this too. But the original objective of doing this was to get this out and make sure it works. We found out it works, and this is what we're going to need to do to stabilize it. Once we stabilize it, then we can talk about actually expanding it geographically.
That's how this actually has to go, and that's how you have to build your roadmap around it. So I don't think this is a question about how do you know in advance when it's ready to scale? Those are things I just talked about, like is it bug free? What's the feedback? Are people happy with it? Is it reaching the goals that you thought it would actually reach?
Then you talk about actually scaling it. When you're talking about funding too, this is why funding cycles are so hard in large organizations. Because what they should be doing in this organization is understanding that your first product that you built was a test. And they should have reserved funding for if it works, or a way for you to have flexible funding if it does work.
And this is why we typically fund teams, not necessarily fund projects, right?
This is why we advocate in organizations for stable product teams. Because if we're just switching the teams up and we have to go back for funding anytime we want to make an improvement, you end up in the pickle that you're in right now, right? Like you have to go back, ask for money, but you have to have a roadmap and you have to have all these different things.
Like we need to get away from this concept as large organizations is not conducive to product management to have to go back and ask for money all the time. Like you should just have a team that will help you scale. And we should be reevaluating where we're putting our money constantly. It shouldn't just be like a one time a year thing in November.
So anytime we have an opportunity like this that's working, we want to expand quickly, we're super excited about it. That needs to give us an opportunity to be able to say, okay, let's get some more budget for it so that we can do that. But first, we got to stabilize the product. So I would take this step back, I would go back and explain to people like, first we got this out.
We did not build it like super well because we wanted to test it. That was good. We achieved our objective.
Now let's go back and actually stabilize it. And we'll stabilize it with an eye towards scalability for the future. And I think that's just how it goes, right? Like that is how we have to build products and that's how we have to think about it. And that is a situation that you are currently in. All right, last question.
Dear Melissa, can you provide some sample product and design team organization structures that you've seen work well? Where do product and business analysts sit in the org? Do designers, assuming they're part of the product management team umbrella, have assigned PMs to partner with? Do you see product directors who manage product managers as stronger in the company domain or great PM craft practitioners?
Ooh, there's a lot of questions in there. All right, let's go one by one and start picking them apart. What I see work really well is a couple different things, honestly. Sometimes we have incredibly strong design leaders and we have a VP of product and a VP of design and design reports into design and product reports in the product.
I'll always advocate for that. I think if you have very strong functional leaders that work super well together, you will have no problems.
In the absence of that, a very common structure that we also see is a chief product officer with a VP of product underneath them and a VP of design underneath them. So everybody reports into this chief product officer. I've seen chief design officers too. I think organizations that really have a good hold on design and really value it have chief design officers.
I've seen that, but I don't have a lot of experience with that. So I'm not going to talk about that so much. I'll tell you about what I've seen. So a lot of times it's the CPO, VP of design reporting into the CPO, and then either product directors or VPs of product over different products reporting into the CPO.
And then when it comes to design, I always, always advocate to have dedicated designers sitting on cross-functional teams, not moving them, not floating them. Do not float your designers. Do not make them a resource everybody has to vie for, because that just ruins the entire dynamic and nobody can get anything done.
You need designers on the parts of your product that actually need design, and you need to hire them, and you need to put them on the team. And then they become the product trio of product development and design. And they stay there, and that's their team, and that's where they live. So that's typically what we see when we actually structure product management teams cross-functionally, and that works well.
I have seen people float designers. It becomes a mess. Everybody's like, I need the designer, I need the designer. Come over here, you gotta work with me over here. And now we have to prioritize their time across everything. And nobody can get anything done, and then everybody gets very upset that nothing gets shipped because we had a bottleneck that was designed.
And it's not the designer's fault, and they usually hate that too, because they can't work on something consistently and grow it. They don't feel like they're part of a team, they just feel like somebody pulls in once in a while to consult. So we want to avoid that at all costs. Put your designers on a stable team with product managers.
They're the partner. Your designer, your product manager, and your tech lead, you're all gonna be working together very, very closely.
So that is your stable team. Other question, where do product and business analysts sit in the org? They usually report into the chief product officers for product. You have slash business analysts. It depends if you have business analysts in your org or not, and what they actually do. So in many organizations, there are no longer business analysts because we've moved more into a product direction.
But if you do have a business analyst, which is totally fine, I've seen them usually be more like subject matter experts. And depending on the industry, you might have them align back up towards the business and just kind of work cross-functionally with the product managers. Or if they are more about giving inputs into the software, for instance, worked with business analysts in healthcare, they were the people who understood like what medicine should come up on the dropdown and things like that.
They were aligned to specific product teams, but they were the subject matter experts who could give input on regulations and what should go into the product on those perspectives.
So I don't have strong opinions about where business analysts sit because it very much matters what the company does and what those people do for the company, but I've seen it work both ways. All right, last question. Do you see product directors who manage product managers as stronger in the company domain or as great PM craft practitioners?
Great PM craft practitioners. They are, well, I wouldn't even say practitioner. They need to be great product management leaders. Like that is the job of a product director. They should be strong in product management. Every level of product management should be strong in product management. Your chief product officer, your product managers, your product directors, your VPs of product, your product analysts, whatever you call them, they need to be product people.
Why? I see so many organizations, especially large organizations going through transformations, take subject matter experts and try to teach them product and make them a product director.
It is really hard to manage people when you've never done their job before. It is really hard to understand what they should be doing. Especially if you're going through a transformation, a lot of these companies too have a bunch of product managers who don't know what they're doing. They're learning and they're learning alongside their product directors.
So who are they gonna learn from? That's so hard, right? Like where's my person that I can lean on to watch great product management actually happen? So yeah, your product directors have a big responsibility. They're usually crafting those middle layers of strategy. They're figuring out what direction we should go.
So they need to have a good business mind. And yeah, they should be strong in the company domain, but that doesn't mean that they can't learn it. But they should have a background on it. And in more complicated industries, you need a stronger background in less complicated industries. It doesn't really matter.
But they're gonna be crafting middle strategy that helps inform the solutions that we're actually building. And if they don't know how to do that crafting of a product strategy, if they're not in tune with how products are structured and architected and how they get built, it's gonna be really, really, really hard for them to do that.
So that's why I always advocate for product leaders in every level to have a strong product management background because you're also training the rest of the teams. They're watching you to learn what they're doing. If you don't know how to do your job, they're not gonna learn how to do their job. And that's when everybody gets frustrated.
So definitely try to bring in strong product directors so that other people can learn from them. All right, great questions this week. Thank you for submitting those. Hopefully that helps. And remember, submit your questions to dearmelissa.com. If you've been enjoying this podcast, we would appreciate a review so much.
They really help other people find it. I have actually had people say, oh, I wanted to listen to your podcast, but I only saw a couple of reviews on Apple. So I wasn't sure if I should or not. So reviews really matter. We would appreciate it greatly. So we'll see you next Wednesday with our next episode of the Product Thinking Podcast.
Thanks for listening. Bye-bye.
