In this Dear Melissa segment, Melissa answers subscribers’ questions about the design and strategy in building the best product teams.
Show Notes
Q: Is dividing teams to generate results in different strategies a wise decision? If so, how should they communicate with each other? If not, what is the right way to organize teams?
Q: Are there any best practices in organizing digital products, future teams, and squads? How do you coordinate a backlog of all the products that are connected in an ecosystem of digital products?
Q: How do you rightsize your product teams and value streams when the typical software system can be huge with small components?
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. Welcome to another episode of Dear Melissa. Today, we're talking all about org design and your strategy around how to make great product teams. Today, we're taking questions. And if you have a question for me, too, don't forget that you can submit it to dearmelissa.com.
All right, let's jump into our first question. Dear Melissa, I have read that some companies divide their teams to generate results in different strategies. For example, they have a team for activation, another team for adoption, another for retention, etc.
It makes sense to me, but it makes me wonder how these teams communicate with each other, since if one team makes a decision, it must impact another team or maybe to fulfill the objectives. It needs another team, since the objectives of each of these teams are connected to each other. Is this the right way to organize teams?
If so, how should they communicate with each other? And if not, then what would be the right way to organize them? This is a great question, and I have seen some teams organized this way, but I don't actually believe it's the best way to organize. So this type of organization in a product management team is what we would call goal-oriented organization.
So that means that each team is divided around a specific business outcome, and they're working towards it. So that's where you've got your adoption team, your acquisition team, your retention teams. But the problem is, if they are only goal-oriented, but they don't have specific features related to those goals that are assigned to them, that they have full ownership over, this gets really, really tricky.
There's a couple pros and cons here. So here's a pro. There's so much focus on goals. Everyone is oriented towards outcomes. You are fully empowered to achieve those outcomes. That's something that we complain about a lot in product management. But there's a lot of cons, too. For instance, you're right.
If you are on a retention team and you have to make a change in four different products, that means that every developer on every team needs to know the entire code base. And that might work well for small teams, but as you get really, really large, that's going to be really hard. Developers are not going to be experts in every single feature that you have everywhere.
So you've got that problem where everybody needs to know how to work on every feature. You've got conflicting ownership as well across product managers. For example, let's say you work on Netflix. And retention is directly related to your algorithms on what you suggest to people.
Does that mean that one person has ownership over that algorithm? What if somebody else needs to change the algorithm for something else? Who's got the final say there? Who actually owns algorithms? Who owns that feature and looks at it as a whole? It's going to have a lot of battles. So what if you don't agree on the addition of a new feature or changing an existing feature?
Who wins? Who gets the final say there? This is why I think this organization with teams is really tricky. But if you're a really small team, I think you could organize this way. Let's say you've got three product managers. When I worked for a food delivery startup, we actually had something like this.
We had three product managers. One person's around adoption, which was like, get everybody signed up and onto the platform. But we had full control over the signup process, right? Like that belonged to us. And then we had other people on retention, and they did everything that was after the signup flow.
How do we keep people there? But there was direct ownership over the products that fell under adoption and retention, even though we called ourselves adoption and retention teams. And that's, I think, the trick here. If you are a small team, you can organize like that. You can have, okay, the adoption team is everything that happens before people sign up.
The retention team is everything that happens after. Maybe we have a couple other teams that are not directly related to adoption or retention. But as you grow, your product's going to get more complex, and there's going to be a lot more that relates to adoption, a lot more that relates to retention.
Now you're going to have bigger teams that are going to maybe cross over each other. Maybe the things that actually get you adopted do lead to retention. Maybe how you're onboarding has a big thing to do with that. Where do you draw the line, right? Where do you draw the line around your features? So I think it's tricky.
I think it's really tricky to organize that way. And I'm more of a fan of organizing by jobs to be done or value streams.
And we're going to talk a little bit more about that in the next question, because that starts to answer it. So our next questions. Dear Melissa, I'm interested in finding out more about managing ecosystems of digital products. Products that are different, serve different needs, but share certain features.
Something like Facebook ecosystem. You know, Facebook has Instagram, WhatsApp, Facebook, or Amazon. My questions are, any best practices in organizing product plus feature teams and squads? And how do you coordinate a backlog of all the products that are connected in this ecosystem? So with this, I think you do have to think about jobs to be done, and you also have to think about platforms.
Those would be my two key areas here. I think when you organize by jobs to be done, what you're basically doing is looking across all of these products that solve problems for multiple personas and multiple applications and figuring out what is the job to be done here. For instance, when I was at Athena Health, across the ecosystem of Athena Health in billing, in clinical, in population health, we needed a way to schedule things.
Like we needed a way to schedule doctor's appointments or schedule like follow-ups, anything like that. And they had to talk to each other. It had to talk all the way across the system. So we had a team that was a scheduling team that figured out how to do scheduling across all the systems, but they surfaced it up through a platform API that was readily accessible to anybody in those different areas.
And I think that's what you need here, right? For instance, if Facebook's got Instagram and WhatsApp, messaging is a feature, right? Like it's a job to be done. I need to be able to message people. And in WhatsApp, Facebook, and Instagram, everything involves messaging there. A lot of it involves messaging.
So you can start to see how Facebook is doing this. They're pulling messaging out of those applications and starting to think of it as a standalone job to be done. That's why they have that application that's called Messenger. And you notice they're starting to integrate the Instagram messages into that too.
I have no idea what they're going to do with WhatsApp. We'll see what's there.
That's a job to be done. I need to be able to message people. Now, the elegant part of this, right, which is hard to get right, is now how do you take that job to be done and then surface it back into all the products so that it feels like a consistent experience and not like, hey, that Messenger application is sitting over there by itself, which is what Facebook looks like today.
That bothers me. And I don't like that it takes me out of the experience into this Messenger app, but I understand what they're trying to do with it, right? They're trying to make it a piece of the platform that can plug into anything and so that you can collect all of your messages across Instagram, WhatsApp, everywhere, Facebook, all in one place.
So that's the idea behind it. But I think the hard part is how do you reintegrate that? So that's really where platforms come in, right? You have to have this team that looks at every application that you have on your ecosystem and say, where do we duplicate the jobs to be done and how do we pull that off and treat that like a platform and then treat the user-facing things like applications where we can plug in those components?
And the UX design in each one of those applications might be different. It might be pulling an API out of the platform and then you can really just adjust it to fit your user experience. But you're not rebuilding messaging 10 times, right, across these applications. You're building it once and then you're plugging it in to the right user experience at the right moment.
And that's how I think we need to approach these large-scale products or these really big things where we have the same jobs to be done being solved in many different types of those applications. But the overall job to be done of each one of those applications is different. So that's how I would think about that.
How do you coordinate the backlog for all the products that are connected in the ecosystem? That's really hard. I remember telling a bank about this and they looked at me and they're like, you know, the platform team was like, whose problems do we solve first? And that's where having a really core product strategy comes into play.
You need to make sure that your product strategy is aligned from the top.
You all are bought in on the different objectives up there. They're prioritized, they're stack ranked. You know, if Facebook is more important than Instagram in certain parts, like we need to prioritize that against each other because if you are building a platform that goes across many different products and you don't have a product strategy that encompasses everything or a portfolio strategy, you're just going to be at the whims of anybody, right?
Like anybody in the organization who's like, well, I need this to do my job and I need that to do my job. And that ends up getting you into that waiter mentality, right? Just taking orders from people and not knowing how to prioritize. So this is why consistent portfolio strategies is so important. So we want to organize by job to be done.
We want to think of ourselves as a platform in this case. And then we want to make sure that we have a really solid portfolio strategy so that we can prioritize our backlogs and figure out if we're building the right things in the platforms. This leads us into our last question, which is, how do you right size your product teams and value streams when the typical software system can be huge with small components?
So Microsoft Word, Gmail, and Zoom are all large customer facing products. Search filtering APIs could all be seen as products within a larger product. By the way, I love your book. Thank you. I appreciate that. So great question. How do we right size our product teams? I think a little bit of this is trial and error, but I do think there's some principles that we can put into play.
One of the things that I see organizations do that I don't like is they get really, really narrow on putting product managers around components and they don't have enough breadth to do strategy around those components. So for instance, I once was training a bank and one of the product managers was like, well, I'm the product manager for the login API. I said, okay, can you log in?
She's like, yeah. I'm like, great. What's next? What can you do? And she was like, I don't know. I'm just writing user stories for 40 hours a week trying to figure out what else we could possibly do. But this is my thing that I oversee. That's too narrow, right? That is not right size.
That's too narrow because there's no strategy around that. It's like, can you just log in? So we want to bring our product managers up enough so that they can oversee, again, a job to be done and they can oversee enough to be able to build a strategy around it. So when you've got something like Microsoft Word, Gmail, and Zoom, you can start to break them down into different parts, different major features in each value stream.
And as complexity increases, your team size will need to increase too. But I would start by thinking of, let's look at all the components and all the things that solve a job for our customers. So for instance, let's look at Zoom. Zoom is, by all means, a pretty singular product if you think about it.
Like you buy Zoom, you log on, you do the video chatting, but it has many different components, right? You've got the whole algorithm to generate those little Zoom room codes, right? So you get different numbers and differentiation there. I'm sure there's a huge team around security because that was a really big issue.
And then if you get into the meeting, as we all know, there's a lot of different functionality in there, right? There's recording, there's sharing your screen, there's the reactions. So we want to take some of those and figure out what's the job to be done of that when you're in a Zoom meeting. So for instance, I need to be able to participate or show emotion without talking, right?
Talking over somebody. That's where those reactions come in. So maybe there's a product manager over the reactions. And their mandate is not necessarily like put emojis on there, but instead trying to figure out all the ways that people can communicate with each other without having to talk, right? So maybe they oversee the reactions.
Maybe they oversee the chat. That might fall into that purview. But now you can start to see how we segment things, right? Like this is a job to be done. There's got to be some kind of team. Now we want to drill into that and try to figure out how much work there is there. And this is going to fluctuate as your product strategy fluctuates, right?
As you start building things out to be more mature, these products will get bigger. These features will get more complex. And if there's still a lot that needs to be built, you're going to need more product managers. And if there's not a lot to be built, you might move those product managers onto something else while still keeping a team or a division under that purview so that they can fix anything that might come up.
So for instance, if we are good with emojis, let's say we tested that, it's getting all of the goals that we want, and we don't have a lot more work to do with emojis, I want to look at something different. So maybe I'll go and optimize chat, right? So a product manager might be appropriate for that, right?
Somebody who can work on emojis, who can work on some chat. But now let's say if I don't have any emojis, I'm starting that out and chat is starting out too, I might need two product managers because it might be more complex. I'm spitballing here. I don't really know what Zoom's team looks like, but this is how I would think about organizing if I was them.
I also don't know what the complexity is in building their chat, but if it's really, really complex, maybe you would just have a product manager on that. So a couple of things here, right?
What's the major job to be done? What are these components that get you into that job to be done? And they might have several features there. It might be a collection of little features, it might be one big feature, but what solves that job to be done in your platform or in your product today? That's what I want to look at.
And how complex is that, right? Like how much work is there to do there? And then what's your product strategy? Do you have more work pertaining to that product that's coming up, or is it in kind of maintenance mode? It's just chilling out. It's going somewhere, right? Whereas you might keep that under the purview of a product team, or let's say like I try to think of it as like a director of product might oversee that and have a couple product managers underneath them working on different features.
And that director of product might keep an eye on it and then have to assign one of their product managers to fix it or overhaul it depending on what the goals look like. That's usually a pretty good structure, but you might not have somebody actively working on those features if they are working.
So that's how I would kind of think of it. I like to think of like directors of product over major jobs to be done in this case, right? Like they oversee those divisions, and they have a couple product managers that float between the features that are under their purview. And maybe one person, you know, owns each one of those features to start with, but it's pretty good if you can actually get people to move around features and get more familiar with them.
That's going to level up your team a little bit more as well. So something to think about as you're assigning product managers to different parts of the teams too. So in summary of all that, you know, and going back to our first question, what's the correct way to organize these teams? I really am a big fan of thinking in value streams and thinking of jobs to be done.
A value stream is, you think of it as like a user journey. What are the steps that a user needs to do to be able to achieve value? And then what do we need to do to help them achieve value on our side? So it's a collection of that. So as you break down your product, think about the major value that it provides and what are all the features that they need to go through to get to that value?
And what are the jobs to be done that each one of those features do? And I would break out your product teams around those and you have to make sure that they have autonomy over what they're doing. There's not a lot of cross dependencies with other teams around what they're doing. Otherwise they can't make decisions.
So if I had to go ask another team if it's okay to change something under my features every single time, that's just gonna slow you down, right? That's not a good way to organize your team. So you have to have the autonomy. You have to have the ownership over something. Not a lot of cross dependencies.
And there has to be some kind of outcome value associated with it that a product manager can work towards. If there is no outcome, again, like really looking at these goals for the users in your company, it's gonna be really hard to manage towards that. But I do think it's good to think of it in those components, into those feature components where you've got your large features, they break down with slightly standalone things.
There's a lot of ownership over it and can really iterate yourself towards a goal. That's what makes a good product team for me. So every company though is going to organize their teams differently. And that's okay. There is no like one right way to do this. This is the way that I like to do it and the way that I've seen most successful.
If you're in a platform company or a company that lends itself towards platforms, I mean, you do need a product manager over that as well. I see a lot of teams just try to put that into tech and it does not work. I've seen a lot of companies spend tons of money trying to build these platforms with these APIs in the backend and they don't get consumed by the other product teams because they're not prioritizing, they're not making a strategy.
So make sure that you do have a product manager over that as well. So that's it for Dear Melissa this week. If you have any more questions, please post them at dearmelissa.com. I can't wait to answer them in an upcoming episode. Make sure that you subscribe to the podcast so that you can see it.
And if you like the podcast, we'd appreciate a review. If you can leave us a review on Apple or Spotify or wherever you're listening to this, that would be awesome. Thanks again for listening.
