Should your roadmap show ambiguity? | Teresa Torres

In episode 32 of Talking Roadmaps, Justin Woods interviews Teresa Torres about integrating ambiguity into product roadmaps. Teresa discusses the importance of embracing uncertainty in the product development process and how it can lead to more innovative solutions. She shares practical tips on incorporating continuous customer discovery to make informed decisions and balance long-term vision with short-term flexibility.

Teresa Torres is an internationally acclaimed author, speaker, and coach. She teaches a structured and sustainable approach to continuous discovery that helps product teams infuse their daily product decisions with customer input. She’s coached hundreds of teams at companies of all sizes, from early-stage start-ups to global enterprises, in a variety of industries. She has taught over 12,000 product people discovery skills through the Product Talk Academy. She’s the author of the book Continuous Discovery Habits and blogs at ProductTalk.org.

“How we communicate the what and when without glossing over the ambiguity and uncertainty”

— Teresa Torres

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).

Should your roadmap show ambiguity? | Teresa Torres

Justin Woods and Teresa Torres

In the next episode we are talking to Matt LeMay, Product Leader, Author and Consultant. So watch out for Season 1 - Episode 33!

• Transcript

  - Hello and welcome to the Talking Roadmaps channel. My name's Justin Woods and I'm one of the co-hosts here. If you're new to the channel, Talking Roadmaps is about all things to do with roadmapping, the art, the craft, a bit of a science in there as well. If you're new to the show, please do have a look down at the description. We have special guests involved and I'm gonna introduce one of those to you today. We're speaking with the one and only Teresa Torres, everybody. Welcome.

  - Thanks, Justin. I'm excited to be here.

  - And if you find value from our conversation, please do give us a like, maybe subscribe to the channel if you're watching on YouTube and maybe tell a friend and let them share some of the value as well. Just give our listeners a little bit of a background to some of the great work that you do, Teresa.

  - I work as a product discovery coach. So I basically help teams make better decisions about what to build. I teach a customer-centric approach, I teach a continuous approach. We can get into all of that, but yeah, really the goal is how do we make sure we're building the right things?

  - Fantastic, yeah, it really is and it's something that we're definitely passionate about. I'd love to talk with you about some of those because when we talk about roadmaps, I think the scope is quite large and a lot of people, I think, narrow down into the wrong types of things. But speaking with the co-host, my co-host, Phil Hornby, we've often talked about things like there should be discovery roadmaps, there should be exploration roadmaps, not just what people often think of as delivery plans. I'd love to explore some of that with you. So maybe we go straight in and talk a little bit about what is the purpose of a roadmap and what do you feel about a roadmap from your experience?

  - Yeah, I think traditionally a roadmap has helped an organisation coordinate effort across the organisation. So if we look at a traditional roadmap where we've got a list of things that we're building, the dates by which they're gonna launch, what does that allow? It allows marketing to come up with launch strategies and run marketing campaigns. It allows salespeople to tell their customers, here's what's coming when or that's not on our roadmap, is on our roadmap, that kind of stuff. And I think what's important is to recognise those needs are real, right? We do need to coordinate work across our organisation and we do need to tell our customers what's coming. And we do need our sales teams to know what's coming and our marketing teams certainly need to coordinate their activities. I think the challenge with that traditional format is that we're not very good at predicting the future. So we tell everybody this feature is being released on this date and then we miss the date and that actually causes a lot of harm. So what's nice is that we've seen a lot of iteration and evolution of roadmaps in organisations and I think we're getting to some better models. But I think I will start by saying, if your roadmap is still a fixed list of features with dates, it's probably time to start looking at some alternatives.

  - Oh, totally. Absolutely and in fact, I'd love to visit that. We'll go into that in a bit more detail later on when we talk about some of the good and the bad of the roadmaps because I think we've all started somewhere. I think some of my first roadmaps certainly looked more like delivery plans and project plans. And as I got more experience in the world of product management, I used to be a product manager at Dell and at Vodafone in the UK, started to see that that is so far down on the right hand side, that actually there's so much more that needs to happen upfront of that. If people are thinking their roadmaps are a delivery plan, there's absolutely room for a delivery plan, but there's so much more that comes up front of that. And Teresa, you are one of the people that I often think about that are way upfront in terms of let's the exploration, the discovery, because by the time we've got to commitment to build, that's where the expense comes in. We should be leading with experiments and curiosity. I think that's certainly something that you would agree with.

  - Yeah, definitely. I like to always put things in their historical context, right? So I think roadmaps started being really delivery-focused because organisations used to be really delivery-focused. Software used to be a lot simpler and when software was simpler, it was easier to sit in a room and say, "Hey, this is what we should build," and we often got it right, right? I think as complexity has gone up, the percent of time that we get it right has gone way down and that's required new methods. So I don't think that the old style roadmap was a bad idea. I think it's just an idea that we've sort of evolved away from 'cause it's stopped working. And we're just starting to recognise we can't really predict in January what we should be building in March, let alone July or November. And I feel like the last few years have been a really good lesson in this. I mean, most teams, if they started the year in 2020 with a fixed roadmap, my guess is, by March, when we all started working from home and things shut down around the world, there were some changes to that roadmap, right? Now, hopefully we don't face a global pandemic most years, right? But we are seeing a huge increase in the rate of change in our industry. We're seeing software complexity go way up. We're seeing markets get a lot more competitive. We might be on the brink of a brand new technology revolution with Web3. I say might 'cause I'm not convinced yet, but I hope, right? And so, I think that it's not, things aren't gonna get slower, things aren't gonna get simpler, we really have to adapt to a more complex world. And that's what I think is driving all these changes in our roadmapping methods.

  - Yeah, massively, going from the outputs to more outcome-based roadmap is really important. And I think that's the transition because nobody roadmapped COVID and the pandemic on their roadmaps on their delivery plans. But upfront from that, the customer problems and the opportunities are still there regardless of a pandemic, right? They're the things that we must solve for our customers.

  - Yeah, you're introducing two ideas that I think are really important here. So first, when I was working as a product manager and I was thinking about how do I get away from this fixed roadmap, the first thing I iterated too was a outcome-focused roadmap and a lot of people do that, right? They say, "This quarter we're gonna work on this outcome. Next quarter we're gonna work on this next outcome." And I think that's a good... Actually I think maybe themes happened before that. We don't know what solutions we're gonna build, but we're gonna work on these themes and eventually themes kind of evolve into outcomes. And I think those are both two really good iterations. The challenges with both of them is we don't know how long it's gonna take to deliver a theme. We don't know how long it's gonna take to deliver an outcome. So there's still this idea of we can't predict the future. So if we're putting a date on our roadmap, we're kind of saying we think we can predict the future and if we're getting a lot of evidence, we're bad at predicting the future. And so, with the format that I really love is this now, next, later format. And I love combining it with outcomes, opportunities and solutions depending on how near or far we are, right? So in the near term, what we're working on right now, we probably have both a delivery plan and a discovery plan. And our delivery plan is we have things that we're building right now that we have clarity around the scope, we have clarity around, hopefully we've done enough discovery that we have clarity around how difficult they are to build and we should have a little bit more certainty and we might even have a date on which those features are being released, right? Now in the now column, you probably also have some discovery work. So these are the opportunities we're working on right now. And if you have viewers that aren't familiar with the word opportunity, it just represents an unmet customer need, pain point or desire, right? And so, we have opportunities that we're working on right now and we probably have an outcome that we're working on right now, but then when we get into that next column, things get a little blurrier. We may not know what solutions are coming next. Maybe we know what opportunities are coming next, maybe we know what outcomes are coming next. And then everything beyond that in the future is really nebulous and unclear. And I think the really other important thing on that now, next, future roadmap is we don't know when we're moving from now to next. And so, that format, what I love about it is it represents the uncertainty. It acknowledges we can't predict the future. Now it still has some problems. The problems are how does our sales team tell their customers what they're doing? How does our marketing team coordinate their activities? And so, we lose a little bit of those benefits we got from that original fixed roadmap. But I would argue we never got those benefits from the fixed roadmaps 'cause those dates were never correct.

  - That's right and it only served often as a sword and a shield for the team. Whereas sometimes we'd provide a date to try and be helpful, but that ends up eroding trust and it was only ever an approximation or a guest anyway. So you're quite right there. Makes complete sense to me.

  - And I think there's a way to fix this problem and I think really this is hard 'cause this is not within product teams controls and control, but I think organizationally, there are ways to fix this problem. I would love to see marketing teams not run marketing campaigns based on outputs, right? Why are we doing feature launches? What we should be doing is running marketing campaigns about how our customers are having success with those outputs, right? So just like in the product world, we're shifting from output mindset to outcome mindset. We can make that same shift in the marketing world where instead of coordinating all of our marketing campaigns around, we built these outputs, we could coordinate our marketing campaigns around our customers had success with these outputs. And then, it's less tied to our delivery schedule. I actually think it's much more effective marketing. But again, that's not always in a product team's control. So we're sort of in this uneven change in an organisation where I really think product teams are leading the future way of working and the rest of the organisation is kind of slowly following. And so, it's messy 'cause we're not all changing at the same rate.

  - Yeah, do you know, that's a fascinating concept and I completely agree. It's an evolution of the entire company, in many cases led by product because they're at the forefront or at least these product teams or even the product trios as I know that you've talked about before, totally those sorts of teams assembling and going on that journey. But I've worked on some enterprise transformations where even the customer of that client has had to evolve because they've been used to looking at releases and when are we gonna get this new feature? And so, even the customer or the customer of the client has to evolve on that. That's really fascinating. I definitely agree with you on that. We have to transition as an organisation many times spearheaded by the product team.

  - Yeah and I will say, when I say product, I don't mean product managers, I actually mean product managers, designers, engineers, user researchers, everybody that's in that sort of product and engineering organisation.

  - Right, yeah, totally and that's a really good clarification. I wonder if we just bring it back, 'cause I wanted to go down that fascinating rabbit hole there with you and we'll pick up on some bits of that as well. I wonder if we think about the roadmap not as being as a delivery plan, but more around the now, next, later. In your view, who's the typical audience of those? And I think we've mentioned some of those already, the marketing team, the engineering team, is it the entire organisation in your view that's the audience?

  - I think it's not just the entire organisation, I think there are situations... Well, so first I do think it's the entire organisation and I think there are situations where it even makes sense to share that with your customers. And we have some really great examples of companies sharing their roadmaps with customers. And I think sometimes that can be dangerous. If you're promising a feature on a specific date and then you learn that's the wrong feature to build, you just overpromise to your customer. And that's where I think that now, next, later format and changing the fidelity of how close to the future it is, really helps with setting appropriate expectations with customers. But I think that when you do this really well, it makes it safer to share this with your customers. And I think that's a really great thing 'cause when I buy a product, I wanna know where the product is headed and I think that's a valid need of our customers that we can meet when we get better at roadmapping.

  - Yeah, great context. Yeah, it makes sense. And so, who do you think owns a roadmap? Is that traditionally within product teams again or, in your view, who owns them?

  - Ideally, I want each product trio to own their own roadmap because that's what empowers them to do good discovery and to reach their outcome. That's a little bit idealistic because unless your team is structured really well, which we're still learning how to do, you're gonna have dependencies across teams and you're gonna need your leadership to help negotiate those dependencies and those boundaries. But I do know there are organisations that do work in this ideal way. It's not fictional where each team truly is empowered, they have their own outcome, they each have their own roadmap. When you're communicating to customers, if you have 40 teams, you don't want to communicate 40 different roadmaps. So there's a little bit of a rolled-up view that somebody has to manage, right? And usually, that's the leadership in your product and engineering organisations that are doing that work. But yeah, I really wanna see teams move towards every team owns their own roadmap 'cause otherwise you're not an empowered team.

  - Yeah, yeah and that would be amazing. I've worked in positions where I've been more of a delivery manager than I have a product manager. So these sorts of conversations and concepts really excite me and I think we need more of that. I'm excited by where I'm seeing the industry going, Teresa. From your perspective then, if we talk about the roadmap in the sense that we know it's not the delivery plan, we're thinking of it more as the now, next, later, we're thinking more about some of the opportunities that we're wanting to explore, what's the relationship of that roadmap to vision and strategy and some of the higher level strategic type entities in your view? How does that work?

  - Yeah, this is where language is hard. We often use vision, mission, strategies, strategic objectives, outcomes, OKRs, to all mean the same thing and I don't think they're the same. There are some meaningful differences. I'm not sure that, off the cuff, I can define them in a meaningly accurate way. But I think for a lot of teams, several of those elements we just mentioned are missing. And actually, I think that's where we're still seeing a need for a lot of maturity in our product and engineering leadership. I see this especially on the engineering side. I don't wanna pick on engineers particular 'cause we see a gap on the product and design side too. But we really need organisations to say, "This is who we are, this is what we're trying to do." And that's sort of where we get into that vision, mission, strategy stuff. Strategy starts to get into the how, but we wanna make sure that we're not getting so far into the how that we're prescribing solutions. And I still think we need good examples of what this looks like. This is actually something that my instructor team has been talking a lot about and we might be working on. I know not to promise future products, but we are exploring a future product in this space. We'll see if it comes to fruition of just providing really good examples. Marty Cagan talks about it in strategic context. What does that look like? What does it look like to define your organization's strategic context? I know that Petra Wille does a lot of work in this space and I know she has some really great ideas and includes several examples in her book, "Strong Product People." But I think for a lot of teams, it's totally absent and because we've never seen what good looks like, we don't even know what to ask for. And I think for a lot of leaders, they've never worked somewhere where this was in place. And so, they don't know what to give their teams. So I think this is a giant gap in our industry and I think it's one that we desperately need to fill.

  - Yeah, absolutely. One of the reasons I got into roadmapping and as a product manager, I needed to be able to leading a team, I needed to be able to kind of define strategy at my portfolio level, but then show how that tied into corporate strategy and that's where it fell apart. My team were looking to me for strategic guidance and I was looking for the next tier that didn't exist. And so, I ended up implementing a roadmapping tool called Aha! In there and then I joined Aha! for three years. But really, the reason I implemented largely was to demonstrate that I didn't have that strategic alignment. It was just not defined. And strategy and that strategic context, sorry, is so motivating. It's so important for alignment and when it's not there, it shows. And I think that's gonna make or break the companies of today and certainly tomorrow, is that clear strategic definition. The ones that don't have that I think are the ones that are gonna really suffer.

  - Yeah, and I really think we need to get more precise in our language. So I think we do have some good examples of good visions. The one that people refer to a lot is Dropbox. Dropbox created this three-minute video that was phenomenal at painting the picture of what would it look like to have access to your files from anywhere, right? They didn't talk about the how. You didn't watch that video and go, "Oh, I know exactly what Dropbox is gonna build," but I did say this is exactly what Dropbox is gonna do for me. That's a phenomenal vision, right? But then there's, okay, now we have a business model, how's Dropbox gonna make money? So your business model's a place in here as well, right? And then, you could have a Dropbox with that vision that has a totally different business model than maybe a box that has the same vision, but different business model. So now we're talking about different strategies, right? You could even have the same company, the same vision, the same business model and different strategy 'cause strategy is getting into how we're gonna realise this vision and that I think it's strategy is the hardest 'cause it's where people wanna prescribe what the product is gonna do 'cause we are starting to get into the how. But what I love is we're starting to get some good examples of strategy. I think the book "Good Strategy/Bad Strategy" is a really great place to start 'cause it gives you sort of a framework for thinking about how do we diagnose what's happening in the market, which is a really great place to start. So we're starting to get a little more clarity around these things, but I think we're on day one of this stuff.

  - Yeah, yeah. I feel the same. I see it working with the clients that I do doing transformations and implementing roadmapping tools. A lot of the time when we're trying to identify that, again, there's so many different words and terminologies and frameworks here, but at the end of the day, it's like, well, what do you have? And sometimes they're trying to retrospectively do that. Sometimes you see a product team that's trying to turn into more of a solutions team or they're just trying to retrospectively take product strategy and make that a company strategy. So I'm really seeing that a lot with the people I'm working with.

  - Yeah, this is where... So company strategy is interesting too because that's a whole different level. So if I think about a single product, it has a business model, it has an ideal customer. If I have a business model, I can put metrics around it. Hopefully there's a vision for that product. And so, I can come up with a product strategy. I know that's new for a lot of people, but that's one sort of constrained realm. Now if you're a big company, for a lot of small companies, you have one product. Your product strategy is your company strategy. But as you get bigger and you have a portfolio of products, now there's a whole nother layer of strategy, which is your portfolio strategy, your company strategy, and that's where things get even more complex. Fortunately, I don't think most individual product teams have to deal with that. They have a little bit of time in their career to kind of learn about product strategy before they have to worry about portfolio or corporate strategy. But they're all really important and I think keeping all of those things aligned is really challenging.

  - Yeah, yeah, massively. It's great conversation. I wanna go into kind of the design of a roadmap a little bit and you alluded to the now, next, later, which I have certainly picked up and embraced in my career. I think it's a great way of doing things and actually allows you to have much more of a transparent conversation, a more of a meaningful, trusting conversation with your stakeholders. But what would you think are some of the key elements or content on that roadmap for yourself if you're to see a good example or an example that you like to share with people?

  - Yeah, so I think we have three basic components that we work with as a product team. We have outcomes. These are the metrics we're trying to drive. Ideally, I wanna see outcomes be a mix of two things. I talk about business outcomes, which should be derived from your business model, right? Every for-profit company is trying to grow a profit. The way they do that is by either increasing revenue or reducing costs. The way that we increase revenue is we look at our business model formula and we increase the inputs in that formula, right? So like a really simple example, if I'm a subscription business, my input variables are things like increase number of customers, increase their average spend, increase their retention. So that's giving me this idea of what outcomes matter to my business. Now business outcomes are really hard for product teams to work with 'cause we don't directly influence them, but we directly influence our product outcomes and product outcomes measure a customer behaviour that occurs within the product. It's what we're looking for is what are the inputs, what are the customer behaviours in our product that we believe will drive those business outcomes. So I like to think about it as product outcomes are leading indicators of business outcomes as product teams drive product outcomes, they create value for the business. So that's one sort of atomic element that we work with as product teams. The second one is opportunities and opportunities represent customer value. So they're unmet customer needs, pain points and desires. And we're looking at how do we positively intervene in our customer's world, right? So how do we create something that solves a need, solves a pain point, solves a desire, but in a way that drives that business outcome? So that's sort of our second atomic unit. One is outcomes, two is opportunities. And then the third is our outputs, it's our solutions. It's the features that we're building. And I think the key here is to keep all three of those things aligned. And so, I have a visual called a opportunity solution tree that helps teams keep those three things aligned, making sure that as we explore solutions and we start to fall into shiny object syndrome, that we're focusing on the things that will create customer value in a way that will drive business value. And I think it's those same three atomic units that I wanna see on a roadmap. So in the now column, I'm gonna have some solutions that are currently in development that I already have confidence in that I probably can even put a release date around. I'm gonna have probably a target opportunity where I'm exploring new solutions. I definitely don't have target dates around that. I might have my current outcome that I'm working on. And then in my next column, depending on where I am on my current outcome, I might have the next opportunities I wanna explore on that outcome, right? So if I'm trying to have a big impact on my outcome and I'm in a really early stage of impacting that outcome, then I probably don't have another outcome in my next column because I'm gonna work on that outcome for a while. And so, what I have on my next column is more opportunities that support that initial outcome. Now if I've worked on my outcome for a long time and I'm pretty close to reaching my goal, I might have a new outcome in my next column, right? I'm pretty close to reaching my goal and once I do, I'm gonna move on to this next outcome. So that next column for me is usually a mix of outcomes and opportunities. Maybe it has a solution or two if I already have clarity on what we're building next, but I would say most of the time it does not. And in the future column is usually an outcome. Maybe if I'm at the very beginning of working on an outcome, it might also have some more longer-term opportunities on that outcome.

  - I love that answer. I'm visualising it in my head, as you narrate and paint the picture there. But one of the things that strikes me and again I don't think people do this enough, is actually to put activities on the roadmap that say, hey, we're gonna do some exploration, we're gonna do some discovery on these things. Because I think people are often used to just what are we building? And it just forces that output mentality again. I think showing that we're consuming some time to be curious and actually delve deeper into the why really appeals to me. I'm a former business analyst and I used to get frustrated when we used to throw technology at the solution all of the time and actually sometimes it was a change in process or a change in something else. And it's not always building is the solution to a problem. So I'm loving that, that we should show that we're dedicating time to these things on our roadmaps.

  - The other thing this does is it helps to chip away at this problem of how do we communicate to the rest of the organisation what we're working on. So if I'm in marketing, I wanna know what's releasing when and I'm gonna get that in the near term, right? But I still benefit from knowing you're gonna solve this customer problem next, you're gonna be exploring this customer problem next because I can start working on campaigns around what would it look like if we solved that? How would I run a campaign around that, right? And so again, if we shift our marketing to be less about we released on output and more about we're having this impact on our customers' lives, I can start looking for what customers do I know have that pain point today? How do I reach out to them? How do I get them queued up to, one, help test those solutions with my product teams, but also be open to sharing their story as they have success with those solutions, right? So it still actually helps our sales team if they know we're gonna solve that opportunity next. When they're talking to prospects, they can be like, "Look, we don't currently address this problem, but I know our product team is exploring it right now. Would you like to talk to them?" It's a great way to win business and it's a great way for product teams to get access to customers that have that problem.

  - Yeah, massive, massive. And I wish product teams would do more of this, which is talking to customers, I don't think they do it enough. And being able to show that we're doing that builds relationships with the customer. I'm privileged to have started up my company just three or four years ago and I'm still formulating what my product market fit looks like, what my ideal products and services look like. But being able to speak directly to my clients and product manage them as I'm building the company, it's an absolute gift. And so I think having that is just building stronger relationships that are much more meaningful. It means that we can actually understand the true solutions to these opportunities.

  - Definitely, definitely.

  - That's brilliant. And I'm curious, are there any tools that you prefer to use for managing and visualising roadmaps? Do you like something that's very flexible? What do you typically go to?

  - I try to stay out of the tool recommendation game. Here's what I'll say. We have a lot of tools, a lot of tools. If we think about roadmapping, we have like Aha! And I'm sure Atlassian has a number of products and prod board and prod plan and we could just enumerate a million tools here. I think they all do different things well and I think every team has different needs. So just like anything in product, it's about evaluating a solution based on your identified needs. And so, if I was on a product team and I was trying to pick a product roadmap tool, I would actually create an opportunity solution tree of my needs, right? What are my team's needs for a roadmap? How do I map out that opportunity space and then I would evaluate those tools based on how they serve those different needs. Because I don't think there's one best, I don't think it's possible for there to be one best tool. I think it's really about finding the right tool for the right team.

  - I love that answer. How good is to actually use the opportunity solution tree to find your ideal roadmapping tool. We've had such a variety of answers to that question. And you may think I'm biassed coming from a tool's background, but some of my favourite are the ones that are flexible enough that allow you to show exactly what you need. I think there's always a balance of a single version of truth versus, so a tool that kind of manages that versus the flexibility of showing exactly what you need. And maybe we'll talk a little bit later about the different views of roadmaps 'cause I think the roadmap, as you mentioned at the beginning, is a communication tool and alignment tool. It needs to serve its purpose by communicating directly to each audience and each audience's needs are gonna be different. So that's a great answer, Teresa. I think that's a golden nugget right there.

  - I think also, you know what? We're in an era where tool interopability is getting better. And so, I also would say you don't always need to use one tool to serve all needs, right? So your product teams might need a tool that supports their own work. It might be a different tool that's best for communicating. I think if you're gonna use different tools, you wanna make sure that data is syncing automatically and you're not asking your teams to reenter the same stuff over and over again. But we've got good tools for that now. A lot of these tools are integrating with each other. We have tools like Zapier that help us automate integrations. If you have some dev time to throw out the problem, you might even be able to use some of these tools APIs to do that. So that's the other thing. I see a lot of teams try to use one tool for everything and no tool is good at everything.

  - What do you consider to be a best practise in roadmapping? And I think we picked up on some ones that were kind of things to avoid and we both share those, but what would you like to see as a best practise on the roadmap?

  - Don't over-promise, I think is the short of it. I think that's where roadmaps cause more harm than good. And I think it comes out of a good place. We want to give people what they need, but we have to recognise that sometimes we have to share hard truths. And I think it's much better to give a realistic view of where you are, even if that's, "Hey, we're exploring this opportunity, but we don't even know if we're gonna find a solution that will work. We might have to throw the opportunity away." And I know that creates a lot of uncertainty in the organisation, but that's realistically where we are right now.

  - Right, absolutely. And in fact, I loved your your talk earlier about what you were mentioning about having good examples of what good looks like because I certainly remember when I started off as a product manager or I searched for roadmaps in Google or search engine and what you get back as Gantt charts. So you then go, "Oh, well, that's what's expected of me." And I'm just like... Now it's just like, can we just clear all of that please and start again? So I love that concept that you just shared. What do you think are some of the biggest mistakes people make in roadmapping?

  - It's a similar to what I see with outcomes. Sometimes leaders define the roadmap on their own and they just hand it to a product team and we basically have a delivery team. But sometimes product teams define their roadmap with no input from the rest of the business and I think that's equally bad, right? So I think we wanna make sure that we're always collaborating. And so, there's the easy collaboration of, I mean it's not easy, but there's the simple collaboration of collaborate with your trio and your team and make sure you're empowered and working together on what you should be building. But there's also collaborating up. So this probably falls under managing up of like, are you on the same page as your leader? Do you know what your leader expects from you? Are you creating the right value for the business? So do you have right alignment between your product outcome and your business outcome? And then, there's also collaborating across the organisation. So are you helping your sales team and your marketing teams understand what's coming and where they are? Are you working with finance to make sure that you're not creating a finance nightmare down the road? Compliance, legal, all of it falls into the same category. And so, I think it really is making sure that you are not creating your roadmap in isolation.

  - Yeah, massively. Again, costing my mind back, I remember my first roadmap being locked away in a business room, trying to take all of these inputs. It was a solo effort, it came out as a delivery plan and then you go and hang yourself with it. And it was just like, looking back now, it was what it was, but from what I know now to what I knew then is massive difference. And in fact, I'd love to explore with you a bit more of the opportunity solution tree. Do you have a pet hate to see on the roadmap?

  - Not really. I know some people say they hate seeing dates on a roadmap at all and I don't think that's realistic. There's always times. We got a big conference coming up, we wanna release a new feature to support that conference or whatever it may be. You're bringing on a big new customer and they need to launch with something new. There's lots of reasons why we might need to have fixed dates. I think we overly rely on that. I think that's sort of a concern, but I don't have a never do this type rule for roadmaps. In fact, I think I always try to avoid. Actually I just said always, which is funny 'cause I was gonna say I always try to avoid never and always.

  - Oh, that's great, I completely agree. There's again, just getting these good examples of roadmaps into the hands of people so they can see what good looks like and a good diagram of that. And actually, that reminds me the bit that I wanted to come back to you on, which is that I've seen a couple of great examples of opportunity solution trees and I wondered if you'd talk to us about some locations where people can go and learn more about those as well.

  - Yeah, so if you go to ProductTalk.org/OpportunitySolutionTree.

  - We'll put a link in the description and if you're on the podcast, have a look at the website. But yeah, Teresa, carry on.

  - So that's where we collect all of our articles about the opportunity solution tree. Here's what I'll say about this tool. It looks really simple and it packs a lot of power. The challenge is what I'm learning after having written the book, we also teach a course on opportunity mapping, it's a hard tool to learn how to use well. So if you're new to it and it feels really simple, you're probably missing something. And second of all, if it feels really hard, that's normal. This is a synthesis tool. It's helping you really synthesise what do we learn in our interviews? How do we make sure we're creating value for our customer in a way that creates value for the business? And I will share some of the common mistakes I see teams make. The opportunities on your opportunity solution tree should come from customer stories, full stop. That is the only place that should come from. We can have a lot of conversations about why this is important. So the biggest mistake I see teams do is they go in a room and they create an opportunity solution tree just based on what they think or based on what their stakeholders think. I guess there's some value to that. There's always value to externalising your thinking and aligning around it, but you're missing most of the value. Most of the value of an opportunity solution tree is we're trying to mine gold from our customer stories, right? And so, if you're not collecting those customer stories, you're not getting the vast majority of the value from it. The other place where people really struggle and I'm still learning how to teach this better, is just what's the difference between an opportunity and a solution? And again, it's so easy to say, well, an opportunity is a need or a pain point or a desire. But I've looked at enough people's trees to say, "Oh, those are all solutions." And I feel like I'm in a tough spot 'cause I love that people are starting to blog about how they're using it and we're starting to get examples. They're not always great examples. So one of the things that I'm doing, we do have a Slack community where people are sharing their work and we're giving feedback on that work and we're trying to create better examples and we're showcasing other people's work. If you wanna learn about that community, that's at Members.ProductTalk.org. But we're also taking some of those stories and we're sharing them for free 'cause that community is a paid community. We're sharing them for free on Product Talk as part of our Product in Practise series, just trying to create better examples. What's hard is that most people, when they do a good job of mapping out the opportunity space, this quickly becomes proprietary knowledge. They don't wanna share it, right? And so, what I've been working on as a little side project is I am starting to interview people as if I worked at a big name company about their usage and trying to create good examples of interviews and good examples of opportunity solution trees. And since I don't actually work at those companies, it's not their proprietary knowledge, I'm the one that found it. So I will be creating better public examples of what good opportunity solution trees look like. I did share one in the book. So in my book, I did walk through, my book, "Continuous Discovery Habits." I did walk through a pretty detailed example for a streaming entertainment company, but probably over the next year, I'll be producing a lot more of those examples 'cause it is a big gap right now.

  - Fantastic, well, I know that I remember that example. I think it was increased viewing hours or the viewers at the top as an opportunity and then the solutions down. What really changed the game for me was that you can fall into the trap of when you get a lot of ideas or customer requests coming in, you take them as solutions and then you go and build them. And actually, you need to look at that and obviously, there's again lots of great tools that give us a score and you take the top scoring one and you go build it. But you're not scratching the surface of what the real customer problem was and that's really, for me, what the opportunity solution tree helped me to realise, coupled with my experience of being a business analyst, was like, what is the actual opportunity here? What's the bigger thing that we are missing? And it's not just prioritising ideas there. So I love that we're gonna get more examples from you. Guys, if you're curious, please do go and check out Teresa's website and maybe even consider joining the community there as well 'cause I think that's gonna be a fantastic resource.

  - Yeah, and we have shared a number of stories about opportunity mapping at Product Talk. So if you go to ProductTalk.org/blog, one of our categories is called Product and Practise. What that category is, we're sharing stories of real product teams as they put different discovery habits into practise. And we've done a number of them on opportunity mapping. So in fact, we just published a recent one with Travago where Travago is this travel company. They've been around for a long time, they've had product market fit for a long time. They've done a great job of optimising their product and they had a team that was focused on improving the quality of search and they felt like it was actually really hard to find ways to improve because it's been optimised for years. And they started conducting story-based interviews and they started identifying opportunities and it's just a story about how opportunity mapping really helped them find new areas to innovate in. We have another story with this company, SIRA. SIRA is based I think in the UAE, but they serve Saudi Arabia and they're a travel company and it's a story about what happened to their company at the start of the pandemic when all travel ground to a halt and they basically saw their business fall off overnight. And it's just a story about how they used opportunity mapping to quickly pivot and to thrive during a really tough time. And I think that is the power of opportunity mapping, is that we, no matter what is happening in the world, no matter what stage our product is at, whether we're going from zero to one or whether we're a 20-year old mature product, there are always customer opportunities we could be solving.

  - 100%, phenomenal. Absolutely love that. I knew about the Travago one. I'm interested to learn more about the other one, so I'll go and check that out. In terms of where you get your inspiration and you get your ideas from, who stands out in the industry as being someone that you get your roadmapping advice from or any resources that you use. I'm curious 'cause you are one of my go-tos, so I'm wondering where do you go for some of your roadmapping resources?

  - That's a really great question. For roadmapping in particular, I think Janna Bastow does some really good writing on this. I think Bruce McCarthy and C. Todd Lombardo have a great book on this. Oh, roadmapping in particular, that specific focus is hard for me. Melissa Perri always writes really great content. I can't remember if she has content specifically on roadmapping, but I really respect the work that she's doing. I also wanna share that I think people read or listen too narrowly in our field, right? So we have a lot of great product thinkers and I'm not gonna poo poo any of them. I think there's a lot of great work in this space, but I also think we can benefit a lot from broader business research and business literature and business books. I think we also can benefit a lot from decision-making research and problem-solving research. So whenever I'm asked about, where do I draw inspiration, for me personally, a lot of it is beyond the product world. Not that I don't get inspiration from people within the product world, I absolutely do. John Cutler is another person who is constantly throwing out really just innovative thinking. But I also wanna encourage people to look outside a product as well.

  - Yeah, I love that. I think we had a guest on recently or it's one that I watched who got their inspiration from film sets and directing and things like that. And I thought that was fascinating and there's a lot of parallels to this because a lot of product management is good storytelling and kind of those sorts of things. So I think that's a wonderful answer actually, is that there's always the classics, but thinking outside of that as other innovative ways of being able to take one learning from one space and apply it to product and roadmapping.

  - You mentioned storytelling and I think the reason why storytelling is becoming so popular in the product world, product people don't wanna hear this, but a big part of our job is sales. And it's not sales to customers, it's sales to our internal stakeholders. And nobody, I mean, people who aren't in sales tend to think sales is this dirty thing. And so, there is a book that I'm going to recommend, it's called "To Sell is Human" and it's by Daniel Pink and he just writes about how all of us, 100% of humans are selling, right? We sell to our spouses, we sell to our children, we sell to our friends and family. We're selling, we're constantly trying to influence behaviour. And I think that he does a really good job in that book making that argument and removing some of that negative view from this idea of sales. And I do think it's a really critical skill and particularly related to roadmapping.

  - Love that, what a great recommendation. It's one that I've read, so I need to go and reread that one. It was a while back now, but I think that's fab. If you had to distil your philosophy of roadmapping into a couple of sentences, how would you describe it?

  - For good roadmapping, I think it's all about how do we communicate what we're doing and when without glossing over the uncertainty and the ambiguity that we all face looking into the future.

  - It would've taken me so many attempts to even get that one right, Teresa. That was gold right there. And again, a lot of us watching or me right now nodding along with that, I think that's a fantastic answer. We're gonna definitely quote that one in the episode.

  - I think it's the back half of that definition that's the hard part, right? How do we give a clear picture of the ambiguity and the uncertainty that we face? And I think this is where traditional roadmaps have really fallen short. We make it look like the world is certain and not ambiguous, whereas I think our more recent methods are starting to acknowledge we need to visually represent this in some way.

  - That's right and it's exactly that that we're embracing on the channel as well. Trying to be able to correct some of that misinformation and those anti-patterns to be able to show people there's a different way. And Teresa, you've definitely helped us with that.

  - Bruce McCarthy and C. Todd Lombardo, when they were writing "Product Roadmaps Relaunched," they reached out 'cause they wanted to include my opportunity solution tree in their book. So they were telling me about their book and my first response was like, really? You're writing a book about roadmaps? 'Cause I was thinking, aren't we over roadmaps? And actually in talking with them, it made me really realise, we're never gonna be over roadmaps. Roadmaps have a very distinct need and it's really about how do we evolve the roadmap. And I think they have done the industry a great service with their book and I think there's lots of tools that are now helping us realise some of those ideas. And so, I'm excited about roadmapping again.

  - Yeah, absolutely. Oh, that's fantastic, I love it. Teresa, it's been wonderful chatting to you. I'd love to give you an opportunity just to share with our viewers, and we've obviously talked about it through today's episode some different links there, but please, for people that aren't familiar with you, let us know kind of what it is that you do and pitch your offering. Let them know how they can get in contact with you.

  - Yeah, so the easiest way to learn more about what I do is just go to ProductTalk.org, that's where I blog. I've written over 200 articles. They're mostly long form how-to articles or just showing how other teams are working type of articles. Our editorial philosophy is show don't tell. And then, I did write a book called "Continuous Discovery Habits." It's available paperback, Kindle, Audible, so whatever your learning style is. And then, for folks that need help putting the book into practise, we have a number of resources. I mentioned our online community. It's a mix of Slack plus live Zoom calls. It's a tonne of fun. You can learn about that at Members.ProductTalk.org. And then we have a variety of online courses designed to help you build skill in the different discovery habits. And you can learn about that at Learn.ProductTalk.org.

  - Fantastic, what a great resource. I think that's incredible information for people that are just learning, they're pivoting away from roadmaps in the old space or they're trying to pick up tips on how to approach new product management and new ways of working. I think that that's phenomenal. Teresa, I want to thank you massively for being with us today, for so graciously spending your time. I've absolutely loved it. For the viewers out there, I hope you've enjoyed it as well. Please do like, follow and share. If there's something that we've both talked about that you think somebody in the organisation could hear and learn from, maybe somebody in marketing on the new ways that we're gonna interact with them, send the link over to them and let them watch it. And please, if you'd like to get in touch to take part and be where Teresa is, then drop a note in the comments or email us. But Teresa Torres, what a fantastic privilege it has been to speak with you. Thank you so much.

  - Justin, thanks for having me. This was a lot of fun.