Kickoff Strategic Product Planning

Read the Full Transcript

The following transcript has been altered for readability.

Becky Flint: Welcome to the strategic product planning webinar!

We’ll talk about why you need strategic product planning and how to conduct it in an agile and responsive way. We don’t want a traditional method, we want it adjusted to work for today. Then we will also touch upon the tooling you could use to make it easier, such as Dragonboat.

I get a lot of people who ask “how do I do annual planning with agile? Annual planning is taking too long and I think it’s going to change anyway. Why should we go about doing that?” And the same thing can be said for quarterly planning or sprint planning. For many people to go from point A to B there are many routes the company is onboarded with collectively. Who should they be bringing along and how do they get there? That is something every company struggles with and something I also went through.

In one company I worked at, I built their first strategic product planning process for them. It was growing well and their goal was to raise the round of funding and to grow 80 revenue next year. From afar, it looked all good but when you looked at the product backlogs, there was tons of stuff.

There was no clear theme so we went to the leadership to talk about how to get there. The sales team said we have the technology and the platform, we can build this new product in this adjacent area from what we have today. But from the product team’s perspective, the product takes a lot of time to implement, so we cannot realize the revenue until we’ve done that. What we should do is build solutions and take what we already implemented, then customize for different product markets.

We can use that opportunity to educate the teams on why and how we do strategic product planning. It is not that things won’t change along the way but we have to start somewhere collectively. 

Basically what we start to work on first is to pull back a little when we talk about strategic product planning. Back in the days, when it came to product planning, we would use a three-year strategy, one year plan. That’s how we implemented it back in PayPal about 20 years ago. Then, during the agile transformation about 15 years ago, we changed it to a one-year strategy with a quarterly execution because that pace just works much better than a three-year, one-year.

However, If you cannot do a quarterly strategy because that’s just a little too small of a focus, you can do a one-year strategy and a quarterly turnout. That would be a really good cadence now for your company. Depending on the size, it could be six months and then two months, it could be one year and quarterly, or you could even do two years and a half-year depending on the size and the speed. I would just keep in mind that that kind of cadence typically would have a longer horizon and so it would be best if you broke it down throughout the period.  So making sure you truly understand the market segments that you’ll go after is very important. I know that you might think you’re just a pm or a director and you don’t get to decide on that but the interesting thing is that if you don’t drive a decision for that it is very difficult to go down the path for other activities.

Around this time last year, I was helping a fintech company, one of the fastest-growing, biggest fintech unicorns in this world. They were trying to work on strategic planning for a technology roadmap. Think about it, strategic planning doesn’t have to be for the whole company. It could be just for a big enough product area, and that product area was just tech. Tech wants to do strategic planning, but they don’t typically have product management so they’re like “hey, how should we go about this because our CTOs, our head of sales, VP of product, all of them come out with a list of 25 initiatives. And all of them have very strong opinions on that”.  So, the way they might go about this is by looking at all of them. Everyone’s passionate about that and they will spend the first half a day going through four of them and let it run for a while. I say why don’t we flip this around and let’s talk about what our goal is and how we get there. What is blocking that? What are the key things that will help us to achieve our goals? Because if we agree on that, we can use that framework to put these 25 things or even more things into it. By doing this, we flip things upside down and it becomes a much easier conversation. Once everyone knows the goal, all we need to do is be able to support x amount of volume of transactions and integrate things. Things will then begin to run so much faster.

It’s funny because every company has the same thing happen where nobody can agree on what they are having trouble with. “It’s the transaction platform, it’s our partner, it’s our pipeline, it’s our API”. That’s why it is the most valuable thing to discuss- where is the problem?

That’s a good conversation, once everyone figures out the problem and the six key areas of improvement, because it lets everything just flow right in. Then you know exactly what things to be doing, and then you can prioritize things into each of the buckets. Then the rest of the conversation of deciding initiatives, estimations, and goals across teams become very straightforward and fairly quick.

The reason we have strategic product planning is to have a clean slate not look at a backlog of x number of things that could be done. We will always start with where we are, where we want to be, and how we go from here to there because aligning how we go from here to there is a big part of the goal. Once we decide on that, everyone can say “this is where we want to go, here is the key focus”. Then we can put initiatives, projects, features, and all that good stuff inside of that. We can also estimate the effort, understanding the budgeted head allocation, and then take it into the execution to the next level of discussion.

Now let’s move to questions from the audience: 

Attendee: I have one question Becky, earlier you were talking about the long-range planning horizon relative to your short-term planning, like the 1 to 4 ratio. Can you still use a ratio like 1 to 4 if two companies merge?

Becky Flint: 1 to 4 is very commonly used. Just in general, whatever we do, in the end, we’re part of the business. Businesses typically, in a financial cycle, operate in this model. You have an annual quarter, and then a quarter month.

Attendee: That’s interesting, and I would add that not only is the 1 to 4 ratio helpful for me when I’m blending two separate companies with different time horizons on strategy and execution, but you also brought up another dimension like aligning this to the rhythm of the business. If you’re already having quarterly planning with your board, you’re already having an annual trade show or you’re already in a two-week sprint with Scrum teams, then you would align this to those rhythms.

