Episode 52: Answering Questions About Startup Roadmaps, Buy-In vs. Consensus, And Restructuring At Scale
In this Dear Melissa segment, Melissa answers subscribers’ questions about how roadmaps fit into an early stage company, the difference between gaining buy-in as a leader and reaching team consensus, delineating ownership as a leadership team, and how to restructure teams when your organization starts operating at scale.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: Do you have any suggestions for creating the product roadmap per quarter in a startup company? [1:10]
A: In really early stage companies, it’s actually impossible to create a roadmap… because you are always trying to find product market fit. It’s characterized by high experimentation and trying to figure out the right feature to build, so you can’t actually plan that far in advance. You have to be rapidly experimenting, rapidly trying to figure out what customers want, testing, analyzing the data, analyzing the feedback and making moves. If you try to do a quarter by quarter roadmap you're going to get stuck… What I’d suggest instead of doing a roadmap is look at your company growth goals, figure out the drivers behind them and start prioritizing experiments for the quarter. Think about how you're going to measure them and line those up like that's your road map. [2:37]
Q: As a product leader, how do you decide where to draw the line between activities you need to lead versus activities you would be more successful with if you had buy-in from your team? How do you draw lines of responsibility and ownership between VP, product director, product managers and other supporting team members, when as a product director, your responsibility is to lead the product team, the product managers report to you, and there's overlap with what you and the VP are both currently doing in directing team activities? [6:02]
A: It’s always good to have buy-in, and everybody wants to hear about how their work impacts the company, so you need to be a really good storyteller to get everyone on board… give them more information; draw the parallels between why you’re doing xyz this quarter, how it’s going to help them achieve their goals, and the information xyz is based off of… [6:55]
The second part of your question is about drawing lines of ownership between your VP, who oversees more than product management, you as a product director, and the product managers. This sounds like you are compressing your strategy. If there is a lot of overlap between what your VP does and what you do, your VP is too into the weeds; they should be leveling up to think about more than just product management, especially if that's what they oversee… Start having a conversation about the business objectives; say “to do my job better and to help you be more successful, I need to understand how we're prioritizing these types of things in our business.” [10:19]
Q: How do we best evaluate which parts of the product we build our teams around? What are some common pitfalls when restructuring a product delivery organization to operate at scale? [16:11]
A: It sounds like you were organized around value streams to begin with, so now we just need to think about ownership boundaries and how that scales for more people. You want to keep the value streams, you want to think about how your product delivers value to the customer and make sure that people are aligned correctly… You don't want it to be where every team has to go get buy-in or align with a roadmap or ask for permission from every other team. Think about which product pieces or features are dependent on the other pieces, and try to keep those together under one leader…[16:47]
I would not structure teams around acquisition retention because a lot of those things will overlap on feature development and, again, dependencies right there. I would probably structure them in a couple different ways; now this depends on your product entirely. One easy one is a two-sided marketplace. [18:31]
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa: Hello, and welcome to another episode of Dear Melissa. This week. We've got three great questions for you about startups and building roadmaps about product leadership decisions and ownership over strategy. And then also about hypergrowth stage companies. How do we structure our teams? So very good questions. And I just wanna remind you that if you, you have a question for me, please submit it to dear melissa.com. I've been, uh, reflecting on this podcast, which is one year old. Uh, I think probably this week, which is nuts. Uh, and it's been one of my biggest joy of doing 2021. So I'm excited to continue it into 2022. I'd also love to hear about, you know, what you to hear on the podcast. So please, uh, you know, drop us a line, if you go to dear melissa.com, you can send us you know, suggestions and questions hit me up on Twitter @lissijean.
I'm always on there waiting to hear about what you think. So please tell me what you wanna hear more of, um, what you love about the podcast in 2021. We wanna keep doing that. We wanna bring you more great content. So with that, let's dive into this week's content and start with our first question.
“Dear Melissa, I recently moved to my first product manager role in a startup company. Having previously worked in development, I have completed the product management foundations from product Institute, but I'm now, now struggling to find a method or template to help me create the product roadmap per quarter, which will project the company vision and growth plan in the new year. Do you have any suggestions?”
I do have a lot of suggestions for you and I'll get to them right after this message.
All right, we're back. And we're talking about building a roadmap in a startup company. So if you've taken the product management foundations course, my course on, uh, product institute.com. Uh, we do have templates in there to help you create a roadmap. And I'm sure you've seen them because I know you've finished it. I can see, I can see who submitted these questions. So I check up on everything and I research, but I think this is why you're actually having, um, a problem. I went to look up your company and I don't give any of this away. Who said anything? It's all anonymous, but I will tell you, I looked up the company you worked at and it's very early stage. Um, so you, it looks like you have less than 10 people. You have a small seed round and you are very early stage in your development.
Fun times. I love startups. It's good times all around. I'm sure it's hectic, like crazy. And congratulations on your first product management role, like taking a leap into a startup is kind of crazy, but I'm sure you're having a lot of fun and learning along the way now here's where you might be struggling because of the stage of your company in really early stage companies. Uh, it's actually impossible to create a roadmap. I wouldn't say it's impossible. Like, yes, you can fake it and create a roadmap if you want to, but it's not gonna be good. And that's because in very early stage companies and very early stage startups, you are always trying to find product market fit. So it's characterized by high experimentation and trying to figure out what is the right feature to build. So you can't actually plan this too far in advance.
You have to be rapidly experimenting rapidly, trying to figure out what customers want continuously testing, analyzing the data, analyzing the feedback and making moves. If you try to do a quarter by quarter roadmap, you're gonna get stuck. I'd actually say you should only be looking at one quarter out at the stage that you're at until you find super solid product market fit and start to scale. When you're in a scale up company, you hit the stage of, you know, probably just over $10 million in ARR. Um, now you really need roadmap apps. This is where all those templates I talk about. Um, product Institute really come in. Now, what you wanna look at is what we talked about in the discovery phase, and you wanna start prioritizing your experimentation. So what I'd suggest is instead of doing a roadmap, look at those company growth goals that you're looking at, try to figure out, um, what you think will be the drivers behind it, right?
What's the customer value. And then start prioritizing experiments for the quarter. Think about how you're gonna measure them and line those up. Like, that's your roadmap. It should be a roadmap of experiments, but you don't wanna go a year out because I guarantee you, you get a year down the line in the stage that you're in and you're gonna, oh, wow, none of this is relevant anymore because we learn so much, right? Like that is startup life. You're gonna be learning continuously. You're going to be talking to your customers. And if you're not, that's, that's something that's really important, right? Have a continuous stream of feedback on all the things you're doing right now, so that you can ensure that you're gonna hit product market fit. So is what you should be looking at. So I'd say like, don't look for a typical roadmap template instead start thinking about experimentation.
So you may wanna look at, um, David Bland's experiment, mapping this in assumption mapping. That is a great canvas to use for something like this. Start to think about, um, how to map out your business, how to scale it. Um, it really tests all different types of assumptions that you can have between feasible, viable, and desirable. So you should be looking at something like that, trying to prioritize, which one of those is most important for you right now, running experiment, experiments in all of those categories. And then thinking about what will scale. So you wanna do are things that don't scale at the beginning, and then start to think about out of these experiments. What are the things that we wanna double on double down on and scale to become more successful and that's after you find product market fit. So I'd say, you know, don't look for traditional roadmap templates. They're not gonna help you. You're not at that stage yet. Um, instead start to think about how do I prioritize my experiments and get ruthlessly focused on understanding the data that comes out of the experiments and putting those into new experiments until we reach product market fit until we're ready to scale what we have. Then let's go talk about roadmaps after that.
All right, next question.
“Dear Melissa, as a product leader, how do you decide where to draw the line between activities you need to lead versus activities you would be more successful with if you had buy-in from your team? It seems that any activity could be viewed as requiring team consensus and buy-in. So the line tends to get blurred. Also, how do you draw lines of responsibility and ownership between VP, product director, product managers, and other supporting team members? When as the product director, your responsibility is to lead the product team, the product managers report to you and there's overlap with what you and the VP are both currently doing in directing team activities. Here our VP oversees more than just the product.”
All right, this is a great question. Um, let's look at the first part where we're talking about activities you need to lead versus activities.
You would be more successful with if you had buy in from your team. I think it's always good to have buy-in and everybody wants to hear about how their work impacts the company. So I think you need to be a really good storyteller as a product director to get everybody on board. So you need to lead certain things. And I kind of think of it as this, right? Like when everybody doesn't have all the information, you should try to give 'em as much as you can, but if they're not gonna get on board, you still have to follow your lead, right. They still have to go in your direction, but it's always better if you get buy-in. So what do you do? You start to give them more information. You start to draw the parallels between, you know, this is why we're doing X, Y, and Z this quarter, and here's how it's gonna help us achieve our goals.
And here's the information that we're going off of, of, and if you have those conversations earlier, rather than later, that's usually how you generate buy-in. So a lot of times you don't get buy-in from your team, from your superiors because you leave it till the last minute and you don't take that time to actually educate them along the way. So I'd say, you know, yeah, it's a, it's a blurry line. And I think if everybody is, you know, going against you and you get to make the decision, you still make that decision. But of course everything's gonna be better when you get consensus and buy-in so I wouldn't, you know, I'd look at how you're trying to get that buy-in first. That would be my first place to look at, like, what do I do to actually educate people, to, um, bring them along on this journey?
How do I get them to see my side of it and why? I think it's exciting also like, think about how to really bring people along on this journey. Uh, we just did a podcast with Maura Kelly from MailChimp. Who's a VP of engineering. And we talked a lot in there about how you bring your developers along with you. And it's about, you know, explaining to them what the impact is on the company for the things that they're building. Right. They wanna know that. So do your VP. So does your product managers, so does everybody else, so like, think about how you're telling your story and who your audience is. Um, that's something I've talked about a lot on the podcast and make sure you're doing that earlier, rather than later. Like, you don't wanna leave this till the last minute and then be like, go, go build it.
It's not enough time to sink in to digest it, to really like manage buy-in. So getting buy-in really takes a while. Now it says that it seems that any activity could be viewed as requiring team consensus. No. So there's a difference between buy-in and there's a difference between consensus and I think a lot of really great CEOs talk about this, where they say, you know, I'm not looking for consensus here. I'm telling you what we're doing. And I'm just asking you to trust me and give me your buy-in. Uh, and that's true when you are the leader, you're going in your direction at the end of the day. I hope you made a great decision because like, everybody's gonna go that way. You should not be looking for a consensus. If it's people that you lead, you should be, um, looking for buy-in and you should be looking for people to say, you know, go ahead, disagree with me, but then commit.
I'm not asking you to agree with every decision I make, but commit to actually following it through. And that's what you do by forming relationships with people, making sure you get the time to actually like know them as humans, building a bond with them, all those things go into being an effective leader. So you need to do that, but don't look for team consensus. Like if you are the leader, a lot of people don't have all the same information as you, like I said, try to give them the information, but your job is not to drive consensus, its to drive buy in and to have direction for the company. That's what your role is. So then the second part of your question really is about drawing lines of ownership here between your VP oversees more than product management, you as a product director and then product managers.
Now, to me, this sounds like you are compressing your strategy. If there is a lot of overlap between what your VP does and what you do, your VP is too into the weeds. Um, they should be leveling up to think about more than just product management, especially if that's what they oversee. So, um, typically this is what I talk about in escaping the build trap in our strategy section, you wanna make sure that the highest levels of the organization are focused on the business drivers, right? Like which new markets are we going into? How do we prioritize our customers? Um, do we wanna expand geographically? Do we wanna start solving different problems for people in our, in our current demographic, right? Those are the questions that they're asking. They're prioritizing on a daily basis. Now you are gonna be thinking about what do I do to the products I oversee to actually make that happen?
What are the problems that we wanna solve as it relates to these products to hit those business goals. Now, if you're not getting that from your VP, and instead it feels like no, they're just telling me what to build. And I'm passing along to the product managers, go back and start having a conversation about the business objectives, right? Say to do my job better and to help you be more successful, I need to understand how we're prioritizing these types of things in our business that can help maybe push them up a little bit. Um, a good exercise that I like to do in companies where I'm worried if strategy is compressed, or if, um, everybody's aligned is start bubbling up everything that you're doing. So take all of the things the product managers are doing and roll them up into initiatives, look at those initiatives and say, are they aligned?
And then see if you can actually match them out to business goals. And if you can't align them to what I call strategic intents, and then you to have a conversation with leadership, that's like, Hey, we've got all of this stuff going on, but how does it roll up into our company's strategy? How do we surface those gaps starting from, um, you know, what we're doing on a tactical level? And then rolling it up into a strategic level, visually is really, really powerful, is a great exercise to do. And maybe that's what you need to do. So you need to make sure that the conversations you are having with the VP are brought up. They're not tactical. This is also like, uh, something that I find happens really really often. Like we'll go and talk to the VP about all the things that we're doing and producing, but not actually asking them questions about, you know, where's the business going?
Where's it heading, what's happening here. So have those conversations, um, get ahead as well of like the roadmaps and the strategy and what you're doing once you learn that information and then go back to the VP with it. I see a couple behaviors kind of drive VPs, digging too down into the tactical product management. Um, one it's because they're not getting the right level of information from you. So maybe adjust the way that you talk about these things. Um, this is all stuff from art of action, which is a fantastic book. I always recommend it. If you're having trouble with this, I'd recommend reading it. A lot of the way that I think about strategy is based off that. Um, and man, have I seen these things that they talk about in this book, these common, uh, strategy gaps happen all over the place.
So like what you're talking about, seen this before happens all the time. Um, so it could be a couple different reasons and this book might help you really see that one. You're not giving them the right information. Like I talked about the right level of information, maybe they don't wanna know about the tactical. They wanna know about like how it's reaching the business goals, but since they don't get that, they dig down deeper, they give more commands, they get very specific. I've seen that play out like 25 times in real life, in different companies. And when we change the way that we communicate, it actually gets a lot better. So I suggest checking that out first and seeing if that is it, but Hey, that might not be your problem. Um, you might have a VP and I actually don't know which company you are from.
Um, I haven't been able to look for it, but you might have a VP that is, doesn't know what they should be doing. So if you've gone through a transformation and all of a sudden this VP is like, Hey, I oversee product. Um, a lot of times there's not a lot of information out there on what you should be doing as like a VP of a business line, oversee all of these different things. And they won't know what their role should be as a, you know, as a leader now. Um, because a lot of the information on product management out there is about the tactical work we do on a day to day basis. So they may be pushing down cause they don't actually know how to push up. Um, so how do you fix that one? That's hard. Like you've just got somebody who's probably not aware of what their role should be, but two, you can say, this is what I need from you to be successful, right?
And this is where you have those conversations about the business, um, strategy, uh, you know, what, what are we trying to do? Hey, it'd be really helpful if you can come talk to our product managers about the company strategy and what's going on there and then get ahead too, of what your job is and what you're going to give them, Hey, here's when we're gonna have roadmap meetings. And then this is when you can give us feedback on it. I'm gonna have a one-on-one with you where we go over, what we're prioritizing, what we're thinking about from this perspective. And you tell me if it's gonna hit our business goals. So sometimes you kind of have to manage the VP and show them like you've got this and this is where they're gonna be able to give their input and check in, um, that usually can help with a lot of lines here. Um, but if this is the case too, maybe we need to help the, a VP understand how to rise up to more of the business strategy level. And what's it mean to work around that product team or be a part, you know, own a product team when it's not just the only thing you oversee. So we might need some more training there, um, some more opportunities for them to actually learn what they need to do.
All right. Let last question. “
Dear Melissa, prior to a hypergrowth stage at my company, we had restructured our product delivery organization with an engineering focus around broad value streams. Now that we have hired significantly more engineers designers and product managers, we have outs scaled the previous structure I've been tasked with addressing this and could use some guidance. How do we best evaluate which parts of the product we build our teams around? What are some common pitfalls when restructuring a product delivery organization to operate at scale?”
Well, first off, congratulations. This is where the fun begins. At least for me, I like I like scale problems. Um, and I think it sounds like you were organized around value streams to begin with that's. So now we just need to think about ownership, boundaries, and how does that scale for more people? And there's a couple different things that I like to talk about in that case.
So let's, let's dive in there. Here's what I would think about. You wanna keep the value streams you wanna think about, um, how your product delivers value to the customer and make sure that, are aligned correctly, that way things to start thinking about as you draw those lines, how do you minimize dependencies? Uh, you don't want it to be where every team has to go get buy-in or align with a roadmap or, um, ask for permission from every other team. So think about which of my product pieces or features are dependent on the other pieces, right? And you wanna try to keep those together under, um, one leader, like anything that has dependencies. If it's aligned under one leader, it's gonna be a lot more easy to manage two. You wanna think about your priorities for growth. So when you start scaling and your product gets bigger, you can't work on everything.
And that's not the point when you are trying to build ownership around product lines and develop a product organization this way. Some stuff is just not gonna get worked on all the time, but it should align under a leader and some different product teams so that if something fails or you need to go back and fix it, or your strategy shifts, we actually know where it falls. So a lot of times we're, we're drawing boundaries around these things and we're prioritizing the strategy and what we're actively working on for growth. But we're also looking at where do we wanna go in the future? Do we have anything else coming up? And we start to move teams towards what our priorities are. Now, this doesn't mean that we are structuring them around specific goals. Like I would not structure teams around, you know, acquisition retention because a lot of those things will overlap on, uh, feature development and again, dependencies right there.
So those types of, uh, priorities, I don't think are the best way to actually structure teams. I would probably structure them in a couple different ways. Now this depends on your product completely. Uh, one easy one to talk about. Here's an example, two sided marketplace. Um, I use something called, uh, teachable. If we're thinking about actually cut that, we'll start from two sided marketplace. So think about two sided market where you have two distinct customers, like take an Etsy or something. You got your shoppers and you've got your sellers who set up their stores. Now I don't know how Etsy is structured, but like, this is how I could kind of think of this part from the basics. Um, you probably have a VP of product over the shopper experience and you have a VP of, to over the seller experience. And then underneath that, you start to think about what are the value streams that, um, that line up to each one of those personas.
And then you think about where do I draw the boundaries around the major features and jobs to be done so that I can put teams around those. And then it kind of filters out from there. Like you don't wanna put teams on super specific functionality at the, um, tactical level of product management, which means like the scrum teams, uh, you want to align them usually under product directors that oversee an area or a large feature set or an entire product, if you're in a smaller company, um, that ensures that the teams underneath can get up to speed on what that product did is they should all understand the features, but then you can, um, map them out and have them assigned to specific parts of the strategy. Once you figure that out and they're working on the priorities for growth. So where companies get stuck is they try to put them around too specific of a component and then they never change it.
So they're like you are the API team. And all they do is build APIs for the rest of their lives. You don't wanna do that, that, that works for like one or two years until you get to a specific point. But if you have that whole team around, um, integrations and you make it a little bit broader towards what kind of strategy you wanna go to with product, and it's not just like this one team does APIs, it can make it easier to adjust and change course and make sure that you're working on the highest priority items. So you want some flexibility when it comes to the team level. Um, you will probably have team working on, you know, specific products quite a while for a couple years, but you also wanna think about in the future, those teams should be able to move around the company so that they get more experience seeing other things.
So what do I mean by that? Think about, um, actually scratch that, sorry. Start from, um, we'll cut it right where I was about the end of the APIs. Uh, and don't talk about the whole switching around companies. So this is a pretty basic two-sided marketplace. What if you're working on a platform for, you know, healthcare or something? I don't know. Um, but like a health, like a platform that doesn't have many different personas and it's hard to cut by persona because there's a lot of overlap in the features that each persona uses. Let's go with that pretty common scenario on a platform or a lot of other different products as well. Um, then you're gonna look at jobs to be done, right? Uh, how does each part of this functionality major product or major feature set, fit into a job to be done? Uh, can I align people that way?
So again, you want some pretty broad script scope at the team level where they can kind of rotate around different parts of the features and work on what's most important with the strategy, but, uh, there should be a leader over each major part, each major job to be done, product lines there, as long as they minimize dependencies and they really align to your priorities for growth. So this is such a hard question to answer, cuz there is no right answer. And I think when we get into talking about, um, team alignment and uh, team design, when we're scaling our products, it completely depends on your company like a cryptocurrency company. You probably is gonna have a completely different type of structure than like a B2B SaaS company. I don't know. Um, I haven't worked in like a cryptocurrency company, but I guarantee you it's gonna look very, very different.
It's gonna look different than a bank structure. Um, there are some guidelines and that's where you get back to minimizing dependencies aligning for priorities, for growth, making sure that you have cross-functional teams. That's another one you don't want to go be like, Hey, I have to prioritize getting a designer and they're booked up with all these other teams, uh, which means we can't start this for six months. Like that's the type of rules that we need to follow. But again, look at your product, look at your company. Think about your value streams. Think about your jobs to be done and think about your personas and start to think about where is their overlap. Here we go back to dependencies, where are their overlap with the features, where is or not, um, are these strategic to our growth goals and then start to kind of put teams out there and I'd say, just get it down on paper, look at it and say, you know, show it to people be like, does this sound right to you?
Does it not get feedback on it before you actually make a decision? That's how we all design orgs. Um, there is no super right way to do it as long as it works for you and you can ship products fast and you can deliver value to your customer. That's the goal. That's a good org design to me. So that's it for Dear Melissa this week. Thank you so much for listening. And again, if you have a question for me, please go to dearmelissa.com and drop that question in. Um, in addition to that, you can follow me on Twitter at @lissijean or connect with me on LinkedIn. Uh, we are always posting, uh, new updates there and new things we thinking about. We will also have a product operations book coming out, uh, myself and Denise Tilles is writing a book on product operations. So if you go to product operations.com and sign up for our mailing list, we will let you know when that is out this year, we are making it a goal. I'm gonna go write more of the book right now. So I look forward to talking to you next week.