C. Todd Lombardo on the strategic role of product roadmaps
In a recent episode of our Age of Product Excellence podcast, host Scott Baldwin welcomed back product leader and author C. Todd Lombardo to discuss a subject he is extremely passionate about: product roadmaps.
C. Todd has done it all in the product world, leading both startups and enterprises. He’s also made a huge contribution to design and product topics in books such as Design Sprint, Product Roadmaps Relaunched, and his new title, Product Research Rules.
In case you missed the live event, here’s a lightly edited version of the conversation.
Product Roadmaps Relaunched came out in 2017. Why do you think the topic of roadmaps continues to be something we all need to talk about and settle on?
I think a roadmap is a good metaphor for a journey. For example, I’m in Boston, and I’m going to drive to the other side of the continent to British Columbia, where you are. There’s a destination – I’m going to go visit Scott. I’ve got a place to go, a vision of going somewhere. One thing that’s really helpful as product people is having that common destination that the team can rally around.
If we take the metaphor a step further, we’ve got a release plan, and that might be some of the turn-by-turn directions. Now, you don’t want turn-by-turn directions for every step of the journey, but having some directions can stop you from getting lost and allows you to change course if necessary.
“Teams need to have a sense of direction to help them understand where they’re going with the product and what they’re building for in the future. Roadmaps are very much a forward-looking thing, and I think we need that. Our investors need that, our customers need that, and our product teams need that.”
What do roadmaps do, and what do they not do? Or put differently: What should they be, and what should they not be?
Roadmaps shouldn’t be a release plan. I have heard about teams that literally thought their roadmap and release plan were the same thing. So taking them apart and treating them differently helps illuminate them.
“Differentiating roadmaps from release plans is one of the biggest points to evangelize when it comes to this topic.”
Your release plan is going to have dates, features, solutions, maybe even some more granular information, whereas a roadmap is much broader and more strategic in nature.
What are some of the attributes that great roadmaps have in common?
In the book, we talk about five key attributes – and we looked at hundreds of roadmaps when researching this subject. The ones that worked well had some level of vision or destination, some goals, some themes such as customer needs or a problem to solve, a broad time frame, and finally, a disclaimer explaining that this is a forward-thinking statement and things will likely change.
Just by putting that disclaimer in there, it gives you the OK to change. I think there’s some hesitancy in people because they think that if it’s on the roadmap, it must happen. But in reality, roadmaps are going to change.
So many roadmaps today are output or solution-focused. Why do you think product managers and others are so focused on the ‘what’ over the ‘why’?
Oftentimes people judge companies on what they make, not why they make it. We are still judged on that output. I’ve got a new iPhone, and I love it. It’s very hard to touch or measure the ‘why,’ but I can hold the phone in my hand, and I can point to a screen with some features.
But if you’ve read Simon Sinek’s book Start With Why or just listened to some of his talks, he explains that when you have the ‘why’ settled first, you can get more alignment and buy-in. You get this element of inspiration – and that’s really important.
That’s interesting because those key features like vision, objectives, and themes are more about the ‘why’ than the ‘what.’
Right. What problem are we solving? Why does somebody care if we solve this problem? The other thing is, whether we are product managers, designers, or engineers, most of us are trained to make stuff.
“There’s an output bias towards making something. And I’m not saying that we shouldn’t make things. I’m just saying that we should think about what’s the right thing to make. Just because you can make something doesn’t always mean you should.”
In the research for this book, we came across a study done by The Standish Group. They looked at 2000 software projects and over 1000 different companies of varying sizes, and they revealed that 64% of software shipped is rarely or never used. Think about that for a minute. Almost two-thirds of software shipped is rarely or never used.
If you had to help a team build out an objective or outcome-led roadmap, what steps might you go through?
“The first thing is learning the mindset of being outcome-driven and not output-driven. That is not an easy shift. It takes time to get to make that journey.”
You have to crawl, then walk, then run. Rather than jumping to a new way of doing things, try to just fix one or two things at a time. Maybe you could think about moving from features to themes.
If you’ve got some features on your roadmap, you could start to then ask what problem they will solve. You can start to lay those problems on top of the roadmap and put them next to each other. Then six months later, the features kind of disappear. Just do it very slowly and take the long view.
Then you could start to change the time horizon, moving from months to quarters or even halves. And again, always throw some disclaimers on there. These are subtle little things you can do, a little bit at a time, that can help you go from, “I’m going to build these features on these dates,” to, “We’re going to solve these problems in this order.”
Let’s dive a little bit into the communication challenges associated with roadmaps. What can product teams do to effectively tell that story and create alignment in their roadmap with other teams?
“It starts with ensuring that you have alignment around the vision and direction. Because if you don’t have alignment there, it’s going to be really hard to get alignment around a set of problems or features that you’re trying to work on.”
If you’re a product person, I recommend reading Never Split the Difference by Chris Voss. It’s a book about being a hostage situation negotiator. In a hostage situation, a terrorist might be asking for $10 million, and they might have 12 hostages. You can’t just say, “Well, I’ve got $5 million, give me six hostages, and we’ll call it a day.” It doesn’t work like that. You need to get all 12 hostages out and not pay the terrorist a dime – and you’ve got to do it through negotiation and persuasion.
The techniques they talk about in that book are very important for a product person to have – and not because you want to be this passive-aggressive bully that always wins arguments. You’ve got to know when you need to be persuasive and when you can’t let something happen for whatever reason — when you know that if you go down that road, it’s going to cause all sorts of chaos and not necessarily result in you reaching your goals.
“As a product person, being a problem preventer can be even more valuable than being a problem solver.”
Another thing to think about is having a lot of one-on-ones. It takes time, but it brings a couple of benefits. First, it builds relationships with your stakeholders. You treat them like you do your customers by understanding what problems you can solve for them. If you start to understand what problems they are having, you get a lot more alignment.
And unlike regular meetings, where there might be some politics going on, one-on-ones allow you to get more honest answers and a little bit more information. That can help you when you’re then trying to understand the root of their disconnect or misalignment.
Once you want to communicate your roadmap to people, it’s really about understanding who your audience is. The roadmap you present to your investors is not the roadmap you present to your customers, or even to your engineers. Different groups will want different information along the way, and you might need to either highlight or pull back different pieces depending on who they are.
I want to jump into the topic of positioning. Why do you think this is an increasingly important topic in the product management space, and what excites you about this shift?
I think I’m excited because in one of my earlier product roles I had a marketing responsibility, and I learned a bit about how to position products. I think April Dunford’s recent book, Obviously Awesome, lays it out really nicely. She tells this great story about when she joined a company and was about to kill a product, her boss made her speak to half of their customers, which was only about 200 people.
So she gets on the phone with these people, and the first 20 conversations were exactly the same – they tried the product and didn’t like it. Then, conversation number 21 was like, “This is life-changing. This is the coolest product ever.” And she was like, “Oh, tell me more. What’s interesting about it?”
“It’s all about finding the customers who love your product so much that they would freak out if it suddenly disappeared.”
On that point, that’s a good question to ask when you are thinking about planning for new product features: If we disappeared, what would you do? The answers will give you some insight into how your customers see you, and how well-positioned you are in the market.
So back to April’s story, she ended up finishing those 200 conversations, and she found that about five to six people would be really unhappy if they killed the product, but the other 195 couldn’t care less. That helped them reposition the product, then rethink their roadmap and how they could double down on that value.
If you can find some people who say they’d be really disappointed if you disappeared, you then need to ask some follow-up questions, like why do they care? What part of the product gives them the most value? For people who are on the fence, you can ask what would help bring them over the line. And for those who couldn’t care less if you disappeared, you can ask them who they think your product would be useful for.
The answers to these questions can help you think about what stuff you want to prioritize and build next, and how you can best position your product in the market.
How can teams better incorporate research as an input into roadmap planning? And in particular, how do you know you’ve done enough research or discovery to get going on this?
“There’s almost never enough research, but you have to feel like you’ve done enough to make a decision.”
That said, it’s better not to do any product research at all than to do it really shoddily. You should work on doing research with a level of rigor, but it doesn’t have to be a six-month effort. It could be a six-day effort, and as long as it’s done thoughtfully and rigorously, you’ll learn a lot.
Design sprints are a great tool for doing research in a short period of time to learn whether you are right or wrong about a particular product initiative. I’ve done hundreds of sprints, and you learn really fast if you’re moving in the right direction.
So if you pull together information from your data and analytics team, from your marketing team, from new market research and user research, do you have enough information to make better decisions? What information don’t you have, and how are you going to get it?
What soft skills can help product managers get better at building roadmaps and communicating that story to other people?
Every product is essentially a story. They have protagonists, they have antagonists, there’s a peak and a valley, there’s some kind of rising action climax, and so on. There’s always something there, and it isn’t always about the numbers. We’re irrational human beings, and it’s important that we bring a level of human emotion, connection, and storytelling to our work – and particularly to our roadmaps.
Ultimately, product people are translators and storytellers. We translate customer requirements into things that design and engineering can understand. We translate information about our products so that sales and marketing can talk about them properly and position them. We translate information so that our customer success teams know how to communicate and help our customers realize the full potential of our products. We’re that ultimate storyteller along the way.
