Who is the roadmap for? | Hope Gurion

In episode 28 of Talking Roadmaps, Phil Hornby interviews Hope Gurion, founder of Fearless Product. They discuss the purpose of a roadmap, the importance of continuous discovery in product management, and how Hope coaches first-time product leaders to make outcome-driven, customer-centric decisions. Hope also shares insights from her collaboration with Teresa Torres and her podcast "Fearless Product Leadership."

Hope has over 20 years of product management and leadership experience, leading product, design and analytics teams. She founded Fearless Product LLC to serve leaders and teams at companies seeking growth through product innovation.  She specializes in coaching product teams and new product leaders to accelerate their confidence and competence in practicing outcome-driven, customer-centric, discovery-led product decisions.  Her “Fearless Product Leadership” podcast series helps new product leaders learn from experienced peers how they tackle some of their most challenging responsibilities. Hope has led and coached over 50 B2B and B2C product teams in start-up, growth, and mature stage companies.  Prior to Fearless Product, Hope was CPO at CareerBuilder and SVP, Product Management at Beachbody.

“Who’s it for? What questions are we trying to answer?”

— Hope Gurion

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

Who is the roadmap for? | Hope Gurion

Phil Hornby and Hope Gurion

In the next episode we are talking to Pamela Schure who is a Product Management Consultant, Coach and Author. So watch out for Season 1 - Episode 29!