Becky Flint: I have a blog on cadences that I’m happy to share after as well. There are four elements of a successful organization – people, process, organization, cadence. The first successful organization is people. You have to have the people so the people can have a skill so you have to train. Then you will have the organization, right. That is the process of how the people work together And finally, the cadence. Any one of those missing is not going to be a high-performing organization.

Attendee: Yeah, I think I have a question around the cross-functional alignment, which you alluded to earlier. How do you influence that conversation? I’d love to hear your thoughts. Especially when there are multiple layers at play like directors, VPs, oftentimes it’s a bit of a political minefield. So I’d love to hear your thoughts on how if someone is in my case an individual contributor with VPs to report to and such, there’s only so much I can say. How do I find a tactful way to influence that conversation?

Becky Flint: Right. Excellent question. That’s why we have a framework here, to tie things together, make the conversation a lot easier. I think a lot of you probably face that. There are sometimes politics involved in companies. Sometimes people want to work on this feature, this initiative versus the others. Now, when we take a step back and ask, “What is our objective? What is our initiative?” That’s how strategic product planning happens. Take a step back and say, “if we agree on the future state, current state, and a key opportunity, then we can talk about allocation”. And this is something that comes before prioritization. Because today, when we prioritize things, it only gives us a linear view like A is more important than B. So, this strategic planning process not only will say “we have these goals”, but they also show how we achieve them.

Basically, you should organize your initiatives or your products around the goals. If you don’t have enough resources you would know by looking at your estimate, your effort, and also, your allocation.

There are multiple ways to look at allocation. You can look at allocation by objectives, to see where you allocate your resources. So that when you have over-allocation in certain areas, you can correct it. You can free up resources for the other teams that typically compete for them. This is a business strategy, and it’s so important for everyone to not push each other, but encourage the company to do strategic planning. That way, we can align our strategy along with where we’re going to focus our resources. Then it’s a lot easier for the downstream teams to work on stuff. It puts everyone in the best spot to have a complete picture of what is important to the company.

Attendee: What are some of the most effective prioritization frameworks you have seen? There’s a lot of frameworks floating out there but from your experience what’s one that you find is your go-to?

Becky Flint: In the past, there was not a good way to prioritize things. You talked to finance and they would say to use ROI, NPV, or IRR. Those were the financial ways of prioritizing you have this initiative, now what is the one-year or three-year revenue expectations, how many resources do you need? We’re very familiar with the traditional strategic planning based on the era of industrial production. So you invest this much money, you get this much machine and you can create this many mugs.

There are two elements of prioritization: one is done with a prioritization model, the other is to compare each thing in a similar category. There are ones that easily compare within the same category but it’s very hard to cross multiple categories so the recommendation is to have a category defined first and then compare things within the category themselves. From there, make sure you not only compare a ratio but also compare the absolute value. This allows you to achieve your objective.

Attendee: I guess the hardest part here is getting a product to create ROI. Estimates are easy, ideas are easy, but making sure that people actually get behind where I invest this time in this future, that’s where the hard part starts right.

Becky Flint: Yeah, exactly. I think that would be the hardest thing for product management and you know I’m not saying working with engineers is not hard, and I’m not saying designing user experience is not hard. I am just highlighting that the really hard part is having a good idea of what the result could be if we do this. It becomes more and more challenging if you have limited resources, and everyone is competing with each other pretty fiercely. Even today every agile team struggles with appointing our estimate correctly. But that doesn’t mean you shouldn’t estimate, it’s just something you can refer back to. If you think about it, in some ways, we as leaders are actually behind our team in some aspects. For example, think about the Agile starting bottoms up. Your engineer teams and the scrum team started agile, and you start to point out things to prioritize. For us, as an organization, regardless of your product manager, product director, etc, that muscle is not quite there to say what is the benefit we’re going to be getting and what strategy will get us there. Can we put a number around it so we structurally see it? Is it okay not to have it on day one? You can be wrong, but you cannot say I won’t start until I’m perfect. Otherwise, you’ll never get there.

Attendee: The key line here most of the time is getting the C-level buy-in. It’s one of the things where if you ask for the C-levels now, and try to define the strategic pillars for next year or their objectives, no one will have that because they don’t think in that way. So then you almost have to wait for another month to get the financials right so they can get some sort of idea of what is going to happen. Then they will start to think about the strategy for the year. One of the other things is that if we think about it in the way that since we started adopting agile and scrum, for instance, the teams are very scrutinized to the estimation and the point level. It can also be hard on the product side to get the buy-in. These are the two points of the C-level buy-in and the key to success. If you have that the company will change a lot.

Becky Flint: I want to also pause here for a second because what we talk about is the ideal state. However, we cannot go from zero to an ideal state in a day, so how do we get there? I think almost everyone, myself included, would say we don’t have all the elements, but that doesn’t mean we’re not going to start. The first thing we can do regardless of your sphere of influence is say what financial goals you might have. If you have your financial goals you can then figure out where you should go. Should we try to get new customers onboard? Should we try to get more revenue from existing customers? That becomes a good conversation to have because you can almost categorize things into buckets of OKRs. You don’t have to decide exactly what each means, because it’s a lot harder to do that. You can just decide on four pillars or four goals so you can use a strategy. Otherwise, if you look at all the things that we need to do, you’re just so overwhelmed. Where do you even start? So for us to avoid that, we need to get more abstract with a relatively clean slate. Then you try to tie them to goals so that once you start to decide out of these three or four categories of goals or themes, you can choose the kind of initiative to use.

