Is your roadmap fixed? | Daniel Elizalde
In episode 3 of Talking Roadmaps, Phil Hornby interviews Daniel Elizalde, a seasoned product executive, and innovation coach. They discuss the flexibility of product roadmaps, the impact of emerging technologies on product development, and strategies for taking ideas to market. Daniel shares insights from his extensive experience across various industries, including climate tech and telecommunications, and offers practical advice for B2B companies. Tune in to learn about the nuances of managing product roadmaps in a rapidly evolving tech landscape.
This is our first REAL episode, Justin and I spent ages debating if we should split or edit down the discussion here. But there was just nothing to cut and it all just made sense together! So we unapologetically have kept it as one long discussion. I know I have relistened several times, and every time I find another layer of insight!
Daniel is a Product executive with over 20 years of experience leveraging emerging technologies to drive product innovation in industries such as climate tech, eCommerce, manufacturing, telecommunications, automotive, and semiconductors.
He has held various leadership positions, including VP, Head of IoT at Ericsson, Head of Products at Stem (AI-powered energy storage company in Silicon Valley), and Instructor at Stanford University.
As a Product Innovation Coach, Daniel has trained and advised over 1,500 product professionals around the world on how to take their ideas to market.
Daniel is also a mentor at Greentown Labs, the largest climate tech accelerator in the US, helping startups address some of the world’s most pressing challenges.
Explore his training programs, blog, newsletter, Enterprise Product Leadership podcast, and more at https://danielelizalde.com.
“It’s a map of the journey as you go, and it’s flexible”
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! Look out for a sketchnote to summarise and a blog post of the best bits coming soon.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
Daniel also just launched a book all about B2B Innovation called “The B2B Innovator Map”. It is a great read, I should know as I was one of the beta readers so got super early access! If that doesn’t convince you then you can checkout a free chapter of the book here. Or if you just want to grab a copy go here.
He’s also the creator of an awesome training program focused on helping product managers in IoT, I’ve taken the course myself so can vouch that it is full of insights and provides a great framework for approaching this complex domain! Check it out here.
We already have loads more episodes recorded with some real superstars of the product world, like Janna Bastow in Episode 4, so watch out for the next episode!
-
Hi Daniel, welcome to Talking Roadmaps. Great to have you here. And yeah, I guess great opportunity. Can you introduce yourself to our audience?
For sure. Thank you so much, Phil. It's really a pleasure being here. Thank you for the invitation. Well, a quick introduction. My name is Daniel Alde. I'm a product innovation coach. I work with B2B companies, helping them with taking their ideas all the way to commercialisation. I've been doing this for a long time and I have all the scars to prove it. I've been working in technology for over 20 years in multiple industries, always B2B industries like manufacturing, aerospace, energy, semiconductors, telecommunications. I've been head of products at Energy storage company in Silicon Valley called stem. I was vice president, head of IOT for Ericsson. I also teach iot product management at Stanford University and today I'm back in Austin, Texas after living in Silicon Valley for seven years, working again as an independent coach, helping companies with their roadmaps in early stage with a specialty on climate tech.
Perfect. Wonderful. And yeah, I have been through your iot product management training course, not at Stanford, the online version, so I can definitely vouch for that one as well. We'll stick a link to that one below as well. Let's go for that one.
Thank you.
Yeah, and I guess what I'll just asked, if anyone's interested out there, anyone's interested in doing what Daniel's doing, please do reach out in the comments below or talk to me and if you find this talk interesting, please do like, subscribe, hit that bell, all those good things that everyone tells you on a YouTube channel. So let's not live with that too much though.
I mean we're fundamentally talking about roadmaps here in the channel and I know you have a particular B2B in innovation kind of slant to where you come at things from. And I know I personally, I've spent a lot of time in the B2B space as well, and I do reflect that there're awesome differences in B2C and I have a philosophically I think innovation is part of product management. I know that some people will talk about it as a separate thing, but for me it's part of the discipline, whether it's one person doing the job or it's distributed is a different matter, I guess.
Yeah, I completely agree. I think innovation, the way I define innovation is just the process for delivering value to your company and to your customers by the introduction of new products and services. So you can think of it as just like the early stages of a product and so therefore product management, it's crucial and there's roadmapping and everything that we do as product people is just a different stage with different characteristics. And of course the B2B flavour adds another dimension there. And you are very experienced in the area. In fact, you were one of the reviewers of my upcoming book, so I'm excited to have this conversation and get your take.
Sure. I've got to be a little controversial then say Sure. Innovation can also be at the pricing level or the repackaging of maybe an existing product and service as well.
Yes, I think that's an excellent point. And really innovation is it's a way to deliver new value for your customer and your companies. And oftentimes when I coach companies, it's not necessarily about building a new product, it's about packaging it differently, positioning it differently, pricing, adding certain functionality. It's maybe going to a new market, it's maybe tacking a different vertical. So yes, all those are true and I focus on specifically new product innovation. But in the process of launching a new product to market, you can have a product that is somewhat similar to others in the market, but the innovation is in your delivery model or in your different stages of the enterprise lifecycle or in your pricing or in your partnership model. And that's very valuable.
I forget who said it, but there's a quote from someone that's something like we're all imperfect copies or we all make imperfect copies. So no matter how much you try to imitate that competition, we end up with something different and that might be better or worse I guess.
Yeah, it's true because I think the key to innovation to me is we have to focus and understand your customer's challenges, understand where your company can add value and then propose a solution. And so anybody can go out and understand the challenges of the companies customers and they will have their own strategy and the solution that they will come up with, it's going to be different because they're coming from their own vantage point. So I think that's very important that the same problem can have many, many solutions and that's where you create the differentiated products, services offerings in the market by adding yours land. And that's how we're all different. Right.
Cool. Yeah, and I guess one of the ways of getting to those solutions is roadmaps. And so maybe from your perspective, what's the purpose and maybe what's the audience of roadmaps?
That's a great question. I've always thought that product management really is the discipline of delivering value and carrying your company through that innovation process and beyond. And so I think that the roadmap, the main purpose of the roadmap, it's an internal tool. It's a tool to align your company on what the vision is in a concrete way, basically what is it that we're building that's going to deliver the value and then have this tool that provides a shared language for your executive team, for your development teams, for your sales, everybody. So it's an internal alignment tool because building digital products is very complex and so it's very hard to visualise. And so the roadmap is that tool to help anchor it down and say, this is what we're building, let's discuss. It's not something that dictates the exact path or something that is magic and is created, create the millions of dollars. It's a map of the journey as you go and it's flexible. Would you agree with that?
I think broadly the interesting point I pick up there is it's an internal tool. What about in the B2B context? I've often shared roadmaps externally, so what's your take there?
Yeah, it is true. I mean there is that option of sharing the roadmap externally, especially in B2B because customers, once they buy your product, they're going to be using your product for a while. It becomes sticky because it takes a lot to onboard and get the companies on your product. So they want to know what's coming, what are you going to deliver when, so you can use that as a potential sales and customer development tool. But it's a little bit tricky though because one of the things that is important to note about roadmaps is that they are not set in stone. They might change depending on new insights you have from the market strategy changes, we have the covid pandemic, it's like that hits and all of a sudden your plans go out the window. And so if you share the roadmap with your customers in a way that says this is exactly what's coming, you might be hurting yourself especially in B2B, because if you are sharing this with Walmart or with General Motors and they say, we want that, all of a sudden your sales VP and your CEO are going to say, we are building that because Walmart wants it.
So it's a tricky balance.
Yeah, I mean you mentioned gm. One of the meetings I quote often when I'm training people is a meeting with gm, funnily enough where I spent four hours in the room in Detroit with 11 senior people from gm, and I flew to the US for less than 24 hours just for that meeting. It was a pure discovery session. It's like where is your business going in the future? Where is my business going in the future and how do those align? How do we help each other? And I guess it didn't specifically take place around the roadmap, but now I think about it, it could have in terms of a strategic level roadmap in terms of theirs and ours and seeing about the alignments.
It is true, and I think that's a very important point because especially when I coach more junior PMs, they're tied too much to the agile methodologies. So for most of them, the roadmap is a bunch of little features and stories and minutia that you need to build. Executives don't care about that. They care about what is the overarching picture of what am I paying for in order to build and what is going to be the outcome of that towards the business. And so I think it's important to define that because the roadmap is a communication tool and you need to understand who you are communicating with. Are you communicating with executives? It's a different flavour of roadmap. Are you communicating with customers? It's a different one. You don't want to overcommit are you communicating with your engineering team? That's a different type of roadmap. So there is multiple flavours of the roadmap, different views of the roadmap depending on what your goal is. And really your goal is to communicate and advance your product forward.
Yeah, perfect. Yeah, and I think if you had my version of this, I think I talked about, and Justin's as well, we talked about communication and alignment. That's kind of key points of this. I think I talk about there being different views of one roadmap, but we're talking to those different audiences. So I think we're very much on the same page, but I think you've mentioned another type of roadmap in your book. You've mentioned an experiment roadmap. Maybe you could unpack that a little bit.
For sure. Yes. So in my book I talk about the innovation journey from idea to your first 10 customers from a B2B perspective. And so there are different stages that you need to go through. Once you get to the point where you understand the challenges that your customer has and you have an idea of where you could provide value by creating a new product or service or offering, then it's time to figure out your solution. What is it that you're actually going to build? And I think that at that point it's very important to have instead of a roadmap, a product roadmap, I recommend having an experiment roadmap because at that point you don't really know if what you in your head plan to build is what will solve the customer problem. As you know, there's a big disconnect or can be between understanding the customer pain and then creating a solution that they are actually going to buy.
Those two things are not immediate. The fact that you understand the problem and you build whatever you think they want doesn't mean that they want it. And so until you get enough traction with customers to know that what you're proposing is the right thing, and that's where my concept of ten first customers comes into play, then you have to be very careful with what you build. And that's why I recommend having an experiment roadmap basically. Now that you understand the challenge, what are the assumptions that you have on what a potential product could be, and then create a series of hypotheses and how to test them. And that's your new roadmap for the moment because at this time you're not ready to build. What you need to go out and do is experiment and make sure that you understand which ones of your assumptions are correct and which ones are not.
So therefore, because a roadmap is a communication tool, what you're communicating here is to your executive team within the next three months, our goal as a product team is to go out and test these things with these experiments, with this desired outcomes. And depending on the outcome of that, we will be able to propose what we will actually build and then that eventually becomes a product roadmap. So in my view of things, when you get to a product roadmap, it's because you have certain idea or certain validation from the market that what you're actually going to invest engineering cycles on is something that the customer would be willing to pay for.
Okay, so that almost sounds like a discovery roadmap and a delivery roadmap within of that kind of dual track sort of thought process.
Yes, yes it is. And although you always have to have that dual track in the way that I propose in my book is that there is a whole stage within the innovation journey where your only focus is on that discovery roadmap. You are still not building, you're just using little prototypes and you're doing experiments. So it's not necessarily a dual track as you would know it later when you are building. So there's a lot that you need to remove uncertainty before you actually start building.
I guess we're doing that kind of early problem solution fit and then get onto product market fit as opposed to the optimization and mentation in life where we can have things running more in parallel.
Yes. And if I may, now I can be controversial. You mentioned the topic of product market fit, and that's a topic that I discuss in my book as I believe that is really a flawed assumption. And I've talked to a lot of companies that their goal is to get to market fit, but when you talk up to them about what does that mean, they really don't know. You ask 10 companies, they have a different definition. And so the challenge with product market fit is that you can't really define it in a concrete way. And so when you are working in innovation, you are not only balancing the needs of the customer, you are also trying to make sure that your executive team keeps supporting you and doesn't pull the plug on your project. And so therefore saying, our goal is to get to market fit, it's really hard to have milestones, no progress. So that's why I advocate instead for a concrete milestone of first 10 customers, if you say to your executive team, in this stage our goal is to do all these different things and when we get to 10 we will evaluate what our next step should be, whether we should go invest in infrastructure, where should we pull the plug there, where should we start scaling how? And that I've learned is a lot more concrete as a communication mechanism than saying product market fit, which is always a moving target. And I know
A little bit of the church of lean startup should we say kind of the general phrase, but yeah, I guess in essence you're making a definition of what are we going to call or what are we going to use as a much more clear to measure measure of we've found some level of fit. If 10 customers are going for it, we've got some level of commitment, someone is interested in it. And you also hinted at the company interest, so maybe there's a strategic fixed element missing as well.
Yes, exactly. Exactly. So you have to carry that strategic commitment of the company and then you can say at 10, we'll make a decision, right? Because at 10 we'll know what it would take to scale, what are the risks, what is the potential? Because what happens with B2B as you know is that you might sell one customer, but you don't know if you can deliver value to them because you still have to deploy and onboard and operate. And so my experience is that after 10, you probably have seen everything that can go wrong with early customers. And so now are we going to be able to find more customers like this? Are we going to be able to deliver the value? Are we willing to invest in what it takes to deploy and sell and operate this type of a solution, et cetera. So 10 becomes a decision point, and so you can say that your roadmap goes to experimentation and leads to working prototypes that you can sell, and then your major decision point is 10. And then from there you continue up to a path to scale, not to scale, but the path to scale
Scale. Although I mean from my own experience tends actually quite a lot of customers in some industries in the automotive space there are lots of brands, but there's only something like 20 companies that'd be half of the market. So I guess there's maybe some element of what's proportional to the market size as well.
That's a really good point because I used to work at Ericsson in telecommunications and the company's a $40 billion company and it has like a hundred and something customers and that's it because that's all there are. And so you are very right. My point with making it tangible is that you have to find the balance of when you think you have seen most of the challenges that you will encounter and you are sure that you can deliver value to that type of customer, maybe five in your industry, maybe three, but let's do 10.
10 is a good rule of thumb,
A good
Haven't got the ability to count. Who can then reason from I guess?
Exactly. And sometimes I get into the discussions of what about nine? Sure. I mean the point is make next step financial decisions of your product once you have concrete evidence that you can deliver value to a certain number of customers, I put the line in the sand of 10. But again, it's a very good point. You have to work within the constraints of your industry and what's realistic.
Cool. So we talked a lot. We've got a little bit ahead of where I'm thinking, I'm pretty sure, but that's awesome because it's more natural. Just circling back a little bit, in your world or your opinion, who owns and who maintains the roadmap?
That's a great question. I think the product team is the group that must own the roadmap. And then since we talk about different views of the roadmap, I think up and down the hierarchy of product is the people that owns the different views. So for example, the strategic roadmap that aligns with the vision at the highest level, the chief product officer must own that. And then down all the way to the quote line product managers that are doing the work in the trenches, they are more focused in the actual digging into the features and the stories and those kinds of things. So I think it has to be on the product team as an owner with collaboration of the various different departments. They don't just dictate what they're going to do, but there has to be this alignment. And so I see it similar to the concept of OKRs
In the sense that objectives and key results where there has to be some high level objectives and then they flow down to the rest of the company. So the product roadmap at the strategic level that is owned by the chief product officer and it's in alignment with the C-suite, then that must cascade down to the different levels that keep adding detail. But it has to be aligned all the way through. Sometimes it's not. Most of the times it's not. And in fact in my book, the first stage of the innovation journey is strategic alignment. I see many companies struggle with not sure what we're going to do. So if we use the roadmap as an internal strategic alignment tool, then it needs to go all the way from the c-suite to the teams doing the work.
Nice. I like of ownership at the different levels. So you've kind of got the different layers of audience and then going parallel across going out, that ownership being taken there. I quite like that. In fact, I very much like that.
And for me it makes sense because if there needs to be a strategic decision and you're taking it to the board of directors, I've been in those situations as head of product that you're presenting to the board because you're raising another round of funding. Well, the roadmap that you're going to take there is going to be very different to what your engineering team needs. Therefore the people that are talking to the different layers of the roadmap need to have access to the right. People need to talk that language and need to be able to convey at the level of detail that is going to advance the project. You've seen it many times. You bring in a young very capable technical product manager to talk to the board about what's coming next and the board is like didn't get anything. That does not make any sense. So you have to be able to use it as a communication tool, therefore communicate at the right levels
And well communication. I think I said this in my own run through this of communications for the audience, just more so than it's for the person communicating. It's about getting the advantage across. They need to receive it. Yeah, totally agree.
I like that a lot.
And you hinted at actually alignment to some of the things like strategy, vision, objectives in the form of OK R. So how does a roadmap interrelate to those things?
Yes, so I believe that the first thing has to be the, there's always these things about strategies that is the vision and the mission and this and becomes very muddy. The way I think about it is from the strategic perspective, the company needs to agree on the business outcome they want to solve for their customers. So at the highest level, the highest level of strategy needs to be we are going to focus on solving this particular business outcome. For example, we're going to help our customers reduce their energy bill. Are we going to help our customers increase productivity in their manufacturing by 30% or something high level? And then it starts flowing down into, okay, now that we have that idea of well, as a company we want to do and what the company is willing to support, then we start breaking it down into the other teams, okay, what does that really look like?
Who has this problem in the market? Who are the players? Who are the users? And then the roadmap starts becoming more actionable. And so I think that it all starts by saying, what problem are we trying to solve? And I mean, you're very experienced this, right? But a lot of companies struggle that when I do coaching and I talk to CEOs and them that question, they can't really tell me what problem they're looking to solve. And so it starts there. You can't have a roadmap. It's a typical one. It's like if you don't know where you're going, you can't have a map or any map will take you there. So I think it starts with that alignment. And then I think as the head of product, our role is to get to the company, get our executive team to agree on what is that high level statement, what is the business outcome that you want us to pursue and explore, not build, explore. If we do that as heads of product, we can take it from there. We don't want executives to tell us what product to build or how it's going to look. Just tell me what problem you're looking to solve as a company and then I'll come back and bring you market information, user information, potential products to invest in, blah, blah, blah. But it starts there,
Getting that principle across to senior leaders who didn't have a product background. I found you so hard as well. I think product people feel a much stronger need for that big picture vision of where we're going for it provides that north staff for us to know that we're doing things that are aligned, you go in the right direction. Whereas I mean automotive in particular, it's often very project oriented. The OE EM has said, I want this with this spec go forth and deliver. Well, okay, but where am I adding the value here? And if I'm trying to create that scalable delivery of a product led approach, I need to know which types of problems we're to solve so we can bring those products together so that when the OEM says I want X, it's like, oh yeah, here it is, it's ready. We'll just make those last 10% of tweaks to make it work on your platform and then we're good to go. But it's not having that clear vision, so many workshops in the past.
And I think it is very important though because I think it's really the role of product leadership to agree with executive team on what kind of business they're looking for. It's okay if an OEM comes and says, I want this and you want to build it, but that's a custom development service type of business that has a certain margin. And there's a lot of companies that make a tonne of money. There's EY and Accenture and Deloitte and BCG. If that's the business that you want to go in, that's fine. You don't need a product team, you need a services delivery team. If you want a product team, it's because you want repeatability. And so therefore it's okay if that OEM wants that functionality, but then the product team needs to figure out is there a recurring business out of this? And by recurring, I don't mean like SaaS, but I mean is there customer 2, 3, 4, 5, and six that we can sell the same thing because the investment in building it is not going to be offset by the first customer. It's going to be offset by multiple customers. And if that market is not there, you're not going to make your money. Right?
Yeah, I mean I've even built business models where ultimately it wasn't offset by just the direct customers and we had, there was things like secondary data markets and things like that to actually make it financially stack up.
And I think it's also important to understand, especially in B2B, where are those requests coming from? Oftentimes it comes from a senior salesperson that says, the OEM wants this today. And there all they care about is making their customer happy and making quota, which is why they make the big money. But there has to be this strategic alignment and this willingness to have this discussions to say, I understand that that customer wants that, but we won't do it because there's no customer two, three and four, so therefore we have to take a step back. It's out of strategy, out of this. That's a lot easier. Like you said, if the CEO has a more productized mindset or really invites product to the table, but if the CEO comes from sales and they want that deal, there's not a lot we can do. Right?
Indeed. Okay. We've talked a bit around roadmaps. What's on a roadmap in your head?
Yeah, I think we talked about the different levels. I think that from a highest level, the strategic one, it's really just saying this is a problem we want to solve and we believe it can be solved with a product of this store that has this type of modules. It's super high level and it's showcasing the benefit of each of those things. It doesn't say how or it doesn't say how you're going to do it, what it's going to look like, and then as you go down, then it's more about specific modules and then each of those modules should have the components that build those modules. But I do agree that at that point you also need the dual track. So this is what we think we're going to build. We're going to start, but we're also going to be testing whether this works. And at that point you're doing less of discovery and more of usability testing and those kind of things.
And those become even more important when your product is not only software, but you have iot and you have connected hardware, and so you have to do all those things. There's also the roadmap for those kinds of things should also include things that you're going to buy from a third party and you need to integrate so that your solution works as a whole. Let's say you're only building the software, but you need hardware. Well, unless you figure out which hardware and have cycles in your roadmap to actually test those, then you're not going to be able to deliver that functionality. So your roadmap at the execution level should be all encompassing, not on the things you're going to build, but also on the things you're going to buy and the things you're going to integrate.
And what about sequencing or time? How do you visualise that in a controversial one?
Yeah, no, I don't think it's controversial. I think it's a great point to have and that's why again, in my book I talk about the prototyping stage of always focused on the items with highest risk and risk can be a lot of things, business risk, technology, risk, desirability risk. And so always focus on those first so that you can systematically remove the risks. I was coaching some large corporations where they were building these new products and they were doing some tests and they had tests for the Sybil visibility and viability, the test for feasibility and sorry, desirability, feasibility and viability. The feasibility and viability ones, they would put some time on and they've determined that they could build it, so they're going to start and build it, but they didn't have any desirability. So at that point it doesn't really matter what you build. So I think that a lot of companies focus a roadmap on the low hanging fruit, the things that they can build, but it's not necessarily the things that have the highest risk because if the thing with the highest risk doesn't come true, then nothing else matters. So I think the sequencing is more about prioritising based on risk and then you start building. Right?
Sure. And just out of interest, there's obviously this new crop of product management tools and road mapping tools out there. Any that you particularly like or you have used?
To be honest, I've evaluated them all and I think all of them are great. I mean, they've grown so much from the time that I was doing these things in Excel and I've used several from AHA to ProdPad to product plan, and they're all really great and they all have different functionality. What I like about them, especially the more prominent like AHA and ProdPad and product plan, they have become the tool to centralise a lot of the information that informs the roadmap. So your discovery, it has a place for it, your personas, it has a place for it. So it's not just this is what we're building, but this is how we arrived at this. So they're becoming a lot richer. And the thing that I like about these tools is that they're getting more accepted. More and more companies are deciding to invest in product specific tools. As before it was like, oh, if it's for engineering, whatever, otherwise you need to use Jira. So I think they're getting a lot more traction because are the product profession is more, it's better understood, it's better represented, and therefore you need your own tools. Right.
Perfect.
Anyone said, what's your perspective on tools?
So my perspective is none of them produce anything pretty enough. And I say pretty enough because again, I come back to that communication piece and something that looks good helps, but what I love is that single source of truth
Giving one source and being able to render different views. Now is everyone producing the different views that I want to see? No, but that's the nature of a product approach. They're not going to hit a hundred percent of a hundred percent of people's needs or desires. So as a product person, I take that pragmatic approach and I mean I was about to source AHA in my last corporate role because I felt the efficiencies driven by it were going to help me there. I'm a partner of ProdPad these days, so look at that quite regularly, and I think Jan is hopefully going to be on the show at some point in the near future.
He's great. He's a good friend.
But yeah, one, in fact, the guy who's going to be on the call tomorrow recording another session that will come out a few weeks later, he's using product board in his organisation and he gave me a toe through the tool the other day and I can see the value of it. Again, I think what I see is the benefit of the efficiencies. It drives as one source of truth and not having a thousand different versions in PowerPoint that are all slightly different and made prettier by sales and usually moved by three months.
And it's true. I mean I think that there's also a lot of power of understanding how your roadmap is going to be communicated throughout because one of the important things about communication is you have to communicate in ways that are natural for the company to receive. And so if a company is used to PowerPoint presentations with this particular template in this way and you get two slides, then it doesn't matter that you have this systems, you are going to go and create a couple of slides that can be in the board deck or you can go in the presentation for this or that. So I like that idea of source of truth, but you're always going to have to be modifying or maybe extracting and using word and PowerPoint so that it can be consumed because the moment you're forcing the company to look at this new format and look at this new tool and you lost the battle.
Yeah, totally agree. So okay, we've got roadmaps now. What are the biggest mistake or the biggest anti-pattern that you see on a roadmap when you see them with those clients you work with on your previous career?
I think the biggest, there's a couple. One that comes to mind is, especially if you're thinking about the early stages, is that it's very important to narrow down your roadmap to a specific target audience because you need to make sure that you are evaluating against the same type of customer so that you can know whether you have a problem and solution that is repeatable. I see a lot of companies with this anti-pattern of, well, I have this feature for this company in automotive and this other feature is going to be for this prospect in energy and this other one is for this startup in healthcare. And so you're not really building, you might be building a product, but you're not converging into something that you can have with 10 healthcare companies that are the same, that okay, this is a prevalent problem. So scatter approach, they're just building for that. So that's one of the biggest ones that I see.
Yeah, it's the blunder bus. We're going to just go out, we're going to fire and hope we hit a bit of everything and get it something that's worth having. Interesting.
And sometimes it's driven because of the relationships with sales. Sales says, Hey, I have this big customer in healthcare, we need to have this to close that deal. And so, okay, we'll put it in the roadmap. And so all of a sudden you are not building anything that it's conducive to something as you're building this Frankenstein from the very, very beginning and your product will grow to be a Frankenstein like all do, but when you're early stage, what you're looking to understand is what are the challenges of this first 10 customers, this first group of people so that you can go and find more like them, but if you have one of each, I talk to a lot of startups and say, Hey, we are in three different industries. And it's like, okay, how many customers do you have? Well, we have one of each and we're doing different things for each. You don't have a product.
All your three separate startups just happen to be in the same room,
So you need three times the funding because you're not going to pretty much, right? Yeah. And that is a hard thing. I think as product managers convincing the executive leadership team to narrow in a specific audience because you need to find that convergence and repeatability of the problem. Solution is one of our critical jobs at the very beginning because if you have that agreement from the strategic perspective, then the roadmap just flows to that. When I see a roadmap like that, I don't think about the product in particularly. I think about there's not strategic alignment on where this product should be, so it's a higher up problem. The roadmap becomes just a symptom.
So now the hard question, Daniel, if you had to distil down your philosophy on roadmapping into one or two sentences, what is it?
I would say that's a great question. A roadmap is a communication tool and your role as a product person is to provide value to customers and your company. So therefore your roadmap should include the items that have the most risk that you're going to test first and should only go to development once you have some customer validation. And so you want to make sure that you're focusing on experimentation first and then you're using your roadmap to communicate what you're doing for whom and what is the next step. Cool. Was that okay?
Probably a little bit more than two sentences, but actually I think the last bit was really it. And the first bit was you forming the thought as you got there,
Right? I was like, hmm, it's hard, right? Because roadmaps are so many things to so many people as a communication tool. We talked about from executive all the way to execution. There's so much. So there's a lot to talk about.
And by the way, when I answered the same question, even though I wrote the question, I did the same as you. I talked for a little bit, it's like, and then I came back. Here's actually my answer.
Yeah.
So last question for you. What should I have asked you that I haven't asked you about roadmap?
Wow. I would think that since my focus is on B2B, one of the challenges that I see a lot is when you start working with your early adopters, your first 10 customers, there's always pilot programmes and a lot of products die on pilots. So how should your roadmap account for that pilot stage? I think that's an important thing because that is the stage where you are getting close to validation and you might need to build a lot of things that you need in order to make that particular customer successful, but they also need to be abstracted in a way that helps the overarching product. So understanding what goes in the product versus what's a decoupled module versus what's a partner module versus what you're going to buy from the market at that stage is super important. So your roadmap at the early adopter stage where you're trying to nail down the value for your first 10 customers, I think it's a little different and it's super important.
Cool. That's really interesting. Yeah, I don't think I've launched a B2B product without doing a soft launch in the last 10 plus because I want that first reference customer, at least the first one, and I want to go through the pain with them, get it more stable for that second and third so that we have less issues. It's also the first question in the sales meeting is that's we great, but who else is you Receiv? And I've already got the answer
And in fact, if I may, I can elaborate a little bit on that because I think another aspect of the roadmap at that early adopter stage is to start thinking about the internal tools that your team will need to deploy, deliver, and operate that customer. So what admin tools will you need? What kind of maintenance things? Troubleshooting onboarding tools because for your first 1, 2, 3, 10 customers, the product team and engineering team has to feel the pain of what it takes. But as you start driving towards scale, you're going to need to start requiring tools for making sure that you can operate these systems, you can demonstrate compliance, all those different things. So those internal tools become an important line item of your roadmap. And once you get to your first 10 and you need to make decisions about your next steps to scale, one of those decisions could be what we need to invest in solidifying our infrastructure, or we need to invest in internal tools or so that you can actually grow. So at that point, it's very important to think about the overarching life cycle of the product as opposed to just the end customer. It's like the end customer product is important, but how are you going to operate that? How are you going to track it? Are you going to collect money? How are you going to all these different things? So that becomes a super important part of a B two P roadmap at that stage.
Perfect. Awesome. Daniel. So I think we'll probably bring it to a close there. I'd just like to thank you for your time today. It's been awesome talking to you about both innovation and B2B and roadmaps. Just to remind everyone out there, if you found this interesting, please like, subscribe and hit that bell so that you get told about future updates. Daniel, in case you chance for a little bit of a pitch.
Thank you so much, bill. I really appreciated your support today and throughout the years. I really appreciate it. And so if you like what we discussed here, my book, the B2B innovators map is coming up in a couple of months, but you can go to b2b innovator.com and you can download a free chapter today. So I'm very excited about that.
Perfect. We'll definitely make sure the link's down there below in the description as well. Great. Thank you very much Daniel. And yeah, I think we'll stop there.
Sounds great. Thank you, Phil.
