Is a roadmap like a safety blanket? | Nick Black

In episode 13 of Talking Roadmaps, Nick Black, CPO at Sama, shares his insights on the critical role of roadmaps in scaling tech companies with Phil Hornby. Nick discusses the importance of empowering teams, strategic planning, and the nuances between good and great organizations. Tune in to learn from his experiences in taking companies from founding to successful exit.

He's a tech founder and chief product officer who's taken companies from founding through to scale-up and exit. Along the way, he's learnt the difference between good and great organisations comes down to empowering people to achieve amazing things. Today Nick is CPO at Sama and also consults organisations who want to build their product teams, strategies and cultures.

“The traditional roadmap just creates a false sense of security”

— Nick Black

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 Roman Pichler author, trainer and speaker on product and agility. So watch out for Episode 14!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about all the things, good, bad, and ugly about roadmapping. Talking to practitioners, thought leaders, and anyone who really wants to talk about them, to be honest. Today I'm joined by Nick Black who I actually met through a LinkedIn post where I think he was deriding roadmaps. So I guess we're gonna hear some of the anti-roadmap position today. Nick, please introduce yourself.

  - Hey, Phil, it's fantastic to be here. So really happy to be sharing some thoughts and experiences with you today on this awesome show. Yeah, so my background is actually as a tech founder, so I started my first business straight outta university in 2005, and sort of took that from being two people up to being 150 people at the point where we required, and at the point where I left about two or three years ago. Through that journey, I had to sort of start by learning what product management was. I remember coming back from a meeting with investors who said, "Nick, we think you should run product." And I said, "Yeah, that sounds really good, I definitely should." And then I went home and Googled, what is a product manager? So that set me on this train of figuring out product management, B2B growth, and I iterated that business through starting off as a B2B SaaS platform into a B2B enterprise model. So I've sort of seen both sides of that. So, yeah, very passionate about all things, product management, product strategy. Looking forward to sharing that with you today.

  - And so just the mandatory stuff. Obviously anyone who is out there listening, we'd love it if you like, subscribe, hit that bell, so you get notifications, or get in touch through info@talkingroadmaps.com because we'd love to have you on the channel as well. So, Nick, I guess, maybe a controversial question, as I know you're not the biggest fan of them, but what's the purpose of a roadmap?

  - So let's take it back to the original idea from roadmaps. So the purpose of a roadmap initially, it evolved in companies like Intel. A lot of the methods and the way we think about things in tech come from companies like Intel. Andy Grove, the incredible CEO of Intel, who created things like OKRs and a lot of the management practise we have, he pioneered roadmaps. And I've actually done quite a lot of work in hardware, selling software to hardware makers. My company was acquired by a massive hardware manufacturer. Hardware is hard, you have to make massive capital decisions, you have to spend a lot of money. If you need to build a lot of chips, then you have to build a factory and a supply chain, organisation is extremely important. You have to plan, you have to have teams collaborating with each other, you have to make these big decisions. With hardware, you also have to get it right the first time. You can't release a device, and then try and change the hardware, as Apple found out with Antennagate a few years ago, remember, when their phones didn't work properly. In that kind of an environment, roadmaps make a tonne of sense. It's literally like, how do we plan all of our teams together and make sure we deliver a good product. Now what has happened in the last 20 years or so, as SaaS has become to dominate, as data has got extremely rich, and as the release cycles have got faster and faster, is that product management and general product development practitioners, we figured out that actually the best thing to do is to focus on the speed of learning and the speed of iteration. So in any product environment, not even in a startup, in a huge company, what we're actually trying to do is put out a thesis for how we're gonna delight our customers, for how we're gonna improve our retention, our downloads, our subscriptions, how we're gonna improve our business. That's a thesis. And we need to, as quickly as possible learn the important things about that thesis, validate it and invalidate it. When we invalidate it, we throw it away; when we validate it, we put more focus on it, and we go deeper into it. So the original purpose of roadmaps is largely not fit anymore because it was designed for an environment where failure came from a lack of planning. In today's environment, failure comes from not learning fast enough. And to me, that's the fundamental problem of where we are with roadmaps.

  - Sure, we can still consider the direction of travel, that overall bigger picture as still the roadmap. But maybe, I mean, because what you're likening a roadmap to, to me sounds like a project plan, which to me is a separate artefact. So maybe you can unpack-

  - Hmm.

  - That thought a little.

  - Yeah, but you're pretty enlightened on this point, I think, Phil. So if you say roadmap to a general product manager, if you took all of the product managers in the world and the people working with and ask them to draw on a bit of paper what you think a roadmap is, what you are going to get in 80% of cases, is this like horizontal grid quarter by quarter what we're going to deliver. One of the purposes of that is to make the CEO feel that she or he is spending their money wisely, people have a plan, and people are coordinated, right? So that is still what most organisations think roadmaps are. And I get like pushback on this when I say it, "Oh no, but actually you mean vision, you mean strategy." But that's good, that means you're working in an enlightened organisation who has figured out large parts of it. Most of the product managers out there, and most of the organisations out there, and I work today as a consultant with large, several thousand person companies, I do work with private equity firms who are transitioning their acquisitions from being, a little bit in an older model to being a more modern, faster model. So I see this from big multi-thousand person companies down to five person startups, the predominant idea of a roadmap is a plan for what we are going to build.

  - I can see where you're coming from there, and I can see that challenge. Do you throw the baby out with the bath water? Is it still not a concept that's useful?

  - So I have a very different model for how to do this. So what I have been doing over the last couple of years since I left my startup, I've been... I started off this sort of cathartic exercise to write down the things I thought I'd known, and all the mistakes I made. And the mistakes were like 50 pages, and then I had a couple of pages of what I thought I'd learned. And I started to publish some of these ideas to friends. They found it useful, so I set up a website, put the ideas on there, and one thing led to another, and I've been running these type of exercises with about 20, 30 companies over the last year or so. What I've found works much better, and this is from these big 1,000 person private equity backed companies, all the way down to sort of 5 to 10 person seed stage startups is to make sure there's a very clear vision. So a lot of the time, when the CEO asks for a roadmap, they're actually putting in place their version of their vision, but they're doing this in a very outputs-based way saying, "This is what we gotta build to realise my vision." What I think is much more useful is for the CEO and the founding team to spend their time defining the impact their vision is gonna have. So to me vision is all about purpose. What is the difference this product we're building is gonna make on the users, on society, on the world as a whole? So I'd like to get really purposeful on it, you have this vision that can be shared through images, through movies, through written stories, whatever works in the culture of the company. From the vision, what we then look at is the North Star metric. So the North Star metric is the behaviour your customers will adopt, and you'll be able to see when they love your product, how your customers will behave when they love your product. And sometimes all you need to do is, spend an hour talking about vision, write that down, a few hours talking about North Star metric, write that down. And then you get these transformations happening within the team where the teams say, "Hey, so we're building all of this stuff in our roadmap, but it doesn't make any sense because the North Star metric is to drive engagement of users, and we're over here doing this other thing, which is just a technical pet project of the CTO. Let's stop doing that." So I like to work it down from the top, you start from the vision, you get the North Star metrics, then you get into the real meat, which is looking at the growth metrics and the retention metrics. And I find that, and the final thing to layer on this, of course, is a good understanding of the growth process. How you run experiments, how you create hypotheses, how you validate and invalidate. And these are the major blocks that you need to have to be successful as a product organisation today. I find, what the traditional roadmap does, it just creates a false sense of security. We know what we're doing, the dev team are obviously on it, the product managers are good because they've created this big nice PowerPoint slide, and the customers agree with it, so it's validated. None of those things are true.

  - So you're casting out a long-term vision, a direction of travel.

  - Mm-hmm.

  - Let's take the analogy of a map. We've gotta get to this destination, surely we can sketch out what we believe are gonna be the steps in that path.

  - Yeah.

  - Not accepting that it's subject to change.

  - So one of the models that I've used quite a bit on that I learned from... You should get him on the show actually, from Gibson Biddle, the former Netflix VP Product, that everyone in product knows, right? So I spent a couple of days with him a few years ago. And so one of the models I learned from that is to look at the big, like the three big chunks. So he calls it like get big, lead, expand. I use that myself, that's how I model our roadmap at Sama where I'm Chief Product Officer. We look at, first, what is the market do you wanna dominate, which is what we would also call product-market fit. So where do you wanna get product-market fit? It's gotta be big enough to be interesting to you, your valuation, your business, and so on. From there, what is the next big market and product innovation you wanna do? And from there, what's the dream? What's the crazy, flying cars kind of dream that you wanna put in place? And having models like that is super, super-important, but that's vision, that's this architecture of where we might go. An analogy I've used in the past with my teams is, at the beginning of an experiment, it's easy to start to build the whole nuclear reactor, right? You're trying to create this massive nuclear reactor, and you start sketching it all out, but we're just trying to see if the atoms react with each other. We're trying to work out, how much like uranium do you need? And can you do it? And what are the consequences? So, yeah, high-level, it's important to know where you're going, particularly very important to have the purpose, very important to have that big picture architecture, and to know the markets you're addressing makes sense, but it's really a waste of time to try and go into all the detail of designing the piping and the reactor before you know if the atoms are gonna react with each other.

  - I mean, so that sounds like almost like different flight levels, kind of there's the very high level direction. The version, what you've talked about is kind of the designing the pipe, which I'd would put down-

  - Hmm.

  - Almost at delivery level. I mean, I personally think of the roadmap somewhere between as almost a bridge.

  - Mm-hmm.

  - And I know you find yourself in that conflict of working with B2B where there's an expectation

  - Yeah.

  - Of a roadmap sometimes. So putting that pragmatic hat on, how does a roadmap fit in?

  - So I think there are three good reasons to have a roadmap that I come across. Firstly is, if companies were operating in a highly regulated industry. So I've done quite a lot of work with FinTech, financial services companies, you kind of know what you've gotta build because there's a law, and it's written and you can read it. And there's one in Spain, and there's one in Germany, there's one in the UK, and one in the US. So yeah, do you need to run experiments? Then yeah, you need to run the technical experiments, and do technical validation, but there is a point in having a roadmap there. And as you say, it is actually a project plan. That's where a good organic chart makes sense. We know what we gotta build, let's build it, okay? So that's one example. The second is that you've already validated end-user demand for an MVP or a feature, and it has considerable technical complexity. So part of what we try and do in team design is make sure that each squad has a clear objective they're working towards, and they'll have all the skills and the competencies within that squad to be able to deliver. That's the perfect model, and many companies can do that. But when you're doing something particularly complex, when you're building a platform, which is the background I come from, platform businesses. When you're doing hardware, there are inevitable tight interdependencies between teams, and then having roadmaps make sense because there is no point in building the base layer of the platform, if you don't have any of the apps ready to run on it, for example. So that's the second reason, but the prerequisite is, you have already validated the MVP. The third is when you need to coordinate multiple different teams in the context of supply chains and hardware, so that also makes sense. So those are three areas that I think it makes sense to have a roadmap. We had Daniel Elizalde on this session a few months back. It was I think the first external sort of session we put out. He advocates for having an experiment roadmap, in fact.

  - Yeah.

  - Just wondering, what your thoughts are there?

  - Yeah, definitely. And I just wanna come back to your last question first, and then I'll get to that. You were asking me to be pragmatic, and I can be very pragmatic. So I'll give an example of this, right? When my team were trying to sell into a very large carmaker, and if any of you out there are not selling to carmakers, I recommend you stay that way because they take a very long time to sell into, it's very complex selling.

  - I spent about 20 years doing that.

  - Really?

  - Yeah.

  - In the UK? Wow, yeah, I mean.

  - Globally.

  - Yeah, ah, okay. So we'll probably share a lot of battle stories after the show.

  - Okay.

  - So one of my sales guys came back, and he was like, "Nick, this customer, they need a seven-year roadmap." I said, "There's no way I'm making them a seven-year roadmap. Go back and tell them." And he said, "I already told them, I think you need to tell them." So I said, "Fine, I'll go in and I'll tell them." So I go in, and I told them. And, of course, I came out of the meeting saying, "Guys, we need to make a seven-year roadmap, it's the only way we're gonna progress it." So we just minimised the amount of time that we needed to spend on it, it was a waste of time, the customer just filed it in a drawer, they didn't do anything with it, it progressed us to the next stage. The problem is, there's a pragmatic way to look at that and saying, "Yeah, okay, it got us to the next step." But if that roadmap gets brought out again at some point, particularly by the purchasing office or someone who isn't your supporter, that's evidence that can and will be used against you. And so you have to be extremely careful when you buckle under the pressure to make guarantees of what you're gonna build in the future. And you don't... Everyone writes, "Roadmap indicative may change" on the bottom, obviously. And no one reads that, and that's not an argument you can have when you're defending why you didn't deliver your roadmap. So be careful if you get sucked into creating these big, long fantasy plans.

  - From my experience, it's because they're planning five to seven-year increments for vehicle platforms.

  - Yeah.

  - For example, so.

  - Yeah, yeah.

  - And they're kind of looking for you to be on a common journey with them, I guess. At least that's my experience there, and...

  - Yeah, and that's always my guidance to product managers who are either dealing with customer input, or other stakeholders, the CEO and so on, demanding a roadmap. Just break it down and work out what are they really looking for because roadmap means different things to different people. In that case they were looking to know that we were gonna be a good partner, and that we would deliver the innovation they needed and we understood their cycles. Often when the CEO asked for a roadmap, she or he is asking to understand the capacity of what the team can deliver. They're wanting to know that the team is aligned with their vision. And so there are, that's my main guidance, right, is just try and get inside the head of what the people who are asking you for a roadmap want. There's almost always something more useful than a traditional quarter by quarter list of features that we're gonna deliver. Such as, as you mentioned, Phil, an experiments roadmap. So, fantastic, like love Experiments Backlogs, one of the tools I work with the most often in my day-to-day work is the experiment backlog. We have growth experiment backlog, we have product strategies in the way that I run it are based around experiments. That makes sense. However, I do have a bit of a issue with the roadmap part of it because I think it's a lot like the arguments against having a bucket list, right? Where you make this list of places you wanna visit in the world, and then somehow your life becomes this goal to tick off the places you said 15 years ago you wanted to visit. So if it helps you and your organisation and your CEO often to have a place where you put experiments, ideas, so they don't get forgotten. Cool, do it. But if that somehow becomes a rod for your own back where the experiment you run in July 2022 is somehow dictated by something someone wrote 12 months ago, that doesn't make sense, right? Because the whole point of running experiments, the whole point of the growth mindset, which we try and adopt in product as well as in growth marketing is to be able to move very quickly and to learn quickly.

  - You talked about backlog, backlog and roadmap related artefacts, but not the same artefact. I guess from my perspective.

  - Yeah.

  - I guess, one of the arguments you made there was about 12 months. So maybe there's a time horizon issue here that we can consider, or how deep is your backlog going in terms of experiments? So how deep would a reasonable roadmap look in that context?

  - Again, it depends on the context. So if you have validated the user need and the technical feasibility, and the user demand for pricing, and in your technical validation there is a number of building blocks that you're really sure you can't decompose it, then soon there is a number of building blocks that you're really sure you can't decompose it, then some plan needs to be made to address that, and you could call that a roadmap, that's fine. But why would you spend any time? I mean, the product managers are already working extremely long hours. There's no product managers that are twiddling their thumbs with extra time, right? We're all overworked as an industry. So like why would we spend our time building artefacts that do not add value to the customer, and really add a very superficial value to the company when we could be talking to customers? What set me off on this whole like rabbit hole I've gone down on why I don't really like roadmaps, is from talking to product managers who are telling me the number one thing they do in the week is prepare the roadmap and the backlog. And the number one thing they worry about is running out of features to ask the developer team to build. Now how many startups fail because they've run out of features to build. Like that's never happened, right? Startups fail in new product launches in big companies, and transformations of big companies, they fail because primarily of value proposition because we haven't done the customer discovery work, we haven't spent the hundreds of hours you have to spend talking to customers methodically going through the results, teasing out the value prop, validating it through low cost tests, right? And then if that works, the next reason they fail is technical delivery. And increasingly now we don't fail to deliver the technology, so this kind of gets hidden, but what often happens is, we just make critical mistakes that slow delivery down by multiple months, and the startup runs outta money, or we miss the selling opportunity to the customer. So those two things, your big risks, which are the user acceptance of the product, the user's desire to use and buy your product, and your team's ability to deliver it to the sort of cost basis that you need to be able to. Roadmaps don't play into that at all, they add no value to those two massive risks. So why are we spending our time working on something when the big risks that are gonna make or break us are not related to those things that we're spending our time on?

  - Sure, they add to the communication and the alignment, whether it's internally, externally, that then helps make sure you are driving forwards on dealing with those risks.

  - So I love alignment and communication. So it's one of the things that I do in... So I do in the roadmap, the product strategy methodology that I've put together over the last few years. One of the big benefits that the people I do it with tell me they get is communication and alignment, they feel far more aligned, but that doesn't come from a list of tasks of telling people what to do. If you think about an organisation you are aligned to, right? Maybe you are a vegan and you don't eat meat, and you're very aligned to animal protection, the World Wildlife Foundation, for example. Maybe you are very aligned to a particular ideology, you are not aligned to their actions that they're doing, the things they're doing, you are aligned to their belief system, to the difference they wanna make in the world, right? So again, why don't we spend our time focusing on the bigger picture things, such as our company's vision. Let's make sure everyone understands the vision, let's make sure the vision is compelling, let's see how our customers feel about it. Let's get a North Star metric, this one behavioural metric, which we all work towards, and then let's make sure each one of our squads has one single metric that they're working towards and an exceptionally clear mission. And if we were just to survey product managers right now, how clear is your mission? How many metrics do you have that represent that mission? Do you think the CEO trusts you to deliver that mission? Those results on average would be disappointing. They'd be pretty low because most product managers don't feel enough trust from their bosses; they don't have a clear enough metric that they're working on; they don't have a clear enough mission statement. So that to me, that is alignment. When I believe in the purpose of the organisation and I fully understand it, and when I come into work each day knowing, this is what I need to do, I need to increase the percentage of users who complete onboarding within five days. That's what my work is all about. That is alignment. Writing a fantasy list of things we may do to do that, changing the sign-up form to take away the first name field and just have email, that's just a thesis of something we may do in the future, that's not alignment.

  - I'm wavering, I'm wavering, but I mean, I guess, I'm hearing telling people what to do, I'm tiring kind of, like largely the feature level. And from my perspective, the best practise to roadmapping techniques these days include roadmapping the problems we're gonna solve for the customers and co-creating as opposed to-

  - Mm-hmm, yeah.

  - As opposed to being dictated. I just wonder if you've got a thought there.

  - Yes, yes, yes. So again, I mean, you ask most CEOs what they mean by a roadmap. They wanna see a quarter by quarter list of the stuff we're gonna build, right? So that's what we have to come back to as the definition of most CEOs of what they think a roadmap is. Now like I was saying earlier on, why do I not want my product managers, product managers I work with to do this? Because there are better things we can do with our time, such as going out and talking to customers, discovering the customers' needs. Customer discovery is still extremely poorly done. I mean, there are not that many organisations that even claim to do customer discovery, and the ones that do most of it are doing it poorly. So the typical things you will see there, the root cause is product managers and product designers are not given enough time to focus on customer discovery. What that will... And often shockingly the bigger companies will then have a design team who sits outside of the product team, whose job is to do user research, which makes no sense at all to me because you're just getting this research report that gets dropped on your desk by someone who doesn't understand the technology of the product, and they don't understand the needs of the customer. So again, one of the things I do with the companies I work with is coach them on how to go out and talk to customers. And this is product managers should be talking to customers. What questions do you ask? Well, firstly, how do you find the customers? What questions do you ask? How do you interpret the questions? How do you know when you've had enough interviews? And then how do you turn that very qualitative work into a needs map? Something that says, from the research we've done, this is what we believe our customers' needs are: One, two, three, four, five. How do you then validate those needs? And if we were spending more time working on this, we'd be building products that engage users more, that increase, users love more, that's gonna lead to better engagement, better retention, it's gonna lead to better financial metrics ultimately.

  - I don't think you're gonna get me disagreeing on doing more discovery. Absolutely, more product teams need to be doing that.

  - Yeah.

  - And it's something I help teams with as well, but I don't necessarily see the conflict of roadmapping there in the same way as yourself. For me, I typically use the now, next and later format of roadmapping, which I have to say-

  - Mm-hmm.

  - The first impression is that CEOs and customers are gonna go, "Ah, no, we can't do this!" But my experience is the complete opposite. When you show it to them, it's like, okay, and it's more honest, it's more realistic. They know it's-

  - Yeah.

  - It's a direction of travel. And having some of those experiments that are really early stages in the far right-hand side with the stuff that we're close to delivering on the left, kind of gives that some level of kind of visibility and some feeling of certainty that we're moving the right direction. Any thoughts?

  - Hmm, hmm, I think, yeah, I mean, I'm kind of curious to know like when you do that, how do you analyse the success of each feature, and how is the success of a feature that appears on the roadmap reported back upwards to the CEO or the customer?

  - There's not a feature on the roadmap, there's a customer problem on the roadmap.

  - Hmm. Okay, okay. So then again, so agreed, that sounds probably great. So how do you prioritise those customer problems?

  - Based on the outcome that they're gonna drive, which typically would be equivalency or North Star? So which ones do I think are gonna move that needle most in the near-term-

  - Yeah.

  - Versus which ones might...? So I almost feel like we're violently agreeing, but there's an artefact that we're fighting over.

  - Yeah. Yes, yeah, and I'll come back to that point because it isn't pedantic, it is important, but yeah, so I agree. So on that, what I'd look at doing is ICE prioritisation: Impact, confidence, effort. So we have all of these ideas for things that we can, for problems we can solve, and we have, of course, ideas for solutions for them. We are like where solutions people are after all. The question to ask is, impact, if we solve this problem, what impact will that have on our North Star metric? And then effort ever is, to me a product manager should never estimate the effort, the engineering counterpart, they like Tech Lead, the SA, the EM, the CTO should do that. Product managers should challenge effort, be a pain in the ass or asking difficult questions, but I have never once overridden it.

  - But then the tech people should change the impact as well.

  - Absolutely, yeah, of course, of course. Absolutely. And I think tech people can have much more, much better impact in, a much better impact on the impact score than product managers could have on the effort score because impact of value proposition everyone gets, effort is engineering, which engineers get. The misunderstood thing in this methodology advice is the C, that many teams I work with, they think of confidence as being like, how confident are you in the engineering estimate? Confidence is how confident are we in the impact school? And I love doing this with CEOs who are really confident of just create their own metric and say, "Look, so how confident are you, 1 to 10?" They'll say, "8." You go, "Okay, so have we talked to any customers about this?" "Yeah, yeah, yeah." "Okay, and how did we do this? And have we run any experiments? Have we run any landing page tests? Have we sent some mass emails out?" And you can create, I always do this when I start in the company, create this kind of scale going from 1 to 10 where 8 or 9 confidence is like, we've just run a longitudinal study over the course of three months, and we're extremely certain, and we are never gonna get there. So we are kind of around to get to 4 or 5 on confidence, that's really confident. That means we have run a small scale validation test against a segment of our customers, for example. So, yeah, get that, but then again that ICE prioritisation, that is the useful time, thing to be spending your time on, working with the CEO going, how confident are we that customers really want this? How, why are we confident? Is it your hunch? If it's your hunch, how do we design an experiment to validate that? Where is the input coming from this? So again, obfuscating that onto a quarter by quarter plan of this is what we're building, or even like a now, next, future, can take away from the real thing we're looking at, which is impact, most of the time impacts confidence, and depending on the complexity, the technical effort. Are we just being pedantic and arguing over terminology? I think that is the whole point of this that when... If you have a VP Product or Chief Product Officer who is gonna fight in your corner as a Product Manager and have this type of discussion with the CEO and just say, "No, this is the way we gotta do it, I'm confident. I'm here to run product, you've gotta trust me, this is the way we're gonna do the roadmapping." That's great. But most product managers I come across out there don't have that, they're on their own being told by their boss and their boss's boss, "You need a roadmap." And what they're delivering is a quarter by quarter list of features that are gonna be delivered, 80% of companies out there. So I think what we can do here is start to show what are the more progressive companies doing? And what impact is that having on the business? Why is that making these businesses able to move faster, to learn faster, and to create far more end-user delight, which is the things that startups and scale-ups should be really focused on.

  - Agree with the goals, the aspirations. It's interesting, one of the things you said earlier was, product managers spending a lot of time on their roadmaps. And definitely you also talked about the feeding the beast problem where it's keeping that development team busy. Definitely seen the latter more for myself, roadmaps have generally been a relatively small effort to keep updated, and typically as well. The more you shift to putting the problems on the roadmap, they tend to be pretty stable. And so you tend to not have to spend time constantly iterating, so you get that kind of communication or direction of travel still. But I don't think I'm gonna convince you.

  - No, and I mean, so there's even the question, right? Of when we write something down into a plan like that, it makes it painful to undo it, and this then, it feels like there's a cost to undoing it, where really as a startup we're on this learning journey from knowing virtually nothing about the problem we're solving and the solution. And if everyone was honest, they just admit that, but investors don't invest in you, if you say that. So no one says that, everyone just says, "Yeah, we know it all." The reality is, you start from knowing very little about your problem and your solution. If you are successful as a company, you quickly climb that learning curve, and you learn a load about your customer, their problems, how they work, how they think, what's... And you learn a lot about your solution, how to engineer your solution. Does that learning...? Is there any other form of learning that we do where the way you learn is by starting, by writing down everything you're gonna know at the end? It's like I wanna learn French, I'm gonna write out the dictionary. It's just not the way we do things, right? I mean, 200 years ago maybe that's how you taught people, but that's not the way things work now. So why would you try and predefine your solution to a problem when you haven't yet understood the problem or the solution?

  - So I think I violently agree with you. I'm not, I don't wanna write out the solution.

  - Yeah.

  - But maybe I want to write out the problems that I believe-

  - Yeah.

  - I'm gonna try and solve.

  - Yeah, exactly.

  - Maybe, and...

  - And-

  - And different teams are gonna different ways.

  - And the key thing there, right? I mean, look at artefacts, I'd like my teams to be spending time on. Value proposition canvas, business model canvas. It's like thinking through things like this is, these are the solutions we're building, which are the problems that we think those attach to? And are those problems actually related to an outcome that matters to our customer? Right? And it's that type of thinking that when you abstract these things too much, you lose the ability to have that in-depth thinking.

  - And I'm just wondering if there's anything to do with a lifecycle stage maybe that change that? Because a lot of your discussions have been startup and scale-up.

  - Mm-hmm, yeah.

  - Large corporates perhaps in a different environment, or perhaps the product at a different maturity level.

  - I dunno, so here's an example of a 3,000, 2 or 3,000 person SaaS company who I've been working with recently, right? So they are making the transition from being very Founder-led, Founder-driven, very top-down Founder vision to being a more distributed, you could call it empowered teams. So I've been working with them to set up squads, a whole squad structure, and making sure each of those teams have clear goals, and so on. The breakthrough that we had, right, we started off by, how do we deliver what's on the roadmap? And they've gotta do serious technical integration projects, they've gotta do lots of technical re-architecting, in my view good use cases for a roadmap because there's high complexity teams needing to coordinate with each other. Cool, let's sit and roadmap how we're gonna do it. The breakthrough we had was when I said, "Guys, okay, let's just spend an afternoon, let's throw away the roadmap, let's refresh ourselves. What is the vision? What's the North Star? What are the things we're learning from discovery about customers? What are the sales people telling us, right? What's all the intel? Put that here on one side of the mirror board. On the other side, let's just do a free-flow brainstorm, what are all of the things we could do to really drive our North Star metric, to drive customer delight? Let's brainstorm all of these, let's get this all out, and then I'm gonna leave it up to you to cluster this. You just look at these, and you tell me how do you wanna cluster these?" Now the breakthrough that happened was, they started to cluster it in clusters focused on end-user value, and they've now completely re-architected the way their products are presented to their users, which was very technology-driven, very based in this old architecture to being very value-driven based on these are the different, five different theses for how we're gonna deliver value to the customer, delight them, and drive our North Star metric, increase our attention, and therefore increase our revenues. That type of thinking requires breaking away from this traditional sort of grid-based thinking. And I see that being as important, if not more important because there's more at stake at these big, multiple thousand person companies. So this really applies to a five person startup as much as it does to a 5,000, 50,000 person enterprise company.

  - So I'm gonna ask you to put your pragmatic hat on for a little bit now, Nick.

  - Mm-hmm, yeah.

  - When you see roadmaps, and when you see them working or being useful, what's the best practise on those roadmaps?

  - Okay, so let's be flexible with the terminology. This is what I wanna see in terms of product strategy, which I think is the bigger umbrella this sits into. Clear vision, the purpose, North Star metric, how our customers would behave if they loved our product, when they love our product? Metrics that predict retention. So each product team having a metric, which is predictive of retention, and they're written down, and that's the thesis, but we've written them down and we've agreed them. Growth metrics, the places we're currently focused in our funnel to drive the most traction through the funnel. An experimentation process that everyone agrees with, and a prioritisation process, that is agreed with. So those are the components that I look for. If we zoom all the way into that sort of retention metrics area, each team has one retention metric. If they're a growth team, they have a growth metric, they will then have responsibility to do customer discovery. Undoubtedly from that using ICE prioritisation, they will have a prioritised set of customer problems that they're gonna focus on, and they will have next to that a prioritised set of experiments that they wanna run to validate or invalidate ways to solve those problems. So it's when we have that, that I see this working really, really well.

  - I guess, the answer might be the whole thing, but what's the biggest mistake or the biggest anti-pattern you see on the roadmaps?

  - Definitely it's this sort of psychological stress that it puts on you to deliver what you've already committed to because most of us are really conscientious, we don't like committing to something and then uncommitting from it, so just the fact. And we know how to use this really well, right? We know that if we're trying to break change a habit, I wanna go running three times a week, write it down, right? That's why we do OKRs like because when you start writing stuff down, what you do and don't wanna do, you're more likely to do it. So that's the anti-pattern that I see, and I know everyone comes at this with good intentions, right? We just wanna get a view of what it is we might do potentially. Cool, that's fine. Like doing a sort of a planning exercise, a vision exercise with what the roadmap could look like. Yeah, maybe that is valuable, but creating a commitment to deliver something before you know if you've gotta deliver it, that's the anti-pattern.

  - And so you've mentioned Gibson Biddle, I would love to talk to him, if you can introduce me, that would be awesome. Whose advice do you listen to in this space?

  - Oh, I mean this is great. I mean, so like the way I got into this whole thing was because my company was not doing well, right? So I'm not like, I don't come out and just say, I've nailed everything in my life. I've just done so many things badly, particularly in product that I was trying to scale up my teams and put in, go from one team to multiple teams and the whole thing was just failing. Cultural problems, people churning, like everyone was unhappy, the products weren't working. So it was at that point that I started to deep dive, and I was probably more pro-roadmap before that point as well, by the way. I was probably like, yeah, you guys have gotta write down what you're gonna deliver, so that then we'll deliver it. So what kind of caused me to flip was a couple of things. So Gib was definitely a big part of it because he's created a framework which works really well. I think like, it just kind of tried to save, but obviously Marty Cagan stuff is very good. He's done, I mean, mainly because for many reasons, but he's evangelised things so well and built such a brand that even when you have the most conservative corporate CEO you work with, you can kind of point them in that direction, and he's got that kind of credence at that high level. Honestly, one of the most impactful presentations I ever saw for me was Teresa Torres speaking "Mind the Product" or something, talking about behaviours, how everything is just a behaviour. All we're trying to do is influence user behaviour. The only thing we can do as a product manager is influence user behaviour. What do we do? We put some pixels on the screen, maybe we do some sounds, but we are basically putting pixels on the screens, and those pixels we need to get to change someone's behaviour. So there's some of those big names have been influential, but honestly going out and talking to other Chief Product Officers. So I kind of, I use LinkedIn for a social networking purpose, which is amazing, right? That I just reach out to people who look like they look interesting, that are interesting things. I talked to Chief Product Officers, to CEOs, particularly people who were struggling or have fixed problems. And it was in deep-diving with these kind of people, I started to understand the power of aligning squads, well-organized squads where the team has all the competency they need to execute with a clear metric, with the North Star metric, with a clear vision on top. It's from those one-on-one conversations that I find super-impactful.

  - And any particular resources you use or would recommend?

  - So, yeah, definitely. So Gib's stuff is good, he's put loads of his content online for free. I have also tried to put everything I do, so I do, I'm Chief Product Officer of a startup called Sama, and I also do a little bit of consulting. I do a few, with a few companies a year, helping them build out their product strategies, so all these things I've been talking about. But my goal with that is very much to put all of my materials out there for free, so they're on my website: NickBlack.us. So I try and put everything that I learn and know about, and the models that I use in the frameworks, I try and put out there for people to use. And I also have a mailing list, in which I share diverse views. I don't just go on about roadmaps the whole time. So we talk about all kinds of things.

  - Neither do I.

  - Yes.

  - Yeah, and we'll make sure we have links for those in the description below, so that people can reach out and get in touch. Okay, this might be an interesting one now. I have two last questions I always like to ask. If you had to distil your philosophy on roadmapping into one or two sentences, what would it be?

  - Focus on how quickly you can learn to the expense of all else.

  - And is there anything else I should have asked? I think this is a Steve Blankism-

  - Yeah.

  - That I didn't ask you.

  - It's been a very expansive conversation, so it's been a lot of fun. I guess an area that could be touched on at some point in the future is just drilling a bit into this. The difference between this kind of quarter by quarter delivery roadmap and then this architecture of vision because the whole area of like defining... One of the areas that I find gets a lot, very mixed up in this is that we have a vision and architecture for what a company needs to look like, and there are financial metrics, it needs to be able to hit. You need, there are certain ratios that are important, we need gross margin and EBITDA to drive evaluation, we need free cash flow to drive evaluation. All of these architecture things are important, that's where we need to get to. The magic and the art I think of a Chief Product Officer is to navigate between knowing nothing to getting to that definition of what the company needs to look like. And I find that is like a level that sits, that's the purpose of the product strategy. It's the how that tells you how you go from this moments of not really knowing a huge amount to hitting the vision for how this company we're building is gonna work, but also influencing that vision because it's not gonna be right. Whatever spreadsheet we made on day one, that's gonna change and iterate.

  - Okay, Nick, it's been wonderful talking to you today. I think we'll call it there. One last opportunity though for you just to pitch yourself and the things you do and the companies you work with or for. Fire away.

  - Yeah, so I work with startups ranging from five people seed stage startups all the way up to big corporates, and I help them do a few things. Firstly, I help them avoid the common and uncommon mistakes that startups and scale-ups make when it comes to product to roadmapping, to having the right metrics in place to customer discovery. So I sort of bring 15, 16 years of experience doing that to help you avoid those mistakes. One of the key things that the outputs we get from this is moving faster, that teams are able to move faster, they're able to move more confidently. I was just catching up with a customer last week, he was telling me that before we did the workshops together, they'd spend a lot of time talking about how they should do things. Is this the right process? Is this the right methodology? And a lot of their times on the how. After I worked with her to put in place a framework for product strategy, they now spend all their time talking about how they're gonna delight their customers. Putting these two things together, moving faster with avoiding making common mistakes, having your organisation structured properly. This is incredibly valuable, and I absolutely love doing it. I do it in interactive workshops, that's a tonne of fun. That is all via NickBlack.us. What I also do, I'm Chief Product Officer at a company called Sama where we are completely rethinking how productivity and engagement works. So we have come at this from believing that sort of telling people to be productive and telling people to be engaged isn't working, there's a massive productivity and engagement problem. What we are doing is empowering employees to take control of their own productivity in their own engagement. And we are building a whole ecosystem of products, which we'll be delivering this, starting with a product that's been in the market for about 18 months now, where we are bringing the world's best exec coaches, so that people who are normally coaching CEOs, we've managed to bring them to all employees. So companies can come to sama.io, they can sign-up to subscribe to our service. And it means that you as an employee, you can meet with this incredibly high calibre coach who will work with you on your goals, your aspirations, your habits, where you wanna go to, how you wanna tackle your work. Whatever the topic that's important, you can work with them as frequently and wherever because it's all over an app, all real video-conferencing, as you want. So we're putting employees in control of their own productivity. So that's super-fun, and that keeps me quite busy.

  - That's interesting. So Nick, it's been a pleasure talking today a little bit more kind of, I won't say quite confrontational, but a little bit more coming from different perspectives than-

  - Yeah.

  - Some of the previous ones, which is actually what I love, that I want my-

  - Yeah.

  - Perspectives challenged. I want to be able to challenge people's perspectives to kind of explore the understanding of the space. So been a pleasure having you here today, Nick. Thank you.

  - It's been a real honour to be here, Phil. This is a great show.

  - Thank you.

  - I'm super-glad to have been here.

  - So as always with any YouTube channel and podcast, just a reminder to like, follow, subscribe, hit that bell icon kind of to join us on this journey and hear more. And if you'd like to take part to stand where Nick is, maybe not in his bedroom, but kind of somewhere where we can have a conversation, do get in touch through info@talkingroadmaps.com, we'd love to talk to you. Thanks very much.