How is making a roadmap like cooking? | Gabrielle Bufrem

In episode 37 of Talking Roadmaps, Gabrielle Bufrem and Justin Woods discuss the parallels between making a roadmap and cooking, emphasizing the importance of vision, preparation, and adaptation. Gabrielle shares insights on creating strategic roadmaps, the role of product leaders in empowering their teams, and practical tips for managing diverse product teams. Key takeaways include balancing short-term and long-term goals and the significance of iterative processes in product management.

Gabrielle is a product leadership coach. She coaches product leaders and organizations on product vision, product strategy, and on empowering product managers. With experience building and growing teams of both product managers and designers. She has built consumer and enterprise products across 9 verticals, serving customers in North America, Europe, and Asia.

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).

How is making a roadmap like cooking? | Gabrielle Bufrem

Phil Hornby and Gabrielle Bufrem

In the next episode we are talking to Harry Max, Executive Player-Coach. So watch out for Season 1 - Episode 38!

• Transcript

  - Good morning roadmapping fans. Welcome to Talking Roadmaps, the channel where we talk about the good, the bad, and the ugly of roadmapping. Today I'm joined by Gabrielle Bufrem. Gabrielle, please introduce yourself.

  - Awesome, thank you, Phil. Hi, everyone. My name's Gabrielle. I am currently a product leadership coach. I mostly coach founders and product leaders on strategy, hiring, growing, also roadmapping, and everything that their teams need in order to be successful. I'm based in New York, I'm Brazilian, and before this, I was at startups, scaleups, public companies. So I've done nine industries in three continents so far, and it's been really fun.

  - Sounds like a great journey. Did you have a roadmap that helped you go through that?

  - I think it was like kind of an engineered symbiosis thing. I think I said yes to a lot of things. Things came my way and I just took advantage of the opportunities. I'll also say I have a course on building impactful products, which has been really fun too to build out.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. What's the purpose of a roadmap?

  - I would say the purpose of a roadmap is to communicate both to teams and stakeholder what the team is focusing on, why, and most importantly, what outcome the team is trying to achieve.

  - And so you've talked about communicating. That means there's an audience. Who is that audience?

  - So I think we are talking about potentially a quite wide audience. So there is definitely the team. So that by that, I mean product managers, designers, engineers on the team, also product directors, everyone in leadership within the product org. That is one of the audiences. I also think that there is everyone that's cross-functional, that is also a core part of making that product a reality. That is sales, marketing, ops, go-to-market, the founders. Everyone else in the company, basically. And a lot of B2B companies, I would say their customers are another core audience in terms of the roadmap, and even some B2C companies. I've been seeing them sharing their roadmap out, which is pretty fun. And I'd say each different audience needs a different level of communication. It's... I mean, I think product people are like translators. They understand what needs to be said and how to say it in all the different languages that people speak. So for the team, it's much more detailed, much more clear. For the company, it's what's relevant to them. They don't need all that detail, all that kind of nuance. And for customers, it's whatever is actually able to be shared publicly.

  - Funnily enough, I was having a conversation with someone in the US only just before we came on this call and I said, "Product managers are Babel fishes." And he said, "Yes, but Americans don't get that reference." It's from a book, a very British book. And a Babel fishes is something you're putting in your ear and can translate from one language to another. And I think product management can be that Babel fish for the organisation sometimes.

  - Absolutely, yeah. You're like the glue between everyone because your job is to understand the business, understand what needs to be done for the business. And in order to do that, you need to speak everyone's languages. And you need to also be telling what's in it for them. Like, when you're presenting a roadmap, there will be things that will be in and things that will be out. And you need to have an explanation on why you're doing one thing versus another. And there will definitely be stakeholders that won't agree. And it's also your role to explain why.

  - Oh, I love that point. There'll be stakeholders that won't agree. I feel like going off piece, Gabrielle. How do you deal with that?

  - I would say, it's interesting. So I used to think when I got into product years ago that I was gonna be building stuff like, "Oh, my job is to go build things." And actually, the job of a product manager or a product leader even more so, I mean, if you don't like that, then like don't go into leadership because that's all you do, is should say no to people. It should be like, "No, we can't do this," "No, we can't do that," "No, we won't do that," without having people hate you. And it's like a tricky row. You need to be respected. Sometimes you're not liked. That's totally okay. But you can't be hated 'cause you do need to work with these people. So one of my, I think I have two core tips for people to do stakeholder management pretty well. I've worked at like some pretty strong like B2B companies where like that was a lot of my job. And the first tip that I would have is that you need to understand what they care about and you need to position things in the way that makes sense for them. It kind of goes back to being that translator but it takes it a step further and understanding what they care about. Like, what is in it for them, and everything I present is about what's in it for them. It's not about what's in it for me or the team, it's about what's in it for them. And then the second one is something that apparently came from like some sort of a like world conflict and it was used by I think like Clinton administration in like resolving piece in like the Middle East. I mean, I don't think we're there yet, but I think they made like huge strides, right? And the name of the technique is shadow diplomacy, and it's all about having 101s before you have meetings. So, the meeting becomes more of a formality. So I'd say like anyone that has had a like, "Oh, here's our quarter, here's what we're gonna do," meeting with everyone together, like, that thing has such a high likelihood of being a disaster that it's like no joke 'cause you have marketing being like, "Well, I didn't get this in," and ops being like, "I thought we were gonna solve some internal stuff," and then engineering is like, "Wait, where's like the tech debt that we promised we were gonna pay?" Right? And it just becomes like this convoluted meeting. So, in order for that not to happen, you should have a meeting with each interested and important party, explain it to them first, and then have the meeting all together in order to present it to everyone.

  - Can't agree more. I think it's even referenced in Roadmaps Relaunched, is that exact technique by Bruce and C. Todd, both previous guests on the show, by the way.

  - Yeah, I love doing that. It also makes people feel happy and important. And they are, but a lot of people don't take the time to do it. And I remember like coaching a report once to do that, and he was like, "Oh, that sounds like a lot of work. I am not gonna do it." And he gave me like this whole explanation on why he wasn't gonna do it, and I was like, "Okay, well, we'll see what happens then." And I remember getting like a phone call. I was at lunch and I got a phone call and he was like, "It was terrible. You were right. I am so upset. How do I fix this?" And I was like, "Oh, it's gonna be expensive to fix, but there's a way."

  - There's the growth mindset that every product manager needs coming in. It's like, "Okay, we tried it, we learned that, maybe should have listened and taken that advice on board." And, right, it's like it probably take, yet it is a lot of work, but it takes more work to fix it later than it would've to get it right up front.

  - A hundred percent, yes. It takes so much more work.

  - I think I go so far as to say, if I don't already know the results of a meeting before I go into it, I failed.

  - Yes, yes. Especially when it is a communication meeting, right? When the entire purpose is to communicate something. If it's like a brainstorm or like all of that, we should not know the result. It's gonna be unfolded there, it's gonna be beautiful and awesome, and we're gonna discover stuff we didn't know. But if you're there to communicate and make sure everyone's on the same page, people should already be on the same page. We should not be relying on like a 20 person meeting to get people there.

  - In fact, I'd go so far as to say, a decision meeting should be the same. And I differentiate, I call those brainstorming ones workshops on purpose to separate the two. So we've got this thing. It's communicating, we're talking to all these different people. Who owns it?

  - Who owns it? I would say the person that is responsible for keeping it up to date, for putting it together, all of that, is the product person on the team. So, that is a product manager, that is like when you're talking about a programme, that's like a product director or a head of product. And then, ultimately, I think it's like on the CPO to ensure that there is coherence and consistency there. I will say there is a super strong difference between having like a good product strategy and having a roadmap, and I see a lot of confliction in the two. They're like, "Oh, we have a strategy. Our roadmap is there." And I'm like, "Wait, that's not the same."

  - That's a perfect segue, Gabrielle, because I was about to ask you how does a roadmap relate to vision and strategy and objectives?

  - I mean, I think the roadmap, to my point earlier, is a communication tool. It's there to communicate with the team's doing, what the team's not doing, what the order of priority is. And when used for that, it's awesome. I think people find tools that they like and try to like add all sorts of things in, and then they become these like Frankenstein tools that are super unhelpful to them, to the product, and to everyone. So I say for me, product vision really paints that picture of where the product goes in like three to five years. I have been recently obsessed with vision types, which is an entire very visual, very concrete way to really show rather than tell what that future looks like. So, I've been working on a few. It's like so, so, so fun. So that's vision. The strategy is how you get there. So like, what are the things you're doing, what are the things you're not doing? What is the beliefs that you have as an organisation that are not only dictated by the market but are also just things that are intrinsic to the company? And that is like truly product strategy. It's like the principles, it's like what you do, what you don't do. And then objectives are basically the problems that the teams are given to solve. They're like, we need to like increase this, we need to reduce that, we need to do whatever, and they are really what drives the business forward.

  - Perfect. And you mentioned product principles in there. I mean, I'm getting a little obsessed with those at the moment, and I think you've recently spent some time with Leah Hickman as well. And hearing a vision type, no big surprise that's, you know, that that's something that's on your agenda. I saw some great ones from her in the past.

  - Yeah, yeah. I love product principles because they actually allow you to multiply decision making within the team. Because if you just look at a principle, and it's like, "We prioritise this over that, and they are as simple as this." Like, job seekers first, like, recruiters will come. That is like an awesome principle for example. And if it's there and you know that you're gonna be making a compromise for recruiters, and that is your principle, you're like, "Okay, well, it seems like it's in that direction." So, I love how easy decisions become when principles are applied effectively.

  - I'm gonna guess from just the example you gave that you were listening in to Mind the Product of Martin Eriksson 'cause I think that's what he said.

  - Yeah, I mean, I love Martin. I think he's so smart, so funny, and he's just like an awesome person in general, so I'm lucky to call him a friend.

  - So, okay. We've talked about the vision, the strategy, objectives, which maybe are the big things, above things. Are there any other artefacts that kinda link in or relate to your product roadmap?

  - Other artefacts? I mean, I think that the kind of lower level to a roadmap is a backlog, which is what teams use in order to actually split up the work and built. And by the time something gets to a backlog, it should be pretty clear that that thing is gonna get done. So, I think in the roadmap phase, it's still a little like, oh. Like, anything. I think I wrote about like roadmaps being a gradient and like anything later than like three months from now can change, unless the team has made like a hard commitment to that thing being there. And I've even been in positions where that commitment was made and we learned something new, and changed. But the backlog is very much like a much lower level of, or like higher level of fidelity. Super clear, very broken down.

  - Yeah, you started hinting. I'm now remembering the conversation we had on LinkedIn. So, yeah, it was that visualisation, I think, of going from really quite solid to a gradient of almost unreadable. So maybe you can tell me about your thoughts around visualising a roadmap.

  - Yeah. I mean, I really like, again, to use it as like a very good communication tool and I like to use it wherever it's needed. I don't believe in like process for process-sake or tool for tool-sake. Like, I am a just in time process kind of person. I'm like, do the least possible to communicate and to be clear. And I mean, the best ones that I've ever made were so simple. I made them in like Miro, or they were like sticky notes behind their team when we were like still in the office. And people knew. They were like, "Oh, clear." They're doing these four things this quarter. And whenever something would change, I would tell people, like, "Hey, this changed," "This is why we moved something here because it's more important."

  - I mean, personally, it's usually always ended up in PowerPoint but it's usually distributed teams and so it's like, I mean, we ended up on all sorts of things pre-SharePoint days and this sort of thing as well. I remember having... I don't even remember what tools we used to share the files on, but we were trying to do portfolio level. It was one platform but there were so many different parts to the platform and how do we interrelate those. Like, all can get quite messy quite quickly I find. So that's super simple. Definitely appeals as a way of focusing on the communication as you've said.

  - Yeah, yeah. And again, like, knowing what it's for. Like, roadmaps are great to communicate. They're not your strategy, they're not all the research that you're doing. Like, you're not putting all of that there. You're saying like, "Our team's committed to solving this outcome, here's what we care about." And I've even seen it go as far as like, "Here's the stuff we're gonna be trying, and then like here was the winner." Like, "Here's what really worked and here's why." And those are actually like really fun for the teams to do, they're fun for other people to see, and they're clear on how the outcome connects to the business goal and how it connects to the experiments, and then ultimately, to what the team decides to build.

  - So, okay, we're visualising or giving that kind of gradient element, but what's actually on the roadmap? What's the content of this thing?

  - Yeah, so I think the best roadmaps have outcomes, like, things that the team wants to achieve. So, I've even seen it be, and the way I like it, I tell people like, "Hey, our team cares about this objective, this is like the one thing that is important to us right now and here are like three outcomes that we have, through research, identified that if we achieve this, we're gonna be moving the needle. So here's the stuff we're gonna be doing." So I'd say outcomes over outputs a hundred percent, especially at that level of communication because that allows the team to be creative and allows the team to solve problems and not be given just like features or things to build, which I think is a huge anti-pattern.

  - But when you're communicating to the customers, are those outcomes at a customer level, are they something that's safe to communicate to them, or do we need to show some features there?

  - I think if you're actually publishing your roadmap to customers, you wanna go deeper into what these things might be. But I would only do that if I'm like 90% sure. If I'm so sure because what you don't wanna do is break trust with customers. So we can be much more exploratory and experimental internally. And I managed to convince people in like marketing and ops that like we might change our minds, and it's not because we're crazy or we're like uncommitted or whatever, it's because we learned something better. But if you promise something to a customer and you attach a date to it, you're gonna... Like, that thing needs to be there. Otherwise, you really broke trust, and I feel like that's like even more the case on a B2B customer or if you're building B2B product. So, I like the idea of the transparency but I'm also like, a lot of really good companies don't do it. So, I think there's like really some value there and I think each company needs to decide what level of exposure they wanna have to commitments that they're making.

  - Ah, so we're doing the... We're playing the consultant card, it depends.

  - I mean, I don't think it's a consultant card. I think it's a product card. Like, I've never been able to say immediately. Like, people come to me with all these stuff. They're like, "Oh, yeah, in this situation, what would you do?" And I was like, "Honestly, it depends. Like, what are you trying to optimise for? Like, do you want predictability and do you want like that? You're giving up innovation. Like, what is more important to you? If innovation's more important, don't publish your roadmap. If commitment and predictability is more important, maybe publish it." So, I think that it depends is everywhere

  - And I just felt a principle coming through again, it's like innovation over predictability, perhaps.

  - A hundred percent. Yeah, yeah. And I'd say like the best companies are innovative. Like, and if they're not innovating, they're like at a huge chance of being disrupted. Like, I was hanging out with like a bunch of coaches last week, and we were talking about how like banks are finally scared of stripe. They're like finally scared that they're gonna get disrupted, even though they're huge organisations, right? And maybe they're like, "Oh my god, now we really need to innovate." Like, there's like some real push for that, and maybe that principle will change. And I've seen principle change as companies grow, and I think it's super normal.

  - We've talked a bit about visualisation design on the roadmap. Now let's go on to good and bad practise. What for you is best practise when it comes to roadmapping?

  - Best practise when it comes to roadmapping. It should use it what it's supposed to be. It's a communication tool. Use it as a way to display what your team is focused on, what it's working on, and do the bare minimum. And I don't mean that in like, meaning to be lazy, at all. I'm saying do the bare minimum process in order to get your point across. So if that is like a Miro board with some stickies and your organisation understands, great. Don't try to like move to like fancier and fancier tools, just like focus on what works. I'd say that is the best practise for me. I'd also say the best roadmap for me are outcome-driven. So they talk about what we're achieving. They don't necessarily talk about what we're building or the outputs. 'Cause, honestly, by the time I'm making these, I don't know what we're gonna be building. Like, I'm not sure. I know that we have a problem in retention or I know that we have a problem in monetization, and then we need to move those metrics, but I can't tell you exactly what we need to build. And even if I could for like six months from now, that might change, and I don't wanna commit to something or even spend all this effort upfront trying to define something that wouldn't be able to be defined this early on.

  - But you did mention tools there, so do you have a preferred tool for capturing your roadmap?

  - I think I mentioned my preferred one. And like I will sound super simple but like I like the easiest thing possible, so I'm like I love sticky notes, I have a sticky note collection just like any product person should, I have all sorts of like forms and shapes and whatever. Amazing. Yes. Exactly. Always in hands. Sharpies, all of it. And I would say that is my preferred. Since we moved from that to the online world, I'd say either like a slide that is super clear and I've had to put those together to like the board and whatever, all of it, or like Miro mural. I think anything else becomes like really confusing and complex. I'd say there are some that are like better than others. Some force you to put a date on everything. I hate those. Like, I am never gonna use you. It's terrible. I don't wanna like institute like bad practise or keep reminding people that report to me that they shouldn't, that they're putting a date but it's just so that the box will move. That's horrible. Yeah. And I think that there's some that are bad like the... I think ProdPad has like a now, next, later roadmap. I think that's like very nice. And if a team needs that level of detail, that can be super helpful.

  - So I think you've started probably hinting at it, but what are the biggest mistakes you see when people are road roadmapping?

  - I think like one is like adding everything under the sun to like a roadmap. It's like, "Oh, like, now we did some tech that, now we did whatever," and it's like becomes such a long thing that no one's ever gonna read. That is a really big one. I'd say the other and like potentially the biggest sin ever in roadmapping is adding dates and commitments without the team being a hundred percent okay with that. I'd say like, we live in like this world, we have business requirements, we have objectives, we have like stuff we need to hit, so like dates are necessary for things. And for certain things, they're necessary. And I think we call those like high integrity commitments or like super strong commitments that the team's making. If your team is making that commitment and that's going on the roadmap and that's gonna be displayed to everyone, you need to do feasibility prototypes, which means engineers on the team should devote a few hours, maybe a day or two understanding the tech, understanding how hard it is to do this in order to actually give an estimate. Otherwise, they can't, no. Like, they're incredible people. I just wrote on Twitter yesterday about like how the best ideas that I've gotten and that I've shipped come from engineers on my team, and that's because they're able to explore and they're able to like actually play with the tech. If they can't and they're just like pressured, and normally they're told by someone that this is due this date. That's horrible. Like, that would be I think my biggest thing, is like adding a date without true buy-in from the team.

  - Yeah, I mean, I'm a former engineer, and one of the mistakes that people make is to think that the word engineer comes from an engine, which actually comes from the French of engigneor. Ingenious. That creative thought process to kind of bring those great ideas to us. So, absolutely agree.

  - Totally agree. And I'd say one more even is, and I think we kind of hinted at this in some earlier questions, but it's thinking that if you have a roadmap, you have a product strategy. It's like, no, you are telling people what you're gonna do, and that is very valuable on its own and super helpful, but that's not a vision, that's not product principles, that's not where you're gonna say yes to or no to, that doesn't give your team topology, direction, any of that. It also is not what your business objective. So, I think the conflation of roadmaps with strategy is the other really big sin.

  - Yeah, that sounds like you'd call that an antipattern almost. It's rising to that level. Now, you mentioned team topology in that. I don't think that's something that's come up before in conversations on the channel. So, maybe you could unpack a little bit. What do you mean by team topology?

  - Yeah, totally. I think... So there is a book called "Team Topologies." I think it's like written for the DevOps stage, or space, and it's really good. It really talks way more about like DevOps than product, but I think there's like core learnings there. I'd say team topologies for me is how you divide your teams. So that is truly a product leadership role, is to figure out like, are we gonna have like a growth team, a monetization team? Are we gonna do like buyers and sellers? Like, how are we structuring this team in order to reduce dependencies? But let's be real, we live in a world where dependencies are present, and the larger companies get, the more complex they get. And also allow teams to be autonomous, contribute to the business goals, and also feel empowered to solve the problems that they need to solve.

  - Yeah, I think if I remember right, there's a common pattern around experience teams and platform teams in there as well. You talked about the buyer, the seller, you might have an internally focused experience team.

  - Totally. They might do like identity. Like, I ran a platform team before, and it was like super interesting because it was all the things that were shared across everyone, talk about stakeholder management there. But it's really around like that core experience that the user is having, and then experience teams deliver on the different kind of slices of that experience that sit on top of it.

  - You know, the interesting thing, I saw a cartoon the other day, and I forget the name of the law that this is, this some sort of law of organisational design that says, "However you structure your team is how your technical architecture will end up being." And so then you suddenly realise, so that means that my HR team are actually my system architects.

  - Yeah, I mean, I think that, like, it's not on HR to like decide these things. Like, they can have ideas, but it's truly on like the product leader and the engineering leader. I'd say the engineering leader even more because they are really signing up for that level of architecture, and it impacts the product people, it can be like really frustrating and annoying, and to redefine that topology is like a painful, lengthy process that causes a water friction and change. But I'd say like if an engineering leader tells me like, Hey, I wanna follow this pattern, this is why, here are my arguments on how this is gonna allow us to write code faster and in a better way," I'll most likely side with them.

  - I guess you are talking about code faster, I'm thinking drive better customer outcomes maybe as well though.

  - I mean, so I think that that's like a awesome distinction to make. So, the first one is like, teams need to be shipping more faster, and that is completely separate from like shipping value But if they don't ship fast, they will never be able to get to value. So it's almost like a precursor. And then, of course, everything that you should be building and everything that you should not be building should be with the intention of providing the most value for your customer, ideally, in the simplest way possible because I'd say any feature you're building is future tech debt that you're signing up for. So, if anyone's gonna think about a cost of doing anything, think about the tech debt because that is real, and the maintenance and like all of the things that are the hidden costs of actually building something.

  - I remember having many build-buy partner discussions with my team in the past, and engineers just tend to wanna build stuff 'cause that's what they do. And then you are thinking about all that long-term maintenance and I'm building it once for this special case when I can probably have 90% of this off the shelf, integrate it tomorrow, ship faster, and the team can focus on the real value that we add, not that boilerplate stuff.

  - Yeah, yeah. So, like, I think a good example is like, if you're gonna build like a scheduling system. Like, probably you're not gonna build that from scratch. Or payments. Like, you're not gonna build that from scratch. You should focus on like your secret sauce and the thing people are actually paying you for. Focus your engineering effort there. That is normally my recommendation.

  - So, Gabrielle, we've heard some of your advice on roadmapping. Whose advice do you listen to?

  - I would say like Marty Cagan is my like idol slash, like, has been a mentor for years, and I really, really love everything that he says. And he does really hold that opinion that roadmap is a communication tool. So I'd say he is one that I really listen to. Let me see. I really love, like Christina Wodtke from, and she talks about like setting goals. I think she wrote like the best OKR book there is. It's so, so good, so, so clear, and I feel like that's a direct precursor to actually building really good features and really good products. So, yeah, I think it's a hard question to answer, actually, because in order to build a good roadmap, it's almost like there's a concept in French cooking that chefs adopted all around the world called the mise en place. And it's like you are kind of preparing every single ingredient before you have to put it together. And I feel like the roadmap is putting it together. You already did so much of the work, it's so there, and you invested hours, days, like, months in doing that, and then you put that dish together and you present it. So I think that my list would have to be so long because it involves like everyone else that's talking about those aspects of preparation in order to make it so that whenever you get that dish, it's like beautiful, well presented, delicious and perfect.

  - I love that metaphor of mise en place leading to cooking up the roadmap to then communicate out.

  - Yes, exactly. Yeah. And it's also the way I think about just product in general. It's like you do all these things that everyone that doesn't understand product thinks is magic. They're like, "Oh, wow, an insight magic." And I'm like, "No, no, no. That was like hours of time into people until we found this like one little thing." And the part of the beauty is that it does feel and look like magic, especially when like design, product engineering all work together.

  - If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - Roadmaps are a communication tool. They show what your team is solving, and by default, what your team is not solving.

  - Is there anything else about roadmapping that I should have asked you that I haven't?

  - That's like one of the best user interview questions ever, by the way, because like everyone.. I always am surprised and it takes me in like a completely new direction, so I've learned to add like 10 minutes after that question because who knows what thing I could've missed. But honestly, I think that you covered, like, everything from, like, tools to purpose to empty patterns. I would say the only thing I would add is like, make sure you know what it's for and use it for what it's for. And there is this tendency of like falling in love with a thing or falling in love with a tool and using it for things that it's not. And I think this is true to roadmaps, and it's true to like everything else in product, and maybe in life as well. We wanna get like really philosophical here.

  - So, Gabrielle, we're coming towards the close. What I'd love to do is just, yeah, give you a chance to pitch yourself, pitch your services, how people get in touch with you.

  - Yeah, absolutely. So I am a product leadership coach. I mostly coach product leaders and sometimes their product teams on how to build products that actually matter, that make customers fall in love, and that also help the business achieve real results. So that's what I do most of the time. I also run a course on Maven called Building Impactful Products. And you can find me on Twitter. It's gbufremsays. And you can find me on LinkedIn, Gabrielle Bufrem. And you can also find me on my website, gabriellebufrem.com.

  - We'll make sure there's some links down below for you so that people can find you. So, Gabrielle, really need to just thank you for your time today. Thank you for your insights, your thoughts. It is been a great chat. Some great insights. We've gone off on a couple of random alleys which I've loved.

  - Amazing. Yeah, me too. This was so fun. Yeah, and it was awesome to hang out with you, Phil. Thank you so much for having me.

  - If you'd like to sit where Gabrielle is and take part in the conversation, reach out either in the comments, direct messaging, or just info@talkingroadmaps.com. We'd love to have you here and have a chat with you. Gabrielle, thanks very much.

  - Thank you so much, Phil. Bye, everyone.