Is a roadmap a plan of record? | Harry Max

In episode 38 of Talking Roadmaps, Phil Hornby interviews Harry Max, discussing the purpose and nature of roadmaps in product management. Harry shares insights from his extensive experience with startups and major companies, emphasizing the importance of adaptability and stakeholder alignment. They explore whether a roadmap should be a fixed plan or a flexible guide, highlighting best practices and common pitfalls in roadmap creation.

Harry is an executive player-coach who works with senior leaders, start-up founders, and technical visionaries to help them realize their visions, build high-performing teams, and zero in on solutions to complex challenges. A servant-leader, Harry Max has been a founder/CEO, executive, business coach, and/or consultant with start-ups, innovators, and global brands including Adobe, Apple, DreamWorks Animation, Google, Hewlett-Packard, ITHAKA, Microsoft, Normative, PayPal, Rackspace, SGI, Skype, Symantec, and Yotascale. An early pioneer in e-commerce and crowd sourcing, Harry Max was a co-founder of Virtual Vineyards (the original wine.com), where his designs powered the interaction model behind the first usable, on-line shopping cart; and the founder of Public Mind, the first SaaS crowd sourcing platform for harnessing the voice-of-the-customer. Max studied Modern Society and Social Thought at the University of California, Santa Cruz, and lives in Silicon Valley.

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

In the next episode we are talking to Francesca Cortesi, CPO at Hemnet. So watch out for Season 1 - Episode 39!

