Should you roadmap your portfolio? | Becky Flint

In episode 47 of Talking Roadmaps, Justin Woods interviews Becky Flint, Founder and CEO of Dragonboat. They discuss the importance of roadmapping in portfolio management, strategies for product leaders to enhance team efficiency, and the benefits of responsive product portfolio management. Becky shares insights on creating successful product teams and aligning strategies with business goals.

Becky is a product and tech executive based in the Silicon Valley. She has built and scaled product and engineering teams globally for both startups and Fortune 500 companies. Currently Becky is the Founder and CEO of Dragonboat with a mission to empower responsive leaders and their teams to build better products faster. Prior to founding Dragonboat, Becky has held executive roles at Feedzai, Bigcommerce, Tinyprints/Shutterfly, and PayPal.

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

Should you roadmap your portfolio? | Becky Flint

Justin Woods and Becky Flint

In the next episode we are talking to Clifton Gilley, VP Research Analyst for Product Teams at Gartner. So watch out for Season 1 - Episode 48!

• Transcript

  - Hello everybody and welcome to the "Talking Roadmaps" Channel. Today I'm joined by someone very special who I've known for a number of years and been following and learning from her. Becky, I'm really excited to have you on the channel. Please introduce yourself.

  - Thank you so much for having me, Justin. My name is Becky Flint. I am the founder and CEO of Dragonboat. But I would almost say that I would've put Dragonboat on the side. I would say, you know, Dragonboat, or me personally, and also our entire team, our passion is about helping product teams in different roles to be successful. So now a quick intro of, you know, what is Dragonboat. Dragonboat is a platform built for product leaders to achieve more product outcomes faster. Then obviously, roadmap will be part of this solution. And there are more.

  - Right.

  - We can definitely talk more. A bit about myself. So, you know, before I started Dragonboat, I was lucky enough, have been grown up professionally with a number of companies. And one of the more notable companies is PayPal. I joined it as one of the first product/product operations to help it grow and expand internationally. And it's company is growing, and we also had to deal with a lot of roadmap challenges on product management and/or the other word is the portfolio management challenges. So had to build internal processes and internal toolings, and even the role for product portfolio managers. And then later on after Dragonboat, I went to... Well, after PayPal, I went to a couple companies including Shutterfly, was helping them to build together a e-commerce platform, joined multiple different product teams, and BigCommerce, and be, you know, became a, you know, from a series B company to ultimately IPO. And another company, unicorn. And I joined there pre-unicorn as well, and then turning to a unicorn. Helped them build a product team from the ground up. Prior to me joining-

  - Amazing.

  - there was no... There was just one product person. So that's in the AI and the machine learning for fraud detection, years, years back. So with all the experience, what I found out is that, you know, we have great product managers in all companies. The challenge is, they cannot achieve the most that they can. The reason is a number of things around it and I would love to talk more, but that's really also the reason that we started the Dragonboat and also the movement of responsive product portfolio management, which is how you connect the business outcome, customer outcome, and product strategy with what you have today in a typical product management, which is the agile and product and the features and releases. So, and I was lucky enough to work with a lot of very talented people within PayPal and then later on after PayPal, going to a lot of amazing companies to kind of, sort of build and expand, adopt, and try this framework. And today we have thousands of people globally have taken the intro or certification of that programme. So it's very exciting to see the product team and the product function being recognised, not just-

  - Yeah.

  - as a sort of a product and a engineer in a little corner do their R&D stuff, but more and more move into the companies where you heard product like company, product like growth. What that is, is the product is now the driver, not just a supporter of the business. A product is the business, a product is the driver, one of the drivers of the business. So, super cool to see that industry evolving and be part of the enabler if you are.

  - [Host] If you're enjoying the channel, subscribe, hit the bell icon, and give us a like.

  - Yeah, massively. And thank you for that great introduction. I think me, myself, I'm also one of the students of the responsive portfolio and product management process. And I think it was so important, you know. I was really fascinated by what you have provided, and really pleased to go through that process. So thank you for bringing that to us. On the "Talking Roadmaps" channel, we're on YouTube, we're on Spotify, and other podcasting platforms as well. But we like to talk all things roadmapping, from the good, the bad, the ugly. Speak to some amazing experts, thought leaders, practitioners, and tool experts, and tool owners as well. And that's why I'm so thrilled that Becky's joined us, because there are overlaps. You know, roadmapping is part of the product level, the product development life cycle, and so it's an important component of that. But Becky, we're gonna explore our PPM and Dragonboat a little bit more together because there was a bigger piece to discuss here. So let's get started. Maybe we'll just talk a little bit about a roadmap for now. We'll niche it down. But then I want us to talk a little bit about, you know, how that fits into the bigger picture. So Becky, from your experience, you've got some fantastic experience there as well. What's the purpose of a roadmap really?

  - This is a really good question. And I almost wanna take a step back saying, product roadmap, obviously, is what we typically think about roadmap. But roadmap existed way before product roadmap, right? Think about it. We have our personal roadmap. That's where, how we wanna achieve our goals, right? And, you know, there are a lot of roadmap in different ways. So the way you think about the roadmap is really, you know, if we put it really simply, it's a plan. How do I go from here to there. And it's interesting because... Let's now dive back to talk about the product roadmap. As a product manager, you will definitely have a roadmap, or should I say, you actually have many roadmaps at any given moment. So one of the conversation I had with a friend recently is about, let's talk about the roadmap. Think about it. At any given moment as a product manager, you have a roadmap for your executives, you have a roadmap for your go-to-market teams, you have a roadmap for your engineering teams, and probably, you have a roadmap that are for you, how you think about it. Same content, right? So in the end is, roadmap is not only just a plan, roadmap is a snapshot in a different angle of a plan. Think about your, the entity of your product you are managing today. It's not like a, it's not a flat piece of paper, it's not two dimensional. It's many dimensions. And the way you think about a roadmap is how you think about it and how you communicate it, about the truth of your product in a different angle to different user, different content for different purpose. So a roadmap, the way we think about it, it's a plan. Or in the other way, it's how you communicate the plan to the people on the need to know a best way to know basis.

  - Yeah, that's a beautiful description of it. I love that. And actually, I think, well, one of the quotes that we'll have there is that the roadmap is multidimensional. That really resonated with me. Becky, you talked about different audiences. So who are the audiences of a roadmap? Is it one set of group of people or is it, you know, how big can that audience get?

  - Wow, so that's excellent question. The audience really related to who your, the people you work with every day. Think about this. In a company, I would say, product management is probably one of the most connected function. You are almost like a supernode in a network. It's a supernode, right? I'm just geek out this for a minute. In a network you have this nodes and different nodes talking to the different people, and the product managers is one of these supernodes, because first of all, they connect to engineer. Obviously, working with engineering all day long. And so that is the roadmap. You have to give your engineers a roadmap. If they're inspired, they know where you're going, right? So engineering is one, and maybe your scrum team. And then you have a cross-functional scrum. Like a scrum of a scrums, right? Because the other teams that also work with you, they also need to know your roadmap. They have a context. They can build a product that knowing where we are going, not just building silos. So on the engineering side, you already have two flavours of the roadmap. Now, because they are all your people you collaborate with, right? Then you have like a design side, you have the roadmap, it's a little bit different, 'cause it's a little less in details and more in terms of user experience, right? And then you'll have... That's sort of you're closely correlated. Now you have other product managers. 92 of the product teams have dependencies when you have five or more teams, because there's no product built by one team, right? Once you have other product managers work with you together to build something, features or initiatives, guess what? They need to know your roadmap. And so then, inevitably, you will have conflicts. So that's another stakeholder, other product managers. Then you work with, obviously, the go-to markets team, sales, marketing. And they also need to know. They have two needs fundamentally. One is, they have to bring a product to market, right? They have to... How do sales talk about it, how marketing gonna talk about it, how support's gonna support it, like there's a whole part. They will support you, right, in terms of bringing the product to market. They also bring the feedback, the insight coming into you. Sure, product managers can go collect insight, it's part of the role for sure, but there are also a lot more tangible functional details. These people interact with the customer. They gonna bring you... Justin, you know that. You're from a customer success side. You have much, much deeper and richer insight bring to your product team. And so then they would give their roadmap, a feedback to you, so you can create a communicate roadmap to them, right? So they know what's coming, they can have the negotiation. So that's your stakeholder there. And then, obviously, you have executives, executive stakeholders, right? So need to understand they have a strategy. They wanna know how you support their strategy, and how their strategy inform your product design decisions. So that's their executives, your stakeholders. They have created a different view to them, right? And then you have another one, which is the rest of the company. Product managers need to... Everyone in the company needs to know what we're building, where are we. So, and then you let alone, you think about there's the board, because your roadmap is connected to your executive roadmap who will go to the board deck. And sometimes, external facing to your customer. Oh, and by the way, what if you have integrators and partners? Their roadmap to connect with you. So yeah, that's different flavours of a roadmap, right?

  - It really is. And maybe, if we add one more onto this, investors want to see-

  - Yes.

  - what we're doing.

  - Your investor, your boards. Yes.

  - Yeah, amazing. So actually, it sounds there's a lot that we've got to unpack there, Becky. And actually, when we think about, you know, how we might have thought about when we first started a roadmap being a single page. Actually, roadmapping is about planning and roadmapping, not just a roadmap. And you mentioned dependencies, planning, feedback. This kind of makes us think that this is something much bigger and actually, probably, plays well into portfolio and RPPM as well. So maybe we can talk about that a little bit more.

  - Right. So there are a couple things you call out. And then I'll give you a joke here, right? Every product manager loves their product. Every product manager would be a champion of their product and a customer. It's almost never the case where product raised the hand to say, "Look, my product is not important. It doesn't need engineer resources right now. You can take all my engineer resources away." It's not gonna happen, right? Because for them, that's their focus. But you take it one step higher, take one step higher, look at it across your entire, you know, 1600, or you know, even 10 product teams as the business leaders, the chief product officer. And you will say, "Whoa, okay. so these areas are not in good shape. We need to invest more." And you have to shift your product investment, AKA resources to this area. And the other area would have a minimum keep the lights on if at all resources. And this is where product leader, when they look at, quote, unquote, "their roadmap," they're looking at a portfolio roadmap. And when you look at a portfolio roadmap, that is the first part you will think about. It's, you know, not just a strategy, right? Strategy is where you wanna go. And the second one, very immediately, how do I enable that strategy. And that means, "Where do I invest my resources?" That could be product teams, could be designers, could be engineering, could be all of that, right? So that's the first part. It's about portfolio management. A lot of times, there is a myth. People think about portfolio management, it's like, "I have a product team, one, two, three, four. I wrote it all up. I have a portfolio view." That's a part of the portfolio management, but that's afterwards, right? It's like you have a six bank accounts, you give, every month how are you going. But when you think about your investment portfolio, you will actually think about, "Where I'm gonna put my money in," right, before you have the reporting. So the true portfolio management start with, "Where's our goal," right? Where we are and how we wanna get there as a strategy. And then how do I enable that strategy, which is the people and the resources. And that will set the foundation for the, quote, unquote, "how you design your roadmap by individual product teams in the next X amount of the investment evaluation period." It could be annual, could be quarterly, could be continuous, right? Now, I also wanna say, every single product manager is a mini portfolio manager, right? Think about it. Every product manager also have to build your product strategy aligned with how the company's strategy needs to go. So it's a part of the bigger strategy you have to achieve and drive certain goals.

  - Of course.

  - Part of that, right? You also have to decide in my scrum team or the team I have, how much I'm gonna work on certain areas, how much I'm gonna... Like, the areas that I, quote, unquote, "have control," how much I will rely on other product managers. So all these come as, these are the decisions you need to make as a product manager as well. Now, after you make this decision, you create a roadmap, because the roadmap is something that it's kind of communicate the decision, right? Communicate the decision-

  - Yeah.

  - on how to tie to the goals, what kind of features we wanna release, and what is the jobs of, you know, I wanna say marketable, or, you know, value delivering unit, right? Whatever you call the features, and stories, and others. Like that is the roadmap, is a output of the portfolio decision at the individual product level across the product.

  - Yes. Yeah, that makes sense. And the big bit that I'm picking up here as well is the responsive side is really important. Because what's typically burn a lot of people creating roadmaps, especially when they're not outcome or problem-related roadmaps, their delivery plans that are 12 months in the future, no product manager can predict that really and know that their resources aren't going to change and everything else. And so the little hour on the responsive side of things is so important because it's talking about things being bi-directional. Things might need to change. The landscape changes, what we're doing changes, our resources changing, our funding changes, and we need to be able to adjust to that. And I think that's a fundamental failing of typical roadmap approaches is that people have set them in stone. What we are trying to do, and I know from your experience as well, is be really fluid with your resources to be able to react to the changing outcomes or goals that you need to-

  - Right. I 100% agree with you. And that's something I think the, you know, part of that is the evolving of the industry, part of it's just the needs, right? I wanna kind of go back a little bit in time. That's 20 years ago at PayPal, right? We built this responsive PPM, PayPal, because PayPal was operating in a very challenging environment. First of all, fintech is not easy. It's complex, it's a lot of dependencies, also very thin margin, right? If you think about it, you make your profit your revenue based on a little difference between how the, you know, the customer pay you to the bank on a fees and how much you have to pay the bank fee. The margin's very thin. So for you, first, a company to be successful, you had to be very good in terms of build the things, the right thing in the right order. The right order is tremendously important. So, and that's something that we are experiencing today now, right? Obviously, maybe in the last couple years, there's a lot of money in the market, it's a zero interest rate, and there's not a lot of focus on build the right thing in the right order, 'cause I have, quote, unquote, "infinite runway," right? I have time to get it right. In today's environment, and more and more gonna be like that, is that the speed is so critical. So you have to think about it. If I have 10 engineers, 100 engineer, 1,000 engineer, how they are going to be mobilised to deliver the outcome. What's the sequence? Because if you build, if some of the things... You know that, prioritisation framework, right? So it's important and urgent, right? You have to figure out how do you do the urgent things in the order, 'cause not everything are urgent at once, right? But not everything is all important. Like, well, hopefully, we don't work on things not important, but the urgency is what matters. So the responsive is to help you to say how do I deliver the most urgent thing. Now, urgent is not what customer ask you. How do I stay in competition? How I get the value to the customer? They can get a taste of the product before you build the whole thing, 'cause quite often, like, team builds a very big thing. That means your value delivery is very late, your scope is very late, you don't have the possibility put it on the market. We are no link startup, we are no Facebook, sort of the fail-fast. But how do you put into practise? What does it even mean? What do you mean by fail, pass? If we all fail, it's not okay. At PayPal, it's not okay to fail. We are a bank, we manage people's money. There's a fraud. You can't fail, right? So what they really mean is that you put your hypothesis. Your hypothesis may fail, meaning the investment you put in didn't create the value you want. It's not like a fail in terms of fail your customer, have legal, regulatory, a brand other risk, 'cause that's a huge risk. You don't wanna damage your brand, right? So the fail here is that when I invest in the product and put something on the roadmap, I have a hypothesis to say this is gonna drive this. And if you can test that hypothesis by putting the minimum thing out to the market to see is your hypothesis right or wrong. You fail. If that won't works, great. If it didn't work, you didn't invest something for six months, 10 month, millions and 100 millions of dollars. That's what we are talking about. So the responsive really is to think about how do I take the outcome we wanna get and figure out a way to jump into smaller pieces, right? And then how do we put some of them out to the market and then to see did it work, it did not work, and then we adjust, right? And the second part of that is, there are different ways to achieve outcome, right? And that gave us a little bit different mindset to say is this product team, is that product team, it's maybe product plus marketing or something else, right? So that the outcome-driven approach really help us to think about our roadmap, exercise or practise a little bit differently, versus the, traditionally, product manager tend to think about my roadmap and the features I wanna build to make this a great experience. Still important, don't get me wrong. But you have to also layer on top of it to say, "Well, before I reach my great experience, I don't wanna lose the customer, I don't wanna be out of the business. So how do I balance that need?" So, yes.

  - Oh, that was absolute masterclass, Becky. Amazing. I was just writing some notes here that I want to kind of just quickly reiterate. So, cost of delay is very much a thing, right? Is being delayed to market, there can be an opportunity cost to focusing on the wrong thing. There can be a cost of delay. You know, we often talk about product managers being risk managers, de-risking things. And I don't see enough experimentation and discovery. And certainly, from my early exposure to roadmaps, they've been delivery plans based on assumptions. And actually, we need some, a level of sequence, and here's our current level of thinking based on hypotheses and problems. So I really, you know, and actually outcomes, which was the third point that I put there. That was just phenomenal, Becky, thank you. There's so many little nuggets of wisdom there. What I'd like to do, talk a little bit on roadmaps in terms of the design of them. So maybe, what some key elements are, visualisation, and so on and so forth. And then I'd love us to step back and understand, you know, maybe with some visuals, if you've got some slides you can share with us. How roadmapping is actually just a smaller part of something that's much bigger-

  - Yeah.

  - from your perspective.

  - For sure, for sure.

  - Would that be okay? Yeah. So let's have a couple of quick questions on what you think are some of the key elements or maybe the content of a roadmap. So it is a much smaller part of that, but what would you expect to see as a product leader?

  - Right. So I think for every single roadmap, it's almost... Look, everything we deliver is a product, right? What a product does? Does this product always solve a problem? And hopefully, at least some sort of reaction that the people using your product. You think about the roadmap as a product, it's something you communicate to the desired audience. So the first thing you create a roadmap to say, what is this for, who is this for, and what do you want them to get out of it once you create that. So there are a lot of the roadmap templates. If you go to dragonboat.io, on our website, we have a 10 roadmap templates. In fact, we have maybe hundreds of them more. Inside the Dragonboat, we have different templates for you. So, for example, let's look at a different lens, right? Look at ICP, who's your customer for this roadmap? Shared earlier, if it's executive, right? So they have to... What kind of questions they may need to have from you for this piece of communication, right? The deliverable, you gave it to them, the product delivered to them. So it's, one is, who's the user. Second one is, you have to communicate. When you have a roadmap, you have to say, what does the roadmap's going to achieve for the company, meaning what is the goal. Sometimes you create a release plan, you create a release plan for people who wouldn't need a release plan, they wanna know what feature is going to be available. Two, what things available because the go-to-market team need to prepare for it. The release plan is important, right? Release plan would also tell your customer success team say, "Okay, these customers asked for it and this is coming along the way." So they know what is coming. The release plan is also very important in terms of go-to market team particularly, right? So that's the most pressure you get from a PM to say, "I need your roadmap," like, "A customer asked for your roadmap," 'cause they wanna know what is going to be available to them, right? So that's like, what is the purpose for that persona, so to speak. And the third one is the level of details obviously. For the executive, they don't need to see stories, like, "This is the way." It just doesn't make sense, right? For the executive, they may wanna know your goals, and they wanna know how you gonna deliver these goals along the way. Could be an outcome roadmap. Talk about the outcomes gonna deliver, right? Go-to-market team's release plan, wanna know features, 'cause that's what customers speaks, about the features. And if engineering roadmap, you talk things. It could be a little lower level, more details, to say, capabilities, right? I need to be able, users should be able to do A, B, C, D over the period of time. So people, what are they gonna use from that? So that you can create your roadmap based on that. So we talk about the people, right? So who's gonna get it? And also talk about the information they need to get. So we give them the level of details they need to get, right? So what this roadmaps going to achieve and how it's gonna go achieve them. So I would say, these are the main thing, right, who's gonna get it and how they gonna use that information for, which is the content of the roadmap. And then in the content of the roadmap, we have to say, what is the roadmap gonna... What is the outcome for the things that people care about, and then what is the time elements. So every single roadmap has a time elements. The time elements could be as small as a sprint or dates for engineering, right? Could be as big as to your executive to investors, say, this quarter and then next. Like, you don't need to commit that level of details, right? And it's the same thing for marketing team or customer success team to say, "Okay, this quarter or this." And then you have something like next, and then later, right? So you could use, quote, unquote, "the lean roadmap format," or you can have something more like a month-based. If you wanna have a roadmap with your partner, they have integration, they have a downstream. They need a level of precision, a lot stronger, right? And then I used to work with the regulators. They wanna say, they wanna know by the date. Like, "I need to have this by this day. I have this by this date." Guess what? You have to communicate their regulators' needs. So your audience dictate what you need to be there in terms of the time, in terms of what is the content, the granularity of the content, and what is gonna get them, like, what they gonna get out of it. It could be outcome, could be customer outcome, could be feature, could be stories. So that's the, in my mind, it's like a key elements of it.

  - I love it. I'm nodding violently here with you as you were talking about that, because it depends. And I think people that try to create one roadmap view are missing the trick. The roadmap is not about you, it's about your audience, and it's about what information they need to show. So there needs to be a single version of the truth, but maybe different views. And also, there is a impact by sharing the wrong view with the wrong audience. Sharing stories with executives, or maybe, sharing, you know, three-year plan with high-level detail with the teams that are peripheral to you, that need that extra detail and that are date-driven. I think that's really insightful. And I think in classic product management, it depends, doesn't it? It really does.

  - Right.

  - Okay, so Becky, let's talk a little bit. Let's zoom out. So we've talked a little bit about roadmaps there, that really makes sense. But from Dragonboat's perspective, but maybe more importantly, from a responsive product and portfolio perspective, that's just one small part of that. So maybe you could share with our audience what our PPM really looks like.

  - Right, and I wanna share something that's observe the truth, which is, in a company, product teams is the most connected teams, right? So the supernode. We can talk a little about how product managers connect with all the different functions and roles. When we say product team, we didn't double click down to see more 'cause it's, product team itself, it's a bigger persona, but there are more detailed persona within that, right? If you think about product team, actually, obviously, they're product managers. Then product managers, obviously, they're really going sort of connect up and down, right? So working with executives, working with the stakeholders. So working with the go-to-markets team, working with the partners, and working with, obviously, engineering designer, the product managers. So product managers are here. Now, when you have more than one product managers, hopefully, most of you have heard of Melissa Perry, and she just wrote a book about product operations, which is so essential. The day you have product management, you have product operations, which is operating product management. How do you run product management, right? As a product operations, so quite often, they have to do a lot of things to work with the product management and the product executives, product leaders as well. So there's a product operations here, and then you have product leaders. And they're also human, right? They have needs, they have struggles. They also have to make trade-off decisions. They have to communicate in and out of product organisation with the product managers. Obviously, if we don't set goals, nobody would. We just go to runway. If you don't set strategy, everyone also going to all over the place. So really think about it. It's like, I wanna think about this as the key roles inside of the product organisation, right? Product executives who need to set goals and strategies and also decide where to allocate resources. And then you have product operations who's connect up and down and also connect across with the product managers and other teams. Obviously, we are product managers. So the way they have to work together to run the product organisation, you have to orchestrate and manage. And that's where really, the challenge here is like, there's no framework for it. We talk about agile, we talk about scrum. So really, thinking about the product management here, right? In this level, right? We even talk about product management. Typically, we talk about, you know, user research and customer-driven innovation, and a lot of things are really just around the product management itself, what about how this group works together. So this is the where really what you think about, it's obviously, you have Dragonboat ball on top, but forget about Dragonboat. Just think about it in general, 'cause really, this is sort of our internal... This is actually our internal education as well. So we will say, "Look, product team operates at all this roles inside the product team and with your stakeholders, that could include executive and investors and obviously, your go-to markets team. And as a product organisation need to operate, that is a, you know, you need to set goals and strategies, you have to listen to customer feedbacks, and you have to think about how you manage your product roadmaps. That's a bit, it's a piece, it's a key piece of it. Then you have to think about, "How do I make sure we have the investment/resource to enable our roadmaps," right? Roadmap is gonna be a daydream. A daydream, if you have nothing behind it, and then make sure you can deliver it. If you can deliver the roadmap that, you know, that's almost as good not having one because you can't set expectations, you communicate something's coming, right? And then, obviously, the roadmap tied off and people forget about that it's more than just a product, right? When you go to a market, did it launch, did it get adopted? And what was the... So there's a whole part of getting the product to the market, to the actual hands of user you can create outcome. So this is how responsive PPM come into play. It's taking into all these different pieces and put them together into a framework. And I will just kind of bucketize this sort of pieces that you have a piece, think about outcome. You have a piece, think about the product portfolio roadmaps. There's a planning, there's a delivery. So when you put all these pieces together, that's where your... By the way, everyone's doing it. It's just doing in different places, right? Hopefully, we'll all do that today already. And then this, when you put this all the pieces together, the product managers and product function, product teams and product organisation, and the companies that rely on product, which I guess, almost every company, right? That's how they can operate effectively to do what they need to do. The product team's only job. There's only one job per product team, right, which is to deliver the outcome, business outcome and the customer outcome, right? Deliver the outcome faster so that the company can stay ahead. Your customer's delighted and everyone's happy.

  - Becky, that's so good to see. And it makes sense. I think there's many elements of that, you know, that where product management incorporates all of this. Even talking about, you know, doing this in our own lives. When I'm thinking about going away on holiday, I'm thinking about, "Well, can I do these things? Can I afford to do them? Do we have enough time to do them?" You know, I'm really passionate that I create my own personal roadmap. And we talked about that before we started recording as well. All of these things are so important to consider. And I think is, historically, why a single-page roadmap has often tripped people up because they've not thought of all of these things. That's why, you know, Phil and myself and many others are passionate about roadmapping. But what this is taking is, this is formalising it into your responsive product and portfolio framework. And I think a good roadmap has to be grounded in reality based on these other things being done. Otherwise, like you said, it's just a wishlist, and there's no reality that we're going to deliver it. And you mentioned actually earlier about Dragonboat's templates. So thank you for making those available to people. Again, for the audience, we'll make sure they're in the video description. And for those listening along on the podcast, we have a blog. So please go to talkingroadmaps.com, have a look at Becky's episode with us, and we'll provide some resources there for you as well. But Becky, that really crystallised those things for me. Thank you for kind of letting us step back and understand your world a bit better. I'd love to come and just talk a few good and bads here. And we can talk about maybe, typically, best practises in roadmapping, but it can be in product, product and portfolio management as well. But what do you think some of the best practises are?

  - Right. Well, I think there are probably a lot of many different situations. So I wanna kind of take a step back. I wanna talk about the product as a function and a product organisation as a whole first, then we can talk about product management. 'Cause I think when you don't have a good backdrop of things, then the context's not there, right? So I'm a person that naturally more curious about things. So I always try to figure out, analyse the data and differences, right? And one of the things I tried to figure out was, I noticed there, you know, in Silicon Valley, there are a lot of companies here. There are product managers considered bad product managers, not a good product manager in a company. And they go to another company, they thrive. They are just the superstars, right? And then I take step back to say, "Wait a minute." There are people moving from Yahoo to Google to like, Facebook. They were like, "What happened to these companies?" Like, "What happened to Yahoo?" You know, "Such an iconic brand. What happened?" Like, they don't have good product managers? They don't have good engineers? Don't have good marketers? That's wrong, right? All of them are wrong. So you think about it's really is this. First of all, are there the environment for them to be successful? And that's really what really led to some of the earlier discussions and the formation of responsive product portfolio management is that there's a very famous memo, if you search it, it's called a peanut butter strategy, right? At Yahoo actually, they said a while back. What they said is they don't have a strategy, they have a goal. The goal is, you know, grow revenue or something like. Everyone has the same goal. Like, every company has same goal, right? Grow revenue and reduce costs and so on. But what is the strategy? Who you are? So the first thing I would say is, it permeates everywhere. When you don't have a strategy or if you peanut butter your strategy, means you're not doing portfolio management in real to say, "What is our hypothesis? How we wanna get there? And then where are we gonna mobilise and change or shift our investment," then you don't have a good roadmap. Not a portfolio roadmap, but definitely not have a team roadmap, because you cannot be successful when you don't have the bigger backdrop. So the first part, I think for the product organisation is to not take a hard look at where we wanna be in terms of... Obviously, there's financial goals. There has to be strategic goals. The strategic goals would dictate how you are going to allocate your resources and allocate your product investment. And that strategic goal also dictate how your product team is going to prioritise things. So product manager cannot prioritise without understanding a broader strategy. So this is something where I would say there is something people... You know, everyone knows, right? There are different scoring systems, you know, RICE, and all that stuff. They all mean nothing, absolutely nothing, because rise against what? It's the same as the feature roadmap. It's just, it means nothing to the strategy and goals. And that's where you have a true portfolio management really to say, you know, how does the strategy dictate the allocation. And these two things will drive your, quote, unquote, RICE score, 'cause you have to prioritise within it. That's the response to PPM, right? You have to prioritise it within your dimension. There's many different dimension. So good roadmap is goals and strategy allocation, guide prioritisation. Bad roadmap, there's no strategy or peanut butter strategy. Therefore, everyone just goes through the motions. And people, not that people don't wanna change. People cannot change because you didn't have that overall view. Product managers are powerless. So Marty Cagan, obviously, the SVPG, they have this whole empowered product teams, right? People always ask you, empower product team. And you cannot be empowered. So in Dragonboat, we do a CPO series. So we bring in world-class CPOs coming to talk to, you know, our customer, our community. And one of them is Scott, he was a former CPO at the GitLab. And one thing he said is, "The product managers cannot be empowered if there are dependencies." Because if you rely someone else to do, to achieve your roadmap and your goals, you don't have control. You're not empowered, right? So that's like, that's more than just remove tactic. That's how you also at a portfolio level, make sure you have that alignment and the support, right? So that's the second part, meaning you cannot be good product manager, or you cannot be empowered, enabled to be a good product manager when you don't have a way to have a cross-team support. Like, the stat says 92% of teams rely on other teams. So if you don't have a way to enable them, you have a better roadmap because you have a roadmap you can deliver. More than 80% of teams cannot deliver what they committed. There are multiple reasons to it. One of them is because they have cross-team dependencies. There are obviously other things that we can also talk about. Another part of the good roadmap and bad roadmap. If you have a roadmap you can't deliver, it's just as bad as you can. Create a roadmap. You tell me, "I'm gonna be there," you're not gonna be there, and that's the worst than you don't tell me, right? So the inability to deliver roadmaps, one of the biggest thing 'cause people don't trust you. When people don't trust you, like, we have so many companies that I worked with in the past, our customers we worked with in the past used to say, you know, we plan our, you know, marketing launches to six months after, 'cause we just so used to the delay, I don't trust what they say. You don't wanna ever be in that situation, right? As the product manager, you have to be able to say, "I have a roadmap. I will be able to deliver it." And that means a number of things, right? One is you have to have a roadmap that has some understanding of the things you have to critically deliver versus things you will be stretch goal. You have to understand your resourcing needs so that you make sure you can deliver. You have to understand your cross-functional needs to make sure other teams support your roadmap. And you also need to make sure, and that's something where the agile and product management has a little bit of conflicts to work through, which is tension or conflict, right? Once things go to agile team, they break your features, epics, into stories. Oh, you thought it's gonna be two week, it turn out to be six months, right? And how do you manage that? Product managers don't wanna be project managers and they're not built and trained for it. But then, because of that, they have to do project management because if you can deliver, it doesn't matter. So that's the third part of that is to say, how can I create a roadmap that is a deliver, can be delivered. And because we, you know, agile doesn't have as much of a time commitment, business does, customer does, your stakeholders, go-to-market team need. So that's the third part, is that when you create a roadmap you cannot deliver. The fourth part, I wanna say good and bad is, can you adjust when things happen? So the parting words, I know we're coming out upon time, it's such a rich conversation. I can talk about this for forever, right? Can forever. But you really think about is that what is a good roadmap. A good roadmap is to be able to say, "We're building towards the goals, we have a strategy." And then the second part is that deliver customers outcome along the way. And the third one is, it's something I can deliver. And the fourth one is, we can actually measure it and then make adjustment. If I achieve the goals I need to achieve, I don't need to continuously invest in resources. If I didn't achieve the goal I wanna achieve, I need to shift other things coming over. So, you know, sort of like overall to call out, right, responsive to product portfolio management is not against a roadmap. It is something you need to create a good roadmap that reflects strategy, reflect outcome, talk to different stakeholders on different things, and can be delivered, and you can just drive the outcome. Because in the end, it's not about producing roadmap, it's about producing outcomes, right? And keep your customers, keep your stakeholders, customers, internal, external, aligned and informed.

  - Becky, that was absolutely phenomenal. Picks, bits that I'm picking up, multi-dimensional prioritisation, because just a framework at one level doesn't mean you are prioritising against strategy. We need to make sure our roadmaps are trustable and anchored in reality. Maybe with some critical deliveries or high integrity commitments, but some latitude to be flexible. And yeah, definitely about those commitments as well. Becky, that's phenomenal. I want to give you an opportunity just to let our audience know how they can find you and get in contact with you. And whether, in fact, even if Dragonboat are hiring, how can people get in contact with you there as well?

  - Thanks, Justin. So, you can find me on LinkedIn, Becky Flint. And you know, we are on, you know, at dragonboat.io, we do a lot of webinars, we have a lot of content there as well. So if you have any questions, just reach out to me on LinkedIn. Always happy and excited to talk to product teams, product professionals. This is something I've been doing pretty much my whole career in different roles. And then now we have more focus on product operations and product leaders. But obviously, everyone in product is a product leader, 'cause you are leading a team.

  - Becky, it's been wonderful speaking to you. Thank you so much for everything you've done for the community, sharing your incredible experiences with us so that we can all learn together. And yeah, we'd love to have you on the channel again sometime, 'cause I know that this is, we've barely unpacked what we could talk about. Just for the audience, thank you very much for listening. Becky has shared so many value bombs there. Please do like and share it with your audience, with your colleagues if there's something that you found that resonated with you, and we look forward to seeing you on the next one. Becky, thanks so much again.

  - Thank you, Justin.