What is the role of roadmaps in globalisation? | Dave Barker
In episode 65 of Talking Roadmaps, Justin Woods interviews Dave Barker, an expert in localization and globalization for enterprise software. They delve into the challenges of managing roadmaps for global markets, including balancing regional customization with a unified product vision, handling legal and regulatory compliance, and the tension between global and local product management. Dave shares insights on the evolving role of localization teams, the importance of "minimum compliant products," and the complexities of geopolitical and cultural nuances in global software deployment.
Dave is a veteran of the global enterprise software world having spent more than 40 years in multiple disciplines including product management, professional services, competitive analysis, development, and sales support. As such he has been both a producer and a consumer of roadmaps. As an independent consultant, he helps B2B product managers with the challenges of localization.
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 Ed Roberts, Partner & Product Strategist @ We Are Systematic. So watch out for Season 1 - Episode 66!
-
Dave Barker:
The final interview with the CEO and he asked me, "If you get this job, "what's gonna be your biggest challenge?" And I said, "You will be Mr. CEO "because I understand that, you have this habit "of changing the robot coming up with these great ideas "every five minutes and then changing your mind." And he assured me that would not happen now, he had someone in the product motion room. Sure enough, six months later, he was chopping and changing, "No, add this, add this." He never wants to take anything off.
Justin Woods:
Welcome to "The Talking Roadmaps" Channel. My name's Justin Woods and I'm one of the co-hosts here. And today I'm joined by Dave Barker. Dave, welcome, introduce yourself please.
Dave Barker:
Great to be here. Thank you so much, Justin. Yes. So I'm, I guess I'm a veteran of the enterprise software space, having spent more than 40 years in many, many roles, both as a individual contributor and a leader. Applications like some may remember back in the 1980s we had MRP then ERP, human capital management, payroll, those kinds of things. And I say in many, many different roles, not just as a product manager, but in implementation, pre-sales, marketing, so on. Yeah. So I've often been part of the European expansion of North American companies in so helping to get them going in various roles. I've spent five years in the US which was definitely useful experience. So now I'm an independent consultant, the focus on localization.
Justin Woods:
If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Well I'm really excited to dig into that with you 'cause I think there's some really interesting aspects that we probably haven't covered on the show and talking with the show, I should probably introduce us. So welcome to "The Talking Roadmaps" Channel, we're the podcast under the YouTube channel where we talk all things roadmap with special guests such as Dave around practitioners, tooling experts, and some of the industry well-known names that you know and love as well. Why don't we get stuck in maybe with kind of one of the first questions, which is, from your perspective, and I know you've come at this from different angles, what's the purpose of a roadmap, do you think?
Dave Barker:
Fundamentally it's a communication tool from the product team to others, typically internal within the company to let them know what product's doing, simply put.
Justin Woods:
Yeah, yeah, absolutely. And so letting people know, who do you think we need to let know, what's the audience of a roadmap?
Dave Barker:
I think the audience is very, very broad. And I know previous additions of the show, talked a lot about what sales are looking for, what marketing are looking for. But perhaps another examples, for example, I once ran the proposal writing team for an enterprise company. So our role was principally responding to RFPs. And there's always a question in every RFP, please attach your roadmap. Now we would never do that because too often, just as you're about to sign the contract, the customer says, "Right, we want your proposal "to be part of the contract." So what I was looking for out of the roadmap there was the story, what is the direction of travel, what's the thinking, the strategy behind, what's going on with the product? So some text to include in the proposal to our prospective customers. So that was important there. Another example was in the role of competitive intelligence when you're trying to help your sales organisation to understand where your competitive advantages are and where your weaknesses are. And again, having an understanding of what's on the roadmap can help how you address those competitive differences. If there's something on the roadmap that's coming reasonably, certainly, you can use that as ammunition against a competition. Whereas if there's, you know, it's not mentioned, then again that's useful to know because you can find other ways as a competitive intelligence professional to deflect the competitive feature or capability that the competition have got. And then I guess the other one I'll perhaps mention is in a implementation role, as I said, a lot of my experience has been in the large global business application space, where typically you might be implementing a programme across 20, 30, 40 countries, across five years. So as you plan that programme with your customer, and this is where we get into the localization nationalisation, you need to understand, when certain countries would be available that you can plan into your programme. So again, as an implementation professional, that's where the roadmap comes in.
Justin Woods:
Yeah, very much so. I think there's some important things that we're gonna go down a little bit deeper into later around the fact that when we're talking about localizations or differences there, traditionally we're having to think about quite big changes, but also very specific to different markets, different legal criteria, different regulatory criteria even. And also they might have very long timeframes here because it needs a hell of a lot of planning in order to be able to think about these. That's quite complex and something that's a lot of moving parts there. You also mentioned around it being, yep, a story and a direction of travel. I find it interesting around, almost as a sales tool heavily when you're doing the RFP process because your prospective clients want to know what you've got planned. But how do you provide that with some level of kind of, here's the things we we're thinking of doing without specifically tying yourself down to dates and timeframes that actually you might not want to commit to as part of know getting that deal.
Dave Barker:
Typically at the proposal stage, you probably haven't got the specifics of any gaps between your product today. So it's actually quite easy to use that general textual information about what the direction of travel and so on. Typically it's later in the sales cycle when the sales team typically that you find a gap to what the customer says they need and what you've got today. And that's when they start lagging the product team button down a date for this particular feature.
Justin Woods:
I've got a question here, and I want us to think about especially the localization challenges of this, which is, who owns a roadmap? And that can be difficult if you've got a central team that owns the main code base and you've got regional extensions of that, how does that work? Who owns that roadmap?
Dave Barker:
I think that's changing. So certainly when I started you had this, and I think you said it's the same thing. You have the central code base and then you have a separate code base for localization. At one point in my life I was running the localization team for an MRP company. We're based in the Netherlands. So we would take the code from headquarters and it was our job to produce a European version or versions. So in that case we kind of owned it. Now I think increasingly with modern software development techniques, modern translation tools, continuous translation, et cetera, then you've got one common code base. But typically in a big enterprise software company, you've got multiple development teams anyway. And so it's the old problem of exactly who owns which piece of the roadmap. Is there a separate localization team or is it part of everybody's role to do their bit towards delivering the suitable product for a particular location.
Justin Woods:
Even if there was a global code base and it was truly a global code base. Do you think there's still importance to have regional ownership and management of that? Because the global code base predominantly, like you said is normally in America. Is it really important those to still have representation and ownership of those items at a regional level, even if the code base isn't?
Dave Barker:
Yes, definitely. And I think a distributed product management team is really important. Because the nuances of localization are really tricky and even if you're a regional product manager, let's say for Europe, even then you are gonna have to rely on people in country, but you can't possibly understand all the nuances of every country maybe targeting. So yeah, definitely a global team with local representation and some kind of local ownership. But often that can be a challenge it would be particularly if the development team are centralised somewhere, getting your voice heard from a regional perspective. I certainly face as a regional product director, I've certainly suffered from that sometimes trying to convince the rest of the organisation of the amount and the importance of the work that was needed to be successful in other markets.
Justin Woods:
Totally. Because you are almost having to create or come up with your own justifications for it, your own mini business cases sometimes of this, because you are competing with potentially other regions as to why we need to make certain changes within certain timeframes of that global code basis. It's a discipline of product management that's quite specific but fascinating.
Dave Barker:
And I think it also ties into this business of, localization being much more than translation, but also I think too many people that might be making the decisions about moving into additional markets don't understand. So you're right, it's that justification of all the work that needs to be done, actually not just by products and development, but by other parts of the organisation as well to be successful in new markets.
Justin Woods:
Yes, absolutely. Talk to me a little bit about the relationship maybe of the roadmap to things like vision, strategy, objectives, how have you seen that? And again, we might maybe step back a little bit and think a bit about more your experience of the past in different roles.
Dave Barker:
Yeah, obviously ideally it should be an accurate reflection of the corporate strategy. Unfortunately, I've seen in a lot of companies a disconnect or no clear strategy at the corporate level. And so as a product level you try and come up with your own strategy and obviously you make sure your roadmap aligns with that, but it can be a struggle when there's no clear strategy at the corporate level. And again, that can sometimes be a challenge in the bigger multinational companies. When sometimes if you've got a software company headquartered in North America, typically the North American market itself can be bigger than the whole of the rest of the world put together. So trying to get the attention of the executives to understand the complexities and the costs of globalisation. Yet the interesting thing is many of those North American, big North American customers actually are only your customers because of your commitment to the rest of the world. So I've done a lot of work in things like human capital management. So you may have 50,000 employees in North America and another 10,000 spread across 30 countries elsewhere in the world. And often the vendor's value proposition is one system globally, but the actual revenue you get, direct revenue you're getting from those 30 extra countries is very, very small compared to North America. But you wouldn't have the North America revenue if you didn't have the capability elsewhere. So particularly depending on how the company's structured, in terms of regionalization, outside products, that can be interesting as well.
Justin Woods:
What about the relationship of a roadmap to other artefacts? And I'm gonna unpack this a little bit. You mentioned around the roadmap and tying into strategy and sometimes that strategy doesn't exist and I've certainly found that as well. I've brought in some tools before to create a strategy for my own product team, but didn't have a clear company strategy to tie into. What artefacts have you seen that the roadmap might sort of relate out to that is important? Maybe even the business cases that we were talking about at the regional level. What's been important for you, for your roadmap to tie into for that justification?
Dave Barker:
So in particular in the context of kind of globalisation, then it needs to tie into the business plans of the business of either just being able to deliver to global customers or even to go direct selling or even indirect selling into a new region. So again, the roadmap needs to be aligned with that. If you are planning on opening an office in Germany in 2025, then you need to have a product for that market in 2025. And again, that this comes back to the, if you're planning on opening up in a new country that does not overnight, you've gotta plan that. So again, the long lead time on the product as well, but you need that visibility of you need to deliver something a year out when as professionals of course we don't like to commit anything beyond the next sprint until the next quarter maybe. So.
Justin Woods:
It's a much bigger world when you're thinking about opening offices to support, and you need regional extensions to support that. It's a much longer roadmap and probably actually a completely different level. So at that level, Dave, what do you believe are the key elements or content that you'd want to see maybe at a roadmap of that level? What would you expect to see on that?
Dave Barker:
What you'll see is that this country or this market in a particular timeframe, and probably not go into the detail, but that's the catch. In the world of business software to be usable in a country, you've actually gotta have a complete product in the sense it must be compliant. So it's gotta satisfy all the legal rules, all the security and privacy rules. It's not like, you can't deliver an MVP, it's where I sometimes call an MCP, a minimum compliant product, which is pretty much a complete product. And again, that kind of goes against the philosophy of some of our ideas of modern product management. So I think on the roadmap, I say you just need to know that country in that timeframe, but behind that there needs to be the assumption that it will be a complete product in the sense that it's compliant.
Justin Woods:
Interesting. So it's much, much higher level and it's actually that we can't really test and learn in some of these places. We can't put an MVP out that might satisfy the software requirements but completely contradict legal and mandatory, which then puts us in trouble or hot water or it means we can't even go live at all. The minimal compliant product is something, is a new term for me, but actually completely makes sense, which is we need to go live with the robustness that means that we can sustain this. We can't just test and iterate on a very small scale. It must meet the needs of that locality and then we can go from there.
Dave Barker:
And also the other factor of these, in my experiences to say it's been in these big enterprise type software, it's not that you can implement the products over the weekend. These are typically six to nine month implementations. So you've been, even if you don't have the software right at the beginning of the implementation, you've probably been using the software for six months before you go live and really find out whether it's good or not, by which time so much time has passed. It's yeah, a challenge.
Justin Woods:
Yeah, absolutely. Interesting. So when we talk about that longer term roadmap, how would you prefer to visualise that? I think in that instance, dates are probably important. So what would you expect to visualise or put on that roadmap?
Dave Barker:
Well, I mean it's a good opportunity actually to be quite colourful. I've seen the word basically just used a flag of the country and the name on a possibly by region by quarter or by half year out for a couple of years saying this is our product. Maybe depending on the nature of your product, if you're a multi-product company, then obviously you have to identify which of the products would be available then. And some might not be, and again, I've seen that miscommunicated where people have assumed that actually all the functionality that's available in the home country would be available in the foreign country. But in fact the product team's goal was actually only to make some subset of that still have a compliant product but not as much scope as in the home country. So again, that's important to communicate that.
Justin Woods:
Dave that makes a lot of sense. 'Cause actually there's so much more that goes on with these different countries. Currencies is a classic one, the native language and then the other languages that might be spoken are other ones. So there's so much complexity there. So I love the fact that the visualisation is, could be flags of the country, maybe something that denotes the language or the currencies there as well. I think we've got an opportunity to be playful with roadmaps and actually add some interest there to, as you said, tell that story and direction of travel. Dave what tools do you prefer for managing a roadmap?
Dave Barker:
So I think in terms of managing it internally then there's a number of tools. In the past I've used things like Aha and this, that and the other. But I think in terms of the presentation, I know this is not a popular answer, but PowerPoint or similar because you want to be able to include a lot of text, you want that story upfront of the strategy and whatever. And I just think that the mechanical tools as I like to call them, they're good for listing this, that and the other or maybe plotting stuff out in a way. But given you want your roadmap to be reasonably high level, not too much detail, then PowerPoint is just as good as anything else.
Justin Woods:
I totally agree actually, and that might be a controversial from my tooling background as well. But I think like you said, the mechanical tools, the management of the roadmap ultimately has to be done somewhere else, where it can manage the moving parts, the complexities, the timelines and things like that. But when it comes to presentation, I think modern tools now, Miro, Mural, online collaboration tools, you have PowerPoint, I mean PowerPoint is ubiquitous and it's always typically available for the companies or something similar in terms of a presentation tool. And it gives you that flexibility. I think it also allows you to stylize the roadmap in any way that you want that might be meaningful. And so that's part of the joy of road mapping is not just the story arc of what it is that we are building and why. But it's bringing some colour and some interest to that to help tell that story. So I think I understand what you're saying, there's lots of tools out there. But the PowerPoint and these presentation tools give us the ultimate inflexibility. I think what I'd also add to that is that the introduction of product management tools is really fairly recent in the last 10, 15 years or so. But product mapping is a discipline that's gone way back, whether we called it product management or not. And so looking at that, there will have been tools that we used at the time that just, that existed then and none of the product management tools that we really are able to leverage now, actually existed.
Dave Barker:
Yeah, yeah, that's right. We certainly come a long way there.
Justin Woods:
Dave, what do you consider to be a best practise in road mapping? And this can again be from some roadmaps that you've created or roadmaps that you've been a recipient of. What have been some of the best practises that you've seen?
Dave Barker:
I think absolutely what I call telling the story, at least in, as you introduce the roadmap itself, make it very clear what the strategy is, what the thinking behind the roadmap is, and then not jumping straight into we have this feature on that data relevance, keeping it as high level as you can for the audience by communicating the background. And I've worked in some companies we were small enough that we kind of kept control of the roadmap and it was one of the product management team that would always present the roadmap to anybody rather than just posting it on a SharePoint site somewhere. But if you have got a bigger organisation, you do need to communicate that way. It's really important that the thinking is clearly demonstrated there as well as the facts the capabilities that you're looking at, et cetera. And any dates, alternative dates that include.
Justin Woods:
Yeah, indeed. And so the kind of conversely, what are some of the biggest mistakes you think people make in road mapping? And this might be an interesting of maybe even attaching the roadmap to the RFP. What are some of the mistakes that you've seen?
Dave Barker:
So actually what one day I was thinking about this, one of the interesting, it's what I call bullying by the chief executive or the senior executives. I remember once I was, when I'd interviewed for the job of head of product at a company, having talks to most of the management team, the final interview with the CEO. And he asked me, "If you get this job, "what's gonna be your biggest challenge?" And I said, "You will be Mr. CEO "because I understand that you have this habit "of changing the roadmap, "coming up with these great ideas every five minutes. "and changing your mind." And he assured me that would not happen, now he had someone in the product motion role. Sure enough, six months later he was chopping and changing, "No, add this, add this." He never wanted to take anything off. He always wanted to add it. And more recently, I've seen this before, that a product team was in effect bullied into including things on the roadmap that in reality they had no hope of delivering in the timeline. So other constituencies had their hopes raised that something was coming. And in reality it never would've done so better to have pushed back if you can in the first place. But depending on how the organisation structures you can't always, as a product team, you can't always push back.
Justin Woods:
Yeah, very true. It often depends, in that scenario, I think it's always challenging when the first person comes in, in a product management role to almost take that over from the CEO is for the CEO to go, "Okay, someone else is now in control." And often they'll feel very challenged. It'll be very difficult for 'em to let go of that. And so I think we see that. Yeah, that's certainly a big one that I've seen before.
Dave Barker:
And that could be particularly be a problem if the CEO is the founder and founded it as a product person, than getting them to let go of the reigns is quite a challenging.
Justin Woods:
I'm wondering if there was anything that we've talked about so far or maybe haven't talked about that you'd like to bring to the surface? Is there anything that comes to mind that you'd kind of like to delve deeper into?
Dave Barker:
Yeah, perhaps let's cover more of the, kind of going back to the localization, globalisation and some of the, you've already mentioned, some of the things. Obviously language, business requirements, but increasingly topics like privacy and security are becoming more and more of an issue around the world. Individual governments identifying, implementing new privacy rules, new security rules, which you have to be compliant with. A big challenge in the world of SaaS of course is the fact the SaaS model was built on one instance, the software running in one place and everybody accessing it from there. But increasingly governments are implementing laws that say no personal financial data cannot be kept anywhere. There's always been this tension between Europe and the US over this. But countries like Saudi Arabia now mandating that all personal data must be hosted within the country. Which again, kind of really attacks the roots of the SaaS model, if you actually gotta have multiple instances by country. And other things like geopolitics. Not something that we always think of to start with, but I'm always fascinated. A couple of occasions over the last few years, some people might remember, I think it was at the last Olympic games, then one of the, yes, it's the Beijing Olympics won the TV channels in North America, put up a map of the area around China and immediately got into trouble because it did not reflect China's claims to a large part of the South China Sea. And then the opposite happened, I think it was when, not a topic I'm particularly interested in, but when the "Barbie' film was launched in one of the promo videos that was aired in Thailand. Again, there's this map apparently in the "Barbie" movie. It's not a real map, but it looks a bit like the area around the South China Sea. And I think this did have what appeared to be a dotted line, showing China's claims and territory and the Vietnamese got upset for the opposite version. And I think again, in our word of software, we need to be careful about this, that if you are representing information or data about countries that is controversial, you can get yourself into trouble if you're not careful. So it's another thing to think about as a product manager when you're dealing with localization, globalisation.
Justin Woods:
It really does. And like we said at the beginning of the show is, it's so much more than than just that language and the complexities, once you dig down into it, you can see why for some products or for some companies, the regional product manager is a full-time job or even multiple people in order to be able to manage all of those things from a product management perspective, let alone a development and an implementation and a rollout perspective as well. Amazing. So Dave, I'm gonna ask you the hard question now, which is, if you could distil your philosophy of road mapping into a couple of sentences, how would you describe it?
Dave Barker:
This may not go done well with your audience, but I guess my philosophy is there's no easy answer. Having sat on both sides of the fence, building roadmaps as a product person and consuming roadmaps in various other roles, there's a constant tension between the two needs. And I don't think there's an an easy answer. And the heart of it has to be communication that's what the roadmap is all about. And in particular, the roadmap will change. I think when the roadmap changes, it needs to be communicated to whoever's got hold of the original roadmap needs to know about the change as soon as possible so that any resetting expectations can happen as soon as possible.
Justin Woods:
I think that's the absolutely the point is it shouldn't be, this is the roadmap, this is what we are building. I know that often when you read it like that, it can be seen in that way, but actually it's a starting point of a conversation. It's to make sure that we communicate what we want to do and to make sure we have alignment on that. And some people might not align and so the roadmap there is really to instigate those conversations rather than to necessarily say, "This is what you are getting and that's the end of it." So I think as you mentioned there, that communication is so important. And Dave, I know you've sat many sides of the table in your career too, around that roadmap.
Dave Barker:
Yeah, I saw a roadmap recently, which quite clearly stated in the sentence at the bottom, for the second half of this year, this is aspirational and lot of commitment. But I know very well that a lot of people that saw that chose not to read or understand that line. They saw a pretty picture above that said, "This country's coming in the second half of this year," and they've gone and planned accordingly. But there's every chance it won't happen.
Justin Woods:
Totally. All that disclaimer gets conveniently snipped off the bottom and then shared with sales or as part of an RFP and we were into hot water. Well Dave, it's been an absolute pleasure chatting to you today. Thank you for bringing some awareness of the complexities and nuances to product management from a regional perspective and in fact products from a regional perspective as well. A lot of things that maybe our traditional audience wouldn't have considered or realised it's going on. You play a really important part these days now as an independent consultant helping companies, not just in a product management role, but in many. I wanted to give you an opportunity to just to pitch your offering and share with people what you do and how they can find you.
Dave Barker:
Sure. Thanks Justin. Yes. Yeah, so as you say, independent consultant, but using my many years experience, a lot of that in helping companies enter Europe software coming into Europe, then offering consulting to product managers and others how best to do it. One of my kind of prepackaged offerings is a localization redness assessment. Being able to take a look at the product and the product team, identify how ready they are, what the experience they've got, things they may not have thought about. And then leading on from that help put together that justification, that business plan. So people can find me on LinkedIn, Dave Barker, and I've also got website antoinebarker.com. So happy to talk to anyone who'd like to discuss more.
Justin Woods:
Fantastic, well we'll make sure that we put those down below in the YouTube video. If you're listening on a podcast somewhere, feel free to go to talkingroadmaps.com and we'll have some of that down in the description as well. But all that leaves me to say is, Dave, thank you so much for chatting with us. It's been a real pleasure.
Dave Barker:
Yep. Justin, thank you very much indeed as well. Thank you.