• Transcript

  - Welcome to "Talking Roadmaps," the channel where we talk about the good, the bad, the ugly, everything about roadmapping. As with any YouTube channel, please do like, subscribe, hit that bell icon and maybe share it with some of your friends so that they can all hear what we're talking about. Today, I'm really pleased to be joined by Hope Gurion. Hope, introduce yourself.

  - Well, it's a pleasure to be here, Phil. I am Hope Gurion, as you said. I have a little tiny company in the product space called Fearless Product. I'm a former chief product officer, and I spend time coaching products leaders, usually first time product leaders. I also partnered with Teresa Torres of Product Talk, and she and I teach teams how to have continuous discovery as a key part of their product practise. I also have a little podcast called "Fearless Product Leadership."

  - Wonderful having you here. I'm gonna start with the softball first question then. What's the purpose of a roadmap?

  - You know, it's a great question, and when I am coaching new product leaders, and they often ask that question, "Hey, I think I have to do a roadmap," or, "I need your help in coming up with the roadmap." My first question back to them is, "Why do you need a roadmap?" And then they're, it's funny, I had a product leader not too long ago was like, "Well, isn't that my job? Like isn't that what I'm supposed to?" Literally, he was like, "I thought that was my like number one job responsibility was to create the roadmap." And once we start diving in, like did somebody ask you to create a roadmap, like is your CEO, is it your sales team? Is it your support team? Is it other members within the product organisation? Like who is asking for a roadmap? Is it yourself? Is it somebody else? Then we can actually start to answer that question because the reason why that's a solution, right? We need a roadmap. The opportunity or the unmet need that the roadmap is meant to address can vary widely depending on who's asking. So I think that's an important thing that any product leader needs to ask before they just dive in and start creating one.

  - Totally agree, but then, so maybe you can unpack a few of the answers you've received to the why then.

  - The first is because we need to know if we can commit to a certain thing in a customer contract that we feel is completely dependent on our committal to deliver that thing. And so that can be more of a sales, it could be a sales rep, it could be a sales leader, but this desire to basically unblock a potential sale, potential agreement to be able to say that is what's coming on the roadmap. The second reason is for internal planning. Often the marketing team, we have a communications plan that we want to be able to meet, and we wanna have fresh information to populate the content of that communications plan. And so if you tell us what's coming up on the roadmap, we know when we're gonna time those communications and what we're going to say so we can plan our internal work. Third variation on that is the support team. We wanna be ready to support whatever these new capabilities are, and so we wanna be able to work backwards from that release date so that on day one, we can, you know, have everybody trained and know what to say and what's going to, you know, how we need to get everybody ready for supporting the customer inquiries or being proactive about providing training. Fourth reason might be because, I dunno, the CEO expects it or the board expects it, and we wanna be able to show that artefact in an upcoming meeting. Maybe it's to investors, maybe it's at a company all hands, whatever it is. Like we wanna be able to show that and give this illusion of certainty that this is what you can count on expecting. And then maybe the fifth reason is this sort of like accountability weapon, which is you said you were gonna do this thing and when you don't do it, you're going to hold that against you. So I don't know if that's exactly the top five, and maybe the other is, aren't I just supposed to do the roadmap? Isn't that my job? That might be the other underlying reason.

  - Interesting. You didn't mention the development organisation in that alignment side as well.

  - Yeah, I haven't found that to be as much of an issue.

  - I mean, I think, I kind of cast out, I have four or five different groups. You just added two more, so I think I've just hit six, seven, because I have three external groups, but yeah, interesting.

  - Yeah, and maybe let me unpack the development organisation. It's not to say that it doesn't happen, but here's a couple of reasons why it might happen. If the development organisation is project oriented, and again, I try my hardest to work with development teams and organisations that are empowered, dedicated, durable teams. So that's not always the case. They are usually trying to in, you know, sort of like almost real time or just slightly ahead of those projects becoming reality, shifting that fungible pool of resources to adhere to the roadmap. And I would also say in those organisations, these attributes tend to go hand in hand. Often the developers have no say in what they're worked on. So like they don't necessarily need to know because somebody's just going to tell them, this is the project that was green lit, and you're gonna go do it. So in empowered, durable teams, they know that the what's gonna go on the roadmap is completely fluid, and it doesn't matter if there's an artefact that's communicated out. So I just don't often see them as being the what's on the roadmap. Maybe their leadership for resource allocation and org planning of project teams. But that's different than I think the larger development organisation.

  - I can follow that logic and understand why. I guess, they're either involved in it, or they think it's irrelevant, or they're just order takers. Like if I unpack that. Yeah, interesting. So again, we've kind of kind of merged to my question. off next, ask who's the audience? Well, we've just answered the audience, so that's great. Well, who owns it and who maintains it then?

  - Typically it's the product team. And this is again where that like who's it for? What questions are we trying to answer? How much fidelity and when is like you have to answer those questions first, otherwise like, I don't know who's maintaining it, right? And what's the horizon for it? And so one thing that I'll say is that the what we're gonna work on this quarter is a reasonable expectation for people to have, right? Like we do need to get the support team trained and ready and know why and who we should communicate this to, who's been waiting for this to happen. If there is a sale or a contract that could benefit or be signed because we have now a reasonable set of certainty that we are going to in fact be able to deliver some incremental value that could tip somebody over to signing an agreement or preventing churn because this is a need that they've wanted solved for a while, absolutely. And so you wanna be able to at least communicate what's coming up in the next, and usually I'm gonna say quarter, that's usually when we have reasonable certainty about what solutions are going to be solved in the next few months. Beyond that, I'm not sure there's much reason. If anything you might be communicating, these are some of the next problems or needs or desires that we think will be relevant to our customers, but we have no detail on what those solutions might look like. So we're not going to communicate anything. But if people can see that stated as a customer's unmet need, pain point or desire or, 'cause I work with Teresa, an opportunity, that is something that is helpful for people to have a little bit of a further out view on, but they can't then start communicating what the solution is. And I think that's the risk. When you start to communicate, any three to five words on a Gantt chart that supposedly describes the solution, wow, like that is just opening the floodgates for misinterpretation, making it up, what I think it's going to be, and then creating a lot of consternation and turmoil around, oh, I thought it was gonna do this, but it's not that at all. Whereas if we can align on what problems we wanna solve later, then we can start talking about the relative importance of solving one problem over another and what incremental value that might create.

  - This is always one of the areas where I struggle on the shorter term like quarters because I've done a lot of work in working in the physical product space, and it's gonna take two years to deliver the physical product thing that solves the problem sometime. So how does that kind of align with that thought process?

  - Yeah, so, and I've done some work with teams that have either long sort of regulatory approval processes or they know it's gonna be like a slow march to try to actually get something adopted or rolled out or it's some sort of hardware, software. So I can appreciate the lead times might be different. Most of the teams that I'm working with, it's purely digital or software experience. And so that's where we don't need to, but if you have longer lead times, and it really, again, this is where it's like, what needs to happen in those two years? Is it purely go to market, education and training, or is it long development cycles because of manufacturing or other distribution? Then you might need to have some more certainty. But again, you're going to be saying, well two years from now is when we expect it to go to market. If you have reasonable certainty about those timelines, then again, it's in the short term, what do we think is going to be getting ready for that sort of go to market manufacturing distribution? And again, that's usually in the near term, even if impact to customers might be in the longer term.

  - Okay, so let's step up a level maybe. So we've got this roadmap thing, in fact, you did hint a little bit, if it needs to be created or maintained. I'm gonna come back to that one later though. Assuming we've got one, how does it relate to vision, strategy, objectives? How do they link in?

  - So this is, again, I see these patterns of symptoms going together. Usually the teams, and I work with a number of product leaders. One of the other things I didn't mention I do is I work with a lot of very experienced senior product leaders. I moderate a council for collaborative gain, and we almost never talk about the roadmap. And the reason I think is, is because usually when people are fixated on what does the roadmap look like or what does it contain, it's because they have not aligned on vision, strategy, outcomes, objectives. And they're using this artefact as a substitute for having made those hard decisions. And so that is where I believe it is much more beneficial, if you're gonna invest your time in anything, that, like what is the vision, why, like what is the strategy, what is the diagnosis? And this is where discovery is, of course, a key component to that, right? How do you diagnose both the opportunity in the market, the opportunity with your customers, your competitive advantage, your core competencies, your coordinated actions, like all of that strategy and aligning on that cross-functionally with your leadership team, marketing, sales, support, other exec, finance. If you don't have that clear, and you've been able to articulate it in terms of measurable goals, who cares what's on your roadmap? And so that is much more important and a better use of time for the leaders, including the product leader, including the technology leader to be clear on, because then the roadmap is just one of those coordinated actions, and it's something that can actually give a preview of how we intend to solve for those opportunities in usually short term, and again, those other objectives, those other diagnoses in our strategy might be further out opportunities that we might communicate. This might be in the next column or the later column of when we would tackle those.

  - As you talked about kind of going beyond for next quarter, you talked about kind of putting the problems on there. So what are your thoughts about roadmapping your discovery efforts as opposed to your delivery efforts?

  - Maybe you're saying the same thing, but let's see. What we, and, of course, totally biassed, we use the opportunity solution tree because that has a view into what customers unmet needs, pain, pain points, desires we might solve in the future. They're all evidence-based. They came from real customer observations, interviews, evidence, and they ladder up to a desired outcome that is derived from our company's business outcome, but grounded in our customer's behaviour, the change that we need our customers to do in order to achieve that business outcome. And so when we talk about other opportunities that we might solve in the future, we have an artefact that can help us communicate that. And it's called an opportunity solution tree. It's not called a roadmap. You could call it a roadmap, but it includes a mix of things that we might do, problems we might solve, needs we might address, as well as ones that we may never address. And so you have to understand that this is a living document and that understanding has to be in the minds of the recipient, viewer, you know, audience of that. And you have to basically set that expectation before anybody sees it so that they don't assume that that means this is all the things we're gonna solve, and it doesn't have timelines on it, and they haven't usually been sized yet. Those that usually comes as we're making progress. So it doesn't have the same impact, that sort of negative downside of communicating a roadmap, which often creates this false sense of certainty or false sense of timing. But it does give a view into what we might need to address in order to drive towards that outcome as a product team.

  - So I'm a big fan of the opportunity solution tree. I kind of experimented with, okay, rolling up the opportunities that I've prioritised onto a roadmap while still maintain the broader artefact to give that fuller context, almost like a drill down, which is something I think could work.

  - The thing that's missing on a lot of roadmaps, right? What is the objectives? I mean, most roadmaps are what and when, right? And so this is where the why, what is the outcome that we're trying to achieve, what will that lead to as a business for our company is just not part of most example roadmaps that people create. And I think that is the most important thing to have alignment on, not the what and the when.

  - You've gotta have the vision, you've gotta have the outcomes that we're driving towards, and then the sequencing flows from it, or at least the best guess of sequencing to do, which is, you know, probably the reality of it. But I'm gonna kinda, I'm gonna come back to that hanging thread now of, if they need to create it and maintain it. So that almost hinted at, do we need one?

  - Do we need one? That's what I'm going to ask, right? So when any type a product leader says, "Ah, I have to get a roadmap!" Every time I produce a roadmap, people are dissatisfied. I feel like I'm constantly trying new formats. And again, it's usually because we haven't really distilled down the questions for whom that we're trying to answer. And often, and I'm sure you've talked about this, it's different questions for different audiences. So how can one artefact, so usually you're gonna create multiple views of that. I'll give you an example. Like the marketing team, marketing team I've found can be a great ally to avoid this, I don't know, belief that we have to create an artefact of a roadmap that also goes beyond a quarter, right? So marketing teams often are, they've got customer events they're trying to plan, right? And they have to plan those events usually farther in advance in person, you know, conferences, what's gonna be our talk track? They have to start nurturing, you know, relationships with the press and teasing things that they believe will lead to meaningful stories and articles about them, right? So like the marketing team does need this as much as the sales team, but the marketing team, usually if you talk to them and you say, so you want to have new information to share, we could share, hey, we plan to solve this problem in the future. Maybe that would be a newsworthy story. But a good marketing person, a good communications person would be like, I can't get anybody interested in problems we might solve in the future. What's really newsworthy is, if we've in fact solved those problems. We have referenceable customers, we've got testimonials, we've got data, we've got case studies, we've got things that like show and demonstrate and prove, that we have solved something so important for our customers better than their alternatives, better than the competitors. That's what we wanna know. And so what I instead do is say, let's talk about what problems we're solving and why and which customers are in our pilot groups and how we're gonna measure success, and let's plan for, we're gonna be able to use that as the content of our marketing. Those are the people we're gonna showcase in whatever customer event or conference or communication that we're gonna do in the future. And if you can get the marketing team on your side as a product leader to say those are gonna be the anchors that we're gonna communicate out, way better for the sales team too, right? Like sales team, it's nice, it gives them maybe some certainty if they haven't been burned by this many times of things not happening as they expect or when they expect, but smart salespeople who've been down that road know better. So rather than say, okay, it's gonna come on, you know, September 15th, but if we can say, you know, maybe it didn't happen on September 15th, but in October, we've got four reference customers. Each recorded a video explaining why this has changed their lives. They've given this testimonial, here's the data about how it worked for them. Now that really can turn into, not just maybe winning one customer who was waiting for that feature, but unlocking many, many new customers who would benefit in the same way that those referenced customers were able to. So that's how I try to shift the conversation away from the roadmap to what do we want to communicate to whom and why is that impactful?

  - Totally makes sense. What else kind of links in and that kind of occupies the same space?

  - I mean, again, this is where like, we do need to make sure that the team, not only understands what matters to customers and why that is potentially gonna drive value for the company, and that's all the things that we consider discovery, they also need to build solutions that meaningfully deliver on those needs and drive value for the company. And so there isn't a reason for the rest of the company to know what the product team is working on and why, because we need to be able to quickly convert that into that value that we aspire. And that comes from sales, it comes from marketing, it comes from support. But usually we don't need to communicate that far in advance, right? What we need to communicate is, when we are ready to take action on it or when we have more certainty about the fact that it will in fact deliver meaningful value, solve the problems for our customers, then we wanna make sure that people are aligned and ready to absorb that information and turn it into that value creation. So what I find is most teams, if they set, and the cadence could vary within a company, depending on, you know, your cycle times, quarterly tends to work for most people, but maybe it needs to be semi-quarterly, right? Every six weeks or so, that we can share, this is what we released, this is who it's valuable to, this is how we know it's worked, this is what we expect to release in the next quarter, six week cycle, here's who's gonna benefit from it and why. We usually have prototypes, we've done some sort of testing around that. We have a sense that this will in fact work, and we've got visuals and stories to make it easy to remember, right? When we just show a roadmap with like three to five words describing a feature with a date, a month usually, it doesn't help people retain the information. When people can see this is the customers, this is what they're doing today, this is how they've said it's problematic for them, this is how we've imagined we're gonna solve it, this is the reaction of customers to how we're gonna solve it, this is when we expect to release it, then people remember it, they retain the information, and they can immediately see how to create value from it. And so that's why I want my, well, when I was a product leader and the teams that I coach, I want them to put their energy towards that sort of storytelling and communication versus spending a lot of cycle time and iterations on a roadmap artefact.

  - Yeah, I guess it depends what's on the roadmap artefact, which I guess kind of brings me to my next question quite nicely. If we've got a roadmap, what are we putting on it? What are the key elements on it?

  - The why, the goal, this is our business objective for the year or for the quarter, right? We wanna be sure that we're always aligning it back to what matters to the company. For many companies, that's some sort of derivative of a revenue, an input into the revenue formula, right? We're gonna increase our win rate of prospective customers, or we're going to increase contract value, or we're gonna increase by upsell or initial contract value. Like whatever that clear input into the revenue formula is, is usually the business outcome. That could be cost avoidance or something else on more the internal efficiency side, but mostly people want customer-facing value, which tends to align to revenue. Or we're gonna do something to reduce churn or increase our retention rate. And that's the way we're gonna extend the lifetime value of our customers. So there's usually that why at the business level, what are the outcomes associated with different product teams. And again, if you have a multi-team product org, which again, the larger the sales organisation, usually the larger the product portfolio and number of product teams. So we wanna be clear that these product teams are working on these outcomes towards this strategic business objective, usually the lagging financial indicator, and then this is the opportunity that they're planning to solve this quarter, right? In the voice of the customer so people can remember it and retain it. And then if they have something to share, this is the prototype that seems to be doing the best or here's a working version of it, maybe it's not in production, maybe it's in test. You wanna create these visuals to show people what they are. So again, that's off the roadmap artefact, but more likely to be retained and more likely to be useful to the audience. So again, it follows that opportunity solution tree structure, but it's filtered for the opportunities that are being solved in the near term, which is usually within that quarter.

  - Is that one page, five pages?

  - Depends on the number of teams, right? It depends on the number of teams, right? Like you could have that tree structure work its way down, but most people, then it becomes useless. I don't actually know what it is. This is why I usually couple it with a ritual of let's talk about what's coming up this quarter. And each team, they link back to the why, and let's tell you who this matters to, why it matters to them. Maybe they've got videos of customers or testimonials explaining the problem. Here's how we're planning to solve it. And if they've been able to do their assumption testing, they see how well it's performing to solve that problem or versus the customer's alternatives, then they're able to show that as well. So again, it's not just the artefact. It's got to be this ritual and communication and visuals that help people see what's coming so they can retain it, and they can create value from it.

  - And do you have any preferred tools for doing this in?

  - No, I don't. Most people, you know, if they're doing a presentation, they're taking screenshots out of whatever whiteboarding tool that they like, or they're, you know, using good old PowerPoint or Google Slides.

  - It is the most common one. So, okay, now let's dive into the good and the bad side of things then. So if we take a roadmap, what is best practise when it comes to a roadmap or roadmapping.

  - Best practises, why do you need it, who is it for, what question is it trying to answer? And get clear on that. Because I see a lot of leaders and teams struggle with this. I hear this question a lot. I feel like I'm constantly being asked what is the product team working on and why? And that, you know, somebody in, again, depending on the size of the organisation, you know, a new hire in the support team can't tell us what's on the roadmap. And I have to ask, why is that the goal? I get that it creates friction. I get that it's, you know, annoying maybe that that person in support doesn't know what's on the roadmap. But I actually think it is more symptomatic of a culture that values trying to create shared understanding at every part of the organisation. Nobody in the organisation ever has perfect understanding of what anybody else in the organisation is working on. So why are we trying to solve that problem? Instead, maybe we need a policy or a principle that says the roadmap, if we're gonna communicate anything to you, it is going to be the things that we have certainty about that you can immediately take action on and create value for so that we drive to meeting our company's objectives for the year, and if you're curious, then we're gonna have rituals, like a quarterly product review that tells you this is what the product team is working on, this is what value they recently created and who benefited from it, and here's the problems they're solving next for whom and why that matters to the company, why that's gonna drive the outcomes. And if you don't want to attend that ritual, or you forget what was in that ritual, you can come to the next one. But we cannot solve for internal shared understanding for every single person for that level of detail 'cause we will move too slowly. We won't make progress on the things that actually will drive the business forward.

  - Best practise is, I guess, if I simplify that, to keep it short and what we are absolutely sure on, if we need it at all. What's bad practise or an anti-pattern?

  - I think the most common anti-pattern is just feeling that you need to produce this artefact that has these, you know, three to five word descriptions of a feature and a timeline, you know, Q1, Q2, Q3, month one, September, October, November, whatever level of granularity we have on the dates, and believing that that will, in fact, address your audience's questions. I think that's the biggest anti-pattern.

  - Have some thoughts from yourself. Who do you listen to though on the subject of roadmapping? Any one's advice you kind of hear and listen and take heed of?

  - I mean, I've heard lots of people talk about roadmaps, and I feel like, maybe it's totally self-selection, but like the ones that I listen to are like Marty Kagan, and you had Rich Mironov, and, you know, Teresa and I talk about this quite a bit, that it is not really the most important thing for a product team to worry about and spend their time on. It's low incremental value and usually creates more confusion than it helps. And so again, I think if you can distil down to what are you trying to understand, who is trying to understand that, and what's the best way to communicate that in a way that is sustainable for the product team or the product leader to communicate to that audience, then you've got a winning formula.

  - Have to be honest, I don't remember roadmapping being a big activity in my product life. It was like once a quarter, I'm gonna spend a couple of hours updating where our current thinking is and share it for alignment purposes. I hear some people talking about it being something that like is their main job all week, every week. It's like why are you doing the real work?

  - That's the worry. And I think if you can time box it and make it something that's easily shared, here, let me just thin slice what's in our opportunity solution tree right now. And this is what is gonna create value in the near term, and here's how you can benefit from it, that usually answers the question with more meaningful information and makes it more actionable for people.

  - Now normally, this is where I'd return to asking about any hanging themes, but I think I've done them already as we've gone through. So I'm gonna give you the hardball question, the one of the first of the two. So if you had to distil your philosophy on roadmapping, which I guess you kind of done, but maybe you'll get it nice and short from that into one or two sentences, what is it?

  - I don't think you need one, but I do think you need to communicate what the outcome is that you're trying to achieve for your company, who's problems you're trying to solve or who's desires you're trying to solve, what those desires are, what those unmet needs are, and demonstrate the evidence that you have in fact a plan to solve those needs, not just a plan, evidence, assumption test results that you have in fact solved those needs and that the solution is imminent, and here's how you can create value from it. And so that is, I think, what you can do. And if an artefact like a roadmap helps you do so, then absolutely you should use one. But I found that most teams can do that without the roadmap artefact.

  - And so then my last hardball question, what haven't I asked you about roadmap that I should have?

  - I can't think of anything, I don't know. I feel like we've covered a lot about roadmaps, so I can't think of one right now.

  - So then maybe I'll switch in the softer ball version then of can you tell me a war story of something go went wrong on a roadmap for you in the past?

  - I guess more so than the roadmap, I've had people, more of my war stories have to do with people selling things that weren't on a roadmap. It's not like they sort of pre-sold what was coming soon and misinterpreted it, just sold things that hadn't even been contemplated, and then all of a sudden, we are now having to pivot to deliver a special for one customer, and also not wanting to stop the progress on all the other expectations for what the teams would be working on. And so again, not exactly a roadmap, but it essentially created the need to have this conversation about, let's like really look at the organisation and everything that they're working on, and how do you propose that we're going to do this now that you've signed the contract? And that essentially created, that was a good lesson learned for our CEO, our sales teams, and we were able to avoid that happening in the future because we couldn't sell things that didn't exist in the product organisation. And so that was, I guess, an accident, an unfortunate war story that turned into a really good policy that helped us be able to drive value by not getting distracted by a commitment that one person, even the CEO, made.

  - Well, I'm amazed you managed to wrangle that agreement. In too many organisations, especially in B2B organisations, getting to that agreement, it takes a lot of effort. I have got there, but it wasn't just the one time before we got there.

  - Yeah, no, well, I mean, it could have been a slippery slope, but when the CEO himself was the one who made the commitment and then had the realisation, it became a very easy policy to put in place. Not always easy for the sales team, but a necessary constraint, let's call it that.

  - Hope is been absolutely wonderful talking today. I've had a really interesting conversation, and as much as I love roadmaps, I'm not gonna fall out with you for saying that we don't need them.

  - There's no one way to do product.

  - Indeed, in fact, I'm a true believer in that there is no one way. It's all contextual, and therefore we have to find what fits in where we are, how we're doing it. So, Hope, really appreciate having you here. Just as always, shout out to everyone. Please do like, subscribe, hit the bell icon. If you'd like to sit where Hope is and have a chat with us, do get in touch either in the comments below or by email on info at talkingroadmaps.com. We'd love to talk to you. Hope, thanks for your time today.

  - Thank you, felt great, it was fun.