How To Do Quarterly Planning for Product Managers

Read the Full Transcript

The following transcription has been paraphrased for readability. 

Bhaji Illuminati: We’re going to spend the next 45 minutes deep-diving into quarterly product planning. We’ll give you practical and tangible advice that you can apply to your business.

Let me introduce our speakers today. Two phenomenal women with deep expertise in product management. Becky is the founder and CEO of Dragonboat, the ppm platform for outcome driven product organizations. She built product portfolio management and led quarterly planning at PayPal, Shutterfly, Bigcommerce, and Feedzai, partnering closely with both product and technology leaders. Becky started Dragonboat from her firsthand experience learning to streamline and automate product portfolio planning, tracking, and reporting.

Connie Kwan is a storyteller and product executive from Silicon Valley with 16 years of product leadership experience. She led teams at Atlassian, the company that created JIRA and set the standard for product led development. She has shipped products at Microsoft, was the VP of product at the OMG network, and CPO at a Khosla funded startup. Connie brings a breadth of domain experience to product challenges. Currently, she’s a fractional CPO and advisor on product strategy. She teaches storytelling to empower leaders to build their influence, her next class starts in May.

Becky Flint: Connie, why don’t you tell us a little bit about your journey from individual PM to becoming a CPO, and how you help companies and other CPOs succeed today.

Connie Kwan: I worked in product for many years, I actually came from an engineering background. So what I learned during college is that I enjoyed putting the team together, and then writing all the specs. So I teamed up with other computer engineers, and they ended up writing all the code and I wrote all the specs. Nobody wanted to work in my field at Microsoft, writing pseudocode, but I really enjoyed it. I thought it was interesting to think through the greater logic and the purpose of the product. And that’s a lot of what product management is. And of course, you know, this was maybe 16, 17 years ago. It wasn’t really a role I was familiar with yet. There were some product managers but as a discipline it was fairly new.

I kind of fell into product management, I’ve worked at large companies and small companies. Being at Atlassian got me exposed to agile, agile-based development, product lead, and go to market.

Being at Microsoft allowed me to see how to work with partners and customize the products and also ship. We shipped the product from Windows 8, in 200 countries and 40 languages all at once in a global launch. We had to test in so many different ways and prioritize for the deadline.

Becky Flint: Interestingly, you kind of touch upon a couple of challenges I’ll dive into when talking about quarterly planning. I know from conversations with a lot of PMs and program managers that there’s a love-hate relationship with quarterly planning. Quarterly planning is chaos and conflict all at once, but you also get to focus on building the product.

Connie Kwan: Larger sized companies are more suitable for quarterly planning. When I worked in a startup with only 30 people, we weren’t in the quarterly cycle, we were continuously planning. But at some point, there’s enough people and enough moving pieces that you want to put some deadlines against the planning effort. Otherwise, it is too much noise all the time.

It’s helpful to have a moment to come together and think so that you can disperse and go back. The challenge, of course, is as soon as you get out of the room, things are out of alignment. And so as a product person and the communicator in the team, you’re usually tasked with holding all the pieces together. As the quarter progresses, you make sure everybody is still up-to-date on what’s going on. That’s a big challenge. What I’ve seen work well for teams is to have a shared source of truth- teams with good communication across all departments where everybody is owning part of that planning.

Becky Flint: Yeah and I want to emphasize planning is successful with a source of truth. This will keep things moving and allow changes to happen, it is really important to keep that in place. The other interesting part you mentioned is alerting others. I definitely notice a decentralization when everyone is taking care of their piece of information. When you have lots of stakeholders coming in, teams tend to have different needs. Sales teams probably want something different from customer-success teams and other product managers probably have their own areas of focus. How do you manage? How do you even capture these kinds of diverse competing needs and prioritize across them?

Well, it depends on what the product is and what the competing needs are, right?

Step one is to capture the different needs, and that’s a continuous effort. You’re continuously trying to juggle new versus existing problems. And of course, everybody’s familiar with tech debt. Where you are also juggling with the new set of different competing priorities. So how do you juggle all those? There’s lots of frameworks that try to put it on a spreadsheet, you can put some numbers against it and use it as a way to discuss the different ways to prioritize.

