How many roadmap views and versions should you have? | Phil Hornby
In episode 2 of Talking Roadmaps, Justin Woods interviews Phil Hornby about the optimal number of roadmap views and versions a product team should maintain. Phil shares his insights on balancing detailed planning with flexibility, the importance of tailoring roadmaps for different stakeholders, and practical tips for effective roadmap management. Drawing from his extensive experience, Phil offers valuable advice for product leaders aiming to enhance their strategic planning processes.
Phil is a seasoned product leader, coach, and technologist with over 20 years of experience. His mission is to help entrepreneurial product teams to be successful. Phil has helped thousands across hundreds of companies, empowering teams to deliver exceptional results.
He is one of the cohosts of the channel and also the founder and director of for product people, a provider of coaching and workshops for technology-based product teams and entrepreneurs.
“One version, one source of truth, multiple views for your different audiences to communicate the direction of your product”
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 below! Look out for the full transcript of the discussion available soon along with a sketchnote to summarise and a blog post of the best bits coming soon.
Here is an audio only version if that’s your preferred medium - this will also be published on as a podcast eventually too!
We already have more episodes recorded with some real superstars of the product world, like Daniel Elizalde in Episode 3, so watch out for the next episode!
-
Hello and welcome everyone to today's edition of Talking Roadmaps and I'm joined by Phil Hornby who is the founder of Scale Business Performance. Phil, welcome.
I just pleasure to be here. I love the fact we've now got the name and the title. We can actually put it in there after the working title last time.
Absolutely. Well, it's iterative as all good things should be. Phil, tell us a little bit before we get going about your role and how you help people within the world.
I guess my pitch is I use help entrepreneurial product teams to be successful and so that's looking at both team dynamics, et cetera, but really it's focused on product people and I typically use training facilitation. So the training is to kind of upskill people and the facilitation is to help them explore their own product space, explore their own problems, and hopefully solve some of them along
The way. Awesome. And do you do that as a set of workshops or offline work or is it a combination of those
Generally? So it's usually training courses with live sessions as well, but some trainings live some trainings on demand.
Excellent. So taking them through a roadmap, if you will, which is a nice segue to where we're going to go on today's conversation, but essentially taking them on that journey.
Absolutely
Superb. So obviously you are an established business professional and veteran within the industry and you'll have been using roadmaps for a long time throughout your career as well. I'm interested to think about some of your perspectives of roadmaps. So maybe start off with in your mind what you think a roadmap is or what a purpose of a roadmap is.
So for me, the purpose of a roadmap is to strategically communicate direction. It's where are we going? It's getting everyone aligned and on board, but not everyone cares about the strategic level as well. So sometimes it also has a bit of a tactical element or an operational day-to-day element might notice. One of my concepts there is I always like to look through that strategic, operational, tactical lens of kind of the different levels.
Yeah, absolutely. And I think that's important, isn't it? Because a roadmap's not going to do everything for everybody and it's not going to be the one deliverable that gives everyone the information they need, but it sits quite in a specific area, right?
Yeah. I mean it's kind of one of the bridges between strategy and execution.
Yeah, I think that makes sense and I'd agree that's really how I feel from this as well. So with people kind of having a focus on the strategic side and the tactical side of things, who do you think the audiences of roadmaps are and can there be multiple?
Absolutely. Actually these days I'm on four, possibly even five different versions of views of the roadmap I would say because actually I think there should be one roadmap, but different people seeing different versions or different views of it. So my favourite one of them example is the internal facing one. So you've got your senior execs, they want something that's very long-term, kind of directional strategic, the path we're going on, but not the specific little micro details. Well actually some CEOs really want the micro details but they shouldn't. And then you've got that operational and development focused team. So the people who are going to actually deliver it and live with it, they want a much shorter, much more detailed view of things that helps them deliver and helps them get ready for delivering maybe up to a year out. Then going externally, you've got let's I start thinking layers of trust at that level it's how much do I trust these people outside my organisation?
So I've got getting all the way out to prospects, those people that they're not current customers, I don't dunno them that well. So they're going to get one level of information and there's a little bit of a catch 22 there. You want to share lots of information, you want to win the business, bring them on that journey with you. But if you share all that detail, then it's going to end up potentially in the hands of competitors. Now I cover philosophy there a little bit that with competitors you have to assume if you've shown it to anyone externally that competitors have seen it and you have to assume that you can now execute the competition, but there's still different levels of granularity or information you might put there for a prospect versus a customer who's a customer, someone who's buying from them, you've got a relationship with them and then you've got that kind of, I guess external relationship like partners when you're collaborating with them, they might need a slightly different version. Again, it's slightly operational, it's slightly strategic, but they're also not in that full zone of trust perhaps.
Yes, exactly. I was going to say that and I love the fact that you talked about those layers of trust, much like an onion skin model type thing. You've got these different levels of circle of trust and it makes sense. You want to show enough information to paint a picture, but not necessarily too much. And especially I love the fact that when you said sharing it externally, your competition can pick up. So you must assume that if you shared externally anybody could see it, but actually there's still advantages of being able to do that. It gains trust from your customers, which sometimes is more important, but also there are other ways to overcome challenges with competition out executing them for instance, or just being first sometimes can be the differentiator.
I just remember in the past where your clients would ask you, oh, can you leave a copy of the roadmap with you? And there'd be that sense too. It's like, no, we can't, and this was in the day, smartphones were already around, so someone would just stand up at the back of the yard and say, click, they've got it. What heck if the smart people they can just draw it? Usually not that much detail on there. So if you're going to show it publicly, yes, you might insist on NDAs, but you're going to show it, you're going to accept that it's out there.
Yeah, for sure. I think some of my favourite products or services out there have got some level of roadmap and showing you what's aspirationally possible. So I really like that. So talk to me through, we mentioned about maybe different types of roadmaps and the different audiences. Who in your mind do you think owns that roadmap or roadmaps within the organisation?
So I think at a fundamental level, it's product or product management. In fact, same product people seem to shorten to product management when actually shorten product management to product when actually there's product developers, product designers, et cetera. So got to be a little bit more specific, but I think it's product management that own it. But then there's different layers in product management. Not everyone's on the same level. You've got the juniors or associates or the product execs, you go to the normal product managers, the seniors, maybe the group product managers, the principals, the heads of the VPs of. So they all have different layers of influence and different layers of ownership. I think the product managers need to own their product and therefore need to control its destiny, but it needs to also interrelate with other products. So there's some external dependencies that somehow need to be represented in terms of how these things work together, how they play a bigger part and tell a bigger story as part of a portfolio. And then so you end up with different types of roadmaps if you are we talking portfolio, we're talking about individual products, sometimes even just a feature level and how granular is your organisation for that?
Yeah, it completely makes sense. And I think you've also, it depends on the organisation and the needs within it. It could be a small startup versus a large company. Like you said, there's so many variables in here to who owns that roadmap. Do
You have a view to pick up point there with the startups? I mean probably the CEO, someone on the founding team owns the roadmap in that context because the first product manager is often brought in just to be really tactical to pick up some of that tactical work that the C-suite don't have the time for because they've also got to worry about things like getting funding in. But essentially they are a product manager, that's what they're doing. They're doing the job. I don't care what job title someone has, whether they call the product manager, business development manager, product owner, product marketer, A CEO, are they doing product management? Are they really driving consistent repeatable delivery of value to both the business and the customer?
Yeah, for sure. And they often say that the CEO is the first product manager essentially of the organisation because that's what they've dreamt up and created. So completely makes sense.
I've even got a little more thought people talk about the product manager being the CEO of the product. I flipped that on. Its good. CEOs are like big product managers because good CEOs use influence without authority the same way as product managers do. Now that CEO of the product quote has been around 25 years I think it is now since Mark Andreesen talked about it and the principles were sound because it was saying you've got to drive the portfolio, look after it as your baby look after it as a business within the business essentially. And it said using those sorts of things like influence, but reality is actually product managers don't have that formal power usually. But good CEOs don't exercise that formal power, they use much more the same skillset as product manager. So I like to think of the product manager or the CEO as the big product manager because the business is their product
Completely. That resonates with me and I think I found that when people said that the product manager was a CEO of the product, I actually had some fundamental challenges with that because I've worked for some organisations where I haven't been given that flexibility or that ownership or accountability. So in some instances people will find that they're more glorified project managers that are expected to deliver as well as project manage. So I completely understand that and I love that kind of phrasing around the CEO being that product manager or the big product manager. Who do you feel then maintains that roadmap? Because we mentioned different audiences and things like that. So does that mean that there're multiple people maintaining it in your view?
I guess I'll come back to I think the product manager maintains so they're responsible for it. In fact, let's use that language so the product manager is responsible for the roadmap, but perhaps there's an accountability that goes into a broader team like the leaders in the product team and even the c-suite, et cetera, to kind of make sure it's actually delivering the value to the market and to the customers, but someone's going to live it and breathe it and that's the product manager and then they're going to drive it forward so they're going to maintain it in whatever form or tool that it's been done in.
Absolutely. I think they need to evangelise it and get people excited behind that single vision. I was going to say, and actually that's an interesting point which is what's the relationship of some of the higher level artefacts or I'm kind of biassing the question now maybe, but things like vision, strategy and objectives. What's the relationship of those things to a roadmap as well? What do you think that
So I think they provide the context, the frame. There are many things that are going to influence the direction you take a product. Some of them are internal, too many people talk about, it's all about following the customer. Well yes, but within a certain frame, within a certain context we've got as a business, we've said we are playing in certain games, we're going certain direction, playing with certain types of products, certain problems we're going to solve and that creates a context that can't be ignored. That's the internal perspective. So the objectives we're to achieve, are we trying to drive revenue? Are we trying to drive market share that defines things like what we're going to put on the roadmap and similarly the vision of what we want or the future we want to create that's going to define what we want to put on the roadmap, but obviously it needs then all that sense check out there in the world with the customers, with the market to make sure that people really want it.
Because one of the challenges can be that vision and strategy and objectives can be disconnected. It's there and it's created in isolation without the context, without the information from the market because senior leaders tend to be a bit more divorced from the market. You're the product person is the one who's in touch with the market on a regular basis talking to customers. Hey, I say they are not always, sometimes even they have things second or third hand through sales teams that limit their access to customers, which I don't think is good practise, but it happens.
Yeah, I've certainly been there myself leading internal products even though I could access some of those teams, there were teams of teams using those products and trying to get very specific feedback from those users was often very difficult. And so you have to sometimes make some educated guesses or some proxy level information from it in order to build that up. So that completely makes sense. And talking about those artefacts a vision and strategy, what do you feel are the relationship to roadmaps in terms of other related artefacts? There are things we can that support a roadmap document in your mind.
So I mean in some roadmap documents I would actually expect to see the vision and the objectives for example. Nice. Possibly even a high level statement of the strategy that's in there. And so it depends on whether we're talking about the roadmap as this one view of where the product's going or actually a bigger document, which I think actually makes more sense. It's a roadmap document with the context there, but also some relationship maybe to some lower level artefacts. Let's call them things like release plans, which too many roadmaps look just like the Gant chart with the dates we're going to deliver this on this dates.
What do you mean you need a release plan? That is the roadmap. Yeah,
When fundamentally they're different artefacts there for different jobs. Now I talked about that, the operations and dev version of the roadmap, those two things, the release plan and that need to really closely gel because giving them the direction in more granular detail and then there's essentially the release pack plan coming back saying this is what we're going to deliver. And that gives you a sense check that r and d know that what to deliver when it lines up with customer market needs.
Yeah, a hundred percent. No, it's great to hear those views. A lot of those, again, I just can relate to and understand and feel similarly myself talking about beliefs and things like that. What do you believe are some of the key elements then or the content of a roadmap? So potentially it's something that's accompanied by the things I loved your concept of a roadmap document, a roadmap should be standalone but actually would be best when you've got it as part of a narrative. But what do you consider as some of those best practises in roadmapping or sorry, the key elements or content of a roadmap. I'm sorry.
Yeah, I mean I guess I've been influenced quite recently a lot by roadmaps, relaunched by what they talk about in that book. I'm very heavily leaning towards the now next and later style of timeframes that Jana BA created and it resonates with me so much because it's more honest in terms of where we're going and when we're actually going to get there versus timelines that always slip or get descoped and then people are disappointed and I've come across lots of customers saying, well I want a date, I need a date. Or people, particular salespeople, not thinking customers will accept not having dates. But more often than not, the honesty of that style of timeline for example or timeframe is so much more realistic that people accept it very willingly because they think more likely to come true and they can see the priorities expressed in it.
And again, these see things like themes as it's called in the book outcomes or problem oriented roadmaps showing the problems we're going to solve for customers, not the solution we're going to deliver. They tend to be quite static. We say we're going to set out to solve a problem. I love that because I can work on solving that problem. Maybe also looking at what outcomes I'm driving for the customer and the business as well, those sorts of levels of things. But if when I get halfway through trying to solve that problem, I find out, well the solution I originally thought is the wrong one, I don't have to change my roadmap. That's right. I just deliver a different solution. I still solve the problem. When you get very prescriptive, highly technical customers, that's become a problem. They want to see the bits and the bites and exactly what they're going to get and they're thinking operational terms, really what the release plan should be telling them and expecting out the room. I think there was a Twitter tweet a while ago, I remember that I think it might have been John Cutler. He talked about how we need to understand the job to be done of a roadmap, trying to ask one document to do 10 different things because we're conflating, we think by doing it we'll be more efficient, more effective. We're an actual fact. What we're doing is reducing the effectiveness of a really powerful tool by trying to conflate it with five other tools that give different views and different information.
A hundred percent. And I loved your point there about being prescriptive with the roadmap there because again, that goes down the lines of a delivery plan and we dunno what's going to happen in the future. We shared a quote in the last interview that we had and it was just like, I completely agree if we talk about problems, the problem will exist and it leaves it open for us to be able to look at various solutions and be able to navigate different solutions. No one could have seen the pandemic coming, but if you've been so prescriptive about something then that might have derailed all plans. Whereas if you're still focused around the customer problem, then actually it leaves us multiple ways to be able to solve that. So I really like that it
Kind of resonates a little bit with to tourism the opportunity solution tree as well. One the bits of guidance in her book, it talks about prioritise the opportunities and by opportunity it means problems, needs, it's that level of thing for the customer. So you're prioritising that and you're showing that priority on your roadmap instead of prioritising the solution, which there might be a hundred different ways of solving it and well that solution might serve some other opportunity or some other need, but if you prioritise at that level, you are prioritising at the customer and the market level, which has got to be more powerful. And yeah, there's a trade off you might find its heist effort thing to solve, but if it's the most valuable thing to solve, that might be the right thing to
Do. Absolutely. And being customer-centric is so important. And in fact, it's interesting. You mentioned a couple of mistakes or we've alluded to a couple of mistakes already. What do you think is maybe the biggest mistake or mistakes that people make in road mapping? I think we may have touched on a few of those, but is there one that comes to mind for you?
Putting too many dates on. I mean I don't mind putting a date on. There are real realities of corporate life, of customer life, of market cycles and so on. So sometimes you have to commit to a date that's not evil and I don't care what an agile list says, I'm probably going to get a flame wall because of this now. But there are sometimes these realities we've got to make a commit to say we're going to do something by certain date. The implementation of something like GDPR compliance was not a negotiable thing. That's right. It had to be there done by a date and there's probably a thousand other things like that. So commit to those, great, but understand that that means that other things around it are movable and if you try and lock everything down, you're basically saying nothing's movable, there's no flexible, we can't learn anything in the market as we go along. Therefore let's not bother talking to customers. We'll stay in our ivory towers, we'll stay in our ivory towers. We'll just dream up wonderful things that we think are going to solve problems for customers and then we're going to get it wrong.
Yeah, that's right. Absolutely. But we delivered the roadmap. It's the wrong thing to be measuring. And what kind of bad practises or antipas do you regularly encounter? I think one of mine has been that you see that people use the same roadmap over to every different audience because it's easy or it's consistent, but do you see any antipas or bad mistakes in the work that you do with clients or customers?
Regular issue is that every three months they just move everything right by three months and just turn up and it's the perpetual same roadmap that it's just nothing's moved. They've not managed to move the needle, they've not talked to the customers to actually figure out if it's the wrong or the right thing. And so they just keep going on that same path, keep trying to push forward the same way, not making any difference to the customer, not making any difference to their business, just burning cash but feeling good because they're still telling a story of this is what's coming and then delivering on of it and so they just shift it three months every time. I guess another one is when you have timelines is being clear on timelines. People interpret timelines so differently. If you say something is coming in Q1 sales think that means January 1st, right? Okay. Product thinks it means 31st of March and development thinks it means sometime in April because they're going to slip and it's inevitable.
Right. That's great. That's brilliant. And so maybe a bit of do we cover the pet hate one there was that, the dates on roadmap, wasn't it? Yeah. Yeah, I think so. And that goes back again to what we were saying about levels of trust and I think that's really important actually, is that you are actually eroding the trust by putting dates on there that aren't actually even going to be realistic. So I love the fact of time bucketing these things up makes a lot of sense.
I mean, don't get me wrong. So far personally from a portfolio like physical products in particular, I've not found a better way than timelines. I've seen people trying to use the now, next and later, should we say three horizon style for it. I don't think it communicates things well enough because you often need to get into a catalogue or something like that and people need those hard dates and the timelines on hardware are much harder, much tighter, much clearer because you can do the analysis, you can figure out how to deliver it. Detailed functionality that's often glued by firmware, maybe not so much. But when you're trying to look at lots of things relating, I haven't found a better way and I'm striving for one, I'm hoping that through this process we're going to actually find one.
Yeah, absolutely. Well, I've come across many in my time as a product manager looking after the basket pages for Dell was the checkout system. There were tax and legal milestones that we had to meet. There was a cutover from Switch, do you remember the old switch payment type? Yeah. So we had to make sure that we were then moving across to the next billing system or payment gateway that was available because it was being shut down. So there's absolutely these critical legal mandatory milestones that we need to hit and also some crucial customer ones. If some sales are depending on something but it needs to be compromised with then having flexibility elsewhere, you are right. Otherwise we set ourselves up for a fail. Phil, I've been really impressed by some of the people that you've quoted and some of the resources that you're talking about. Whose kind of advice in the industry on roadmapping do you typically listen to or go to for information?
I mean, as you know, I'm a bit of a bookworm and I like my resources. In fact, when I run training courses I tend to send are lots of resources at people afterwards and I probably do too many, which means it gets lost for the wood lost in the trees. But I love resources, I love the learning aspect of it and you never know which is the one that's just going to click with that individual. Absolutely. But I think if I was to choose anyone, it'd probably be Bruce McCarthy and I guess Cton Lombardo and I think there's a couple of other authors of the roadmap relaunch book
Just because it's on my shelf behind me somewhere in there.
It's somewhere behind this green screen there. But yeah, yeah, for me it just kind of distilled down so much thinking, so many thoughts. I mean there are other sort of people who do quite a lot of work, Rob Far, Cambridge University seems to have a lot of good thoughts there. It's one that I haven't actually dug into yet, but it's on my planned list of things to dig into because I've heard good things from other quarters. But yeah, I generally end up just kind of finding the tool providers as well. There's tonnes of webinars, for example, by ProdPad, by aha, by prod board, et cetera, and they all bring slightly different perspectives and slightly different views. You start to see the philosophy of some of the founders and this sort of thing and what they believe in and how they think it should be done. And I think you can bring a lot from those by not necessarily going to always buying the tool, but listening to what they say about road mapping and they're thinking, well, what fits in my context? Because actually if I went back to an anti-pattern again or bad practise is trying to apply one size fits all roadmapping in every context.
That's right.
Product management is such a variable role because we're always dealing with different contexts with different organisational setups. Why would road mapping be any different? It's our core tool and we're in different markets with different technologies, et cetera. We've got to accept that there's going to be different best practises in different places that allow us to get the best out of it.
Absolutely. I mean one of the critical pieces of roadmap is a communication tool and if it's not resonating with your audience, it's missing the whole point of what it's trying to do. So flexing that to them and getting them behind it sounds like it's vital.
Yeah, yeah, I absolutely agree. For me, I think if it is a strategic communication tool, but then I've talked about other audiences and this, but that's where I think it's primary usage. It's that big strategic direction. So if I had to choose only one audience I'm maintaining it for, it's going to be that senior exec long-term version because that's the thing that I'm going to guide with and I can then use other tools like backlogs and things like that to do the more tactical work and I can use it in that context. But yeah, well as you said, communication is key and communication is for the audience, not for the sender. We've got to put it into how they need to receive it, not just assume that what we see is what they want.
Yeah, absolutely. No, I completely agree and I've seen it again done many times really well, and I've seen it done many times really, really badly as well. Just as a side question, have you seen any external companies or companies in the world actually creating external roadmaps and doing it well? I'm curious to think if you've had any examples of that.
I remember seeing some quite nice wands in the B2B context, and that's generally I've operated where there were a vendor coming in to talk to me about where they were going and I remember things on augmented reality technology. I think Matayo had a really great roadmap. They then got acquired by Apple, so their roadmap maybe was part of that. I don't know. That's the basis of all AR kits fundamentally, I believe. But you've got, I remember seeing some quite nice ones from Intel back in the day that were using a three Horizons print concept to present their physical, their hardware product roadmap as opposed to trying to put those fixed timelines there, which was quite nice to see. And reassuring Facebook's F eight conference back in 2016, they had a nice three horizons, one that they put out there. Now whether you believe that was what Zuckerberg really was doing, I thought, no, we will take that with a pinch of salt.
But with five years hindsight, you can look at it now and think, well, yeah, it makes sense. It stacks up what was important to them, what were they investing in to kind of build future capabilities that have then become the foundations of the metaverse, whatever we want to call that geeky thing. Yeah, I've seen a few roadmaps where they're kind of on Trello or something like that in the B2C space. Be honest, I've never really engaged with them. I find that too low tech, too simple. Maybe I'm just because I'm coming from quite a large B2B environment, I find that it's not telling me what I want to know as a customer.
Yeah, absolutely. In which case the roadmap isn't communicating or it's not giving you the information that you need and that completely makes sense. So obviously we've talked a lot about roadmaps and I really appreciated your views and your thoughts there. Could you sort of distil your philosophy of road mapping into maybe a couple of sentences? How would you describe that to people if they had no idea what roadmapping was or they had some misconceptions of it, how would you describe it to them?
I guess I'd start out by saying the name roadmap is problematic. If you think about a roadmap, it's an atlas, right? It's got lots of paths, lots of routes. It doesn't tell you how to get anywhere or where you're going. You need a route plan to go with it to say, take this turn, take that turn. We're going there. And so sometimes the analogy we've chosen has become problematic, but if I step back from there, for me it's all about alignment and communication for across the organisation and our customers. Helping us have a conversation with our customers that brings them on the same journey as us and lets them know that that's the journey we're going on that they can join us on. And having a conversation internally to make sure that everyone's lined up. The people who can see that long term, can see the long term people who need to see the short term, can see the short term. Now that was about 10 sentences, but I guess maybe I can distil it down a little later.
It makes sense. All the points were there and I think this is again, one of the challenges and why road mapping is such a big subject is that it serves so many different purposes and can take so many forms. It can be quite difficult to pin that one down.
Yeah, I've thought of something I'd say as my philosophy. Yeah, go ahead. One version, one source of truth, multiple views for your different audiences to communicate the direction of your product.
Well there you go. Smashed it. I think that's great Phil. Thank you for that. And I'm just wondering before we wrap things up, is there anything else that I should have asked you about road mapping but maybe didn't anything on your mind that you'd like to discuss a little bit more with us?
One thing that I'm a fan of is really visual roadmaps. Make them as visual as possible, as pretty as possible. I know it sounds cliche a little bit, but they don't have to be these big tech blocks of text. They can actually be quite graphical, quite visual. They help the storytelling aspect, but also critically for you as a product manager leave you with some latitudes and flexibility because they're not pinning you down with tonnes of detail.
Awesome. Awesome. Phil, really great speaking to you and getting your thoughts on road roadmapping there. Thank you so much. Love to give you an opportunity just to remind us again of what you do and how you help people. We'd love to hear.
So yeah, Phil EY am the founder of Skill Business Performance. We help entrepreneurial product teams to be successful through training facilitation.
There. It's I,
I'm sure my link will be down below. Why not reach out and connect?
Absolutely. Yes, exactly. Phil, thank you so much for that. We've really enjoyed spending this time with you. Folks. Please remember to follow and share this if you found value and you want to share that with other people and do get in touch if you'd like to be part of this. And actually we'd be delighted to interview you. Reach out and let us know and that will be excellent. Alright, thanks so much Phil.
