Episode 70: Answering Questions About Strategy, Discovery and Delivery

In this Dear Melissa segment, Melissa answers subscribers’ questions about separating product strategy from overall company strategy, rules of thumb for discovery and delivery phases, and what a small company starting to scale up really needs in order to carve out a thoughtful product strategy and vision. 


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 advice on how to align between product strategy and business strategy, especially when a product doesn't have a strong executive presence? [1:13]

A: When you have a separate strategy team, it only works in the context where they're going to have to be figuring out a company strategy that is far removed from a product strategy… It sounds like you have a SaaS product because it sounds like the strategy you're driving here with the strategy team is product strategy. But if you are in a non-SaaS company… [your] strategy team should be responsible for the business strategy… If you have strong product leadership that can do both [strategy and execution], you don’t really need a strategy function. [2:04]

Q: How do you manage discovery and delivery simultaneously during a 12-week quarter? Should there be two different roles? [6:59]

A: When we align things by quarters, it's what we want to deliver but it might take another quarter to actually measure that and figure out if we need to iterate, so I’m not sure why you need to get that all in there in one piece. Quarters are good ways to time box things, but what I’ve typically seen is that discovery might happen for a quarter on a bigger project especially and then the next quarter you build it. These are arbitrary dates - you don't necessarily have to hold really strict 12 week quarters for everything… [There] absolutely should not be two different roles [for discovery and delivery]. If you separate discovery and delivery, you lose the transfer of knowledge there. You also get a bunch of delivery people who only know how to execute but they can't think strategically and then there's no career path for you. [7:39]

Q: What should the next step be for a company entering a scale-up model with no long-term strategy? [11:13]

A: You’re going through this phase as a company where you’ve found product market fit on the first thing, [but you don’t know what to] do now. Usually, there's a lack of product leadership here and this is when we would go out and hire a CPO - depending on how big you are, maybe a VP… You have to start thinking [about whether] you should be going into other markets, how you should be satisfying this market, how to maintain retention here, [etc.]. You’re going to have to make these decisions really fast, and that’s why having a great CPO at this phase is worth its weight in gold. [11:47]

Resources

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com

Transcript:

Melissa:
Hello and welcome to another episode of dear Melissa. Today, we have three questions around product strategy and discovery versus delivery. And I wanna remind you as always that you can submit all of your questions to me@dearmelissa.com. And I will pick some to answer on this segment. We do this every other week. We're always out on Wednesdays and I can't wait to hear what you wanna learn about. So without further ado, let's dive in. First question, dear Melissa, our company has struggled with strong product leadership product reports to a CTO. The CEO has strong product views, but lacks product leadership experience in the last year or so. They've also built out a strategy team that reports directly to the CEO. This has created some challenges in who's responsible for driving product strategy and how to work well with the strategy team. Do you have any experience with this type of structure, any advice on how to align between product strategy and business strategy, especially when a product doesn't have a strong executive presence?

Well, I have definitely seen this before and you're probably not gonna like my answer because I don't love this structure so the right answers don't work this way, but , there's also some nuances in here too. So let's dive into them. Well, when we typically have a separate strategy team, it only works in the context where they're gonna have to be figuring out a company strategy that is pretty far removed from a product strategy. And I also still don't like it being a totally separate function that dictates the product strategy. In this case, it sounds like you are not in an organization. That's doing something besides software. It sounds like you have a SaaS product because it sounds like the strategy you are driving here with the strategy team is product strategy. So I don't know, but if you are in a typically non SaaS company, let's talk about that first.

If you do have a strategy team, what they should be responsible for is the business strategy. What markets are we entering? They should be doing Tam and Sam analysis. They should be doing competitive analysis on a market level. They should be looking at where things are trending. This is a lot of stuff that consultants will typically put together when they do a market analysis to acquire a company. That level is good. That's actually pretty good inputs. And I wouldn't mind working with the strategy team, kind of figuring that out. But to me, that team should always be inputs into the rest of the leadership because it's really the CEO's job to define what that strategy is. Now. Maybe the CEO has determined that they're more of a salesperson and they want a chief strategy officer to help figure out what that company level looks like.

That is one thing that I've seen happen when you don't have strong product leadership. So sometimes people will look at the product leadership and say, Hey, well, they're not creating the strategy. They're more execution focused. And then instead of solving that with a leader who can do both things, they put this function in that's common. I've seen it actually in a lot of places, but if you really have strong product leadership that can do both of these things, you don't really need a strategy function unless they're figuring out company strategy. Now it also depends how big you are too. And really, really large companies. You usually will have some kind of strategy function. It's just impossible for one person to keep up with all the different things that you're actually doing. So I've seen it in those places. It works, but there's always tension. Now, in your case though, I'm not sure how big you are, but this isn't feeling right to me.

It says, you know, product is reporting to a CTO. CTOs are usually not super strong at product strategy themselves. So it sounds like there is a gap that people realize in product leadership, nobody's doing the strategy function. So what did they do? They pulled it out and made another team for it. Instead of hiring a product leader in the executive level, who can help them with strategy. This usually happens when the CEO doesn't understand what product leaders do. So they might have very strong product views. They might be afraid of putting a product leader in there, and instead they're creating a strategy team. So they don't lose grip on product. I have seen that as well. You kinda have to dive in there a little bit more and try to figure out why this was happening. But the chief product officer role is relatively new.