Think of it as picking which route you’re going to go, but you might not know how you are going to go there. However, along the way, you can decide on your bucket and then you get started from there. Then you can go from there and further break down your initiatives to epics and then your team can break up extra tasks. In the end, you will have this nice tied-up thing. The thing that sets current strategic planning apart is the responsive way each step gets broken down so that the next phase can happen. If we don’t decide the general goal at the higher level, your next phase is just shooting randomly because they just don’t have enough context on what tasks and stories make sense.

Attendee: Yeah I agree, putting things into buckets just makes everyone’s life easier because they are not used to thinking buckets.

Becky Flint: Exactly, and speaking of that has anyone heard of the rock, pebble, sand analogy in product management?

It is something we used at PayPal almost 20 years ago. We would use the big rock analogy every year during strategic planning. The goal of the strategic planning was to decide on the big rocks and the jars. So the idea is that for any organization or product manager, you always have a myriad of things that are in front of you. They are sometimes really big, complex, and not nicely defined. Those are the big rocks and then you have those features, the stories, the UX improvement. Those are the pebbles. Lastly, you have all those things that just come along, the tickets from customer success, and so on.

So, when they all lay in front of you, they are each staring at you as if they require the same amount of attention. This is because when we look at all of them at once the strategic task and then a tactical task all take the same amount of information to process. So the most important thing for us to make a strategic impact is not to stare at them in the same way we decide on the bucket first.

Instead, you will say the big size jar is a small size just tied to different objectives or strategies. Then you look at the big rock first because these big rocks need to come in first. You wouldn’t fill up a jar with the sand, because then your rocks cannot come in. That’s why you put most of your brainpower prioritization energy into the ones that matter. The other stuff keeps falling and they fill up because they don’t make that much difference in the grand scheme of things.

Speaker: When you say they’re different sizes would that change quarter by quarter because the investments in strategic themes change quarter by quarter?

Becky Flint: There’s a lot to unpack here. You’re right in that way jars are not flexible. Like you said, from time to time based on your cadence- annually, quarterly, etc,  you revisit the size of the jar. The jar is only at the strategic level so that means that you know your team level doesn’t necessarily decide on the jar. However, at the strategic level, the leaders and executives will say, “okay based on how we are achieving our objectives then we will have a bigger or smaller jar for certain areas”, so that’s exactly like what you said. The jar size itself changes as a part of the allocation, and it’s part of the portfolio adjustment.

So I’m going to take a little bit of a segway here. As soon as you mention strategic planning, a lot of people start to think about this as anti-aging. People will say that planning for a year and quarterly planning doesn’t make sense, because things are always changing.

It is the case in the past that strategic planning was done once a year and the quarterly planning was done once a quarter. However, one of the key reasons I believe is because it’s so hard to do it. Afterall, you need everyone in a room. You’re going to have the papers and boards then you have a lineup of all the teams. It is very expensive, and it’s very hard to plan. As soon as you plan it, things change pretty quickly. That leaves you feeling like a couple of things happen.

Firstly, it takes a lot of effort to plan.

Secondly, the plan never really goes anywhere because nobody has the context other than a group of people in that room. So as soon as they leave the room the context is lost, and the rest of the organization doesn’t really know what’s going on.

A deck sent out to everyone Is very difficult for people to follow. It becomes not very useful so people use that as a way to allocate a budget and you’ll be done with it. That has changed with better tooling. If you have better tooling, what happens is the planning is a lot easier because you can do it almost in real-time. The context is there, you can see the objectives, you have strategies, and you can see the teams.

Therefore, that information is not only available for the small number of people in the strategic offsite, it is available to everyone in the company. When you see it, people can actually tie everything back to what was discussed. You can tie your stories to your epics to the initiative to the goals and the other way around.

Obviously, we don’t want to roll up, we start from the top down. You do top-down, high-level planning. You visualize your roadmaps and see what’s going on. Then you can provide that information to your team and adjust it along the way. Something people always worry about is, what if the estimate is not correct? What if the estimate on the benefit is not correct? But the thing is we have to start somewhere because you already made a decision that’s based on something.

I think there’s a statistic that says that more than 50 percent of tech debt was because of a lack of understanding of the product context. Therefore, when we give people a bit of information rather than where we want to be, they’re filling all the other gaps in terms of building products. Engineering is a craft, it’s not just a mechanical code. People have to think about where it’s going. Therefore, when you tell people what we want to be, not necessarily where we are going to be, they have an idea and they can code better. You can reduce tech debt by up to half by giving your engineers and designers the context of where we want to be. That allows them to have the same vision as the product side.

Your team is built on what they understand and if they don’t understand something, they’re filling the rest of the context themselves.