That loss of demands from different areas is very difficult to prioritize. In the financial world, people call it ROI. They try to normalize something, but in the product, you don’t really have an immediate gauge on that. So over the years, we created something called MoaR to really tie products with outcome.

In order for us to normalize everything, one of the dimensions we think about is if the product outcome could be driving revenue, growth, retention, and so forth. You want to define these outcomes, then have a metric over them. You can score how much different product-features or initiatives contribute to the goals you set out to achieve.

Connie Kwan: So a fundamental problem is the incoming features are not apples to apples, right? The incoming priorities can be revenue driven, personality driven, etc. So you got those coming in. And then on the output side, the results are also not apples to apples, because you have growth-based goals (more users, more eyeballs, more trials), but then you also have some revenue driven. So how do you turn it into apples and apples with the MoAR framework? Or is it never going to be apples to apples? You realize you have three channels, and each one will compare the apples within them.

Becky Flint: First of all, when a company sets up goals. It’s always a set of goals. It’s never one, you will always have a few goals. As you set goals, one things that connects the product management function with the company and strategy is to have a goal and an allocation to how much we’re willing to invest in that.

These goals come before a product manager’s quarter planning, or any other form of planning. You need to decide how much we as a company want to invest in these goals, for whatever our timeframe. Once you decide on the allocation, you will have the apple to apple comparison within those buckets. When you have a healthy portfolio with even just one product, you have balance and you can think about the allocation.

What makes a product manager’s job so hard is that not just one thing, it’s not linear. A product portfolio works in a way so even with different dimensions, you allocate and look at one dimension at a time. However, you do need to think about the others so you don’t miss out on things.

Connie Kwan: Yeah exactly, keep track of your growth metrics, which are your leading indicators, and your actual conversion metrics. I’m curious, in a large company, you’ll have multiple products and each product will have their own tracks. So as a company, how many tracks do you typically see?

Becky Flint: Right, when you have 15, it’s almost impossible to do, right? So I think it’s almost a rule of thumb to keep it between three and five. When you go beyond that it becomes too much. What you may want to do is have three to five tracks, and then have three to five within that. That is probably the most you can handle, because ultimately, these goals help us to prioritize the activities we need to work on without spending too much time to decide what fits into a bucket.

Connie Kwan: You’re asking the organization to internalize these goals that quarter so you want people to remember them. I have seen shifting. Every quarter the organization chooses new themes to go after. It could be which initiative will help us get that growth, so that shifts, but the underlying purpose, more or less stays the same.

Becky Flint: I think the shift is healthy because the company operates differently. Until we put it in the market to get it customer adopted, we don’t know if it helped us to grow or retain . So from that perspective, shifting is a great thing to understand. We can ask if we achieved our initial goals. If we did, then we don’t have to over-invest in this area, and we can invest in other areas. Then when we plan our next batches of product features, and alignment, so forth, this shift is faster. You see this especially at software companies, because the feedback loop is so much faster.

In the last 15 years, we went from three year to one year to quarterly plans, because things are now faster, and we can put the product to the market quicker. From there, we can see how people react and what drives our metrics and goals. So then we change the way we rebalance our portfolio. Are we going to spend more time on growth or spend more time on retention. We need to have more innovation, more things to help us to adapt to the future.

Connie Kwan: These changes make the ship go faster with more and more outcomes sooner. Once you have the plan set and come together, how do you keep that message alive and work with everybody else to stay on pace with the changes? I’ve definitely seen my students see a lot of stress in this area because times are changing constantly. It’s a challenge. And we definitely need product portfolio management tools over roadmapping tools to help us do that work.

Becky Flint: I’ve had people reach out to me about how product management is a very stressful job. They want to change careers because they can’t handle the constant barrage of feeling like they’re never going to satisfy their internal and external customers.

Individual product managers have to collaborate with sales, marketing and customer success teams as well as customers. And then we also have to work with our engineering team, because engineering teams deliver the work that we communicate to stakeholders.

So how do you plan it? Product defines our strategy and our priority. After that, you can send it to engineering teams where it’s created. However, in my experience, it’s never that easy. You have to partner with engineering, your tech lead is figuring out how much this effort is going to cost. You do a lot of back and forth.

