What are the 6 key inputs you need to your roadmap? | Alex Brodsky

In Episode 61 of Talking Roadmaps, Justin Woods interviews Alex Brodsky, who shares his insights on the six essential inputs needed before creating a roadmap. From understanding organizational goals to capturing customer insights and technical requirements, Alex emphasizes the importance of moving away from feature factories to outcome-driven roadmaps. He also discusses the role of AI in simplifying product management and how his company, Iteright, helps product leaders align strategies with measurable business outcomes.

Alex's journey from developer to product manager to visionary product executive spans 15 years. His pivotal role in transitioning multiple companies from their idea stages to achieving over $100 million in revenue underscores his expertise in harnessing the power of product management for business growth. With a foundation built deeply in agile methodologies and feature factories, he has had to unlearn much of what was initially taught to truly drive business results and revenue growth for the companies he has been a product leader with. Alex founded Iteright in 2022 to guide all product leaders to champion a strategic approach to decision-making, moving beyond mere output to emphasize the significance of generating business outcomes. His mission with Iteright is to empower product leaders worldwide to replicate this success, focusing on impactful results that drive businesses forward.

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

In the next episode we are talking to Grant Hunter, he’s Cofounder and COO @ Product Growth Leaders. So watch out for Season 1 - Episode 62!

• Transcript

  Alex Brodsky:
  Yeah, I actually went and listed out six inputs before this because I really wanted to get this right. I think it's super important to get this data before you create the output. You can't create an output before having the inputs.

  Justin Woods:
  Welcome everybody to the "Talking Roadmap Show". My name is Justin Woods and today's special guest is Alex Brodsky. Alex, welcome. Please introduce yourself?

  Alex Brodsky:
  Hey there, everyone. I'm glad to be here. Thanks for inviting me, Justin. So I have spent the last 15 years as a software developer, product manager, and fractional CPO for the last few years. My claim to fame is I came up in this Agile transformation, like most of these last 15 years. And we really were taught to build these roadmaps focused on features, we were grown up in feature factories. That's what's happened to us over the last 15 years. And I've actually built a new company called Iteright, really focused on driving outcomes, driving strategic value to organisations, and that's what we'll talk through today. But I really wanna hit the roadmap from all spectrums with you and I'm excited. Let's dive in.

  Justin Woods:
  If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Why don't we get started with kind of just setting the scene a little bit, and you've got great experience in this space as well, what do you think is the purpose of a roadmap in its most primary form?

  Alex Brodsky:
  I think a roadmap, it's an output. So there's a lot of inputs that need to go in first, and sometimes we forget those things, but product management is absolute chaos. We have meetings all day, we have stakeholders at our throats, we have customer requests coming in, and a roadmap is a really simple way to just visualise that for people. And there's different ways to visualise for different people. When I show my wife the roadmap, it's gotta be really simple, she knows nothing about product management. We go to engineers, they want the details, the features, they need to know the timelines. And of course, timelines aren't always hit, but they want to know what we're doing each sprint. And that's why you see things like PI plans, like those 10 week plans about what we're gonna do to save. When we're working with our product team, we're talking about, you know, Now-Next-Later, made famous by Janna and the ProdPad team. But it's really like just a visual cue. We don't care about the sprint level. We're trying to think about what are the big features we're focused on next? And now product management is starting to move into outcome roadmaps as well, which is how do we speak to executives about the things they care about? What are the strategic goals of the company? So roadmaps can be all of these things. But there's things we need to understand first, and you need to understand those things before you build the roadmap. And that's what, I think, has been kind of broken over these last 15 years, is we take requirements and we just build the roadmap around those requirements without understanding the why at all in the first place. So it's why are we building this? And we'll dive into some of these inputs today, I'm sure, but that's really my take on what a roadmap is.

  Justin Woods:
  Yeah, massively important. And I think that's captured a lot of the challenges that folks that are new to product management and roadmapping in general have found. Which is that there are so many different interpretations of it. There's so many different views and types of it. There's different flight levels of it. I spoke to Cliff Hazell in earlier episodes we recorded with him and he talked about the different kind of flight levels or different levels of, is it outcome based and what dials we're gonna move? Is it the coordination layer and how teams are gonna work? Is it kind of, like you said, the delivery outputs? I'm excited to see where product management changes, and I think yourself and Iteright are surfing ahead of that curve as well, which we'll come into. But yeah, I think that's a great answer. And in fact, you picked up on my next question actually, and we've mentioned this slightly, which is, who's the audience of a roadmap? Because I think they're quite varied as well.

  Alex Brodsky:
  Yeah, I think it's funny I started with my wife, 'cause it can truly be anybody. And in our conversations too, we've talked about marketing is a roadmap, sales is a roadmap. If you go look at sales, and their quota, and these deep spreadsheets, only they understand those deep details. When sales talks to product about what they're trying to achieve this year, they need a roadmap. Like, "Hey, we're gonna start this year focused on this customer, and then we're gonna move into this customer like later on in the year." And the same thing for our product team. The audience is different people at different times. So I think of these different use cases and different stories that we need through a roadmap, I always start with engineers, I think if you can't get execution right, then you shouldn't be developing or planning at all. So how do we get these people to be accountable? How do we make sure they understand what we're building? They should have links to the designs, they should understand like the timeline we're looking for, why it's important we build this, what ethics these stories dive into. So that's really the engineering roadmap. It's detailed timelines, engineering, it's for project management. And that's great for a feature factory, and that's okay to be a feature factory, 'cause that's what engineers do, they want to think the next 10 weeks, what are we building? I think as you move into product management as the audience, it's those outcome roadmaps. It's getting aligned internally as a team. The product leader needs to make it really clear, "Guys, this is what we're trying to achieve this year, and here's how I think we're gonna do that now, next, later, here's the big strategic themes." I go to strategic themes on a PowerPoint quite often, and I'll start the quarter, "Hey, here's our three big themes, here's the goals we're trying to impact, and here's some of the features we might be working on now around these." And that's great at the product management level. Now they can take that and move to that engineering roadmap. And now the one I've never seen at any company I've ever been done correctly is that executive and strategic roadmap. And there's different reasons that it's broken. Sometimes we don't understand what the executives want. I work with a lot of teams we're like, "I have no idea what this company's trying to achieve."

  Justin Woods:
  Right, we have no idea what the strategy is.

  Alex Brodsky:
  That's important. So I think as a product leader, it's your job right off the bat, what are those strategies we're trying to accomplish? And put that into your roadmap, 'cause if you can take the words of the executive, they're gonna finally understand what you're saying. 'Cause I mean, executives speak Japanese, and the engineers speak Spanish, and like as product people, we need to be the translator there.

  Justin Woods:
  What a fantastic answer, I totally resonate with that. I love the fact that you talked about even the different purposes of roadmapping with your wife. I have roadmaps when I think about going on holiday, I've got my own goals and initiatives I wanna achieve in my personal life then. And so I think, as you said, roadmapping is for everyone. But critically, and this is again where Iteright's thinking, and from yourself as the founder is that, roadmapping is for every department, and potentially should be sales, marketing. It's not just a product artefact there.

  Alex Brodsky:
  So there's something you just hit on that I just wanna call out too, is let's say for your weekend, if I took a trip to Japan and we created this intense itinerary, 'cause my wife and I are both type A planners. But some people want it to be loose. So you really need to understand who you're speaking to too. So we just talked about those three use cases, but they're gonna be visual CTOs and detailed CTOs. Sometimes a roadmap can be a full document of words, 'cause that's what they want. So you really need to understand who you're speaking to at your organisation. I know we'll talk about like who we should be listening to, but it's really understanding who you're talking to. That's the key. as a product manager, we need to discover and learn people. So that's what you need to do, learn the people we're trying to communicate to, from the engineering level, the product level, the business level, and then give them what they need. That's what a roadmap is.

  Justin Woods:
  100%. You know, I've talked on the channel before about Elon Musk's roadmap of build a car, build a cheaper car, and you know, where he went there. Those three sentences for me was a roadmap of sorts. And I think what was great about what you said there is, a roadmap is a communication and alignment tool, it has a certain job to be done, and it has to communicate and align with different audiences, and so therefore it has to be positioned and targeted for them. And I think that that completely makes sense to me. We may have answered the question already here in terms of the fact that roadmaps can be for different people and different functions, but who maintains the roadmap?

  Alex Brodsky:
  Yeah, I mean, I think it's the function. So from a product perspective, I think it's the product leader very often who needs to own the structure and teach the team about how this works. I can't come in as a junior product manager and build the roadmap. And I tried doing that a few words, but that's not gonna work. Most product people are type A, we want to get this right, we see everything about roadmapping. And it's okay, I think, as a junior product manager to be building your roadmaps, but that's probably not the one that's gonna be shared across to everyone. It's good practise. It's really the product leader's job to educate their team, to educate the business on how they're gonna be communicated to, and guess what, the business will often say, "I don't wanna be communicated to that way." You're gonna get great feedback, just like with any product and customers. So it's the product leader's job to kind of set the tone and own that roadmap. And it's the the team's job then to manage that and keep it filled with data. And I think we'll talk about design here and all the different inputs that I believe are important.

  Justin Woods:
  Yeah, that's a great response. And I think it's moving beyond the roadmap artefact or document and into the roadmapping practise or process, which we should product manage our roadmap in terms of looking for feedback, who's it for, what are the personas? And doing that, I think, it leads to a much better document. And I think that, again, resonates exactly with what you're saying.

  Alex Brodsky:
  It's an internal product. Think about it just like the external product we're pushing out to people. So it's who are you talking to? Who is your customer? Who the personas for this roadmap? And you're gonna have multiple roadmaps. And I think what's so great about some of these tools that are out there is they make it easy to manage one roadmap, and like, one set of inputs, and present different outputs to different people. And that's what's so great about some of these tools, because it stinks having to edit 20 different Excel sheets in 20 different ways and keep 'em up to date. We don't wanna be doing that. So some of these tools are really awesome to help you present these roadmaps out.

  Justin Woods:
  So you mentioned at the beginning of the session around the roadmapping as being kind of the output. So it suggests that there's some thinking that we need to have before that roadmap. What are your thoughts there?

  Alex Brodsky:
  Yeah, I actually went and listed out six inputs before this, because I really wanted to get this right. I think it's super important to get this data before you create the output. You can't create an output before having the inputs. And I actually just saw a really great report, about three days ago, 2024 trends from Product School, and they talk about how, like, our job is product leaders is supposed to be connecting tech and business. And we hear this all the time, but that's their biggest trend for this year. We need to start connecting everything we're doing in product to revenue. And I think 'cause we've done such a good job with the timelines, and the feature factory stuff we talk about, it's got such a bad tone. But that's important stuff too, understanding the requirements and the user stories. But that's my sixth item, that's the sixth thing to know, and that's often all we know as product leaders and product managers. So I'm gonna start from the top, but I think as a product manager, our job isn't to start from the top, it's to go top down and bottom up and meet in the middle. So there's really no order to capturing all this data. But I think number one is organisational goals and strategy. So what are those words that your CEO, COO, you know, the chief revenue officer, they're often on a stage, if your company's big enough, talking about these things, getting the company to drink the Kool-Aid, and you're hearing this over and over again. We've all seen the presentation on strategy. And what happens after it gets delivered? That goes into some drive somewhere and no one sees it again until next year when we do it all over again and talk. And I mean, Product School did that too, they talked about the trends for 2023, so different than their trends for 2024. But we probably didn't revisit those trends at all, and we're just like, "Oh, we missed." And that's what often happens with strategy. So we really want to get it right and make sure that we're impacting that strategy. Number two is the impact metrics and success criteria. As product team, how are we gonna actually impact that strategy? And that's what I think is a huge gap. We often see the strategies and just walk away and go right back to our features. What are we gonna do to impact those strategies and what are the goals we're trying to hit? It's kind of the OKR mindset, objectives and key results. It could be big rocks, and small rocks, and pebbles, some people call 'em goals and strategies, it doesn't really matter what the words are, but what are the big goals and what are we gonna do as a product team to impact those? Then there's the insights and priorities from customers. Often I see this in a big spreadsheet that comes every quarter. You have 20 stakeholders, everybody gives you their top 10 things, that's the stakeholder priorities. Then you have these customer requests coming in. We need to take all that into and understand it. And product teams do a good job at this, but often we just put those in the roadmap and start building 'em instead of really connecting all the dots to those things I talk about above. Then it's the tech requirements, this is why product's so hard now, it's not only understanding strategy, but really getting into the details. So the tech requirements are working and understanding the architecture challenges, and what we're gonna need to do around performance, and all these key little things. And you start to get really overwhelmed in the weeds here, and that's why we start. It's hard for product people who aren't that technical to get this out. Then we have the resource availability. Do we have backend resources? Do we have front end? Like, where do we have gaps in our execution as a team? And every team has their gaps and their strengths. If you have this kind of the feasibility, I think we see like Strategyzer talk about that, Marty Cagan. So do we have the skills in this team? Do we need partners to come in to build this new AI functionality we're trying to build? And the last thing I call is the feedback from the cross-functional teams. And we've already talked about this one quite a bit, but it's so like, does marketing understand what we're talking about? How is marketing gonna impact this feature? Is there anything they need that we need to build for them? Is there anything they need to see in this roadmap? So with all those inputs together, you really have a complete view of what we're trying to build, why we're building it, what it's gonna impact, and roadmapping becomes pretty easy to do once you have that. And this is what AI is so great at, organising data. So if you can have all these inputs and just keep using that over and over again, go ask ChatGPT, "How do I explain this better to a marketing individual? How do I explain this better to someone in sales?" It's gonna help you with that. But what it doesn't have is that unique data and insight that only a product manager can capture, and that's what I just highlighted.

  Justin Woods:
  That's just such a phenomenal response. And I think that's right, there's so many bits to unpack there, but I think using AI to do the mandraulic work of product management rather than replacing product management is a massive thing to consider there. You know, it's like being able to use it as a sparring partner, to summarise, to position, to write audiences of what they need to hear, makes a lot of sense. And in fact there's a lot of things that you're talking about there in those six things. Maybe talk to us a little bit about how Iteright can help with some of those, 'cause it sounds like you're really well researched in those areas?

  Alex Brodsky:
  Yeah, I mean, Iteright, let's go to the Marty Cagan's of the world, and the Strategyzer, all these great leaders who talk about the frameworks to use for product. They learned those from their own company. You can't just go take a framework and drop it into your company and expect it to work. It's everything we've talked about. It's understanding what your leaders need to hear. It's your unique product leader. So if we have 20 product managers in the team and a single product leader, there's some key information that product leader wants to make sure that we're going through with each idea we analyse, and that's what Iteright helps you do. We can download that product leader's brain, it creates a unique framework that's scalable, repeatable, comprehensive for a disciplined way to analyse and get all these inputs. And for people who like me who came up in the Agile feature factory world where we just cared about requirements, let Jira, let Azure DevOps handle that, we handle everything else. It's all these other inputs around strategies, and goals, and impact metrics, and all the things that often get missed, Iteright helps you track that in a single repository. It helps you collaborate with sales, marketing, customer success. Because if I go and say, "Hey Justin, what's your change management strategy for this?" It's not up to you as the product leader or product manager to know that. It's your job to go ask someone in change management. If we need to know how are we gonna position this in sales, who are we gonna sell to first? It's not my job to know that. It's my job to go figure that out with sales and marketing, and if we can get them to be part of that collaboration process, they're not gonna hate us as much anymore. They're gonna feel like they're part of the journey. We're gonna be working together on something, and that's what Iteright's about.

  Justin Woods:
  Yeah, absolutely. You know, we see a lot of frightening stats from Pendo and other research places talking about, you know, circa 90% of features that aren't used, which makes it even more important that while we're spending all of this time building stuff, it's ultimately not gonna get used. So why doesn't it make sense to actually vet these ideas, quantify them, and do a better job upfront so that we can dedicate better resources to it, and maybe even, dare I say, do less of the doing, but do the doing on the right things that move the dials?

  Alex Brodsky:
  Yeah, in 2024 profitability is in the air, right? It's all anybody's talking about, how do we spend less, do more with less? And I mean, again, all these tools have been built over the last 15 years were built on top of Agile. So you have Jira to start, but then we have Aha!, and Productboard, and ProdPad, and these tools have been built to visualise what's in Jira. But it was just roadmapping without those key inputs we talked about. Then you have Pendo and some of these, like Amplitude, and these measurement tools that measure and show you, well, 90% of the stuff's not being used, or like, what's really being used. But what if we never built those 90% in the first place? What if we analyse these things up front, and saved our company money, and thought through them, and got aligned, then that's what needs to happen more. And that's really where Iteright sits, it's thinking through it fully, does this make sense? Is this gonna impact our strategies? And once you think through that, you're probably gonna be right. And if not, we thought about how we're gonna measure it, and you can quickly, before you go spend four years building that silly mobile app or doing that whole $2 million UX upgrade that we don't really need, maybe we can see that, maybe we can see if this is gonna cost 2 million, and it's not actually gonna help impact any of our strategies to move internationally this year. Why did we do that UX upgrade? I have no idea. So it's really thinking through fully, doing things before the roadmap. We need to get better at that. That's what product is. And one more big point on this, let's think back to before Agile, like, what were we doing? And there's these powerful companies, there's so many books on this, like the golden years, the '90s and 2000s of building tech, but when they built these things, product owners were the name of these people, and they would think through, how are we gonna make this product successful? We had this big waterfall two year strategy of building something, we need to get it right. And we need to go back to that mindset a little bit. We're faster now, but how are we gonna sell this, market it, support it, what are we gonna build first? This goes back to an MVP too. You can't just build one feature, like, what is gonna be valuable that we can put on the market, that's gonna make us some money, and a little bit of impact? That's what an MVP is. And then we can learn and adapt. And that's one of the magic pieces of roadmaps too, is that it should be adaptable and it shouldn't be locked in. Like, that was in the roadmap for September, we can't change it. No, we're on a journey to achieve something. It's a visualisation that can always change. So all that is a lot of roadmaps and a little bit data, I hope that was helpful.

  Justin Woods:
  Yeah, great response, I love that. And that's why it's great to interview, even though on the channel we have the similar set of questions, the responses, the answers, the viewpoints we get are always coloured by the different guests that we have. So thank you for that. In fact, you ended on quite an interesting point there, and we'll talk a little bit about the design of roadmaps if we might. So what do you believe are some of the key elements or content of a roadmap? And we touched on some of that with Now-Next-Later, and you talked about roadmaps at being different levels. But from your mind, if you were to take a typical roadmap, what are the key elements that you would want to see on that?

  Alex Brodsky:
  Pretty colours. No, I'm just kidding. I do like pretty colours though. No, but I think it goes back to to who is the audience and who are you? Like, when I talk to engineers, I tend to use Notion, a single document, and I'll talk about the feature we're going to be building, and I'll give 'em a link to the design, and here's some light description about requirements. Because I believe they know how to go take those requirements further. Some people from engineers will get very detailed, like they'll get into the deep stories and everything. So it really changes based on who you're talking to. Again, we've talked a lot about this, but I think the key components, again, the most important thing is gathering all of those inputs as a product team. If you can gather all those inputs and figure out what someone needs, you guys can work together to get the product roadmap as a product to V1, to V2, to V3, until there's just something automatic. And just like a product, again, it's gonna start with a lot of manual work to get it there. You're gonna have a lot of updating, it's gonna be very tedious, and that's why it all takes a team. But eventually you should automate this process and scale it, because you should be able to change one thing in one place and it should update all those roadmaps once we've figured it out. And I think that's the magic of it. It's just like anything, you start manual, you get the process right, and you scale it. So I think the system you use is the thing that takes building, more than the colours and what it looks like, you know, that really doesn't matter.

  Justin Woods:
  I wonder if there's some tools that you prefer to use for managing and visualising your roadmap? And I want us to be able to talk about Iteright, but obviously, maybe before when you were a product manager as well, what you've seen work well? So actually, we can kind of look at, you know, roadmapping before Iteright and now roadmapping now that you're the founder of it, kind of how you see that evolving as well?

  Alex Brodsky:
  Yeah, so I always start with the presentation, the PowerPoint. I try and keep it to one slide of the big themes we're going after. That was me as a product leader. So just getting everybody really aligned on the themes. And that was kind of my middle ground where I could speak upwards, and I don't wanna say downwards, but over to the engineers and product team downstream. So going upstream or downstream, if I can get that single slide about the themes we're focused on for this quarter, for this year, that was really important. And as we move downstream then, it starts to change. So I would use, I used Product Plan a lot, because it was really easy for me, and connected to Jira, and it was really pretty. That was five, six years ago. There's so many new tools for doing that now. It was honestly one of the cheapest, which is why I went with it at the time. But then going upstream, that was really difficult for me. I didn't know finance words, I didn't know the words they needed, and I started realising that. I would go sit, you know, kinda like a programme manager, I would speak about a major programme to the CIO of a 40,000 person organisation, and that her eyes glazed over as I was speaking to her. And that started happening to me, and that's what kind of triggered this movement for Iteright for me. I didn't know how to speak in business terms, I didn't have an MBA, and guess who was getting more time in the room than me, those consultants from Accenture, and KPMG, and all these companies. They don't know anything about our product, but they did know how to speak to executives. They know the business words, they know how to speak strategy, and that's why the OKR movements has happened so much. It's like, all we've done is created this OKR silo at the top, because we didn't know how to speak about what we're doing to executives. So I take that on me now, and it's time to learn to speak that language. And that's what's so great about a good roadmap from a product leader, if it comes with a glossary or some sort of, like, help for our team to speak this language and visualise this data. And I haven't really seen a tool for speaking to executives with roadmaps, and that's where Iteright comes in, that's what we're trying to do. How are we gonna impact our strategies? How do we speak and get a seat at the executive table? Everything Product School is talking about, how do we get a seat with business? How do we connect all that great work in tech and the stuff we know to the business outcomes? And that's the journey I'm going on right now. So I'll tell you when I build it and it's fully done, and that's what I'm gonna use.

  Justin Woods:
  Fantastic, I love that. You know, you've been where a lot of product management's were and in the world that we've worked in, and it's arguable that we are coming full circle again, you know, the pendulum swinging the other way, back when the very early days of looking at product management, it was more product marketing managers, it was more around the value of what it did. Then we started to obsess about delivery. And so the obsession moved into faster ways of being able to deliver, but not necessarily faster ways of changing direction, and I think that's fair to say. And now we're starting to, you know, with these product companies, Brian Chesky, other people looking at product management with a little bit more of a critical lens going, "Well, you know, we are much more than the delivery function", starting to now think exactly what you are doing, which is, why are we doing what we're doing? How can we build the right things first time? How can we reduce waste? Because sometimes you can increase velocity or what you could do is just reduce the amount of stuff that gets not used by the end client, you know?

  Alex Brodsky:
  Brian Chesky is right on with this. He has the same frustration I had. He's like, "We're just spending so much time writing these stories." Like, they get it. He's like, "We are brilliant, we have the best engineers in the world on our team, they can figure that out." And so he's talked about product marketing managers is what he really wants to shift these people into, but what he's saying is exactly what we're talking about here, why are we building it? If we can educate the engineers on why something's happening, they're gonna show impact to you too. "Hey Alex, you said this is why we need to build it. Just so you know, we think this might be a better idea than that." Like, they can help you. But if we just give 'em stories and requirements, they're just gonna go build it and it's typically the wrong thing and it's broken.

  Justin Woods:
  So let's talk a little bit about some of the good and bad of roadmapping. And I wanna pull on some stories of the earlier Alex's and the earlier Justin's back in our career. But what do you think some of the best practises in roadmapping are? If someone was just starting out, and the Alex's and Justin's of 10 years ago are listening in now, what would you say was the best practise of roadmapping for them?

  Alex Brodsky:
  I'd put them three words here, transparency, adaptability, and alignment. And it goes to everything we've talked about today. So don't hide this in stealth mode, it's a product, like, share it right away. Be transparent and you're gonna hear from people. This doesn't make sense, I don't care about what's on that. That's kinda the leadership telling you, "This is a black box, we don't know what's happening." You're like, "Well, there's the roadmap." No, like figure it out. Be transparent, they're gonna tell you what they need. And this needs to be adaptable. So make that clear, educate the business first off. But this is the game plan to achieve these goals. And the second we see it's not achieving those goals, we're gonna shift the plans, we're here to help you achieve your goals. So being able to make something that's adaptable is really key too. And then the alignment, like, once we really get aligned, that's when we know we have the right thing. So those three things, that was kinda more of a business level conversation. The same thing for the engineers now. If PI planning isn't working and 10 week plans aren't working, figure out why. And Basecamp's really famous for this, Jason Fried, they always talk about this, but they do six week plans, and they do no roadmaps, because that's what the engineers need. They do these little chunks of six weeks of work and no one needs to know anything beyond that, but I'm sure it's always running in Jason's mind. So it's figure out what works for your team and make it happen. So it's transparency, adaptability, and alignment. When I've done those three things, it's been beautiful. Like, that is the tool to get us all rowing the boat in the same direction.

  Justin Woods:
  Phenomenal, what great advice. And I think that picks up on one of the maybe the biggest mistakes that people would do in roadmapping, which is creating and committing to a 12 month plan that never gets updated, it never gets reviewed with our current learnings. It's the opposite of what best practise is. Is that that biggest mistake? Would you agree with that? Would you say there are any other kind of big mistakes that people make?

  Alex Brodsky:
  The most common one we always hear is overemphasis on deadlines. And it's when you take that engineering roadmap and you created one roadmap for your team, and that is a good roadmap for engineers, it is a good roadmap for Agile and what you're doing. But that doesn't translate to the product team and it doesn't translate to the executive team, and everybody gets frustrated 'cause they don't even know what EpicXYZ means, why is that sitting there? And then oh my gosh, you open that carrot, and EpicXYZ, it's just story one, story two, story three. And like, they get frustrated. I'm frustrated talking about it, 'cause I've been in that seat now and I've seen product people sharing it. So it's even too much for me as an ex-product manager. Imagine like someone in marketing seeing that. So it's the overemphasis on deadlines, like, product manager's job is to really translate this and get everybody aligned as an org. Another one you hit on is something that isn't adaptable. So going back to the PowerPoint slide, it's a really great place to start, but when you stick on the PowerPoint slide, that ends up in a drive somewhere and never looked at again. And when you start putting roadmaps on the slides, that's not the place to manage it. It's okay for a one time like presentation, but really shift that to an everyday tool that can be in front of people all the time. This is the guide. There's gonna be a lot of words everywhere. It's like, this is the one pager, the visualisation that takes everything that's happening. So we just need to constantly be updating it and talking to people about it. It shouldn't be a quarterly review where we take all these new things and just shove 'em into the roadmap and look at it again next quarter. It's a living, breathing document. It should be on the TV screen, like, sitting in the office if you're there. And if you're at home, it should be in a tool. And there's a lot of great tools for this now.

  Justin Woods:
  Incredible response, I love that. And I've got one last question and then I've got a question around how Iteright helps with those things. But you mentioned that you love to see colours on the roadmap, and I agree, one of the things that I'm so passionate about roadmaps is the fact that there's a level of visualisation and artistic licence where we can make things beautiful. So I know you love to see colours on there, and I do too. Is there a pet hate of something that you hate to see on the roadmap?

  Alex Brodsky:
  Something I hate on the roadmap? I think it's just that the deadlines crush me. Like, it's gonna be done by this sprint, and I've built these, oh my god, like I was so proud when I built these too. It's like a game of Tetris in a way and you're trying to Tetris this out. I can't even do that on my daily calendar now. And as business owners, Justin, we know this now, like, it's okay to adapt our calendar, but that's our to-do list. So I think what I hate is when people totally misunderstand what a roadmap is about and they think it's the game of Tetris, and they try sticking to it, 'cause lies start happening, 'cause you're not gonna hit it. And our whole organisation becomes a lie. We're like, "No, we hit it." And that's the same thing in like financial graphs. It should be illegal. Like, I don't know if you ever saw, what's that, Theranos? That story about where

  Justin Woods:
  Oh, yes, Elizabeth, yeah.

  Alex Brodsky:
  They were lying about getting blood. And that's what you're doing when you're, like, not being transparent about your roadmap there. When an organisation is not going in the same direction, you can feel that, and it's often because of the roadmap. It's like our job as product people to be the one who hugs everyone and keeps us together, and that's part of the game of being a great product leader, and a broken roadmap can really cause pain across an organisation.

  Justin Woods:
  Yeah, massively. You know, our strategy shouldn't be static, our roadmap should not be static. And that's why I think a snapshot view for instantaneous sharing can be valuable. But ultimately these things need to change and evolve many, many times quicker than the quarterly reviews or however they're doing at the moment. And I wanna bring this back to Iteright, because one of the important things that you are doing is you are considering all of these different changeable factors in real time. So is that accurate and is that an important thing that you see to help teams going forwards?

  Alex Brodsky:
  Yeah, Iteright's about a living, breathing document for every single idea, and it's all those inputs we talked about. What are the key inputs to having a successful idea? And they're always gonna be changing. Go back to the Business Model Canvas, the Lean Canvas, it's that same type of model, except you can't just drop the Lean Canvas into organisation and say, "Go for it." Because that again becomes all product words. Like, if I go show my CEO a Lean Canvas with note cards all over it, he'll roll his eyes. "I'm not gonna look at notepads on a wall." They want us to know the strategy. So it's understanding these key inputs. It's always changing things. You're iterating the right way, that's what Iteright's all about. So we're always iterating input one, or input two, or, "Oh, this customer didn't work, but we're still solving the same problem." Maybe Iteright's not for product managers, maybe it's for students. And like as you learn these things, you figure it out, you adapt, and that's the key to good roadmapping. It's having these inputs understood for every potential idea, which then goes into a simple roadmap. But the simple roadmap can't be built as an output until we understand these key inputs, and are always adapting 'em, and always changing them in real time. I may have thought I was gonna improve activation rate by 10% this year when I'm talking to executives, but the moment I learned that I should've adapt my inputs, maybe it's gonna be 8%. And it's really important that I update that based on what I think and based on the conversation that I have with sales, 'cause that might affect marketing numbers, and that might affect here. So it just allows us to continue to adjust. I mean, a company is like a cruise ship, and it takes a lot of time to turn. And I think of us as the captain, is these product managers. So just always letting people know what we're seeing ahead, what we're seeing behind us, 'cause they don't know in sales, they don't know in tech, they don't know in marketing. It's our job to capture that data in real time. And that's what Iteright's about, it is the ship that allows dev, and hopefully that 90% failure rate we've talked about can be flipped around with a tool like Iteright. We should be succeeding on 90% of what we do and failing on 10, especially if we're updating the numbers all the time.

  Justin Woods:
  I mean, if we only get four times a year to turn the steering wheel on a ship, it's no wonder we're crashing into islands, right? And so it's kind of, like, look, just bringing the timescales, bringing the right data in, letting us be informed by the data, course correcting as we need, knowing that it is dynamic and not static, and making those micro adjustments as we go, not four times a year. That totally makes sense. And I think Iteright is a beautiful portmanteau of iteration and doing things right. It makes a lot of sense to me. You're clearly an experienced gentleman in terms of the product landscape and different experts and things like that. I'm curious, whose advice on roadmapping you listen to?

  Alex Brodsky:
  Marty Cagan's my number one, I saw he was on here. But the caveat for Marty Cagan is he's an idealist. Like, all his books are, this is how you do things the right way in the right world, and it's this very small pocket of Silicon Valley companies who've got it right. And the funny thing is, like, 99% of Silicon Valley still have it wrong, but they like to pretend we have it right. But most of us don't understand like the Marty way. So I really like Melissa Perri as well. She goes into kinda the real world. She's talking about enterprise where most of us are, and there's some others as well. But I like to listen to these different people, 'cause they talk about how it should be done. But then it always goes back to your own CEO, your own CRO, your own dev team, have those conversations. What do they wanna see so they can be more successful? That's who you should be listening to more than anything online. Because you're capable, there's so much content out there. Go search for how to build the roadmap and you'll get 20 good examples, and guess what? None of those are different than the other. Like, it's the colour difference or the UI is a little bit different, but they're all the same roadmap. The one thing that's gonna be different is your own data at your own organisation, and that's what makes your roadmap special, and unique, and right. So I think that's who you should listen to more than anybody. It's your org, your people, that's how you'll win and be different.

  Justin Woods:
  Yeah, that's a great response. It totally makes sense. Are there any roadmapping resources that you use or recommend, or is it purely just getting the information from the different people's advice there? Are there any materials that you typically use?

  Alex Brodsky:
  It's the "Talking Roadmaps" podcast. No, it's Google. I mean, if you have a specific question about a specific thing, and I had done this earlier, I think if you go get these key inputs, so there's some researching you could do on, like, what are the key inputs to a good roadmap, and you'll get some of these things. I mean, you could start with the six I talked about today. But once you get those, it's just how do I visualise this? And again, that's the key. If you get all the inputs, that's where AI can be really helpful now. I think AI has been my go-to. How do I speak to someone in sales about this information? How do I speak to someone in marketing? 'Cause that's really hard to do when we're in the weeds to step out. And AI really helps you with that. What AI doesn't know is the unique things about your organisation. Those inputs, only you know that. So that unique data, that human data that you can get, mixed with the organisation and the knowledge of AI capabilities, that's gonna be the magic going forward. And that's a big part of Iteright too and a big part of Product School's trends, like, doing more with less with AI, there's so much power it has. It's not gonna give you the answers, it's not gonna tell you if building that new tool is a good idea, but it can take your data and organise it and share it in a way that we've never been able to do on our own. 'Cause we're too much in the weeds, we're too detailed.

  Justin Woods:
  Absolutely. And I love that, I mean, Alex, when I logged into the trial and also spoke to you previously a couple of weeks ago, you know, that totally made sense. Your application of AI and the way that you are using things like the Iteright Score to make sure that people are populating enough data within the records, or AI is used as a tool to help translate the communication, not to tell people what to build, I think is something that I think really sets Iteright apart and I'm excited to see, because it's not designed to replace product management or product managers, it's designed to be the ally that helps 'em to have the important conversations that they were previously left out of the room on, or like you said, that the consultants were listened to, but product management couldn't speak the language. So I love the fact that all of your experiences so far have caused you to be where you are and to build Iteright, I think that's fantastic.

  Alex Brodsky:
  Thank you. It's a great point you had was that all these different companies are so unique, because it's the founder's voice that makes it into the product. And I think, that's what I believe right now. I believe AI is a guide in the future. It makes humans so much more powerful, and it's a little bit scary about how powerful it's gonna make some humans, but it's not gonna take over the world. We'll see, if you put it in a robot maybe. And these tools, it's gonna be a guide. You see a lot of these tools just like generative text. No, it needs to be, how does it help me? For me as a company, it's gonna make customer success cheaper. It's gonna help guide you through, it's gonna help use your data. And you don't wanna talk to me either, you don't wanna go call our customer success team, it's that help chat that's always there, but it sees what you're doing, it sees what part of the tool you're in, it sees what data you even filled out, it sees what framework you're working on, it knows your strategies, it knows all these things, because you filled it in. And it's amazing what it can help guide you to do now. And one of the big examples in Iteright is, as I say, is this idea ready to put on the roadmap? You can just click that button and it's gonna tell you. No, like, this idea is not even close to being ready. And most of the time it says that for ideas that would typically five years ago be already built and in the market. And that's why Pendo is telling you this, no one's using it. It's because we didn't even change our sales deck. We went and built this massive $3 million initiative with the tech team and our sales team wasn't even aware we were building it or they didn't change our positioning. So that, I think, is really the key to AI going forward, it's guiding you. It's using a unique data set built inside of each of our tools, and we all have all this big data we've captured now. How do we use that unique data, plus AI, to really help our users be more successful, activate better, learn better in the tools we're creating?

  Justin Woods:
  What a mission, Alex. I'm totally subscribed to that, I think it's fantastic. And it's the thinking that's got us into this situation is not the same thinking that's gonna get us out of it. And so, you know, that fresh look on tools and idea validation, I think, is really welcomed. I'm gonna ask you a difficult question now, but I think you may have answered it earlier on with those three words. So I want to invite you to bring them back up again if it's a relevant answer here. But if you had to distil your philosophy of roadmapping into couple of words or one or two sentence, how would you describe it?

  Alex Brodsky:
  Yeah, so I mean, the three words we said were transparency, adaptability, alignment. And I think that's the big thing. Like, am I showing people? Can this change tomorrow, if I had to, it'd be really easy to do? And is everybody aligned across those three different use cases we talked about? So downstream, my current internal team, and then upstream executives? Ad the two sentences I wrote are that, "Roadmaps are a visual map for building products, they should be showed to everyone, from the tech team to the bosses, it needs to show where we're going and why. They turn big plans, detailed inputs, all of this overwhelming amount of data that no one's ever gonna read in your organisation, into a clear picture so we can all stay on the same page." People don't read things. I think I read something, like, six seconds is our span now. And I'm sure with Gen Z, like, the TikTok world we're growing up in, it's gonna be less than that. So if you're gonna get less than six seconds of reading, a picture is just perfect. And everybody should know that we did the research, we did the data gathering, and this roadmap is truth. That's where we wanna get to.

  Justin Woods:
  Yeah, totally agree. You know, and to your point before, it needs to speak to those audience in the way that they can understand, in order to maximise the six seconds that we've got with them. Alex, is there anything about roadmapping or even about Iteright that I haven't asked you or you'd just like to share with us?

  Alex Brodsky:
  I think the roadmap take for Iteright, it's very much the upstream approach. We're not gonna be creating this downstream timeline roadmaps, Jira does a great job with that already and there's other tools for that. We are creating the living document that guides strategic decision making, the one I told you I've never seen done right before. So it's an outcome driven roadmap. We take the goals that the business is talking about, and the features are like hidden in our roadmap. They're good, they're there, we know they're happening, they connect to Jira, but I want you to show me the impacts you're gonna create over time and actually track that. So, oh, on Thursday we added 1% to activation, on Friday we did this, onboarding success rate is up, and showing that we worked on this goal and here's the impacts we had over the year. And by the way, here's what we were working on at that time. You can kind of start to see that maybe that caused this impact, this caused that impact. And now when the bosses say, "Product team isn't doing anything, we're spending millions of dollars here, we don't know what we're getting." You're gonna say, "Here's what you got." Like, it's not only a plan, but you can retrospect on this roadmap. And roadmaps sometimes, I've heard portfolio of bets quite a bit where sometimes you work on things with a high Iteright Score or high maturity. Sometimes we're just gonna run forward, especially in AI you're seeing it happen, we just have to try this. We haven't really validated it, don't know how much it's gonna cost. I saw Intercom was one of the first people to do this. They like started pricing AI, they're the first people to go and do it. And it's a guess, and that's okay to say, like, we're not sure, but we're gonna go take a guess and see what this does for us, because then we can learn and become more sure, and Iteright this thing. So really, these impact driven roadmaps, I wanna see more of that, and I hope to be one of the leaders in this space.

  Justin Woods:
  Incredible. Well, I know that myself, our co-founder Phil, and our audience are gonna be cheering you on on the sidelines and really excited about that. The concept of value-based roadmaps with benefits, realisation, milestones, or this is what we think we are gonna do and this is the benefit that we delivered, is absolutely the landscape that we should be moving to, certainly at those higher levels. And so I'm really excited.

  Alex Brodsky:
  I think every roadmap is a plan and you should have a retrospective behind it. We all know the word retrospective from our feature factory world. So were we right, were we wrong? That UX project I talked about that we know we shouldn't do? Guess what? You're gonna be forced to do it the first time. I had someone reach out to me and say, "I got fired when I asked for these inputs, Alex." And I'm saying, guys, don't just demand this, it's a team effort, it's baby steps. So it's really about making sure that we're providing impact and showing that, and that's what we hope to help people do.

  Justin Woods:
  Yeah, I couldn't agree more. I think that's what product management from my perspective was always about. And it got distracted over the time, but I think it's swinging back this way. Alex, it's been an absolute pleasure speaking with you. I want to give you an opportunity just to tell our audience how they can find you, how they can find Iteright, and how you can help them.

  Alex Brodsky:
  Alex Brodsky on LinkedIn, the DMs are open always. I love talking to product leaders about this right now. I've talked to 350 product leaders over the last year and a half building this, and it's really helped me build the right tool. So I know when I'm saying these things that everybody believes it, 'cause I've heard it so many times. And if you wanna check out Iteright, it's free to try. So go to Iteright.com. And I mean, our pilot is just super easy to try out and buy too. And that's really like us handling you through process. This is a transformation that we're trying to really help your company change, and we're here to help you do that. And what we're seeing is a lot of success in this pilot. So it's try it out, cheap and easy to try pilot with us, and the goal is to really make it work, and then you can spend afterwards, 'cause it's gonna be so valuable that you can't say no at that point.

  Justin Woods:
  Leading with value, just like your roadmap should. Alex, thank you so much for spending the time with us. I know that you're a busy entrepreneur with an exciting product that you're working on already, but we really appreciate you sharing your learnings with our audience. Otherwise, Alex, it just leaves me to say thank you so much. We'll drop a load of your links in for our audience down below, as well on the podcast and on YouTube. But thank you for spending time with us.

  Alex Brodsky:
  Yeah, thank you. This was awesome, Justin.