A lot of CEOs are not very familiar with it. So they don't know what a chief product officer actually does, but this is what they should be doing. The strategy piece. They should be partnering with the CEO to understand their vision and help manifest that through product strategy. So it sounds like you just created a team to do that part and they see product as the execution, sit on the scrum team, go with them. So in this case, it's really challenging and there's not gonna be a perfect answer on how to align these two things, because it shouldn't be that way to begin with, but there's probably some stuff that you can do as well to really figure out how to bring this all together. One, you should probably be managing up to the strategy team. Two, you should be maybe saying, I need to be included from the beginning so that we can understand what the goals are, what you're trying to achieve here.

If they're trying to give you things that feel more like outputs for you to actually create, I'd go back them and say, okay, what are the objectives here? What are the goals we're trying to hit? How did we get to this answer? What was the inputs in here? And try to poke into some of the reasons of why they're doing things. That's probably the best way to handle a bunch of this stuff, but it really sounds like to me, you need a product leader and not a strategy team. Hey, I don't know if that strategy team only does strategy or if they've ever done product leadership before. But to me it sounds like you're solving a knowledge problem that is already solved through a chief product officer role with like a completely different team. And it's just going to be a problem. So I know I can see that you're the head of design. This is gonna be challenging for you. I will say that to begin with, but I think the best thing that you could do is get in there early and often force the strategy team to like sit down with you and go through what they're doing. Ask them a ton of questions, dig into all of those things. Just keep really poking at how are decisions made and how do we get to those places? And that's gonna be the thing that aligns you the most.

All right, next question, dear Melissa, I recently listened to your episode with Jeff Goel and I'm a huge fan of OKRs. My question is about how to manage discovery and delivery simultaneously during a 12 week quarter, what are strategies to stay far enough ahead to have done the discovery so that you can actually get things built, launched, and measured results by the end of the quarter, ideally should discovery and delivery be two separate roles. For example, separating the discovery from the day to day, writing of user stories, defining detailed requirements, team ceremonies, et cetera. So who says you gotta get the results by the end of the quarter. I'm curious. That's interesting. Hoing there. Hoing right. You don't need to like get all of your answers by the end of a quarter. Typically like when we align things by quarters, it's what we wanna deliver, but it might take another quarter to actually measure that and figure out if we need to iterate.

So I'm not sure why you need to get that all in there in one piece. I also think quarters are good goals or good ways to time box things. But what I've typically seen is like discovery might happen for a quarter on a bigger project, especially, and then the next quarter you build it. So these are arbitrary dates that I feel like you're time boxing into, but you don't necessarily have to hold really strict 12 week quarter for everything. Now, if it's a smaller feature, like yeah, you can usually test something to make changes to a feature or put something small out there in 12 weeks. That seems like a reasonable amount of time for it. But should they be two different roles? Absolutely not. I talk about this a lot. When we talked about product donors, reverse product managers, because if you separate out discovery and delivery, you lose a transfer of knowledge.

There, you also get a bunch of delivery. People who only know how to execute, but they can't think strategically. And then there's no career path for you. So I can see that you're an SVP of product management. I'd really encourage you to not separate your people. So I'm seeing that you're really looking at this holistically from an overarching standpoint of a big team, the way that discovery and delivery should flow is that we wanna look at how big the initiative is and how much impact have on it. Is this something that we feel wildly uncertain about? Discovery's typically gonna be a little bit longer in those things. And especially if there's more at stake, you typically have a larger discovery process, a longer discovery process. If there's more of an outcome associated with whatever solving that problem would be. If you are doing something faster, that's gonna be shorter.

So your portfolio of work that you're gonna see on your roadmap is gonna have some big things and some small things, not everything is gonna neatly fit into a quarter. So I'd encourage you to start with that and try to figure out how do I pull work in that's not necessarily all same size or anything like that, but how do I pull things in based on the priority? How do I understand the capacity of the teams to figure out how much they can actually take on? But when we're really managing a roadmap like this, looking at discovery and delivery, you may have one team like let's stick a scrum team, for example, right? Like a team executing on something that's well defined towards the end of it, a product manager starting and a designer starting like a big discovery spike, but the team might be working on well defined things throughout that quarter.

While the product manager in the UX designer is doing discovery. And you might not start building until towards the end of the quarter, towards the next quarter. Like you don't have to really fit it in to nice time boxes, but I'd really encourage you to go back, read some of the stuff that's been written about POS versus PMs. Jeff Goel writes a lot about discovery and delivery as well. But Jeff Patton writes about how to do this with scrum. How do you have dual track scrum with discovery and delivery? Like go read about those things because it's gonna show you how do you kind of put these together, but I would say do not. do not separate these two roles and understand that you're not gonna get enough information usually by the end of a quarter to do all of this all at once, unless it's a small thing and that's fine.