Instead of all that, you can create an execution roadmap that you have confidence that your team can deliver.

Connie Kwan: You put a good point. A lot of people say I want to quit product because it’s too stressful. And I think those of us who survive and stay in the product, find a way to have joint ownership on the dates and on the outcome, right. Because if you’re not able to do that, then you are taking the whole burden of owning everything. The reality is you can’t own everything, no one person in the organization can or should own everything. It’s really a collaborative effort.

The only way to accomplish this is to all come to the table and say okay, let’s plan together.

By creating a system and a process for that communication between different parties, I’m no longer the bottleneck. And suddenly it’s a lot smoother for everyone. But there’s a training phase.

Becky Flint: I have also seen that as the individual product manager, you coach your team on how to best think about the product, how you communicate, and so forth. You write requirements, but then you also help your team to understand the context and so forth. That is why as a product manager there’s another level of collaboration.

Now, once you become a product leader, you have a product manager work for you. How do you handle that? How do you make sure every product manager is thinking about their own areas, but that they’re also thinking collectively at a higher level?

Connie Kwan: I don’t want each of my team members to own so much that they can’t sleep at night, that’s not healthy. In that same way, I don’t want to be blocking anyone, I don’t want to be at the helm. Of course, there will be issues where I absolutely need to get called and figure things out. But for 99% of the items, there should be a process by which, if it’s a decision to be made, then there’s a clear understanding between me and my reports on what type of decisions need to bubble up to me. That’s my quarterly planning.

Becky Flint: I definitely hear you on having a repeatable process, but still being tuned in. It allows you to improve over time and really streamline a lot of complexity.

This will happen quite a bit, at least in my experience when product teams will have dependencies. When you have dependencies, let’s say there’s a, there’s a web version of a product, there’s a mobile version of the product, and they all need each other. The PM will say, “hey, my team only has this many resources, I have three people coming to me, and I have my roadmap, how do I deal with this? How do you help them to manage that kind of dependency to decide who gets to do what they want to do.”

Connie Kwan: Yeah, so if PMs are asking for the same resources, but for different purposes, take one step back and look at the greater purpose of what we’re trying to do as a company.

The prioritization actually has to come from the company’s Northstar first. These competing priorities come up all the time. The way you neutralize a competing priority and make a decision about it, is to go back to your principles and say, “what are we trying to accomplish overall?” Ask yourself if it’s worth doing as a company.

Becky Flint: I want to add one more element to that. When you have an apples to oranges comparison, how do you go about doing that? That’s when portfolio allocation comes into play.

Connie Kwan: That’s usually a conversation at the executive level, where you say, “look, we have a real growth problem right now. We’re not going to make our numbers for the growth that we’re expecting. So either, we’re going to reduce headcount or we’re going to put some resources against it and see if we can push the numbers up. That way, we can continue our hiring plan”. I think those are the trade offs being taken. Think “what is the effect of something not hitting”. Then we can make those decisions because maybe that decision isn’t to push growth.

Sometimes we put more oranges in because we’re just betting more in this area. If it doesn’t work, maybe we slow our growth because it is not the time to put more oranges and we can think more about the apples. But that has to be looked at holistically. And then you are ready to keep the ship going, even as you’re not investing in certain areas.

Becky Flint: Yeah, that totally makes sense. Now, I want to shift gears a little bit, we got an audience question around tracking. How do you keep track of moving dates and how do you plan multiple quarters?

Connie Kwan: I have used many different tools in the past for this. JIRA has some capability for it, you can create some reporting for start and end, and you can collect in the epics and track that yourself. I’ve kind of done it manually. However, I mostly use Dragonboat. And what I like about that is it connects to JIRA. That way, I can automatically update it and I don’t have to go in manually. I really like this because all the other tools I’ve used like aha or productboard, mostly focus on creating a visual. They still require me to go in to shift things manually. It is much more convenient if it’s all connected so that all the systems are connected to OKRs and to JIRA too.

You want to get everybody to actually use it as a source of truth and update their JIRA tickets to all the engineers so that what is reflected is actually reality. Because what you don’t want is people to go there and realize, “Oh, I still got to talk to Connie anyways. So I’m gonna stop using that tool.” So that requires managing but once you have the system up and everybody going, then you can get to that state where 99% of the inquiries go there and I only have to handle the 1%.

