Juggling competing stakeholder demands, business priorities, and customer needs is a daily challenge for product managers. How do you effectively navigate through this while building amazing products, tying annual planning to long-term strategy, and advancing your career?
In this webinar, Dragonboat CEO & Founder, Becky Flint, was joined by Janette Chung, CPO at Copper to discuss her secret sauce (spoiler alert – portfolio management) in growing her product and career at some of the world’s best product companies (PayPal, Ant Financial, Jobox, Copper).
The speakers shared strategies, best practices and specific examples and advice for how to:
- Prioritize effectively using a portfolio management approach
- Define and get buy-in on product objectives / OKRs
- Negotiate and plan roadmap dependencies and resources
- Move up the ranks to a senior product leadership role
Watch the portfolio management webinar recording:
About the speakers:
Becky Flint built the portfolio management functional at PayPal, Bigcommerce, Shutterfly, and Feedzai. She launched Dragonboat, an integrated road-mapping and portfolio-allocation platform to help product teams strategize, prioritize, deliver and improve industry-leading products.
Janette Chung is a seasoned product executive, startup advisor, and investor in global fintech, payments, e-commerce, and the marketplace. She has led products in startups, pre-IPO, and publicly traded enterprises. Currently, Chief Product Officer at Copper Inc., Janette has a proven ability to drive results.
The following transcript has been altered for readability.
Becky Flint: We have a global audience here and I’m very excited to lead a conversation on portfolio management. We will start with some of the things we’ve learned from our career journeys, as we built products and aspired to grow our career and deliver business values. We’ll also take a look at achieving stakeholder buy-ins, annual planning, and what portfolio management in action looks like.
Janette Chung: Becky and I actually met when we worked at PayPal, early in our career. And I want to highlight that when we were at PayPal, we were very much aspiring product leaders. We were always looking to climb the product leadership mountain. The typical advice we got from mentors was to work on highly visible projects, get more exposure, and present to the executives as much as we could.
Now, looking back, I know that is all good advice. But I also know that there is a big chasm between product managers and product executives that advice did not address. It is the mentality of ‘are you limiting your scope to just thinking of that project?’
When I was a product lead, I would think about how I could collaborate to solve very tangible business problems. It was only when I became the directly responsible lead, that I stopped thinking like a product manager anymore. As the person responsible for a business objective, I had to think like a general manager. I had to look at my relationship with my stakeholders very differently. The biggest differentiator is that it’s not just about the product anymore. I help the stakeholders succeed, which in turn helps the company succeed. I think that’s the chasm, you have to shift your focus to the business, as opposed to just the product.
Becky Flint: Yeah, I think that’s spot on. A lot of times, when you talk to PMs, you realize how strong the focus on customer experience is. You always think about how the customers can be delighted, how the customers can have a better flow, and faster sign-on, etc. I think those are really important foundations, but ultimately, they’re a means to an end.
Janette Chung: Yeah exactly, and typically the easiest way for a product manager to gather feedback is from the user research team, salespeople, or customer success. You should gather requests bottom-up, and then figure out the common themes of all these requests before you put together a roadmap. And what I have noticed since I became a CPO, is that it’s more about how to combine the top-down view.
The top-down view is typically defined by the CEO and co-founders before the leadership team will have to agree on how to achieve the different key results. And this is the time when a product executive will be very active as they try to understand and negotiate with stakeholders and look at everyone’s request. It’s a very iterative process.
Sometimes the executive will roll out their wishlist of key results initially based on the OKRs of that quarter. That is when the product comes in to actively engage with each executive. It follows a back and forth based on the resources which allow them to create realistic key results. And because of this process, the stakeholders are counting on product and engineering to deliver those key results. Therefore, it’s very important to calculate resources and allocations to each key initiative owned by all stakeholders across the company. This has to work. If this doesn’t work in one quarter, then next quarter, other stakeholders will start to question if you can deliver. So this type of conversation has to happen in order to maintain trust.
Becky Flint: I actually want to dive into what you just said and go deeper. You mentioned that it’s very typical seeing the product roadmap as bottoms-up. You have some features and propositions, coupled with whatever scoring system you use. And then you also have some engineering resources associated with this.
Early in our career, we thought this was a pretty good mechanism. It’s data-driven and quantified with good product engineering collaboration. I want to point out something that you mentioned earlier about how it’s an iterative process. At step one, you get the features or customer requests, and then you prioritize them. And then you work with the engineering. There you get some sort of high-level effort with which you can only do a certain amount.
But you also mentioned this is a bottoms-up approach. Which later on in our career, we realized is actually a very seriously flawed exercise. And that is because it didn’t have the top-down approach. From a top-down perspective, you look at feature versus business outcome. You want to know how these features potentially affect the business outcome. This is a great example of portfolio management in action.
Janette Chung: Yeah, so there are usually three company objectives. Typically, depending on the stage of the company, it could be a user-growth goal, a revenue-growth goal, or something relating to compliance in our industry. And typically, these three goals are what the company needs to achieve. By achieving these objectives, the company would be ready for the next milestone, let’s say 12 months later. Therefore, everyone in the company should rally towards these objectives knowing it will bring the company to the next milestone. And as a result, each department can clearly see what they can do day-to-day to contribute to any of these goals.
Additionally, the executive team can also agree on the three goals. And from there you use a tool where you can actually have a target allocation for each of the objectives. This will allow you to check over time, whether it’s a monthly or weekly cadence, if you’re on track, in terms of allocating your resources to these different objectives.
For example, let’s say this quarter I am supposed to invest heavily in user growth but I end up overdue on compliance. Then I need to have this conversation with the stakeholders to discuss changing the priorities of our projects. Otherwise, we can’t clearly know what we are supposed to do. It’s better to change our allocation in the middle of the quarter so everyone knows our new target. It allows us to give our product and engineering organizations full transparency on what we are delivering.
Becky Flint: Yeah and a lot of times people say “Hey, I’m just one company. I’m just one product manager, why do I need to have a portfolio?” And that brings us back to how product managers think versus how product executives think. If you’re a product manager, you think about features you seek, you think about user experience, etc. It’s very easy to think about the product portfolio management context with five products, but product managers should always be using the product portfolio management context.
For product executives, they are more focused on business outcomes so they take a portfolio management approach, not necessarily to five product lines within your area. You’re actually looking at these three business outcomes you need to drive. Then you use a portfolio management approach to actually allocate the outcome, not necessarily allocate to the work itself in the first place.
Janette Chung: At the beginning of my career, the themes were more around products, what we call a product-centric roadmap. And then lately, I’ve noticed that my roadmap is more focused on OKRs because we need to make sure that we are investing in the areas that drive the right business outcome.
Becky Flint: Right so one thing you start to focus on more is negotiating with different stakeholders. How do you engage your stakeholder in the conversation? When you talk about a product-centric roadmap portfolio, it feels like the burden is on the product leader. Because that’s their product roadmap. You have five product themes, and then you decide it doesn’t translate to your stakeholder’s goals.
When you switch to an outcome-focused roadmap, all of a sudden you start to align with your stakeholders on the same things they care about. They care about your revenue. If the product theme is onboarding, that’s a very difficult difference to translate into revenue growth. But if you look at the growth revenue as a goal then onboarding or elements of onboarding can easily be tied to it.
Janette Chung: And I also want to point out a disadvantage of a poor product-centric roadmap is that it’s harder for product managers to think outside of the box. In other words, they will stick by the requirement of their stakeholder.
However, if you are able to think outside of the box, you can focus on the problem, as opposed to the product. If you can focus on the problem, then you will suddenly open your eyes to a lot of creative solutions. Some could be a product. Some could be just a manual workflow. As long as there is a way to support the experience where the stakeholder can still achieve their goals.
For example, maybe that goal is to sign up for big teams. You could think about putting a Google form, and then figure out how to run a script at the back-end to achieve some onboarding requirement. That could at least be for the beginning to get that key results started. You can then think about how to productize it later.
Becky Flint: It’s really cool to think about how focusing on an outcome gave us a different ability to look at the problem. The alternative is looking at the product. It’s so limiting on having to improve certain things versus what we tried to achieve.
I think what happens in companies often is that the product roadmap is driven by near-term business goals like conversions and revenues. And so then the company optimizes for these near-term focuses without building for the future. Ultimately, the company fails on their own success. This brings me to my question. As a product leader, there are some other things that may not give you any of these benefits this quarter. How do you make sure it’s still built so that the product would have some future benefits?
Janette Chung: Great question. That’s why quarterly planning is more quarter by quarter. However, you always have to remember that there is still an additional annual planning process that has to happen that should be vision-driven. Annual planning should remind you why the company is here. What are we trying to do? How do we think we will be playing in the market a year from now, 18 months from now, or even a little further. The annual planning exercise has to be tied to the company’s long-term strategy.
And as a product executive, you also need to think about things based on that long-term strategy. What are the product strategies that need to happen quarter by quarter to ultimately make sure that we pave the way for that long-term vision? And therefore, sometimes in addition to the quarterly plan we need to deliver, I will also add an objective for the long-term. I will reserve, let’s say, 10% of the engineering resources. I would align with the stakeholders by saying that this is the 10% capacity that we need to pave the way for our long-term goal. Therefore, we should try to protect that and think about optimizing the remaining resources for the quarterly goals based on the buckets. We may also need to think about how to add more resources into those buckets, as opposed to completely putting the long-term vision aside.
Becky Flint: Annual planning and allying executives are both things we need to achieve, as well as a longer-term product vision. There’s a lot of myths around annual planning and so I want to spend a little bit of time on why annual planning is important? How can annual planning be done effectively?
Janette Chung: First of all, annual planning ideally should be done when the executives are able to have an extended period of time to discuss how the company would look 1, 2, or 3 years from now.
For example, if we said that we want to disrupt a particular industry then the question is how. Is it by automation? Is it by connecting supply and demand? It’s just like looking at a map from point A to B. If I want to get to B, there are many different ways to get there. So the executive needs to discuss which path seems to help us get there sooner. Is it about deepening the engagement with supply first or is it about engaging partners for demand first?
We need to be very clear because oftentimes, they all need to be done. But the sequence can be different and the executive needs to align. So to get from point A to point B, as the drivers, we need the navigation, aka the executives, to tell us where we need to go first to really nail annual planning. You need that sense of direction for the company planned out before you tackle annual planning.
Becky Flint: Exactly, and I’ve done a lot of portfolio management strategic planning. We basically say, “We want to double our revenue. How are we going to go about doing this?” So we did a poll and everyone wrote down how we could double revenue. When we opened up our paper, everyone had different opinions, and that showed us something so important. If we don’t do this alignment, then there are these different strategies that will be carried out by different functions. Executives already are the ones that have the most context than anyone else in the company. But because of their function, they actually have a different idea of how to go about doing that. If we don’t get everyone on the same page, you have all this misalignment. The roadmap is just a mess.
Janette Chung: And this alignment sometimes could be difficult conversations. And it’s not even product-related. It’s like if I want to focus on the core market in Q1, but I will focus on the international market in Q2, then someone is going to be unhappy about it in Q1. However, at the very least the conversation allows us to be aligned. And we all understand why this is the best decision for the company, given the milestones ahead of us. And then it’s really a matter of trusting that we will be able to play a role.
Becky Flint: Right. And you mentioned something that is very important, which is to trust the direction laid out and share that direction. We want to give our teams what they need to achieve the right allocation of resources. When you don’t have that, people from different levels all have to dive down to the detail to see exactly what’s going on.
Janette Chung: And that’s where the alignment needs to happen. Sometimes, when we focus on new features, for example, to help ourselves to acquire a larger team, then we might not have the resources to cover some of the critical asks from customer success. They end up spending a lot of time manually doing certain operations. That part is more so about us saving the CS team time.
We understand that it is important and it might not translate to the OKR directly. But I will work with the head of CMS to come up with reasons, such as “freeing up 40 hours for the CS team, will allow CS to actually help to cross-sell, and therefore, we will be able to support this”. I will help the stakeholder understand that I am helping them to succeed, I am helping them achieve their goals. If I have the resources, great, if I don’t, I have to do some scenario planning. Facilitating that conversation and making those trade-off decisions will ultimately help everyone feel more comfortable.
Becky Flint: You know, in the early days of product management, there was a big focus on being a product manager, not a project manager. There’s someone managing your project. You don’t need to worry about the timeline, you don’t need to worry about resources, just make sure you build the customer experience. When you become a product leader, all of a sudden, you actually have to worry about all of those things. You need to worry about building the right goals and allocating things to the right places, and obviously prioritization negotiation. And then you actually talk quite a bit about resources and delivery and the commitment. When and how did you see that change happen? And why is it important that product leaders not only concern themselves with the feature position but also the delivery, even though that may feel like a program project management kind of activity?
Janette Chung: It goes back to how my revelation about my relationship with my stakeholders as our allies. We are helping each other to succeed. And therefore, if I start to feel like I might not be able to deliver, I need to think proactively, what are the ways that we could still help the stakeholder deliver the key results that they committed for the quarter. If things have changed, it’s important to be really proactive. Become a problem solver to think about the key decisions that need to be made in order to make sure that the ‘what’ they promised to deliver will be delivered as soon as possible.
Need to build responsive products that delight customers, achieve business outcomes while progressing towards long-term product vision? Sign up for a free trial of Dragonboat – the all-in-one Responsive Portfolio Platform seamlessly integrated with Jira, Github, and Asana.