Is your roadmap a beauty or a beast? | Martin Röver-Parkes
In episode 5 of Talking Roadmaps, host Justin Woods interviews Martin Röver-Parkes. They discuss the intricacies of creating effective product roadmaps, balancing strategic vision with practical implementation, and the importance of adaptability in product management. Martin shares his journey into the role, insights from various industries, and the value of cross-functional collaboration in achieving roadmap success.
Martin is the Chief Product Officer (CPO) of Scrive, he was VP when we recorded but got promoted just before we published things! Having met Martin we know that is a great decision from the rest of the Scrive Exec team!
He has worked across a lot of industries and like many product people fell into the role without realising how awesome it is, then found he loved it and stayed!
“Roadmaps can be the beauty and the beast”
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 also continue our discussions with product leaders who are doing real-world roadmapping in their businesses helping us hear a practitioner’s perspective. We already have loads more episodes recorded with some real superstars of the product world, like Simon Witkiss in Episode 6, so watch out for the next episode!
-
Hello everybody and welcome to the Talking Roadmaps Channel. I'm your co-host, Justin Woods. This is the channel where we talk about all things roadmapping from products, tools, methodologies, and we get to speak to really fantastic industry experts like my special guest who I'm going to introduce in a minute. If you like the channel, please do like follow and give us a share. It always helps to get more audience here so that more people can understand the wonderful word of road mapping. If you'd also like to get in touch, reach out to us. We'll have some communication details down below and let us know you want to get involved on the channel and we'll see if you can get on In terms of introductions, not only am I joined by the wonderful UK Sunshine here, Martin, I think you've got quite a bit of sunshine coming in as well right now.
Well, I wish I could say that that was organic sunshine, but it isn't. It's fantastic Scandinavian lighting because I'm actually joining you from Sweden in Stockholm.
Superb. So, absolutely. So I've got the wonderful UK Sunshine here and I am introduced brought on by Martin Rover Parks Martin, massive welcome to you. You've got an impressive product management and product marketing career behind you. Tell us a little bit more about yourself and your role.
Oh gosh, thank you. Yeah, so I've been in product for, what was it, 12 years or so now I'd love to say like I say, to whether it's an intern or the chairman of a board or an investor that I saw the light and I was called towards product, but I fell into it after graduating and within several months realised it is the best job. And of course I think I'm paid as well as want to be biassed on that topic. And in my career spans logistics, manufacturing, software and SaaS predominantly across Europe, but also some business towards the United States.
Superb. So really rich history already, but built on top of a strong foundation of a number of degrees in that space as well.
Yeah, so there's a master's in international marketing and management. There's a bachelor's in business management, so that's good foundations around marketing and general business as well as specialist product management training course that I went on. And I actually went on that a couple of years ago. I wanted to make sure that the experience was also matched with the latest in learning and development. And I think the very fact that we have the time here today to discuss roadmaps specifically shows the evolution that our industry has been on and the need to make sure that we're understanding all of the tools available to us in product management and therefore the business to ultimately drive that business
For sure. And I think it can be no more important than in your current role at Scribe as VP of product management. Road mapping is really an essential part of what you do.
Absolutely. And the phrase I often use is sort of the roadmaps can be the beauty and the beast. It's essential for Scribe as it is for any business to make sure that we have a clear roadmap that is a visualisation of that strategy that we want to deliver, that vision that we want to deliver and to pull that sort of alignment together across the business. But it also has its Achilles heel, so we need to be careful of that.
Yeah, that's very true. And so actually that's a nice question to start with, which is really, you mentioned that the beauty and the beast, it can make or even embrace some companies. So in your mind, what's the purpose of the roadmap then? So bringing it back to its core purpose within a company, what do you think there?
So for me it is about making sure that we have a single place where we can reference to understand where we are going. Some people would say it's a map. I'm a little bit nervous about maps because they don't change as often and the only time they might change if there was force Mayur and a mountain has popped up or a valley has being created, ironically, that will influence a product roadmap as well. If a massive competitor shift or a change in legislation affects your product, but the roadmap is there as that reference point where the entire business can look at it, align and understand where we are going, but it isn't quite as rigid and it mustn't be as rigid as a printed map of the landscape, for example.
Yeah, that's a great point and actually an unusual analogy, maybe we need a different name for a roadmap that's been a common topic already in just a few episodes that we've had, but it's almost too prescriptive and actually we shouldn't be so confident that we know where everything's going and we can just pick our journey. Actually, we're crafting some of that journey as we go.
Yeah, absolutely. And so we are almost the explorers, that's how I talk to the product. And we are the explorers that are, we have a mission and a vision we want to chart and we want to chart our course to new lands, to the top of summits to really exciting places. And the irony is we need a way to get there. We need an understanding, a compass bearing. And so that's what we're building with the roadmap, this sort of how are we going to get there? And that's what I said earlier with the visualisation of our strategy. But as we're explorers, we might come across things that mean we have to our course or we may decide that we're going to, as I said, get to the top of a summit and halfway up the summit we realise that it's just not worth the time, effort, or investment. Or in the case of the analogy of a summit, it's too dangerous. There's an avalanche risk, the weather conditions are coming in, so we need to take a different course now if we just blindly push on, we might make it, but at what cost or we might not make it. And therefore we've seen behemoth of businesses codex, for example, suffer and peril because of that. And that's where that flexibility and that agility and the roadmap needs to come into
It really is. And actually just sharing that with me reminded me of a story, which I'm going to get terribly wrong at the moment, but there's obviously been a lot of expeditions to Everest and climbing to the top of Everest. And some of the ones that have made it are the ones that read the landscape and the weather, the meteorological signs of things that said, right, today it's going to be a blizzard, we're going to rest or make very small progress and where the weather's better, we're going to push on and make more progress. And the ones that have kind of explored and looked at the surroundings and been prepared are the ones that have made it. Whereas I think it may have been even Captain Oats, who is actually a relative of mine way way back, he actually, he perished on Everest because I think it was either him or another explorer that they were trying to do a set amount each day and when it was going well, they still did 10 miles or whatever it is, but when it was bad, they did 10 and it led to their demise. So I love that kind of thought of exploration and of course a roadmap or an Atlas prescribes that people have been there before and we've been able to plot it out. If you're an explorer, you may never have been there before. So I think we need to work on some terminology here, Martin, that better describes a roadmap than using those terms. So I'm wondering in your mind, what are the audiences of a roadmap then, if we are the explorers, who are the audiences, but more in the context of a company?
So it's very interesting because the roadmap have several audiences with all slightly different demands. And so let's look at a couple of them. You've got perhaps first and foremost for us in the world of software, the engineers. So the engineers want to understand what needs to be built next, why does it want to be built? We need an awful lot of empathy around that to help them understand the broader context there. And it also helps 'em understand if we're building X today, what does that mean for Y and Z in the future? And engineers are incredibly talented guys and girls and it's important that we show them that longer term vision so that we don't end up with tech debt or we have to do refactoring or strangler approaches to stuff that we feel that's no longer useful. But then you've also got an audience like the revenue team and that feisty bunch of salespeople that are committed to getting those pounds and dollars and euros in and their need and their view on the roadmap is slightly different.
They want to see where the industry's going and how the product is supporting that. They're talking to customers that want to see that their problems are registered on our roadmap. And the secret source there is when we've got on our roadmap things of interest that they haven't even considered for their industry. Those golden gems I think is a cliche, but if we look back 20 years ago, so the iPhone wasn't on anyone's horizon, but now we can't imagine a world without it. So can you imagine creating a roadmap for that product and what it would look like today? It's incredible.
Yeah.
Phenomen, other audiences would be investors, the management team. And it is really interesting for me, I and myself have three views on it. I have, when I put my management hat on, I'm looking at strategically is the roadmap delivering on the objectives? Then I'm looking into more detail in the roadmap, what do the key results, the metrics look like that show that we're going to hit that direction? And then I've also got the engineering perspective where I sit with my colleagues in the engineering team to deliver on that. And it really is a way to get everyone in the business aligned with a visibility on where we're going strategically and operationally. But I almost get bored of hearing my voice when I say it is not fixed in stone. It is not a shopping list. Because if we look at Kodak, if they followed their roadmap so rigidly that in the end there wasn't really much of a business, why?
Because people still want to take photos, they still want to share photos, they just didn't want the hustle of taking the photo, printing it out or going into town and printing it out, storing it in the big book. You can't find where in the book that photo is, and yet Instagram and the iPhone came along and I can type in mom, dad, pet rabbit, beach, and all of those photos will come up or it's geo location as well of those photos. And that's where the roadmap really comes into play. What is the outcome that you're looking for and are you still achieving that outcome or is that outcome still relevant or not? And that's perhaps another topic, sunset,
That's such a good one about the outcomes and the constant validation that we're going in the right direction as well. Is this really what we're trying to achieve here? I love that. And yes, I'd love to come on. That's what keeps
Me up at night. Yeah, for sure. I want to know, are we still going in the right direction? I don't anymore want to know what the Jira tickets look like, what the backlog looks like. I am looking at are these outcomes the ones that we still want to hit at Scribe, it's the digital transformation economy. It's about signing and verification, and are we still meeting those needs? We know the roadmap says that a pen and paper will only be reserved for love letters in the future, but already we have PDFs with digital signing, so what does the next experience after that look like? So yeah,
And we need to bring the next iPhone revolution to that area as well. What could we bring that we haven't even thought of? I love that. So you've mentioned a couple of different views of the roadmap, but I want to think about it more around ownership there. Who owns the roadmap do you think?
It is funny because if you speak to revenue, they'll say it's product. If you speak to engineering, they'll say it's us and product because engineering have their own. If you speak to the management team, they say, well, we own the roadmap. None of us own the roadmap. It's the customer and the market that owns the roadmap. And I sort of get quite passionate, particularly after a glass of German Riesling or maybe a nice British beer that the roadmap is owned by the customer and by the market. And as soon as we go internal with that, we then live in an ivory tower and we really start missing those new opportunities or those risks on the horizon. So another way to look at it is the roadmap is bringing the customer into every single discussion. Yes, you've got blue, ocean, red ocean, you've got all of those sort of strategic considerations, but ultimately those strategic considerations are still on either existing or future customer pain points, customer opportunities and market demands. I
Love that. I love that. Such a good way of putting it as well. It's actually the customer owns the roadmap and I'd not heard,
Sorry, I'd say that to the board, and I say that to investors, sure, it's the investor's money or it's the board that ultimately will approve the strategic direction. And when they ask, well, how have you got confidence that you're doing the right thing? And I would say this to anyone out there listening, if you're bringing the customer into every decision that you're making, and you're also saying no to things, not just yes, yes, yes, yes, yes. Because that's another Achilles heel of the roadmap, then you generally can't go wrong because the a RR or the revenue will follow when the problem is solved, when the market's understood.
Yeah, such a brilliant point. I think that's excellent. So if the customer owns the roadmap, who do you feel maintains the roadmap? Is that more of a, and we mentioned a couple of different groups there, so what are your thoughts?
I love that, Justin. That's such a good way of putting it. It is product, it is engineering, it is the business then that's accountable for that. And so the product managers, the product management team, we pull all of that insight into the roadmap. So we own that, we prioritise it. We're often seen as sort of the mean department saying no to everything all of the time or that horrible phrase, great idea, it's on the backlog, it isn't in the elephant graveyard and it will never see the light of day again. And that's something that we as product people need to improve on. And it's one of the key skills, communication and empathy. So product own that, engineering own it as well from a perspective of can we build it? How quickly can we build it? What is the cost of building it revenue, own it to make sure the customer understands where we are going, revenue own it to make sure that their insight is in the roadmap and revenue also own it to make sure that their, they're telling the story correctly of where the product and the market is going.
And that then goes back to product because we're not only taking one customer into account, we are taking maybe 10,000 customers presently into account and maybe a hundred thousand customers in five years time as a business grows. And that's another consideration. How do you slice and dice those? And then of course you have the other functions, you have the management team, the legal teams, they all need to contribute. And if I briefly touch on for example, the legal team, you might say, well, why do the legal team need to be involved in the roadmap? Well, if we're transforming our product and our contracts need to keep up with that, then if the legal team have visibility on the roadmap, they can very early come in and say, Ooh, that's something that we need to consider. And so we have our legal counsel in our monthly product syncs, so they're bought in early on. And that could be technology that we're acquiring, acquisitions that we're making or features that we're introducing that might require amendments on the contract. And maybe one for another time is the whole product led culture organisation. But yeah, we can park that and save that for another sake.
No, it's great conversation because actually it's really making sure that the understanding across the organisation is all on the same page as well. And by coming out with something and saying, this is what we're thinking about, it invokes discussion and invokes that and encourages that collaboration, which I think is so important. I'm curious that we've mentioned a lot around what goes into the roadmap. So the strategic direction are often defined where we want to go in the eyes of the customer, but is the roadmap the highest document that we create there or what do you think that the relationship is of a roadmap to things like the vision, the strategy, maybe objectives? What are your views there? What have you seen that works? Well,
It's a great question. Depending where your organisation is or where your product function is or the market that you're in, there's going to be shifting priorities. But if we take a broad stroke here, the first priority is what is that vision that you're heading towards? Often refer to as the north star, although that term's used interchangeably and that vision is which summit do I want to get up? And that's what we said at the beginning of our conversation. Do I want to head up the Everest Summit? Do I want to head up the K two summit? Ironically, I wouldn't because that's more dangerous than Everest. So I've got that vision and then I've got my mission and I've got my objectives in order to fulfil that vision to get there. And then underneath my mission and objectives, I've got my key results, my metrics that are making sure that I'm hitting my objectives.
And the roadmap is bringing all of those into one place. But don't worry, it's not one massive document. There's the Jira board, there's Kanban boards that are supporting that. There's various other documentation, discovery sessions, customer research, et cetera. But that all ultimately needs to be visualised and put into a roadmap that's interchangeable and flexible. That's showing on a weekly or monthly basis, the key results are heading in the right direction. Could be usage, usage, feature, adoption, monthly active users. You can also look wider than just product metrics, revenue performance, NPS scores, et cetera. And then you're assessing your objectives with those metrics. And the most critical thing for me is the vision. One that excites the entire organisation and is it one that's sort of realistic? So if you've never climbed a mountain and your vision is Everest, that's probably not a great idea. But you could say, my vision is Everest, but my roadmap is broken into several trunks, the stage of getting fit, then the stage of smaller mountains, then the stage of bigger mountains and then ultimately Everest, and then you've got objectives along the way to hit that. And then you have the KR frameworks as well and all sorts of methodologies and processes. Yeah,
Yeah, it makes complete sense to me. And so I'm wondering then we talked about some of the OKRs and things like that. What do you believe are some of the key elements or content on the roadmap then taking that conversation a bit further, what do you like to see and what do you like to present on your roadmap?
I like to see the outcomes that we want to achieve. And those are the themes or the trends on the roadmap. There's many roadmap softwares available there. So I'll just name one for example, product board with product board, there's differing views. So there's my view at a very high level of the outcomes that we want to achieve, the themes that are being matched. And then that would be broken down into, in this case, product areas where I've then got blocks of deliverables in those product areas that make sure that that's linked up to the themes, which is what we just spoke about, that vision and then the mission and then the objectives. And then when you go into the individual parts of the roadmap, there's often links out to Atlason, Figma, Miro, et cetera, which are all of those operational tools. So if we go back to the climbing analogy, that's your kit.
You've got the summit, you've got your bag, and in your bag you've packed a pick, ISACs, extra boots, extra socks, first aid kit. And in the roadmap at that level of detail, you have your Figma mirrors, product descriptions, use cases, and then with good roadmap software, that's often linked to specific enterprise customers who they might be notified when a feature is available, word of caution there, do not build a roadmap for a specific customer unless they happen to be worth a billion euros, then it's probably a big enough customer, a billion euros to you, should I say, not their turnover. So it might only give you a slice of the pie. So those are the elements that I'm looking for. I'm also looking for flexibility and going back to product board, I get a weekly update and I actually like to scroll through that email.
And the longer that email is with the updates, generally I have a sense of confidence that we're making the right changes, that we are really assessing everything. And here's a quick story. I think about three, four weeks ago, I pinged my team and said, I've just had the weekly update from product board and I only see two changes. And one of them said, Martin, why are you just basing it on how many changes are happening? And I said, because for me and my roadmap and my objectives and metrics that I'm measuring, and you could say it's rudimentary, but for us it works. If I'm only seeing one or two changes, my question would then be is the roadmap flexible enough? Are we assessing all of the elements on there? Are we killing? Are we adding features? Are we moving them forward? And I'm not seeing any of this. I'm only seeing a couple of things. Well, I think the team took that on board and also maybe rather cheekly were like, right, we'll show Martin. So the following week when I got the update, I think I scrolled six or seven times through that email to all of those changes. But it's lighthearted, but it's an important point. Going back to that flexibility and adaptability
For sure. I mean, it's those footprints in the snow that you're trying to see there and you just want to see that we're making some progress, but the strategy, setting the direction, we don't want to make progress in the wrong direction. But that's part of your touch point, right, is that you are looking at the roadmap at the VP level and you are looking at the board level. You want to make sure that there's traction going, but ultimately we're going in that right direction.
And so I think it's important as a product function, and this is why this is sort of a product culture to empower everyone at every level to make those decisions. And I joke with the team, I do not want to be a hippo, the highest paid person's opinion, I don't want to be a seagull. Even worse, swoop in course GA fly off. So the product teams, the rest of the organisation need to be empowered to deliver. And so we can focus on the strategic direction, but also there's an accountability that everyone in a business should have towards their leadership team that we remove roadblocks, we make the difficult decisions, and we support with that prioritisation. And ultimately, and I now speak for the product leaders out there, ultimately if we have the right insights, we can make those right prioritizations, which comes right back to the roadmap and that sense of confidence around it.
It really does. And that just shows one of the many purposes of that roadmap document is actually serving within our organisations. I love the fact that you talked about frequently sharing that roadmap. I've been with some companies that have created a roadmap as a checkbox exercise at the beginning of the financial year and then put it on a shelf or the SharePoint document, a SharePoint area for the rest of the year. But I love the fact that you said it needs to be frequently shared, frequently questioned. What else do you consider as to be some best practises in roadmapping apart from frequently sharing things?
That's a great question. On a monthly basis, we want to do a roadmap grooming session, and that's a little different to the backlog grooming. The backlog is that granular level of detail, but we want to make sure that is it still in the right direction? And that grooming session is done with heads of departments, the senior product managers or so. And then on a quarterly basis, we want to have a session with the management team, with the executive team to go through that on a half yearly basis. You want to make sure that that's visible and walked through with the investors or with the board level, other good practises, making sure that you're regularly spring cleaning it, updating, keeping it maintained because if it looks old and out of date, people aren't going to go into it. Other best practises, how do you bring feedback into the roadmap?
How can you share the roadmap in a way that protects your competitive position but also gets feedback in? So you could have up voting and down voting of features by users, by customers, by prospects, and they have that visibility, but they may not have the visibility of the strategic direction. If you're in stealth mode or you're pushing back against competitors or you're going into Blue Ocean, you don't particularly want to share that. Best practise as well is to have confidential restricted on any slides that you share. And much like social media, if it's posted online, you've lost control of it. So just remember that when you're sharing it, it's hard to say because you go to your point, if you're that tight and you're that restrictive, people are going to be terrified to share it so it just stays on a shelf. But also you don't really want to be at a conference and suddenly you're like that roadmap by that competitor looks extremely familiar and either they're exactly onto the same thing as us or they've had a copy of it and then they're exploiting that.
Yeah, for sure. You want to do enough where it keeps your clients happy and your customers engaged and seeing what's going on. There is a very fine balance there, especially in SaaS software, whereas you, like you said, you don't want to be serving the largest number of clients that you can or customers that you can. It's not just serving one unless they are giving you a billion dollars worth of revenue. So you want to give enough to give them something to be excited about, but not so much that as you said, you can start to see software once you've lost control of that roadmap data and it's out there, you have to assume that's in the public domain.
And you've made me think another best practise, and some of this is in good product management almost second nature, is I try to attend weekly customer meetings and I present that roadmap to them and I present it for two reasons. They want to know and they want faith, like I said earlier, but it also gives me a chance to subtly interrogate the validity of that roadmap. And I always say to my product peers and team, you can leave that meeting with two feelings. One is a good feeling and one is a bad feeling. Let's go to the bad feeling because everyone's interested in that first. And for me, that bad feeling is I've walked through a roadmap, I've listened to them, I've left the room and I've gone, shit, that's not on the roadmap. That's not even being considered. Wow, have we missed something? And that is not a great position to be in, but it's good you can still do something about it.
The other is you leave the meeting, you go, shit, it's all on there. We're just not moving fast enough. And that is a perfectly good position to be in because that will lead you back into your internal discussions around roadmap, prioritisation, the backlog, grooming the executive stakeholder, and all of that can then allow you to prioritise that roadmap. And it's worth saying all of this sounds like the elixia to life and the reality of how you want to tackle things to being sort of in the thick of it is very different. So maybe one for another time, what is life like as a product person?
Absolutely. A whole series we could do of that. And it probably turned into therapy and counselling as well.
It really would. You'd probably have hundreds of thousands of users. You'd have the holistic psychologist from Instagram, but a product version of that for us, you really
Would. So what are some of the bad practises, do you think of road mapping then? What are some of the biggest mistakes people make?
Yeah, well that's the really juicy one, isn't it? Sort of the do's and the don'ts, right? The bad practises of roadmap, first of all, allowing the business to think that what is on there is set on in stone and come what may you will deliver on that. It is absolutely not a shopping list. The second real risk is that you have very customer specific requirements on that roadmap and it depends on the scale of your business. For example, startups, they may have to have that on there in order to stay in business. The same with scale apps, but they're also trying to push into wider markets, but also with the very large enterprises, is that really moving the needle or is that a roadmap of just maintenance? And maybe that's another one to talk about the difference between an innovative roadmap, a maintenance roadmap, a new market roadmap or a sunset roadmap.
They're all important points, but that's the second thing, having a two customer specific roadmap. The third one is not getting feedback and having a very rigid mind to your roadmap. You've got to constantly, I call it the scientific approach, which is I really, really have such strong beliefs in things, but I've got to hold onto them very likely. And I like to put theories and concepts out there and let people challenge you, create the psychological safety in the business and the team for people to really critically ask you those questions and peers in revenue and in engineering other perfect people. Because as product managers, you've got to pitch to both of them. And if you can answer their questions, then you're actually in a really good position to think, yes, this is a very reliable roadmap, but then that goes to 0.1, make sure it's not too rigid.
Yeah, I love the collaboration side of how you interact with your business and bringing people along that journey with you. And they've got tremendous insight. It's not just product carving the way and in sales you get what you're given. It's bringing that into all of those different areas together and saying, this is our roadmap and bringing that in. I think that's great. Have you seen any antipas or bad practises of mapping? So where people have done things typically what bad habits or antipas they might introduce into roadmapping?
Any of the ones that I speak about, I would say I myself have been guilty of or the businesses that I've been in, we've all done. And I think that's important to say because I don't want everyone listening in to be like, well, it sounds like it's all perfect. It really is not perfect at all, is why I'm going to have a nice glass of Riesling this evening to start the weekend on the roadmap. If you've got very high level themes and deliverables and you haven't got the detail behind it, that's interrogated. That leads to the second point straight away, which is it's super easy to go onto product board or any other software or even just you don't need to buy software. You could have PowerPoint and to get drunk on your own hubris of this is such a great roadmap and you've moved everything into the positions and you're going to deliver this and this and this, and that's what you deliver and you say, yep, we're going to do this. And then at that point, you haven't done enough interrogation with the engineers, you haven't done enough interrogation with the sales people. And it's really disheartening when you can see market trends, you can see where it needs to go, but it's just not a feasible realistic roadmap. And so don't lock yourself in a room, build the roadmap, be drunk on your own fuse with that, and then expect the rest of the organisation to understand it. That's risky.
Such a profound point. I think that's really like that. Thank you. And so the bad practises, do you have a pet hate or a single pet hate you hate to see on a roadmap something that just makes your blood boil?
Before I answer that, I look out the door and just check if any of the team are there waiting on the door because they charge in pet hates for me on the roadmap. It's seeing so much detail today and then nothing in the future. And the purpose of the roadmap is to help us get towards the future. So I say to teams, I want to see lots of detail today, more detail in three months time and themes and visions for where we want to get to after that. And if I just see a whole block and then nothing almost like dropping off a cliff, that's what we've got to picture. Imagine we hit all of that, we then dropped off a cliff. The other pet hate is not having the roadmap updated and going in and I'm like, what on earth does this mean? I click on an item or an element of the roadmap and there's no detail in it at all. I'm famous for tagging everyone on Slack to give reminders about that. So that is an absolute pet hate and it's also not having an exciting enough roadmap. I mean, we all come to work, we want to contribute. Yes, we want to earn money and we want that money to go on holiday and feed our family and do really nice things, but also we want to be excited and empowered by what we do. And so if it's a boring roadmap, if it isn't visionary, then what are you doing there?
Yeah, it's got to be excited. It goes kind of into the kno model side of things as well. What are we doing to excite our customers, but what are we doing to excite our business? Like I said, we've got tremendously hardworking engineering or development teams, other parts of the business, we want them to get behind us and push this thing forward and it has to have a level of aspiration and challenge in it. Otherwise why are we doing what we're doing?
And I guess on the other side of the coin of not having anything after the immediate future is just having everything on there. And famously when I've joined businesses, I've often, and I've never managed to, but I've wanted to print off the entire backlog and literally find six months and one day draw a red line and cut from there underneath because it is an utter waste for the roadmap prioritisation and planning to look at feedback from a year ago. Yes, you could challenge back and say, well, what happens if the iPod was on there? Well then I'd say, you're not looking at the trends well enough to bring those topics to the top, but you cannot look at things a year or more ago because they're just not relevant anymore.
Yeah, absolutely. You can't move forwards if you're always looking backwards. Whose advice on road mapping do you listen to?
That is a brilliant question. That is a brilliant question. In what sense? How to build them or the concept? I mean you've
Brought some really great concepts and I'm an analogy person. I've really loved your analogies as well. So I'm thinking where do you build up? Where have you collected a lot of your knowledge? Who do you respect in the industry that's helped sculpt some of your views of roadmapping today?
So I am from two cultures and two backgrounds, half German, half British, lived in both countries and worked very much internationally. And you may say, well, why are you starting with that when we're talking about roadmaps? And that's because for me, roadmaps are, like I said earlier, this amalgamation of so many viewpoints. So I'm going to go to industry experts on the themes, the topics and get their insights. I'm going to go to the VPs and CPOs that are doing a brilliant job and get their insight. I'm going to go to my product managers, the junior product managers, the senior product managers, everyone in between to get their views on where do they want to go, what do we want to achieve? I'm then going to take in the views of the rest of my team in the executive leadership team because they've got their goals I want to hit. And then of course I've got the Marty Keegans of the world with inspired. I'm a little reticent to mention those because otherwise it's like fanboy. This is the silver bullet. I would say if I was to answer in one sentence, where do I go? I go to so many different places and actually I also go outside of the world of business. So that would be hiking or skiing or just you need to look after yourself because running a roadmap is really hard work. Whether you are leading it at a strategic level or leading it at a very operational tactical level, you need to make sure you're looking after yourself holistically to be able to deliver on that roadmap.
What a great answer. And I think you've got a wealth of experience in the industry as well working up describe, but previously Quest back and previous companies there, a lot of things you've picked up just from the organisation, the type of business where it is in its growth cycles, what type of products they sell can define SaaS versus something else, different types of businesses. So I think just a lot of vocational experience as well that you've been able to pick up. Martin. That's brilliant.
I think we're going to see, sorry. I think we're going to see we are seeing that trend now, which is exciting. Product management's been around for a while and it's now going through its maturity and adding a wealth of training, which I'm so pleased to see the various training providers across Europe providing that now it's important that we don't lose, and I sound like I should be sat on maybe a rocking chair here with a cup of cocoa and I'm really not that old. But we need to make sure that all of those that have gone through the trenches in the last 10, 15, 20 years, many people smarter, more knowledgeable than me with many more battle wounds that we keep that thirst for doing it, for rolling up our sleeves, that practical application, but we also embrace the technology, the learning, the training and the development. That means that we can make less mistakes or make them quicker and learn from them better. And I think, yeah, it's that combination you can't really beat.
That's perfect, Martin. Thank you. And so I'm wondering if we might go into, if you had to distil your philosophy, and I've loved what we've talked about so far, love to share a glass of wine with you and carry on as well, but if you had to distil your philosophy of roadmapping into maybe just a couple of sentences, how might you describe that to people?
Be really clear on the exciting passionate summit that you want to go for. And when I say you, your customers and your customers that are going to deliver commercial success, however that looks, and then make sure that that is visualised on a roadmap that anyone can pick up. Should you get stuck halfway up the summit and they can then carry on that journey for you. Brilliant.
So important as well. Martin, is there anything else about road mapping that we should have asked you that we haven't? I know there's lots of things we could have talked about, but anything you want to just bring out into the open from what we've just talked about?
I would summarise with get it all down on the roadmap. Read around what good roadmaps are, talk to the providers out there, talk to the industry experts, talk to your peers and then build it and immediately start iterating on it. And in a previous business, it was within three months of buying the software, building it and the real work came two, three months after that first roadmap where everyone's iterating and getting in on the detail, the detail at a high level, is it the right direction and the detail at the backlog, JIRA ticket level,
Just start with something if you haven't already,
Take that first step. Actually that's a pet hate if I find out that we just haven't started because we're too afraid. Fail, fail fast. And you could make the same mistake a couple of times. By the third point, we might have to have a chat, a beer, but until that point just get going. But
Start, right? Because the best way that we learn and you sound like a your sleeves up and get your hands dirty kind of guy. So I really admire that about you. Martin, thank you so much. I've absolutely loved speaking with you. I think an incredible career that you've had so far and some really great thoughts on roadmapping. I wanted to just give you an opportunity just to talk a little bit about Scribe and where the audience can get involved or what they can learn from you. Is there anything you wanted to share with us about the digital signature functionality that you provide?
Someone that loves talking, I've suddenly gone very shy there. I, which is probably not good considering that I'm representing from a product perspective, the company. If you are interested in your digital transformation, if you want to sign things quicker, if you want to know your audience through verification and authentication more efficiently than myself and the team, or I shouldn't say myself, the revenue team, who definitely won't just be like, bye bye bye. We want to facilitate your success, drop us a line scribe.com or if you just want to have a chat with me, searching LinkedIn for myself or anyone from Scribe and we'll support you with the signing, digital signing and digital verification journeys that you might want your business to go on.
Fantastic. Martin, it's been an absolute pleasure. I can't thank you enough for joining us and hopefully we can enjoy some more dialogue either in this format or offline or in another channel in the future. But I wanted to thank you so much. That's Martin Rover Parks from Scribe. And guys, that's it for today. If you've enjoyed the session, please do give us a drop, some comments or some suggestions about what you've particularly liked in the session below, and feel free to share this with other people that you think will be interested as well. If you'd like to be in Martin's position and join us on another episode, again, please reach out and let us know. Otherwise, I've really enjoyed speaking with you Martin today. Thank you so much and have a good weekend.
Thanks very much.