Becky Flint: Yes and we all have had our shares of spreadsheet, that’s why I started Dragonboat. If you connect Dragonboat with your plan, it tracks your history which can be a really good starting point to talk to your team when you do quarterly check-ins. When doing quarterly planning usually you follow up weekly or bi-weekly cadence. At the portfolio level you have a quarterly planning or bi-monthly with weekly or bi-weekly check-ins to see how you’re performing, to remind you of your original plan, tell you if you’re falling behind, or if you need to add anything to the plan. A tool like Dragonboat enables you to make those adjustments and relieves PMs of having to take on that burden.

Connie Kwan: Yeah the magic is that what used to take me four hours to do, now only takes me 10 minutes. I used to have to manually get input over here and manually adjust everything before talking to the stakeholders. It was frustrating because if something shifts, everything else shifts. I have to shift to a new plan and propose it to various people, have those meetings, then gather everybody and explain it. That’s a lot of time and a lot of time wasted. Whereas in the tool, if everybody’s hooked up with our tool and using it properly, then I can pull it off in 10 minutes. I don’t have to take hours to prepare for meetings on meetings.

Becky Flint: It’s very funny, you mentioned how it’s tied to the theme of not wanting to be the bottleneck. You don’t want to be the only one responsible for everything. Because you do rely on collective input of different stakeholders to make the best decision across the board. Therefore, put yourself on the side of trying to do that kind of planning and managing all that by yourself. And the presentation is actually very slow too. It’s not collaboration. It’s more asynchronous, I do my work, present it, it gets rejected, you go do more work, come back, etc. That’s definitely something that we both have experienced a lot. And that’s why I created a new way to address that.

There is a question on what granularity other organizations use to plan and communicate their roadmaps?

Connie Kwan: The granularity depends on the audience, which is what actually works with students on this particular topic of storytelling, because the story is very long. When you communicate with specific folks, for example, engineering, it’s a very specific piece of the story that you’re carving out to communicate, because they only care about that piece.

In contrast, with executives, they only care about this other piece. So the program manager holds the whole story, but then how do you adapt how you carve out the right piece for the right audience? And then how do you adapt that message so that they understand. That’s why this is important. And the answer depends on who you’re talking to, and as an influential product program person you have to adapt that message to your audience.

Becky Flint: Right, if you talk to executives, they don’t really care about the epics and stories which are too granular. You want to give them something like initiative or higher and that’s how you really package the work to them. And when you talk to individual salespeople, they only care about the feature that his or her customers care about so you go down to the feature or epic level.

Product managers have to create all these decks, one deck for the board, one deck for the sales team, and one deck for the others because those are the stories you have to tell.

I also want to highlight that when we do quarterly planning, there’s a huge emphasis on connecting bigger initiatives, which you will tend to look at multi-quarterly and then quarterly. You should mostly look at things at the epic or feature level- a couple sprints in length. Then once you go to sprint, you look at the stories and tasks. Lastly, when you look at the quarter, you look at the features and so forth in a couple of sprints. You can then go to the executive level of discussion that will go to initiative that could be multi-month or multi-quarter or even longer.

How do you get stakeholders comfortable with just in time collaboration?

Becky Flint: I think getting collaboration just in time is very similar to having meetings. The difference is that when you have meetings, you don’t commit so that people can discuss and see what’s going on, before summarizing. The idea is to have a  “just-in-time”, but you don’t commit.

You can have a draft mode of some sort where you discuss scenarios before committing. That is also something you can use when building Dragonboat. You can do things in a draft mode, so you don’t have to commit to scenarios until people feel comfortable.

Connie Kwan: Agreed, and that is an interesting question because it’s a shift over time on how we work together, rather than a particular shift to a just in time model. I actually wouldn’t position it as that. Because it might make people think they have to change how they work, when the reality is, you don’t really have to change how they work. You just change how you get them to listen to each other. 

So rather than going to work with sales, where they ask me all these things, and then going to work with marketing, where they also ask me all these things, and having to try and reconcile it in my basement and give them a happy answer, I put them in the room. I say, “Look, you know, we’re a team, we should get to this outcome together. Because there’s no way for me to satisfy A, but also satisfy C, I’m running into these problems that I cannot relieve so I need your help in getting this right”.

