Can we have a roadmap and custom work? | Steve Johnson
In episode 20 of Talking Roadmaps, Phil Hornby interviews Steve Johnson, a product success coach, on the nuances of creating effective roadmaps while balancing custom work. Steve delves into the real purpose of roadmaps, distinguishing them from release plans, and highlights common misconceptions. He shares insights on agile product management and the importance of simplicity in processes. Steve also recounts a humorous anecdote about the unrealistic expectations often placed on roadmaps.
Steve Johnson is a product success coach focused on removing the chaos from product planning. He’s the founder of Product Growth Leaders, where he uses modern methods to guide product teams from idea to market in only a few weeks. His approach is based on the belief that minimal process and simple templates result in a nimble product team. Steve is a former instructor and executive at Pragmatic Marketing and the co-creator of the popular QuartzOpen framework.
Steve is the creator of Fundamentals of Managing Products, which provides a strong foundation for the mechanics of product management. Remove the chaos from your product management process.
“We allocate 100% of our resources for the roadmap and plan the other 100% to do specials”
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).
Next up we have Randy Silver Product Management consultant, coach, speaker and author. As well as co-host of The Product Experience podcast. So watch out for Episode 21!
-
- Welcome everyone to the latest edition of "Talking Roadmaps". It's great to have you here where we talk to everyone about the good, the bad and the ugly of road mapping. I'm really pleased today to be joined by Steve Johnson. Steve, please introduce yourself.
- Well, I'm Steve Johnson. I am a founder at group called Product Growth Leaders, where we do training and coaching for product management teams. I have been a consultant for 25 years, starting in the mid '90s with Pragmatic. And about 10 years ago starting up my own boutique, if you will. And our focus is on simple methods, simple process, effectively agile product management.
- As with any YouTube channel, I've gotta do the whole, please do like, subscribe, and hit that bell icon just to show us some love and kind of keep updated on how things are going. So let's dive straight into it though, Steve. What's the purpose of a road map?
- Well, the purpose of a road map is to imply that you can do more than is actually possible with the resources you have available, or so it seems. Road map is one of the most popular or most often requested documents from literally everybody. And yet nobody can seem to agree on what a road map is. And so I think the word road map is really helpful. When you plan a trip you get outta map or you go to Google and you say, all right, how do I get from here to there? And it says, here's your route, which is what a road map is for. It's not a release plan. Janna Bastow from ProdPad says that the road map is a prototype of your strategy. And yet the delivery people the customer facing people, they're like, oh, no, no, no, we want this to be a committed set of deliverables that we can ensure a year in advance. And I had a meeting a while back that was particularly funny. They said, "Steve, can you commit to this road map?" And I said, "Yes, I can commit to this road map. We will do nothing more than is on this road map." And they went, "Oh, whoa, whoa, whoa wait a minute. We need to have all these other things." And I'm like, "Well then I can't commit to the road map."
- You talked about everyone wants a piece of that road map. Everyone kind of wants one. Who is that audience? Who are those everybody?
- Executives can't read. They ask you for a business case. And there's just two darn many words in it. So many of us have said, well, okay, here's my business model Canvas and here's my road map. Here's a picture of what we're going to do, which I think is the appropriate use of the road map. First here's a set of work we have to do, and then once we have this, we can do this. And once we have this, we can do that. And just like a road map you're gonna drive from here to Maryland to Connecticut to Massachusetts. I forget what the order of estates are. But it's my plan, right? But on the delivery side, they're like, no, no, no, I need to know what features are coming out and when. And I go, "Well I'm kind of curious of what leads you're going to close and when?" And salespeople are like, "Hey, whoa, that's entirely different." But it's actually kind of the same. We generate a whole bunch of leads in marketing for sales to follow up on. And some of them they follow up on. Some of them, they say, you know what? This isn't very important, or this isn't a very good client. Or for some reason they disqualify them. And guess what? We do the same thing in feature requests. We get a thousand feature requests, we've got a team that can do 50 of them. So we have to go through and lop off a bunch of stuff. But I think fundamentally the road map wants to be, here are the initiatives or epics that is part of our overall plan. And yet sales in particular says, "Well, no, I want the road map to be something else. I want it to be a committed schedule." And development also says, "I would like to see where we're going and I don't want you to commit me to any sort of a schedule until I've had a chance to actually look at what you're talking about. Because I do believe that only the person doing the work can give you a reliable estimate on the work."
- And even then it's questionable if they can really be reliable.
- Correct. I do remember one of my favourite DEV friends said, "This would take about a half a day. I'll be available in six months to work on." Right? So even when they estimate, it doesn't mean starting tomorrow, right? And so for instance, a general rule is we no longer put dates in road maps, dates belong in schedules. And yet even with fuzzy dates, like second quarter, each audience hears something different. I mean, development says, "Oh, delivery and second quarter means midnight on June 30." Maybe.
- They probably mean they just checked the code into the repository now Q&A need to do their work and will get it sometime in Q3.
- Right. And then marketing says, "Well, gosh, second quarter, that would be when I come into work on April 1st." Right, and then salespeople somehow feel like they need, second quarter for them means we have to start building pipeline in first quarter. So I'm gonna need a whole set of sales enablement tools starting on February 1st or something like that. The road map does not have dates, I think is the big idea. And it says this is the sequence of events we have to go through. What other people are calling a road map can only be produced after we have done project scheduling, because other people are calling a release schedule a road map. And they're using the wrong terms. And I'm crazy about terms, by the way. I mean, when I went to college, marketing was strategy, and then when I joined business, everybody said, "Oh, how are you gonna market this?" Meaning promotion? And some companies call it a product owner, some call it a product manager, some call it a product marketing manager. So words are really important. And the most common misuse I see is people referring to a road map when they need to be referring to a release schedule.
- We're asking the road map to do too many jobs. You're asking it to give that certainty of timing and dates and provide direction. And what we generally end up doing is making those both things badly.
- Exactly, it's kind of like a sofa bed. It's a bad sofa and a bad bed.
- Yeah. So, okay, we talked about who's looking at it? Who owns it, who might maintains it?
- Whoever is responsible for the product strategy, which is itself a whole other conversation I'm sure. I did see some survey data the other day that suggests that 60% of product managers don't have a strategy, which means we're just keeping on, keeping on. We're just continuing whatever trajectory we were on. But what I've seen evolve over the last few years is particularly interesting that product management for 25 years that I know of has been a strategic role, a business role. And even in the early days of Agile, when the creators of scrum were describing the product owner role, they were describing a business role. And yet now we see most product owners are actually what we used to call business analysts. They're Jira ticket writers without strategy, right? So there's actually like three roles. There's a strategy role, there's a release planning role, if you will, the product owner role. And there's a go to market role that I like to call product growth. A lot of companies call product marketing managers, but for me, the goal is to grow the product we now have, and yet we need somebody else thinking about, well, what's the next product we ought to have?
- Product management has always, and I will maintain that it is a strategic rule for what... One of the things I've kind of commented a few times recently is why are there so many product managers? And I think it comes down to, because it's shifting to be a bit more tactical in many organisations.
- I was on a panel of consultants a few years ago and the question from the audience was what is the scope of product management? And I had just done my strategy, planning, growth thing. And the last consultant said, "Oh, what product manager's job is to do everything that no one else wants to do." And I think that's kind of the essence of your point is we didn't hire a project manager, so somebody needs to do that. Hey, product manager, would you please do that? And oh, we don't have any UX designers. Hey product manager, why don't you do that? Hey, we didn't hire any sales engineers for our B2B products, so hey product manager could you do that? And I don't know what these product managers were doing before, but I've never been in a role where I had any extra time. And it seems like most product managers are so busy helping understaffed or under-skilled teams that they often have little time or no time to do what you and I would call product management, product strategy.
- Spend the time in touch with the market, understand it, and then say, what the heck are we gonna do about it?
- Exactly. I like to describe to somebody who is looking to be a product manager. As the product manager is really a problem manager. They're looking for problems in the market, or if you don't like that word, friction in the market. When a buyer has friction trying to buy our product, that's an opportunity for us to optimise. When a user has friction using our product, we need to understand that and so we can build a solution to that. But I'm amazed at the number of product owners or really even product managers of whatever role have had no, I mean, zero customer experience. So how in the world are you gonna prioritise for business value? How in the world are you going to represent the business in the market, in your meetings with development if you're not allowed to talk to customers? And I talked to somebody just the other day, he said he'd been at the company for four years and have never met a customer except on a sales call where he was told to just be quiet until he was called on.
- What about other related artefacts, like vision, strategy, objectives, how do they link into the road map?
- Well I think that's one of the things that I've certainly seen from Bruce McCarthy that I strongly applaud that if a road map is a vision document as I think it is, then we should have the vision on the road map. One of the examples I use in my training class is the Apollo programme, which is a really funny analogy to use because none of the people in my class was born when the Apollo programme happened. But in 1961, John Kennedy said, "We're gonna go to the moon." And it was kind of interesting the way he put it. We're gonna send a person to the moon and bring him back before the decade is out. So, wow, here's a vision that is pretty good. I mean, it's gotta accept his criteria, you gotta bring him back. And it's also got a timeframe, within a decade. And so James Webb, I think this is right, who we now know for the Telescope that's been deployed. James Webb honestly didn't know how they were gonna do it. And so what they did was a road map. They broke, go to the moon down into seven major initiatives. First we're gonna have to get a rocket to leave the Earth. I mean, when is that gonna happen? And if you've watched any history, I mean, when he made that announcement, I don't think we'd actually gotten a rocket into space yet. And so they broke it down into seven initiatives. And guess what? We can't begin the second one until we've succeeded at the first one. And we may have to do it multiple times. And nobody had any idea how long those missions would take. And one of the engineers or actually I think he was the programme manager, said yeah, we were over budget. The reason we were over schedule and over budget is we were doing things that had never before been done. And budgets and schedules are based on experience with previous work. And I find in many of the organisations we work in, the team that's doing the work is not experienced doing that kind of work. And we don't take that into account hardly at all. So I've taken you far field, but things that belong on the road map. Yes, definitely a vision statement. I think we're all agreed that the now next beyond or now next future time scales are the way to go instead of quarters or months. And then one other thing that Bruce McCarthy calls out in his book is this information is subject to change. I have a friend who development team got COVID and went to the hospital, the whole team in the hospital with COVID. And the leadership team was like, do you think this is gonna impact our schedule? Yeah, I'd say it probably is.
- Companies talk about carrying risk for example, quite often as well. And that's an example there is like, and they're just assume that that means it's still all gonna be all right on the night we're gonna deliver, we're just gonna carry it, but it'll never actually happen. But there's tonnes of risk in everything we plan. And that kind of direction we put in our road map.
- Again, the road map is such a powerful example because I can make a plan, but then maybe I don't leave at nine o'clock, maybe I leave at seven o'clock because I wanna beat the commuter traffic. But oh gosh, maybe I encounter traffic or an accident and the whole road is shut down. I mean, there are so many things that can go wrong in a journey that either we lie to everybody and say, all right, we're gonna give you a 300% estimate or we just say, "Hey, this is our plan, we're gonna adjust it as reality hits." And I honestly think this is one of the real benefits of Agile is it says, you know what, we're gonna work for two weeks. We'll show you where we are. If we need to adjust, we can, we're gonna work two more weeks and we'll see where we are. And I have for, gosh, my whole career said, I would rather ship what's ready on a date than ship what's ready, whenever it's ready. And so many organisations still seem to have a waterfall orientation of, no, we have a fixed scope and a fixed date. And they have no recollection that we've never succeeded at that, right? So again, a road map is a way of saying here's what we're working on now, here's what we're working on soon, here's what we're working on next.
- That's interesting 'cause I was actually training a team just this afternoon in fact and saying the same thing to them but getting a bit of they were pushing vaccine on my customers, my managers, my sales will never accept. I said, in my experience, sales are the ones who will fight the hardest against it. The customers will generally look at and say, "Oh, okay, that's more honest."
- I used to hold a customer advisory board. And the customers would request, "We'd like to see your road map." And I said, "Great, I'd like to see your road map." And so we'd get together me and like 10 CIOs or whoever our customers were in my case it was CIOs. And we would each share our road maps. And what their deal ultimately was not I want to have feature X and the sales guy promised it to me. What they really wanted to see was, was my business viable going forward? I mean, they don't wanna make a big investment in my enterprise product if I'm gonna go out of business, right? But also, am I headed technically the way they're headed? I mean, am I moving to the cloud? Am I moving to Linux? And so that they can synchronise their plans and if they see that I'm going someplace they really don't wanna go, then they've gotta make a decision about that.
- Yeah. You used to do something very similar on 20 key customers. What's your road map? What's ours? Let's see if we're on the journey together.
- Exactly. To me that's what customers want. Not when are you gonna have a report that does this thing, this one tiny minute thing that I want? And yet I don't know why we get into these arguments with the sales team. Another person who is interested in the whole road map thing is the chief financial officer. Typically they do not want anybody talking about futures because here in the US at least you can't recognise revenue on any deal that is contingent upon future deliverables until those deliverables are delivered. So if I present an 18 month road map, then I may have to delay the revenue for 18 months. And sharing that with sales is easier when I say it's going to delay your commission for 18 months. Suddenly they are not interested in sharing the road map any longer.
- So we've talked about kind of linking to vision and strategy. We've talked earlier about a release schedule. Are there any other artefacts that kinda link into our road map, have a relationship to them?
- The way I teach product management, there's actually... I think product management is easier than we make it. I think there're just a few key artefacts that we oughta have a product Canvas that expresses what the product is, who is it for, what problems does it solve, what vision do we have? We've got a road map, we should have something like a con bond board. And frankly the con bond board is the better indicator of your schedule. So the release plan that I talked about, I think as much as anything is a dump of your con bond board. Here's what we're working on now, here's what we'll work on soon, this is what we'll work on next. And what else? Let's see and probably a launch plan because you need to coordinate multiple groups. But do we actually need all these plans and all these meetings and all of these get togethers? I think that we've kind of patched it with adding an artefact or adding a meeting or adding a ceremony. And for an example, I hired a new product manager and assigned him to this one project. I went to a meeting and I didn't even know what the meeting was about. And it was about his project and he was there, I was there and four or five, six other people were there. And I said, "Hey, Bruce works for me, he's great. Which of us needs to leave because there's no reason for me and Bruce to be here." And they said, "Oh no, no, no, we need Bruce because he knows stuff." And I'm like, "Oh yeah, good. Well I don't, so I'm gonna leave." And they're like, "Oh no, no, you can make decisions, you're a VP." And I'm like, "Bruce can make decisions." And I just wonder if we have failed to empower our teams to make decisions to push decision making as far away from senior leadership as possible. And so we end up with these enormous meetings of dozens of people trying to make a decision which is impossible. So I think we could make product management a lot easier if we just had a few key things. The Canvas, the road map, the backlog and then a launch plan, maybe that's all we need.
- I've had some much the exact same conversation. It's like, okay, there's three of my team invited to this, including me, which of us is going. In fact, we got to the point where it's one of our rituals as the product team who's going to this one now? 'Cause we've all been invited and we do in our team standup. It's like, okay, we've all been invited. Who's got the ball on this one, right? What do you need to know? We're out of it. What I've found is the more you share the big picture and the context with the rest of the team, the less of them you have to attend as well 'cause they're all on the same page as you.
- Indeed, well that reminds me of another principle that I strongly favour. And that is the more we can get others to understand the big picture, we don't have to get involved in the little picture. So for instance, I've long been an advocate for personas. And if we don't have them, then developers assume that our customers look just like their developers or their mothers. So those are the two kinds of people in the world for a developer, me and my mother. And yet our customers may be entirely different than that. So we build a persona, we teach them about their story and their challenges and then when they have a question on how to implement something, they go, "Well what would Sally expect?" As opposed to, well if it were me I would wanted to have 72 options. But if it was my mother, I would want her to have no options. And actually Sally needs three or four options. So the more we can provide context, the happier we'll be. And to run with that just a bit further, my first job in product management was such a good learning experience because it was a really good team. And I said, how can I do well here? And I was afraid they were gonna say, "Give us better specs, give us better prototypes." And I was hoping that wasn't what they wanted and it wasn't. They said tell us what's going on in the business. We wanna know where's this company going? What other products, how other products are doing, how our product is doing, what promotions you're planning for our product? And I realised that they wanted the business context that I was taught in the role of product management and they had not been getting it from their product owner who was coming in saying, "God spoke to me in a dream and I believe we need a button on the screen." I think so many organisations think that development is factory work. That we just sit here and punch out Jira tickets. And my friend Rich Mironov said, "Product management and development is like parenting. We build this thing that we love and that we're proud of and that we hope does well and goes off to college and has a good life. I mean we're super excited about the health of our product and no one else in the organisation really looks at it that way." But again, the more context you can provide to your team about what's going on with their child the better off it you'll be. So if you have an engaged, empowered team and provide them with context, you don't have to give them all the detail. If what you have as factory workers who say, "Don't bother me with all that context, just tell me what you wanna build." You have to give them specs.
- The one problem I have with the metaphor of raising a child is at some point I'm probably gonna kill this thing. And so I more think about it is rearing cattle 'cause I'm rearing it, I care about it and I'm gonna sometime take it to market or I might even slaughter it but 'cause that's the right decision for the business maybe.
- Well I had not thought of that aspect. So yeah, that is a very big difference.
- It's one that's been bothering me for a few years 'cause I've talked about it being cradle to grave, my baby as a product. And then I thought, hold a second, I don't want to outlive my baby.
- I was doing a training for a company not too long ago and the product manager came up and said, "Are you Steve Johnson?" And I said, "Yeah, why?" And she's like, "I have your business case." And it had gone like through four or five product managers to get to her and she's like, "I've just been following your business case from years ago that you wrote." Which was a little bothersome, but still it was not like I stay with my product all that time. There are other caretakers.
- Metaphors at some point you always find that there's a little challenge with the metaphor, which is one of the things I think about road map, the metaphor doesn't always help us because actually the road map itself just shows the options. It doesn't show the actual route, the root plan that you talked about earlier. And I think really when we're using that metaphor we're actually combining a number of things.
- I think that's true. And I think that's why it's so confusing that people equate it with okay, therefore I go to road to Google Maps and I print out a plan and it says, get on this road, you'll stay on this road for 47 minutes, get on that road, stay on that road for 15 minutes, then turn left. I mean, it's certainly not sort of specification document that you would get out of a mapping programme.
- Let's switch gears a little bit. Let's think about design on a road map. What are the key elements or content that we have on this thing that we call a road map?
- Well first I would say initiatives and epics, not features or stories. And I did mention subject of change without notice vision is good. I wonder if it wants to have the name of the executive sponsor. Like if you have any questions, go talk to that person instead of calling me. Another one would be audience. I think you do have different audiences and therefore need different road maps, which is why having some kind of automation is pretty helpful.
- Are there any particular tools you like using?
- Before the software existed, I was still using either PowerPoint or Excel. I could do an awful lot in Excel by using pivot tables and such. And of course that is one of the problems in product management is you do your road map in Excel, I do my road map in PowerPoint we both present to our senior leadership going, "Do you guys work for the same company?" This inconsistency of our deliverables is I think reflects poorly on our professionalism. There are certainly two or three, four really strong players today. And in particular, I think it's ProdPad that I saw the other day, has the ability to publish to your website multiple flavours of your road map so that you've got real time information. So the sales guy can say, "Hey, here's the road map." Slack's road map is in Trello and it's publicly available. Which I think is somewhat nervy that, I mean, yeah, we can put our road map on the web. I hope you like what the road map says. So I think enterprise salespeople would say they would want that and then they would see it and they'd say, "Oh, I don't want everybody to know that." And maybe you don't want your competitor to know where you're going either. I think in B2B we tend to be overly secretive and I think maybe in B2C they are not quite secretive enough. I remember seeing one where the objective had a question mark on the end. It was something like, would changing some aspect of the product, I forget which increase retention? And so they were putting in major experiments in their road map, not just major design and development directions.
- We've kinda figured out what's on there. Are there any particular best practise or bad practise or anti patterns that you think of on a road map?
- Well, I do see a lot of bad behaviour in road mapping. I see features rather than themes or objectives or trends. I see features and I see day commitments. And no matter how many times you say it, if you put a date and a feature on the same document, you have made a commitment. The other one is what's becoming kind of a famous quote for me is we allocate 100% of our resources to the road map and then plan to use the other 100% of our resources for special situations. We can only do what we can do. I mean this is the essence of Agile. We're gonna work on the top priorities now and then next week we'll work on the top priorities then. And who knows how well that's reflected in the road map, which is why we talk about themes and initiatives and objectives. So in terms of anti pattern, having features and dates on a road map is never a good idea. Let me quote Mark Twain. "Stick to the truth, it's easier to remember." So when you're putting together a road map, what do you know to be true. And leave your hopes and dreams in a different document.
- Whose advice on road mapping do you listen to?
- I'm a big believer in Bruce McCarthy and the team that he worked with to write their book on road mapping. I also follow Rich Mironov and John Cutler. And of course the various presidents of the road mapping tools companies.
- If you had to distil your philosophy on road mapping into one or two sentences, what would it be?
- A road map is a plan, not a commitment. It shows you how we will achieve our vision.
- Is there anything else about road mapping that I should have asked you?
- I think people are asking too much of a simple document. They want it to be the answer to all questions. It's a magic document that people think will shorten the sales cycle and improve the visibility in the market and a myriad of other reasons. And a road map's pretty straightforward. It's how are we going to achieve our vision?
- Here's your chance, Steve, give us your pitch for Product Growth Leaders.
- We started Product Growth Leaders a few years ago because largely we couldn't find a community for experienced product managers. We found a lot of newbies and wannabes. These people say, "Oh, we've got 20,000 people in our Slack channel." And you're like, "No, you've got 2000 who have ever returned the second time." And all of them say, "How do I get a job in product management?" So all these boards that I have gone to and LinkedIn groups and all these places, I find a bunch of wannabees or newbies. And yet I knew there was a body of experienced people who wanted to talk to one another. So we started this community and as we've worked with teams, we found out that they needed a different kind of training. And so over the last few years we've developed applied coaching as training. And we now offer a class on strategy. We offer a class on planning and we offer a class on growth. And each class is 90 minutes a week. Learn one thing, use it with your product and then next week we'll learn something new. Because what we found is if you don't use a technique within a week, you forget the technique. So Product Growth Leaders does training and coaching for product teams on how to do product management correctly.
- Steve, it's been absolutely wonderful talking to you today. Really just wanna thank you for your time. Please do remember to like, subscribe, hit that bell icon and follow us on this journey listening. And if you would like to join us here on the channel like Steve do get in touch, reach out by info@talkingroadmaps.com and we'd love to have you on the channel to talk about it. Steve, thank you very much again.
- It was a pleasure being here. Thank you.
