How grounded should your roadmap be? | Simon Witkiss
In episode 6 of Talking Roadmaps, join Justin Woods as he interviews Simon Witkiss. Simon shares his extensive experience in product management, emphasizing the importance of creating a grounded roadmap. He discusses maintaining ownership, regularity in the process, and the necessity of a strong framework to drive growth. Discover how a well-crafted roadmap can align your team and propel your company's vision forward.
Simon is the Global Head of Product & Marketing at TrustQuay, and a superstar product person with tonnes of experience. He tends to work for scale-ups in the financial services space where roadmapping is a key tool helping them deliver growth as a team.
“A roadmap that isn’t grounded in your ability to execute is a house of cards”
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).
The next episode will return to talking to thought leaders. We are super luck to have the epic Rich Mironov, the CPO smoke jumper, coming in Episode 7, so watch out for the next episode!
-
Hi, I am Justin and I'm one of the co-hosts of Talking Roadmaps Channel, the channel on YouTube where we talk everything roadmaps from people, best practises, some of the thought leaders in the space, and we have some awesome guests on the channel as well. If that sounds good to you, please feel free to subscribe to the channel hit if you like some of the things that our guest speakers are saying or you've got some questions, feel free to drop those down in the comments. And if you'd like to get in touch because you want to take part, please just reach out to us below and we'll reach out to you and get you on the channel as well. But talking about getting people on the channel today, I'm really excited to welcome Mr. Simon Witkis. Simon, welcome to you.
Thank you. Thank you for having me, Justin. It's great to be here.
So Simon, you've got an extensive career in product management, an enviable career in product management. You've been working in product probably for the most of your career in product roles most recently, a couple of decades of product leadership roles as well, and for some well-known brands as well as your own product consultancy. So I'm expecting some great thoughts around road mapping from you and really excited to hear what your views are. So tell us a little bit about your most present role, if you would.
Sure. And well, thanks for the intro. It's amazing what you can put on a LinkedIn profile to make. Yeah, so currently I head up product and marketing at a company called Trust and it's a B2B business in a specialised industry. And that's probably the key thing for this discussion today is a lot of my career has been in those B2B specialist businesses quite often in scale up mode as well. And I think that's important to say because I think when we talk about roadmaps, when we talk about product roles for 10 product role descriptions, there are 10 different types out there. So yeah, that's my particular expertise. And as you say, yeah, unfortunately it is now decades plural that I've been in this business,
But phenomenal to see the industry change, to see the product management techniques change and probably even road mapping change as well. I mean it is just accelerated so quickly.
Yeah, I completely agree actually. And I think the benefit of nearly 20 years in UK product management I think is, it's just great to have seen the role come from probably what was a niche, possibly unknown role, to actually being the UK catching up and being at the forefront of product management, kind of like the US really. We used to look to the US for our guidance and leadership on product management and road mapping, but now I think we've got a great cohort of product leaders in the UK itself. So yeah, it's great too. I've seen the development of the career and the role over that time.
Yeah, massively. And talking about the development of the role, I understand you've also just done a major launch as well, so congratulations a busy time for you. So we're grateful you've spent some time with the channel, but massive congratulations on that. That's great news.
Yeah, thank you very much. I think product launches are always kind of a milestone. I always like to think is as a product person, one of the things, best things we get to do is look back on our career and our CV and look at those launches and those big events. So hopefully another successful one to add to the career list. But as ever, as we all know, product launches now is when the hard work really kicks in.
Yeah, absolutely. And obviously those product roadmaps, product launches will be on a roadmap, which is of course a really nice segue to the purpose of the channel. So I wonder if we might start a little bit with, in your mind, what would you say is the purpose of a roadmap? And that's an intentionally wide question.
Yeah, that's a very wide question. And I think in that there are so many, there's probably hours and hours of content. I think firstly the clue is in the name, it is a roadmap. So it is a journey, it's a description of a journey at the very highest level. And I think that for me is the interesting thing because it is a description of a journey. So you kind of have to have in mind a destination. And I think that's important. So for me, a roadmap, much like when you are physically adding to a destination, you're going to stick the, well, no longer do we have atlases and roadmaps, we do now have sat now, but you stick your destination in and it tells you how to get there. And for me that is what a roadmap is about. Ultimately, I think often where we get into difficulties with roadmaps is then there's all these secondary purposes that roadmaps serve and different stakeholders have those different purposes, but I think at the highest level it's all about getting yourself to that destination where you want to head to.
Yeah, I think that's a great summary and of course a great analogy back to a physical roadmap as well. So it makes sense to me. I wonder if roadmap is quite prescriptive sometimes we talk about a roadmap often gives you every direction that you need to take. And actually part of road roadmapping is we almost at some point go into the unknown, don't we? So it's almost like we know where the destination is, we might understand the first roads to get there. And then with the nature of business and who could have seen things like the pandemic coming, there almost needs to be a little bit of ambiguity there so that we don't specify exactly how we're going to get there.
And I think that's where concepts like North Star helps. It's about directionally how you get there, not necessarily prescribing which specific roads you take. And that's where I think a lot of the conversation is around outcomes rather than the specifics. I think that's really important. There are various frameworks around road mapping and things like that, but I think a lot of what they have in common is just trying to connect the dots from that ultimate vision through to actually how you execute. Because also we talk about those secondary purposes of roadmaps, they are a guide to how you execute to that destination. So yeah, I think as long as you focus on the outcomes, focus on your North Star, a roadmap should actually be able to cater for a huge amount of challenges. If anything, actually when you are faced with those challenges, the roadmap should be the first thing that helps you rather than being a hindrance, it should be the thing you go to actually help you guide you through your next big business challenge.
I think that those three points that you've made there around the North Star, the outcomes and those other purposes love the concept of joining the dots as well because sometimes it's not a clear line and we kind of have to put those points of where we want to get to and sometimes it might not be so clear. In fact, I'd love to come on to North Star and outcomes a bit later there, but talk to me maybe a little bit around the audience of a roadmap then. So we mentioned North Star, so potentially there's quite a lot of strategic information in there. In your mind, who are the audiences of these roadmaps?
Anyone and everyone really. And I think that is, and that is often the challenge we find as product managers because not only is the audience pretty much anyone you can think of connected with your business, but also what they perceive to be a roadmap is different. So I think ultimately your roadmap does need to cater to them. We talk about stakeholders and for me as much as a roadmap is a thing, an artefact, it is also, it has to be a process. It also has to have engagement, collaboration, it needs to be a continual thing. It's almost road mapping as an activity rather than a noun. And it has to be something that you do engage your entire audience. So it's your leadership and your senior leadership for them the roadmap is as much about showing how you feel you're going to help reach that corporate strategy and deliver on that vision.
But also it is going to be your engineers and your developers who want to know that their day-to-day work is contributing to the vision and back to that, connecting the dots and also then many others within your business. But then also maybe the slightly controversial topic of your customers as well. And that's often an interesting topic. Do you share roadmaps with customers? Whoever you are, you're going to have to share a vision. I think depending on your business, you may or may not need to share a roadmap. I work in a business where we are B2B and some of our customers are big businesses, some are small. I'm lucky to operate with a range. But yeah, there comes a time when I do have to show a roadmap. So thinking about the needs of those different stakeholders is absolutely crucial and what they want to get out of it as well.
Yeah, absolutely. Talking about the, it serves so many different purposes. There's a lot of different audiences there. It's expectation management, it's almost a sales tool in some ways of that external roadmap that you were saying about having a trusted version that you can share. It does so many of those purposes. That's a great answer.
And I think to that point though, no one single document does that and that's where I think it is important. It's a process because if you think you're creating one roadmap that serves your management team, that serves your engineering team particularly when ultimately you have to deliver on it that also serves your customers, that's when you're going to start getting in trouble.
Yeah, that's right. It's not just a single page in a PowerPoint and then a tick in the box that you've done it. I love you are saying that road mapping is an activity rather than just even, I mean it is an artefact in itself, but there is so much more around it there. It's a great way of thinking about it. And so who do you think owns a roadmap? This is quite a widespread document or process or activity? Who owns the roadmap in your mind?
That's a really great question and I guess being a politician, I'm going to answer the question I want to answer because actually another question. Yeah, I think if you talk about who owns the roadmap, that's difficult. I like to think product management is the guardians of the roadmap. Certainly we're on the hook to do a lot of the activity associated with that process, but ultimately all the stakeholders have to feel a degree of ownership. I think that's important because as soon as somebody doesn't feel ownership, then they don't start to feel the buy-in the alignment. So it's not an easy thing to do, but trying to have everyone feel like they own it, have a bit of skin in the game is important. So yeah, I like to think of it as the product, people being the guardians, guardians of the roadmap and ultimately the people that do have to just put the blood, sweat and tears into creating those artefacts and going through the roadmap process.
It's a great way of looking at it. I love the specific word that you chose around guardians because I think that's important. It can be used as a sword and a shield, the roadmap to protect what you're doing or try and go after something new. And also there has to be a level of governance and just robustness around that process because if we did everything that if everyone in the company wanted, we may well just decentralise everything we're trying to do. We want to make sure that we are heading towards that north star that you mentioned as well. Yeah,
I think you're absolutely right because in the life of a product manager you are saying no more often than you say. Yes, that's an inevitability. And I think it's important throughout this that we have processes that even though we're saying no, people feel like they're being listened to and whether that's at the day-to-day release and sprint process or whether it's at the road mapping process, you've got an ability kind of get people to still buy in even though you're saying no. And I think also when you highlight about everyone wanting different things, I think there's another important aspect of a roadmap is it serves as corporate memory because all too often you generate a roadmap and it's about your long-term vision, but the next day you head into a sales conversation or you talk to your support team or any host of a number of the usual day-to-day conversations a product manager has.
And all of a sudden these short-term things come up, which always then seem like the next big thing, the burning issue that needs to be solved. And if you don't have that long-term memory of your roadmap to remind you what you're doing and why you're doing it, it's actually all too easy to all of a sudden lose a lot of your strategic ability into those short-term tactical things. Not necessarily the wrong thing to do, but equally it's important that the roadmap again serves the purpose of reminding you why you're doing it. It gives you the ability to make active choices should you want to change for those short-term decisions.
Such a great answer, just thinking about it, especially when you said serves as corporate memory and that really resonates with me, especially when leadership changes might come in in a couple of years and they want to push a strategic direction that actually we've done in the past and we want to be able to show the learnings from that or the rationale why we didn't. If we're always creating a forward looking roadmap, we don't always push forward and forget where we've been. So it's not that we don't want to think about the past, but it serves, there's a lot of decisions and key thoughts caught up in that roadmap that can help define where we want to go. That's such a great way of thinking about
That and absolutely right, and a roadmap is never set in stone, and that's where I think it's a process that allows you to set that strategy that how you're going to execute on it. But it is important that it does serve to remind people of the previous data you've created, the previous reasons you've had, that it is perfectly fine to change minds, but importantly, we have that framework around which to change our minds. Change is not a bad thing, change is not to be feared, but importantly change without that framework within which to control and contain it, that's when it becomes chaotic, that's when it becomes inefficient.
Yeah, absolutely. Great. I really sucked into that conversation. That's such a great answer. I'm already
Down the rabbit hole.
Absolutely. And that's quite normal for these types of sessions. It's great to explore how your mind and how you see this. One of the things that you mentioned to me was some of the things like North Star and outcomes and things like that. I'm wondering what you see the relationship of things like that to a roadmap. So do you see a roadmap as being the north star in the outcomes or do you see those as separate things that should live elsewhere but be incorporated into the roadmap? How do you see those different artefacts?
Yeah, I mean that's really interesting and I think you almost can't have one without the other, but I think it is important you can't have one without the other. I have seen companies that in the absence of a corporate strategy, look to their product management team to create a roadmap that dug them out of the hole, but actually that's not going to work because you're just going to spin wheels and you're just going to get frustrated. So yeah, I think you do have to have that vision. I think importantly for me, the roadmap then is about taking that big vision and breaking it down and distilling it into increasingly executable parts. Not unlike what we do with development day to day, right? We're taking big things and breaking them down into atomic units that can be executed within sprints by developers. It's the same thing for a roadmap.
And I think in that perspective that's where the different optics through which to look at the roadmap come through. So I think importantly, you have your vision, you have your north star breaking that down into actually what are the component, what are the component goals of that? What are the component outcomes we want to get to? And then from then you can start to break it down into the what are the themes? Because those goals and outcomes are likely to have multi quarter, multi-year things to them. So you have commonality, you have the themes, and then once you have your themes, you can then start to break them down into things which are probably a little bit more things you can wrap your arms around, understand and ultimately start to size and ultimately start to sense check with your customers, but equally you can just track it back up straight back to that vision.
And I think that's the important thing. And then as you go through that process, you're generating data that then feeds back into the vision and allows you to adapt the vision and it allows you to then understand, well actually the market is telling us this, so therefore does our vision need to change? Now I'm not saying your vision changes every time you do the roadmap process because certainly your roadmap and process should be probably a bit more frequent than maybe your corporate vision. But equally there comes a time when actually the data you've learned from one has to influence the other. And for me, the big thing when I look at roadmaps is I do see them as a spectrum and they have to sit at one end with the big vision and then down to the other end where it's the day-to-day execution.
Brilliant. And two things that really struck me there was again, it's that decomposition that we're familiar with in development of taking functionality and breaking it down smaller is not dissimilar to what we need to do at a higher level just with bigger boulders and bigger rocks that we're actually tackling at that site. Exactly,
Exactly. Justin. And I think that's often sometimes where teams can get a little bit caught up in it. Sometimes road mapping can be scary, but ultimately yeah, we are just decomposing things. It just so happens that they're bigger things. Exactly right.
Yeah, that's it. And critically also the sense that actually from the operational and the work that we're doing, there does need to be a level of bidirectionality there. Often when I speak with people or think about roadmaps, they think it's very prescriptive. This is the roadmap, this is what we're doing or else. And what you've shared there is actually if we want to test and learn with our customers, we should be working with them at the coalface thinking about more what was going on, but feeding that back into the roadmap to validate it at those times. And that's something I think is often quite forgotten.
I totally agree with you and I think so I think two things come from that for me. Firstly, that's where it's important. It's it's a roadmap process. You have to have enough regularity in it such that it becomes a heartbeat because I also think that as we talked earlier, that helps you consume change and it helps you get stakeholder, but when it's a process, it means you can adapt to that. And I think the other aspect to that as well is we shouldn't be fine of the change. I mentioned that earlier, all of my roadmaps, they actually contain the agile manifesto phrase, which is we value adapting to change over following a plan. I think that's really important and that's really important when actually you talk about roadmaps to other people because you can put various phrases on a roadmap such as, don't take this to the bank, don't assign deals based on it.
They're generally ignored. But I like to think that when you just say to people, as a business, we value responding to change as a result of data over following a plan that tends to sit well. And I think for me that is, again, it just comes back to that process. A roadmap is never right. The thing I can say about a roadmap with a hundred percent guarantee is it's not going to be the final answer, and that's where trying to then actually focus your activities on just that continual adaption as the data comes in, that's when you're going to hit a successful roadmap process.
Such a great answer and many great insights I think our audience can take from there as well, as well as myself included, it's the experience that you're bringing to this and the fact that you've been through it many, many times. You've seen it. There's a lot of wisdom in what you've shared there, Simon, so thank you. You talked about some of the bits that you would put on the roadmap, the agile manifesto, the fact that it's part of a process here. What do you feel are some of the key elements or content that you like to see on the roadmap? And obviously you are in the B2B space, so it might be that maybe some dates are more important than B2C. Tell us about what specifically in your industry or in your experience you like to see on those roadmaps.
Yeah, and I think, yeah, so that's an interesting question, right? Dates. I think some sort of time is inevitable because I think if you're not putting some sort of indicator as to time, then you don't actually have a roadmap. You probably just have a pretty diagram, which is ultimately a list. But how you convey those dates I think is important. And I think again, this comes to the stakeholders. So internally we operate on a now, next later basis, those now, next later, they have proximate timeframes and that's as much to educate people that now next later isn't just this month, next month and the month after. It's to kind of say, well, this first chunk is about three months and this next chunk is about six months, and then the following chunk, well, who knows, right? It's nine to 12 months. And that's important because it then allows you to roadmap at a fairly sensible level because you certainly don't want to be doing in your later timeframe the level of detail that you will put into your now bucket.
So you kind of have to figure that out. But then equally, when we, as I mentioned earlier, we have a customer facing roadmap, but we don't put dates on that to be honest. We don't really have dates on our internal roadmap. When my team operate, we do have the super secret internal roadmap where we have some dates, but equally when it goes wider internally, it's that now, next, later. And then when we go to customers instead we change the terminology. So we talk about what's in development, then we talk about what's in planning IE, we're proactively looking to validate. We are proactively looking to generate data that verifies this as the right thing to do. And then finally we've got the under consideration bucket at the end, which I think is just a useful term that allows us to just really paint the uncertainty of that not only in timeframes but also in whether they actually happen at all. And importantly, what we're looking to do there is doing some really high level validation and get some understanding as to whether it's worth in doing the research, the proof of concepts, the prototyping that we might need a D do to understand the value proposition and whether it comes forward on the roadmap. So yeah, ultimately dates they're important, but how you convey them is important. Just to answer the wider question, we kind of got hooked on the dates and what else do I want to see on a roadmap
That may have been me, CD you unfairly, so sorry about that. But as simple as proximity is what I was getting there, which I really like, depending on the audience and the circle of trust that you are giving people an indication of proximity or some form of timeframe, but still not making sure that we're held down to key data, which I think was great. Sorry Simon, you were going to say some of the other things
Were important. Yeah, you were saying there about it's proximity and uncertainty and it's allowing people to understand just how likely stuff is to change. If there's something in the now bucket and all of a sudden we do an about turn on it perfectly possible if this happened before and it will happen again I'm sure, but understandably people might be a little bit more frustrated than if something drops off the later bucket. So I think it also actually guides your stakeholder communication and engagement as well. So yeah, so some of the other stuff I think we talked about the kind of connection to the vision, the goals, the themes, and I think that has to come through in your roadmap because I think it's all well in good talking about that. I think where I have in the past seen teams kind of fail is actually they talk about that, but then the actual roadmap is just ultimately a list that's kind of thrown together and is somehow organised by commonality. I do like to see in the roadmaps and ability to connect that through so that you can see where stuff's coming from and then you can see where it's going because ultimately that's then also going to help your development process. A development process that has that strong link to the vision is always going to be easier than just scattering random stuff into sprint.
Yeah, that's really interesting. And one of the questions I have here, but I think we touched on it, is if you have a preferred way to visualise and style for the roadmap, and I think the now next later really came through in what you were saying there as being something that's served you really well in that area, have you found some tools that are able to help you do that internally? And I know from ProdPad, from Jana, Basto is another tool where she was the inventor of that. Now next later roadmap, have you got internal tools that you use or internal frameworks that you're using to help?
Yeah, so that's an interesting question I've used in the past I've used dha, used ProdPad and there seems to have been a flourish of tools I guess in the market at the moment. It's quite incredible for me. I think when it comes to tools, I think if you can't roadmap well without a tool, you're never going to roadmap well with a tool, a tool is going to make it easier. It is going to help you not have different lists in different places. It's possibly going to help you create the different views for the different stakeholders you need. But I sometimes see teams just sign up to AHA thinking it's going to make them roadmap geniuses, but it never will. And that I think for me comes to the process and the framework. You've got to have that strong framework which is there's prep work that goes into it and there's data collection, there's market validation, then there's a roadmap process and then there's the engagement afterwards and the closing the loop, going back to people who had suggestions and kind of explaining, but then also then effectively teeing up your next roadmap process, trust key.
We generally don't go into a roadmap process with everything done that we wanted. We'll quite often go in and say, we've done this and already in the next one, next quarter we do them quarterly, next quarter we're going to focus on this. And for me it is that process before and after the actual roadmap that's just as important. And for me that's the framework. So tools, big fan of our heart and actually also liking ProdPad as well at the moment. I definitely put my hand up on those. But I do think I'm also a believer that unless you've started and wrangled it in, whether it's Excel or PowerPoint, you've got to be comfortable knowing that your process works before you adapt to it all.
That's right. I mean it's like you said, the discipline of product management, these tools are there to expedite it and arguably it could make bad roadmap being quicker. One of the things that I think
You're absolutely right there because these tools all have the ability to publish your roadmap or email your roadmap and who thinks when they click the publish button in aha that they think, alright, cool, tick the box for stakeholder engagement. And that's the key. You can quickly perpetuate bad habits with tools whilst they seemingly make your life easier.
Someone in my career once told me, and I can't remember who it was to attribute it to them, but a fool with a tool is still a fool. And I just absolutely love that. It's kind of like this, there is no silver bullet, it's not there to replace good discipline, good road mapping, hygiene and processes. It's just a tool that
Made life. Absolutely. And I've kind of maybe gone a bit down on the tool tool in there. I absolutely love that there is a lot of tooling around and I think that goes hand in hand with product management being recognised as a discipline in its own right. But what I've said just goes pretty much every career, every profession, if you don't know how to do it and you just go straight to your tool, it's not going to end well. That's
It. That's it. No, that's superb. So thank you for that. Let's switch gears a little bit then. So let's go into some sort of quicker questions. So I want to talk a little bit about the good and bad of roadmapping and get your thoughts on some of the things that you think are done well and not so done well. What do you consider to be some of the best practises in road mapping? Are there any practise? I think you've shared some of these already, so we might pick up on those of iterative, the fact that it's an activity with one that I really liked what you said. Is there anything you'd add on to that in terms of some good practises road mapping?
Yeah, that's a great question Justin. And trying to think of some new answers actually. I think the first thing is we did talk about it is iterative, so you've got to find the cadence that works for you. We do ours quarterly, so I think that's important. I think the best practise, or equally you could argue it's when it goes bad, is that the roadmap is not my delivery plan. We at trust, we have a very deliberately different delivery plan. We don't connect them too much, don't get me wrong. The process is linked and obviously the delivery plan takes its speed from the roadmap, but you don't simply just turn the page on a roadmap and then there's your delivery plan.
You don't change the title Simon.
Exactly right. Which when roadmaps go badly, that's what happens, right? Because all of a sudden your roadmap starts to become more detailed, it becomes more about the features. And so actually for me, how you might go about this might change. What we do with my team is we just have a deliberately different process for going through our sprints and releases. And for me that ensures, that actually maintains our roadmap focus on the vision, the outcomes, whilst our delivery is then still focused on the, yes, it's focused on outcomes, but also importantly the features and how we're going to execute in a bit more detail.
That's a great practise almost giving yourselves a level of differentiation or separation between two to make sure that we are distinct in those two areas. I think that's a great way of doing it. You
Mentioned, just to pick up a bit more as well in terms of where roadmaps go bad is I think quite often I stakeholders can sometimes see product management and road mapping as a bit of an algorithmic exercise. And I think this is a challenge we've got as an industry is to actually educate people that road mapping is not just a case of just feeding it into our favourite scoring algorithm. Don't get me wrong, the various things like kaino or rice analysis or outcome driven innovation, they're all important. But the other thing where I see roadmaps go wrong personally I've done it myself, is when you just create your formula in Excel and just sort it high score first and bang, there's your roadmap. I think at the end of the day, these are all data points, but product management is a blend of art and science. If it was all about the algorithm and actually we'd be firing teams of product managers and just installing our heart and that's just not the case. So that for me would be the other kind of, I guess anti-pain that I've sometimes seen in the past. And as I say, stick my hand up have sometimes done in the past,
It's where I've started too. And you said about an art and the science and that was kind of the saying that was running through my mind as you were going that, so I'm really glad you said that because I think it's true. It's not something that we can replace with a single formula. There has to be a balance there as well. So thank you for sharing that. I guess just to conclude that section, do you have a pet hate that you hate to see on a roadmap? Something you really dislike seeing?
That's a really good question. Probably my pet hate is seeing a roadmap with a date but without an expiry date. And that to me is my pet hate because I think the date a roadmap is created is virtually useless for me. What I want to see is how long are we happy for this roadmap to circulate? I think it's sometimes difficult for teams to do that because as soon as you put an expiry date on it, it puts you on the hook to actually do your refresh. But also I think that's the positive of it, right? You commit to saying, I will refresh this in three months time and whatever you do, don't rely on it after that point. It does help you to motivate you into doing that refresh. So yeah, for me, my pet hate would be roadmaps that have a date but don't have that expiry date.
Simon, that is so insightful. I think I might have to steal that one. I'll put quotes out there with expiry dates, but I've never put roadmaps with expiry dates and I think it forces the teams to keep contemporary and it's just that sounds like a very good process and exactly.
And it just feeds into setting the context of a roadmap into this isn't set in stone. You know what, in three months time I'm going to change it and it's going to be different. And some of the things you may have been wanting are going to be gone, but there'll be some new things and we'll have some data behind it. So as well as providing a degree of frankly, protection for the team, it does also again, help to set the context and it helps to educate people that see the roadmap as to actually to what extent they get to rely on it versus actually it's going to change. That's right. And that's something I'm particularly hot on because as I say, we do have customer facing roadmaps. You can't just go to our website and download our roadmap, don't get me wrong. But equally, my assumption is as soon as that roadmap is shown to a customer, I start to lose control over who has it. So again, the expiry date is a part of that protection about people who may not have directly engaged with me and my team understanding that's when they need to go and seek out new information.
Simon, some absolute value bombs there, some real insights has been phenomenal. Clearly road mapping has been central to a lot of the work that you've done through your career and that you've shared some really great thoughts there through with us. I'm keen, whose advice on the road mapping space, whose advice in that space do you typically listen to or who really resonates with you?
Yeah, so that's really interesting. That's interesting for me because I think product management, I hate to use the phrase uniquely. Sure people in other careers might disagree with me, but I guess they're probably not listening to this anyway. But I think for me, product management uniquely is something where you have to experience it. Actually. You increasingly see product management courses at university, which in colleges, which I somewhat disagree with, I think it is a role that you have to experience. And actually, so to your question, to your point, who do you listen to? The books you read? I think when you can learn from other people's experiences, you're going to accelerate what you can do far quicker. So for me, rich ov, he for particularly being a B2B specialist in the product space, rich ov, I find he writes far more eloquently and explains things far better than I do.
The number of times I read a blog from Rich and I think yes, that's what I was trying to explain when I got all frustrated and couldn't quite explain what I was trying to, and then immediately we'll just send the link to Rich's blog and say, read this. That's why. So I think that's Rich for me is definitely someone that pay a lot of attention to his work and his book. The Art of Product Management is a great read. I think also in terms of books, recently we had product roadmaps relaunched that was created by a couple of authors, I think Todd, oh there it is. Look, you can just kind of read it out to me. But Bruce McCarthy was one of those authors and I find what he does. Yeah, great little book. And I think also Bruce McCarthy has a great kind of very short newsletter.
And for me particularly working with my teams, these are all, they're short little snippets that allow me to, we have discussions and for me, I don't know everything in product management. And it's great just to have that discussion with the team around points. So Bruce McCarthy's email and then you get onto Twitter, product management, Twitter. I do. I really do enjoy it. I think product management, Twitter has come on so much since Twitter first came around, really enjoy it to be honest. I value that more than maybe the LinkedIn, Twitter, the LinkedIn product management groups. I think it's really great, particularly over recent years, a bit more of the reality I think with Twitter because quite often you can read things and you're getting a perfect view of the world. I mean probably like we're talking about today, right? We're talking about that perfect rose view of the world.
What I like to see on Twitter as well is you do sometimes get that dose of reality. You do get people saying exactly. You get people saying product management is chaos. And yeah, these are all tips, these are all frameworks, these are all templates. Try and deploy them. Admit it's the chaos just to kind of help you out. And I think for me that's really great because actually you get for that, you get empathy. And I think again, that's particularly important where if you're in a small business, I work in scale-ups, most of my career has been in scale-ups, so don't have hundreds of product people in the business to quite often seeking that empathy externally is good. So to your point, I think the product management hashtags on Twitter, they're a great read at the moment.
Yeah, that's a great resource, Simon, and thank you for sharing that as one I hadn't thought of to go and look at. And as you said, it's a bit more raw, a bit more honest, a bit more of the time. So I think that's great. And also you mentioned Rich Marinoff who we're actually hoping to have on the channel as well, so if you're subscribed, fantastic, please watch this space for him. And if you're interested in hearing from Rich and his views, then any of our viewers, click subscribe and you'll be notified of that as Rich comes along. So yeah, I think Rich is a big favourite for many of us as well, Simon, I think that's phenomenal. I'd love to wrap things up a little bit. So we've talked a lot about what product management is and what it isn't, and I've loved your philosophy on it. How would you distil your philosophy of road mapping into just a couple of sentences? And I know that's a hard ask because I've had to do it myself, but would you be able to summarise road mapping into just a couple of sentences for our viewers?
Yeah, sure. End with a difficult question, I guess. I think the first thing for me is it's not something to be scared of. I think sometimes the word roadmap gains an aura that can make it seem scary, particularly when quite often, who's the first person that asks for a roadmap, the ceo? The CEO says, I want a roadmap. And all of a sudden it's like I need to create something that's a delivery plan. So I think for me, just roadmap, just get on and do it. The first one is never going to be perfect. It's the second and the third, it's the fourth one that will, and again, it's that process really. And I think the other thing for me is it's about explaining to people the leavers, you have to change what you're doing in a business. I think a good roadmap will help people understand that if they want something different, these are the levers you need to pull.
And I guess the final thing for me about roadmaps is they do have to be grounded in reality. And by this I mean what resource you have to hand. And again, we talked earlier about how vision and North Star and roadmaps come together. For me, yes, a roadmap can be an investment plan and should be an investment plan that is proposing for investment. But equally, you can't do a roadmap if you don't have any idea about your capacity because at the end of the day, a roadmap that does not have some sort of link to your ability to execute, it's just a house of cards waiting to fall down, right?
It is. So I think to summarise that, and those are great points. I think what I took away from that is it's something that we shouldn't be scared of. It's something that should be iterative and is a process or an activity, not just a deliverable. I really liked it when you said that it should think about our business drivers and the different levers for the business, and most importantly, or in addition, it needs to be grounded in reality. It can't just be an empty wishlist of things that we want.
Definitely a hundred percent.
Great point. Simon, last thing, the question is, is there anything else that I should ask you about roadmapping that maybe I haven't? So any questions that I should have asked you that I haven't or things that you'd like to end on in terms of today's session?
I don't think so. I think we've covered a lot of ground. I think for me, every time you go through roadmap and you learn something new every time with the team, we go through a roadmap process. There's a new idea or there's a new way how we should be engaging with stakeholders to validate or get data. And that for me is probably the final thing I'd say. It is a learning process. There's always questions, and again, it comes back to Twitter because if I've got a question about roadmaps or want to figure out how something needs to be done, invariably somebody's already done it in the past, so a quick tap into Google or into Twitter, you can quite often find the answer. So for me, there's always questions and part of the fun is finding those answers. It
Absolutely is. Simon, thank you so much. Just want to give you an opportunity just to share a little bit to our audience about Trust Key and kind of the work that you do, whether you are looking for careers or new hires and things like that to give our audience just a little bit of an idea of that, if you would.
Yeah, sure. So Tru Key, we operate in the global trust and corporate services and fund administration sector. So yeah, quite a specialist market for me. Yeah, trust key. The beauty of trust is we operate in a market that's traditionally been behind the curve when it comes to innovation. So I doubt many of your listeners are going to need our software, but certainly, yeah, we are hiring at the moment, very much so. Yeah, I've got a couple of product roles. We have product owner roles, developer roles. We operate in a pretty cool global market where we are trying to pull the market by the scruff of its neck to innovate and use innovative tools. So we like to think that we're trying to build the cutting edge technology that our market needs, and that makes for a pretty cool company to be working in product.
It does an exciting team and obviously an inspirational leader. Simon Wickers, thank you so much for joining us on today's session. I've absolutely loved speaking with you. Thank you for sharing your thoughts with our listeners. For those of you watching at home, please drop down into the comments, let us know what you thought, whether I didn't ask any questions of Simon that you'd like to know whether anything that Simon said resonated with you, it certainly did with me, and please give us a like and subscribe to the channel down below would be fantastic. Also, if you'd like to get into play a part of this and be interviewed on the channel, please reach out and let us know. We'd love to have you on to speak more about your views in roadmaps. Otherwise, thank you for joining me on today's session and I'll see you all again soon. Cheers, Simon.
Thank you, Justin.
