Episode 260: Avoiding Common Mistakes in Org Design
In this episode of the Product Thinking Podcast, Melissa Perri delves into the intricate world of organizational design for product management teams. She explores how to structure teams effectively around value streams, rather than falling into the trap of organizing by architecture.
Melissa emphasizes the critical role of platform teams and the importance of starting with a solid product strategy before diving into organizational design.
Melissa sheds light on the necessity for product managers to have a clear roadmap ownership and the challenges of maintaining short layers of control in large organizations to enable quick decision-making. She also discusses the benefits of platform teams in scaling services across an organization, stressing the need for high collaboration and alignment with customer-facing teams.
Want to understand how to build a product management organization that maximizes business and customer value? Listen to this insightful episode for practical advice and strategic insights from Melissa Perri.
You’ll hear us talk about:
01:33 - Organizing Around Value Streams
Melissa discusses the importance of structuring product management teams around value streams, ensuring clear ownership of roadmaps and effective delivery of customer value.
02:32 - Avoiding Organizational Bottlenecks
Melissa explains the drawbacks of having too many layers in decision-making processes within large organizations, advocating for shorter control layers to enhance efficiency and decision speed.
06:38 - The Role of Platform Teams
The episode highlights the strategic importance of platform teams in scaling services organization-wide, emphasizing the need for these teams to align closely with customer-facing value streams.
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | LinkedIn
Episode Transcript:
PreRoll: [00:00:00] 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 find your way.
Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.
Melissa Perri: Hello, and welcome to another episode of the Product Thinking Podcast. This is the segment of the show called Dear Melissa, where I answer all of your burning product management questions. If you have a question for me, go to dear melissa.com and let me know what it is. Today we're gonna be talking about org design, especially about building and structuring teams.
Ready to level up as a product manager. Product Institute offers online courses [00:01:00] that teach you the strategy, tools, and data skills you need to make confident product decisions. Access expert led videos, practical worksheets, and proven frameworks. All at your own pace. This holiday season, get 40% off all courses with code Holiday through December 31st. Visit product institute.com and start thinking like a great product manager. Training teams, email info at productinstitute.com for group options.
Dear Melissa, how do you build and structure teams, especially when you join a new company? Are there any guidelines to follow? So when I think about building and structuring product management teams, I like to think in terms of value streams. So what I do is I map out what we deliver to our customers and what value it brings, and then I try to connect it all the way back to the platforms and the people who are building it.
Then we start to think about what's needed to deliver that value and where are our boundaries. So when I'm thinking of the couple different factors around those value streams, I think about ownership. So who's owning the long term [00:02:00] and the short term roadmaps? Do we have good coverage over that? Is there a head of product around one of those pieces of value that can really see it through end to end, so that it feels like we can deliver on it fully?
I also wanna look for clear reporting lines to functional leaders, and then there's usually dotted lines back to the business. So product management should go all the way up to the C-suite, into our chief product officer, but in a business line with different divisions usually have a dotted line to a GM or to somebody who's running that business line.
When you're also figuring out org design, it's really important to look for short layers of control for quick decision making. One big issue I see in many large corporations is when there is one person reporting it to one person, reporting it to one person, reporting it to one person. And the worst that I've seen is actually 15 people all the way up to the top.
Just one person all the way down. And that was because you couldn't get promoted unless you were a people manager in many situations. This is why you see principal product managers in [00:03:00] many large corporations so that you can feel they can be promoted, they could take on more risk, but they're not managing people because that's not what they wanna do.
Same thing that you see with developers. You want short layers of control. Because if you don't, what happens is people look for control all the way up and down the organization, and then they compress the strategy. So everyone's always gonna be looking for what do I own in strategy? Am I initiative? Am I an epic? And then they're gonna create more direction. So when you get to the teams, it's do this. So short layer is a control. You also wanna make sure that there's balanced teams, you have people on that team or associated with the team in the right proportion so that there are less handoffs, there is less waiting and queues.
For example, if you have centralized design teams and every time you wanna do a design for UX or you want it fixed, and you have to go to a centralized design team and say, Hey, can I please have a person so that I can get on your backlog to do this? You're gonna slow yourselves down. So think about what do you need [00:04:00] to release that value. How much of that time do you need from these different people? And how do we make sure that we're all balanced? So we have the skills that we need to get it out there, and we have the time commitment and the people dedicated to actually do that.
~So when you're thinking about balance teams as well all of this organizational design too doesn't have to be done through reporting lines. It can be done through how you can assign people around problems and the customers to serve in your scope.~
~So what do I mean by that?~
So then there is the how do we allocate PMs around the problems to solve or around the parts of the product for that ownership.
And usually it manifests in a variety of ways. Two very common ones is to organize by customer. And you would do that when there's clear differentiation in the products or tools that they use. So for example, electronic health records system, sometimes the back office, not doctors and nurses, are using the billing systems.
And they're gonna have very different workflows than the people who are treating the patients, which would use more of a clinical system. So in that way, you might be organized by persona so that everybody has what they need to be able to get things done. Or you could be organized by jobs to be done, which is a very common allocation as well, if there's a lot of overlap in the personas and what they use.
When we talk about jobs to be done, that could be, for [00:05:00] example, reporting maybe many different personas, access reporting in different ways, but it's highly customizable or configurable to each one of those personas once they get in there. So when we look at that too, at scale, in larger organizations, it might be both. It might be a combination of it. I've seen it where there is jobs to be done at the top, and then we get into customer's persona orientation as we get further down. It could be a whole host of different ideas like that, but you really wanna make sure that you anchor it back to the value streams and figure out what makes sense for your context.
One thing you do not wanna do is organize by architecture. So when people first started to introduce product managers and product owners out into their company, I saw a ton of companies organizing by architecture. So it was like there is an API, we have to manage that. API, we'll put a PO around it, and what will happen is that.
Product owner would sit there and try to optimize that API to death and find all this work that would be needed for it just so they could keep their job. Now that API may have been solving a [00:06:00] problem, it may have been good to go like a year before, but somebody will always invent work if you put them around every single little component.
So instead, you really wanna think about your value streams, your strategy, and what your product portfolio strategy is gonna be, and that's how you're organizing your teams for scale. There should be good coverage over many components, many technical components from a product manager, so that they have choices and those different areas can be moved to solve different problems in a large swath of a job to be done.
That's how I would think about it. Now, when talk about organizing by architecture, there are platform PMs and of course we'll always go back and start to talk about, well, is that really architecture? And it kind of is. So there are benefits to having platform teams. They're a horizontal team, and it makes sense to have them when you want to scale the same services to the rest of the organization.
This can become extremely valuable when we're not rebuilding the same scheduling functionality or the same data tools, and we don't have, we're not building all of our single components in each one of these product [00:07:00] lines. So we do usually have platform teams and they serve the rest of the organization with apps on top of them, and the platform teams can get pretty big.
This is the only delineation typically that I like to see between the value streams. But what happens is when you do have platform teams, you're now making up for it with really high collaboration, making sure that you are aligning the platform roadmaps back to the customer facing teams and the value streams there as well. And you need to have the infrastructure set up so that the platform teams are aligned to your customer facing value and coming all the way back through, and you're going back and forth and negotiating that value and trying to figure out what's gonna help your customers. So that's what's needed in order to make platform teams work.
A lot of people skip that part when they have platform teams, they just operate in isolation. That's never good. They're not just order takers for the customer facing teams. They should be strategic as well. They're usually building a very complicated backend, [00:08:00] so they're just gonna have to match that as well though, and figure out how do we also service our customers who are more of the internal teams, and how does that customer value go all the way back to our customers?
So this type of architecture, though, will help you scale. And that's why platform teams are very important. You still need product managers on platform teams because you need a strategy to figure out how that platform scales what problems we actually want it to solve. It doesn't have to solve all of them, and how it can be strategic to our whole company at the end of the day.
So I hope that helps you with your org design questions. It's always fun diving into this when you get into a company and wanna figure it out. I would advise you to start with product strategy always. Figure out your product portfolio, figure out your strategy, and then work your way back into an org design.
Don't just leap into org design first, do the strategy portion first, then come back and figure out how to organize to get that strategy done. I hope that helps, and if you have any questions for me, go to dear melissa.com and let me know what they are. And remember to like and subscribe to this podcast so that you never miss an episode. We'll see you next [00:09:00] time.