Tell them why you brought them. It’s a very important meeting where we’re going to make some decisions. So you want important stakeholders there. The next step is to do your work. You bubble up the things that need it, that is the just-in-time collaboration, and it doesn’t need to be a separate thing. It’s just part of how you work together, and you start slowly increasing this way of collaboration over time, and people get used to it. It’s not really a big change. Management effort has been slowly shifting over time, shifting how organizations work and pushing more things on your plate into the 99 automated percent of your work.

Becky Flint: Yeah, you speed up the decision making to real time instead of going back and forth to make it easier. Now, what are the differences in role between program managers and product managers in quarterly planning.

Connie Kwan: I have had the benefit of program managers in the company, but only when the company got really large. Mostly, I’m the product person and I have to handle whatever is in the gaps. And so if nobody’s managing the project I have to do it, and if nobody’s managing the program, I have to do it. If the company has both product managers and program managers, product managers focus on customer interactions and getting input from customers. Program managers can focus on lining up all the stakeholders and hosting the meetings. This is where, if you find you have an armwrestling with C on an issue, you get them in a room and you help move that ball forward.

I’ve seen that even at large companies, or when I talk to other product leaders who have the benefit of having a program person, they’re suddenly able to spend a lot more time in the market. Consequently, they understand what the market-needs are and feed that back into the process and then the program managers just hold the reins on.

This is what’s happening next quarter when you’re a large company, and that’s why you need it for a large company, right. When you have a large company, you have a lot of moving pieces and things are unraveling all the time. Therefore you need someone dedicated to just listening and making sure nothing has gone rogue and pulled the whole thing apart. And those two roles will work really closely together. Great program managers are very intimately aware of what the customer needs are. And the product person often comes in with a little bit more engineering background, so they do a little bit more sussing out of feasibility with the tech team.

However that’s not always the case, and it’s important you guys figure out how to work together. Create a list of items you need to handle between you.

Becky Flint: Yeah, larger companies tend to have program management. Previously, product managers played both roles, and the product elements of the role are really focused on the product itself, the customers, how the product looks and feels, and how it may be done. Now a program manager is more internal facing on the work with the teams and across multiple teams, but they are very closely connected.

Okay so, when you present your roadmap, are they usually just focused on the product, or do they sometimes represent another initiative, like marketing, to drive compensation?

Connie Kwan: I actually had both the product and the marketing team, as the VP for one company, and I wrestled with this question a lot. I had a Director of Marketing, and initially, I tried to include his stuff in Dragonboat. But at the end, I ended up noticing his stuff was moving too quick.

Marketing is quick. If you think one-week sprints are fast, marketing has daily sprints they’re pushing. They’re writing blog posts or creating really short experiments. One experiment runs for a week, but some would run in the day if you have enough traffic on a website. And so they were running these things so quickly, and the marketing team wasn’t tracking in JIRA. I didn’t want to force them into JIRA. In the end, they ended up tracking their own, and I would have pieces in Dragonboat that I would use, simplified epic-level kind of tracks, so that the rest of the organization could see, especially where they’re borrowing engineering resources.

It was made easier for companies that had marketing with their own engineering and design. That company did not. And so either they were hiring out engineering, but then we’d run into problems. If there was anything hooking to the back end, I would have our engineering team do it. But since marketing is owning the spec, I would put that in because it is cutting through what the rest of the workload is for engineering. So my point is, it depends. If it’s part of the pie that everybody in that team is looking at to prioritize, it needs to be put in there.

Becky Flint: And I have seen, and there are two types of marketing activities, there are bigger complex ones. These need collaboration and visibility to be bubbled up so engineer resources can be tracked as we do our quarterly product planning.

There are also those daily things that are just going on, like a blog. This may not need to be part of the tracking.

But we do know that investment and marketing are the big initiatives. And so we might need more effort, maybe tie engineering to it, especially if it leads to product lead growth. That is when marketing and product tie together closely.

Connie Kwan: People say, “ Where does marketing start and where does product start? It doesn’t. It’s one continuous flow. They want to know what websites and assets are which and how fast your sprints are, but it’s the same ideas, the same setup.