A (0: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 welcome to the Product Thinking Podcast. Here's your host, Melissa Perry.

B (0:37)

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 dearMelissa.com and let me know what it is. Today we're going to be talking about org design, especially about building and structuring teams ready to level up As a product manager, Product Institute offers online courses 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 productinstitute.com and start thinking like a great product manager. Training teams email inforoductinstitute.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 a couple different factors around those value streams, I think about ownership, so who's owning the long term 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 want to 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 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 want to 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 going to be looking for what do I own in strategy, am I initiative, am I in epic? And then they're going to create more direction. So when you get to the teams, it's do this. So short layers of control. You also want to 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 in queues. For example, if you have centralized design teams and every time you want to 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 going to slow yourselves down. So think about what do you need 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 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 record system, sometimes the back office, not doctors and nurses, are using the billing systems and they're going to 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 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 customers customers Persona orientation as we get further down. It could be a whole host of different ideas like that. But you really want to 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 want to 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 will 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 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 want to think about your value streams, your strategy, and what your product portfolio strategy is going to 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 we 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 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 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 going to 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. So they're just going to 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 want to figure it out. But 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 time.