• Transcript

  - Welcome to "Talking Roadmaps," the channel where we talk about everything roadmapping, the good, the bad, and the ugly. Today I'm joined by Harry Max. Harry, give us an introduction to yourself.

  - Yeah, certainly, so I'm at this point in my career, I'm a Silicon Valley executive player coach, and by that I mean, you know, I typically go in as a fractional executive and actually do executive coaching from within the company, working with one or two or three clients and whatnot. But I've got a long product and design development background. You know, prior to this I was product executive at AllClear ID and at Rackspace. And prior to that, I've held positions at Apple, HP, Dreamworks Animation, and a number of other companies. I've also had my own startup. I've been involved in about a dozen other startups, including Skype. And I love all things product.

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

  - Purpose of a roadmap is to create consensual reality. It's to help people understand what the options are and what the timing is, and what the high level dependencies are for getting something out there in the world.

  - And so that was consensual reality. So that's us all buying into the reality we want to create or the reality that's actually there?

  - Well, it's a little of both, isn't it?

  - Okay, so if we're all buying into this reality, who's that all and who's looking at it? Who's taking part in it? Who's contributing to it?

  - Well, it depends, right? I mean, in a product and design or development environment, you know, there are stakeholders, you know, those people who are either gonna be influenced by or are influencing whatever it is, it's in design or development or exploration, or is in the process of being released. And, you know, so there are internal stakeholders and external stakeholders, internal stakeholders being, you know, people inside the company, partner suppliers, contractors, anybody that's involved in the design, development and sort of production deployment of, you know, whatever products or services are being pushed out. And of course, customers are also interested in these things as well, to the extent that a company is willing to share where it's going and what it's doing and what its intentions are. There are external stakeholders who may be keenly interested in what an organisation is up to.

  - Yeah, in fact, I think I've pretty much always found my customers wanting and needing to see my roadmap, but I've typically been in B2B, and it's kind of that joint journey that we're perhaps going on and trying to see if we are on a common journey I find. We've said there's a reality we're creating, these things on this roadmap. I guess we're doing something to prioritise what's on there. I'm gonna give you out that hook to bring in that slant on prioritisation.

  - Sure, you know, stepping back from it a little bit, you know, while I am in the final throes of writing a book on prioritisation, which is really, it's a holistic look at the topic for organisations, for teams and individual contributors and frontline managers, there's nothing like it on the market today, really is quite surprising actually. But a lot of that fell out of my work in product design and development, and specifically some of the work in trying to produce a complex roadmap and roadmaps in environments that were where there was a lot of volatility or a lot of uncertainty in the environment. It's one of the things that informed the roadmap style that I currently use, which I haven't seen anywhere else. And I call it a Certainties Roadmap. And that roadmap, actually, instead of having one swim lane, which is where everything usually goes, it has three swim lanes. The main swim lane is the swim lane of things that are being committed in a timeframe that would allow you to create consistent, predictable results. But there are also two other swim lanes, and this is a swim lane that includes things that are in design and investigation, and there's a third swim lane for things that are aspirational but can't really be pinned down. And so this gives you a view of reality of not just what's being committed, but also things that are increasingly less certain and increasingly higher risk. And all that relates to prioritisation, of course, because, you know, your priorities really reflect what matters most. And that's typically a result of some fairly complex set of negotiations around what needs to happen and when and what needs to happen in order to make that possible and when things are gonna land and with what certainty.

  - I love that concept of certainties. It kind of overlaps a little bit with some of the conversation with Daniel Elizalde in an earlier episode where he talks about a discovery or an experiment roadmap to kind of help you map out that sounded like that second swim lane of yours, that we might be using to kind of say, well, we're still figuring these things out. We're working on them, but we haven't got to the.

  - That's exactly right.

  - 'Cause as product people we're always trying to make priority calls, right? Some of those priority calls are as simple as yes or no, but then there's that whole grey area between there.

  - I think they, you know, just stepping back from the whole topic for a minute, you know, the best companies in the world prioritise well, right? And they don't necessarily do it efficiently, and it isn't necessarily a not messy process, right? It's often a very messy process. But the best organisations figure out how to get their priorities straight. And that doesn't just mean the projects they're gonna do. It means the hiring that they're gonna be doing. It means the financing they're gonna be doing, it means the risks they're gonna be managing. It means all sorts of things. And it's one of the things that's so interesting about prioritisation is people typically think about it in terms of projects and products and services and the things that are actually gonna, you know, get put into some kind of queue for development. But there are all sorts of other types of things that need to be prioritised. And the best organisations have teams that are effective at prioritising, right? Sometimes those teams are in product and design and development. Sometimes they're in emergency response, sometimes they're in risk management. You never know, right? But the frameworks and methods and criteria they use for prioritising are gonna depend on the environments that they're in. And of course, those teams, the best teams have people and frontline managers who they themselves are good at prioritising, they're good at figuring out what it is they need to be focused on. They need to be good at identifying what matters most, what matters least, how to make trade offs in the middle. And when you put all that together, you end up with a, you know, you end up with quite an effective organisation if you've got all those things working well together.

  - I mean, so Rosemy said, there's a conversation I was having with one of my coachees on the Elizalde day about is she being driven by the urgent over the important, for example, just to kind of, that was the question, the way I phrased it, just to kind of trigger the little bit of challenge about was she working on the right things.

  - Well, I posted on LinkedIn today a framework that John Cutler, Cutlefish at Twitter posted. He's got a sub stack newsletter that I really like, and it was what I can do versus what I should do, right? Somewhat similar to the Eisenhower Matrix that was popularised by Stephen Covey, which is the urgent versus the important, but can versus should, right? In the upper right hand corner, it's things you can and things you should do.

  - Yeah, I mean, that thought of kind of prioritising within another context, I remember coming to the conclusion that I probably should have hired a designer instead of the product manager because that would've given your team overall better leverage and better ability to deliver. And that priority call is one that I kind of reflect on as what I got wrong in the past. And ultimately that feeds into the priorities of the team because they see how you recruit, they see where you spend your time, and that translates to how they're going to make decisions.

  - Well, that's an excellent example because that's about prioritising capability, right? It's not necessarily about prioritising people, right? It's about prioritising capabilities and what those capabilities can mean. And it may mean prioritising the capacity to deliver on those. 'Cause you may have a designer who may not have the capacity to actually deliver, which means you need to hire more. And so thinking about prioritisation from the point of view of what matters most, it then becomes a question of, well, what are your convictions? What are you really trying to accomplish? And how is it that you're gonna approach doing that in a given context in a given timeframe?

  - And I know my cohost, Justin, he's very much a fan of essentially applying roadmapping to many things. Like you roadmap your team, you roadmap your career, you roadmap your life. And that, I guess, is a vehicle for communicating those priorities of what's coming first, next, and later. There's other elements that are obviously gonna relate into a roadmap, things like vision, strategy, objectives, and they inform obviously prioritisation as well. So what are your thoughts there?

  - Yeah, I mean, the most important thing is that, you know, when you think about vision, when you think about strategy, when you think about goals and you think about objectives, that's a cascade that goes from a high level of abstraction to a lower level of abstraction. And the way that I think about it is, you know, the vision is often embodied as, you know, some compelling thing that a leader or set of leaders are moving toward, or a set of things a set of leaders are moving away from, right? Some balance between what's away from versus what's toward. And ultimately it's about a compelling vision. And that compelling vision drives a set of convictions, and those convictions really inform what it is they're trying to accomplish and why. And from that, from those convictions, which translate very directly to their priorities at a very high level, what falls out of that is how are you going to accomplish that? And you know, if you think about the definition of strategy as being kind of how you're gonna win, right? Strategy is a direct response to organising resources and capability and capacity and everything that you've got in order to pursue the goals that you have, which represent the priorities at the highest level, which are a reflection of your convictions. And so all of this links together, but the challenge with priorities and one of the very tricky bits about the notion of a priority is that it's like a Russian nesting doll, you know, those nesting dolls, you know, you have one and you pop the top off and you look inside, there's a smaller one, you pop the top off that, there's a smaller one, it's turtles all the way down, right? And so talking about priorities becomes incredibly difficult in the context of an organisation, because if you're not clear about the level of abstraction, it's a lot like use cases, right? Are you talking about a user level use case, Alistair Cockburn style user level use case? Or are you talking about some infinitesimally small thing that needs to happen in order to enable an event deep level inside of an organisation or an application rather. And so the way that I think about it is, you know, if you recognise at the highest possible level that you're translating the vision of possibility to a set of convictions, and you're translating those convictions to a set of high level priorities, and those priorities get represented as goals, and those goals get represented as objectives, and the way that you pursue those goals and those objectives is by overlaying a strategy, which is how you're gonna win.

  - No, I guess guess I couldn't not be talking about priorities and bring maybe some other related artefacts like the backlog and this sort of thing. So how do we bring these things together?

  - Well, it's funny, when I was at Dreamworks, they talk about what's above the line and what's below the line. And at Dreamworks, what they're talking about above the line and below the line, they're talking about management prerogative and about how much control you have in the organisation. It's very little about what the priorities are, but prioritisation is often the same way, right? There's the stuff that's above the cut line and the stuff that's below the cut line, and the stuff that's below the cut line is clearly stuff that you know, where you have insufficient resources to allocate to do those things or to approach those things or to deal with those things. There may be more work that's necessary in order to define even what they are, right? And how you're gonna compare them and figure out what you're gonna do in order, what is the selection criteria to pull those things off? And then there are debates about whether a backlog should be prioritised or whether it should simply be constantly curated in order to make sure that things that no longer belong there should be there at all. And that the prioritisation is done as a dynamic process of pulling the item off the backlog and moving it into the foreground above the line, which is where the actual priorities live. So you know, the priorities, if you will, are, you know, ordered items. And so I think about a non prioritised thing, if you will, is an item. And so once you have an item that has been adequately evaluated and you've figured out what the criteria are for ranking it against other things, whether you're doing something as sophisticated as the Analytical Hierarchical Process, AHP, or whether you're doing something as simple as a stack ranking, right? Getting an ordered list of things and then knowing that you've got resources that you can allocate to accomplish those things in some reasonable sequence becomes what's above the line. Everything else is below the line.

  - Just to make sure I'm clear. So the above the line is what's visible and what's actually happening, whereas the below line is kind of the, almost like the swan's legs, we're working hard, we're figuring things out, and then we see some clarity above. Is that right in understanding?

  - I wish it were that simple. I think it's more multi-dimensional than that because I think even things for which there are resources allocated above the line, there is often stuff that is highly not visible. There's work that's going on, people toiling in the edges of the system, trying to get that work defined well enough and figure out how to get the infrastructure, and not just the technical infrastructure, but cognitive infrastructure and other things necessary in order to figure out how is it all gonna get linked together and how is it all gonna get done? And it gets complicated when you're running against different types of disciplines, right? So you've got risk management and you've got design and you've got, you know, you've got your architecture and you've got your development and you've gotta figure out how all this stuff plays together so that ultimately at some point down the line, a thing pops out and it works.

  - And maybe deliver some value for some customers at the same time. You've mentioned you've got a bit of a design background as well. So let's kind of think a little bit on the design side of things. So you mentioned some elements on a roadmap, you mentioned swim lanes. What do you think are the key elements that we should have on a roadmap when we're displaying it or presenting it?

  - Well, I'll tell you what I do, and I actually have two different types of roadmaps that I use and I use them in conjunction with one another. And so first off, I put roadmaps in a context of a plan of record. And so the roadmap is not just a roadmap, it doesn't stand alone. It sits in a context of a plan of record. And a plan of record has multiple things associated with it, including two distinctly different views of what a roadmap is. The first view of the roadmap is the one that I described earlier, where you've got three different swim lanes, you've got stuff that's with a very high degree of certainty, stuff that's with a degree of certainty and stuff that's with a degree of uncertainty, a high degree of uncertainty, if you will. And therefore, dates typically need to be managed as a function of ranges as opposed to hard dates. That's not entirely definitive, but largely true. You also need to be able to represent level of risk management because things at a high level of risk need to be represented. And this is where it gets a little different because flipping back and forth between the two different versions of the roadmap that I have, one of which I have not described, also whether the thing is what state it's in, and I use, you know, stoplight colours for that. So, you know, red if it's in a, you know, an unhealthy state, and it's pretty much coming to a stop, yellow if we're in a caution state or if flags have been raised and things are in question, but it still appears to be moving forward, and green if it's as expected. Also has something slipped? So if something has slipped from one previous or changed state rather, but typically slipped is the most common state change where you would have an item that was green, for example, go in yellow, that means it's shifting and it may shift in terms of its timeline as well. And so if for example, something looked like it was gonna ship on a particular date, it's changed colour and now it looks like it's gonna take a little bit more time representing that that shift has happened so that somebody in one view can see that something's changed state, see that the commitment in terms of when we think it's gonna hit has changed and understand potentially where its certainty level has changed as well. Because something may have gone from being a high degree of certainty, somebody may have discovered something, it may have moved into a cautionary state, it may have slipped and it may move to a higher level of uncertainty, right? All those things can be represented on a roadmap and very simply and very visually. So those are typically the types of things and a clear indicator of what the item is so that they're mutually exclusive and collectively exhaustive, as the folks at McKinsey like to say. That way they're self-evident and you can understand what they are by looking at them and they're not coded in some way that people can't figure them out. And then whether there are any relative categories. So there may be, you know, different categories that need to be represented. So, you know, in one of my roadmap views, you know, I'll actually list, you know, is this product design and development or is this a security and privacy issue, or is this an actual, you know, IT or infrastructure deployment related, or is this, you know, experimental kind of activity? So to the extent that those things can be well represented and done so in a simple way makes it extremely easy for people to have very sensible conversations about them, the investment that's going into them, the development work that's going into them, and kind of what state things are in, you know, day in and day out.

  - Best practise in roadmapping, what's your thoughts on that, what is it?

  - Thinking about best practise in roadmapping to me starts with a plan of record. And the reason for that as a plan of record is it's an organic document, always changing. It allows the constant conversation and capture of a state of reality at a given moment in time to fuel useful conversations about where things are, where things have been and where things are going. And placing the roadmaps into the context of a plan of record allows those roadmaps to be framed constantly in terms of here's what we're trying to accomplish, these are the goals that we have, right? And these are the principles that we're pursuing. This is the vision that we have, reminding people of the strategy that we're pursuing, and then here's where we are, that's the roadmap view and this is the progress that we're making. And then from there you can even have more detailed, higher resolution pictures of what the state of things actually look like, even if you can't fire up a laptop and pull out some code and start running it right now, right? And that way you've got this spectrum is kind of a, it's almost a two by two of here's where we came from, here's where we are, here's where we're going, and then here's what we said we want, here's where we are and here's how it actually looks today, right? And so you have those two dimensions. And then if you've got a, you know, a single roadmap view that covers these levels of uncertainty that I described, and then move into the one that I haven't shared with you, but I will, which provides a targeting system, and by that I mean, it is a view where the centre of the target is actually today and every concentric ring out is another month. And that way what you have is a quarterly view, and every time somebody sees it, in theory, the things on the outside have moved closer to the things on the inside, right? So something that we said was gonna ship in April, next week, it's a week closer to April, so that item should be a week closer in in this targeting view. And so having this broad view that essentially expresses here's what we ideally would like to have, and then a more granular view about how those changes are taking place moment to moment and whether the status of those items is changing and whether things are slipping. Those are the things that in concert I think provide a very healthy set of best practises for allowing that sense of consensual reality to exist, whether you're talking to an executive or whether you're talking to somebody on the front lines. That's the power of a plan of record, right? It's to be able to share with anybody and capture the kinds of open questions that people have, to be able to make sure that you've got a place to jot down comments and issues that are coming up so that those can be shared. And so that to me is sort of the heart of it, a document that reflects reality, but a multidimensional and much richer reality than a single time-based view of commitments that we hope to be able to make.

  - Love it, I love that kind of almost onion diagram that you described of kind of the different layers and not just going left to right.

  - Yeah, and I think when you see this, you're gonna be, people that start using this are I think getting a lot of power out of it.

  - What's the biggest mistakes or bad practise that you see on roadmaps then?

  - Committing to specific dates I think is top of the list. Not committing to date ranges, I think that's number one. Number two is actually not expressing a degree of confidence in that date or date range, using sort of calibrated estimation from, you know, Doug Hubbard, how to measure anything. Like those would be the top. And then not keeping those documents up to date, however they're represented, whether they're online or whether they're physical. But those three things are at the top of the list because without them, what you've done is you've represented a false reality, right? And that makes it very hard for people to predict what's actually gonna happen and being able to, you know, be the only thing a leader needs is followers who are willing and able to follow and then actually do what they say they're gonna do, right? And if you don't give the leaders the tools that are necessary to do that, and you don't give the followers the tools that are necessary in order to meet those commitments, you've disabled the organisation, right? So why do that? So those are the three things I would put at the top of the list. And I love the subtle edge of false reality. You basically mean they lied to them. It's like you've put a plan out there and you lied to them that of something that's not really gonna happen. Maybe not intentionally trying to mislead people, but it equates to the same reality ultimately.

  - I think unfortunately, at the end of the day, that is what happens. And I think the larger problem is it's not so much about one person, quote unquote, lying to another, it's about somebody deceiving themself. They're pushing forward a reality they wish to be true or they want to be true. They're using wishful thinking rather than reality-based thinking.

  - Yeah, yeah, there's no malice, there's no bad intent, but we're fooling ourselves and then we communicate it out.

  - Yeah, and one of my esteemed colleagues, Paul Henderson, who you would love and should probably have a conversation with about roadmaps, you know, likes to say, you know, look, bad news doesn't get better with time.

  - Yeah, I mean, I forget the rule, the law or something. There's one around about how information gets more positive as it goes up an organisation as well.

  - Yeah, yeah, we talk about that as the square having the edges rounded off all the way up to the top where it becomes a wheel.

  - So we've had some of your advice, Harry, whose advice on roadmapping do you listen to?

  - Wow, that's a great question. I think the first person I would go to, if I had a question, it would be Luke Hohmann. No question whatsoever. I think I've learned more from Luke than any other single person. Probably the second person would be Mark Interrante who was responsible for the, he was the SVP of cloud development at Rackspace when I was there. You know, full disclosure and transparency, he's a good friend of mine. He's been involved, you know, he was at Salesforce, he was at, you know, HP, but he has the most, I think he and Luke together have the most robust understanding of the complexity and the nuance that needs to be either represented or abstract abstracted away in order to present an effective roadmap.

  - Luke's obviously a previous guest, but that other guy I've not come across yet. So might be another conversation to have later. So we've talked about some names of people, what about some resources? There anything that you go to in terms of when you're thinking about roadmapping or even how it relates to prioritisation, kind of where do you look?

  - This is another area where I think you've caught me a bit flatfooted. Instead of giving you a direct answer, what I would say is that I find myself spending more time using Miro and MURAL and some of the virtual, for lack of a better word, the whiteboarding, interactive whiteboarding or collaboration platforms that are out there. Because not only are they incredibly flexible platforms to be able to represent things visually, even though they're not terribly sophisticated from a data point of view, but they also have a lot of templates associated with them. And I wish I could off the top of my head list some of the other platforms that offer up these kind of roadmapping tools and platforms and other types of frameworks that happen to be useful, but they're not coming to mind right now.

  - Big fan of the sort of online whiteboards as well, although I do quite like my real world physical whiteboard as well. Analogue still works really well for me.

  - Yeah, I mean sort of, this isn't really off the record, but I really wish Luke Hohmann had been able to continue the work that he was doing with Weave, the platform that he had developed, I thought was on a trajectory. I know Scaled Agile bought it, and I haven't kept up with it since Scaled Agile purchased it and what they're doing with it, but I think it was trending in a direction because the items in the context of that tool were first class citizens, which meant they carried their data around with them. Unlike the collaboration apps like Miro and MURAL, they're just graphical objects. They're not first class citizens, so you can't, you know, you can't have them maintain their criteria or the attributes or the values and then move them in, you know, from one framework to another.

  - Yeah, I guess that's the stuff that started out as conteur. If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - Prioritise prioritisation, number one. Number two, get comfortable with using a plan of record as the context for delivering roadmaps. And number three, provide different views of that roadmap to help people see what's happening in a more dynamic and more holistic way.

  - What should I have asked you about roadmapping that I haven't?

  - I think it is such a profoundly versatile concept that understanding the different types of roadmaps and how they are represented and how they can be used is, I mean, we touched on this earlier when you talked about roadmapping a career, when you talked about, you know, roadmapping different facets of things that are happening. But I think that is really, you know, figuring out how to place a roadmap in context, because a roadmap is a view of now, it has a frame around it that has, it has a timeframe around it that has some bit of the past, it has some bit of the present and has some bit of the future, but it is in effect an application agnostic tool. And so understanding the different applications, like I would talk about how people can spend more time developing personal development roadmaps for their own careers. And this is not a career roadmap, so to speak. What I mean by that is the knowhow, I separate it into knowhow and dohow, the things you know and things, you know, the intellectual things you're aware of and versus the skills and the things that you're able to express and do with your hands. And I don't think enough people spend enough time thinking about what do they need to know and what skills do they need to have over time? And if you do that with a look, there are set of skills that are personal, adaptive skills like listening or good questioning. There are transferable skills like, you know, basic DC electronics, which you can use in different kinds of environments. And there are domain specific skills like, you know, a particular programming language or whatnot. Like, I think what we could have talked about was how do you apply roadmaps to your personal development and what does that mean in the context of your career and your life? And I think that is a very, very rich area.

  - And I would love to dive, I sometimes ask, what's your answer to that? But that sounds like the answer would probably be a whole other interview.

  - Yeah, and I would need to actually prepare for that because ultimately, you know, when you think about the kind of work that I'm doing now versus the kind of work I did as a product leader, the work I'm doing now is very much helping people design and develop their careers. But these are for very senior people typically. And the results of the work that we're doing, you could think of it as design research where we do all this work upfront, but then ultimately that gets expressed in a roadmap, gets expressed in development plan for them. These are the skills and capabilities that they need to become aware of, they need to learn, they need to develop, they need to practise, they need to get good at, because this is what's gonna allow them to become the people that they want to become and live the kind of lives that they wanna live and participate and contribute at the level that they want to contribute.

  - Harry, been wonderful talking to you today. Just, you know, I'd love to give you the opportunity to make your pitch, how can you help people? How can people get in touch with you? Fire away.

  - Yeah, well, I appreciate that, you know, I'm Harry Max everywhere, right? I'm Harry Max on LinkedIn, I'm Harry Max on Twitter. I'm Harry Max on Gmail. And my personal site right now is Metamax, M-E-T-A-M-A-X.com, so above and beyond Max. And, you know, if you're interested in communicating with me or getting help or just having a conversation about priorities, prioritisation, prioritising, even roadmapping, you know, whether it's for you know, work that you're doing with product design and development or whether it's something that you wanna do for yourself or your career or your professional development, you know, feel free to reach out. LinkedIn's another great way to reach me right now. But always looking for opportunities to contribute in a meaningful way.

  - It's been absolutely wonderful having you here today. Just a reminder for everyone, please do like, subscribe, hit that bell icon, get in touch if you'd like to be on the show. Harry, it's been great having you on the show today. Thanks very much.

  - Thank you.