That's okay. I'm curious like where this quarter thing came from, but when I'm doing roadmaps, like I'm gonna hopefully have an objective where it's like, Hey, in Q2, I think we can release this thing, but then I know that I won't really get enough feedback to say, is it gonna be the right thing to do? Or should we iterate on it or do we need to keep improving it until probably the end of Q3? And that's okay. That's all right. That's how we do roadmaps. So it doesn't always have to be an immediate feedback cycle. Sometimes things take time to get data and that's all right. All right. Last question, dear Melissa, my company is currently entering scale up mode and we don't have a long term product strategy. The company recently acquired a smaller competitor, but other than that, there is no vision of where to go next.

And it feels like everything we're doing is just me toing. What are the steps to discover? What is the best path for us in our vision? So this really has to come from the executive team and I can see that you're product manager, but here's how we can help. This is what we can do to start to figure this out. Now, this moment that you're going through scale up mode entering it. You don't have a long term product strategy. This happens really, really often. And what happens is you're going through this new phase as a company where it's like, Hey, we found product market fit on the first thing. What do we do now? Usually there's a lack of product leadership in here. And this is when we would go out and hire a chief product officer, depending on how big you are, maybe a VP, but somebody can actually help with this.

And you wanna start thinking about different strategies for growth and you wanna start evaluating them. So you have to start looking at like, should we be going into other markets? How should we be satisfying this market? How do we maintain retention here? How do we do that? And you're gonna have to make these decisions incredibly fast. And that's why having a great chief product officer at this phase is worth its weight and gold. So that's why I keep pushing this and why I keep telling everybody higher chief product officers in the absence of one. The best thing that you could do is start to ask questions. Now you're gonna have to gather data which goes into setting the vision and your vision should answer questions like this. Where do we believe the market is heading or other markets that we could be solving or heading?

And what's our hypothesis. There put a stake in the ground as a company and say, we believe that this is happening. Two, what are you gonna do to meet those needs? Right? That shift show up for that shift. Where are you right now in meeting those needs for the future? Is your product like ready for that? Or are you gonna have to expand it? So talk about where you are now. What's the current state, what does it look like and how it's gonna change? Then you wanna go out and get a bunch of data on your current customers, your potential customers. You wanna deeply understand them. You wanna get data on your current products and figure out what's strong. What's weak, do a whole nice little SWOT analysis on that. And then you're gonna wanna start to put that together and figure out what could we be doing to solve these new problems or solve existing problems in different ways.

Instead of just me toing, the biggest thing about a vision that I see people get wrong is they don't talk about how they're different than competitors. And if you are just me toing, everything, that's not good, right? Like why would I go with you instead of somebody else? Especially like when it comes to switching, why would I ever switch to another company that just copied somebody else, but didn't do it better. So that's something that you have to think about, how are we gonna be better? What's the current state of our competitors? What are we gonna do differently? And sometimes people choose like going after a different market, that's not solved already. Or some people choose to do it better than the competitors, whatever it is, like, do something different. And that's your vision. That's really what you wanna get to for the vision. Now you can surface up a bunch of this data.

If you're a product manager and help the executives kind of rally around it. But then your job is to ask them questions. The questions that I just was going through, what markets do we wanna play in next? Who do we think our potential customers would be in the future? What problems do we wanna solve? What problems do we not wanna solve? What do we not wanna do? Sometimes writing down things that you don't wanna be or do is even more powerful than writing down what you do wanna do. So I would not discount that at all. So you're gonna wanna pull all of this together, but I would really just ask your leadership, just say, like talk me through all of these things and then maybe just write it down for them and say like, Hey, I'm trying to understand our vision so that I can build our products better based on like what you guys told me.

Here's how I interpreted that. Is that right? Sometimes just putting something on paper and putting it in front of people and asking them like, am I off? Is this good? Gives them moment to iterate. Right? It gives them the moment to look at it, think about it and figure it out. I use this tactic all the time when I gotta get people to make a decision. And if you take their words and put it on a piece of paper, formulate it into like some kind of nice little tube, three paragraph, one pager type thing, give it back to them. They'll probably be like, oh, I don't know, is it right? Should it be right? You know, should we be going after that? That's gonna start the conversation. And that's what it sounds like you need. So I would really go pull this whole analysis of what you're doing and what you think you wanna be doing and all that stuff together.

Ask a bunch of questions of your leadership. Write down the answers on a paper and then just go back and forth. Just keep looking at it. Just keep refining it until you get to the vision. That's gonna be the best way for you to actually set that. All right. That's it for dear Melissa today, but we'll have another one in two weeks. So please go to dear melissa.com. Let me know what you're thinking about. Let me know what your challenges are. And just to remind you, we have a huge backlog of all of these questions that I've been answering for over a year and a half now. So if I, I may have answered some of your questions in there, definitely take a check through the product thinking podcast. We put up all of these synopsis of these podcast at products, labs.com. So go check 'em out there, read through them. I hope you find some good answers to a lot of your questions. And if I haven't answered it yet, submit away to your melissa.com. We'll see you next time.

Guest User