Should your roadmap include a recap? | Elliot Golden

In episode 45 of Talking Roadmaps, Elliot Golden, a veteran in B2B enterprise SaaS product management, discusses the importance of including a recap in your product roadmap with Justin Woods. Elliot shares insights from his 16 years of experience, highlighting best practices for UX overhauls and strategic planning. He emphasizes the value of retrospectives and how they can lead to more effective product strategies.

Elliot is a 16 year veteran of B2B enterprise SaaS product management. While he literally fell into the Product space during a canoe ride down the Potomac River in 2007, he quickly fell in love with helping users find the best possible experience to solve their problems using software. In his career, he has launched 5 products 0-1 and done multiple UX overhauls. Elliot thrives working with sharp, kind, hard-working people who focus on getting it right instead of they themselves being right. He loves the strategic aspects of product management the most. When he is not working on complex consumer problems, Elliot enjoys spending time with his wife, daughters, and many pets, along with watching baseball and playing fantasy sports. 

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

Should your roadmap include a recap? | Elliot Golden

Phil Hornby and Elliot Golden

In the next episode we are talking to John Cutler, Product Evangelist and Big Thinker. So watch out for Season 1 - Episode 46!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about everything roadmapping, the good, the bad, and the ugly. Today, I'm honoured to be joined by Elliot Golden. Elliot is a good friend of Justin, my co-host, Elliot, tell us more about yourself.

  - Hi everybody. I am coming to you from Alexandria, Virginia, just south side of Washington DC. I'm a 16-year veteran of enterprise B2B software. Have worked in various areas of enterprise software, including HRIS, ERP, and CRMs to use a little bit of alphabet soup. Currently, looking for my next opportunity in product leadership, whether it's team leadership or senior-level individual contributors. And I met Justin working at Aha! back in 2017 and that experience really changed my life when it came to thinking about roadmaps, which got us on this topic. So happy to be here with you today, Phil.

  - I know we're gonna have a great conversation about roadmaps and probably a lot more. If you're enjoying the channel, subscribe, hit the bell, and give us a like. So let's start with the softball, easy, let's get it going question that we always like to start with, what's the purpose of a roadmap?

  - I think when you think about the purpose of a roadmap, I would always say go back to the purpose of the product itself. And I think that products are the way that companies express their values to the world. So when I think about IBM, IBM has roadmaps of course, but IBM itself via the hardware, software, AI, data, and other tools that they do, they express themselves to the world when they put themselves out there, the company itself and the customers of that company then consume that value and return it in the form of data, time, money, and things of that nature. When you think about the purpose of the roadmap, it's about how essentially did we get where we are right now and then how are we gonna get to that next spot in the future? So it's really, the whole roadmap, it literally is a map of where you are now and where you are going in terms of how you express your values now and how you express your values in the future. And that could be for one product. It could be for a portfolio, or it could be for an entire enterprise using that IBM example.

  - Love it. And I particular love that, how do we get to where we are today? Just explore that. Just unpack that a little bit more for me.

  - Absolutely. So one of the tricks that I learned during my time over at Infor was oftentimes you have customers that come in because it's enterprise software. You have large customers coming in and ideally, fewer coming up, but there's people who move jobs and things like that. And oftentimes when they come in, you can't just walk in and say, here's where we're going. You have to set the stage, right? You have to say, here's where we are. And oftentimes you want to show them in terms of building trust, remember, this is what we've done for you lately. So you wanna really explore how you got there because really the roadmap itself is a snapshot in time of where you want things to be. But all of those snapshots are built of the snapshots of the previous days there as well. So it's almost like a movie. As everything moves along, the products themselves are going to evolve slowly or rapidly depending on the cadence of your releases and the size of those releases there as well.

  - So it almost sounds like you're advocating for a recap at the start of that roadmap of here's what happened in the last five episodes.

  - I think it makes sense, it works well for media because you want people to remember certain things. And then for me, I think about things in terms of stories, I don't want to, I mean maybe there would be a twist in that story, but what I really wanna think about is the idea of we got here based on a set of assumptions. And especially if you're making a pivot, you wanna say, we made these assumptions and those assumptions were proven false. Or if you wanna celebrate, you say, we made these assumptions and we were absolutely right, we are bang on right, this is fantastic. Either way, if you are honouring reality, to borrow a turn of phrase from one of my favourite bosses from Aha!, you need to honour reality. This is where we were, we made these choices in good faith, we made these investments in good faith and now things have changed. And it might be because we were wrong or it might be because the market shifted. When you think about COVID, COVID shifted everything for everyone for quite a while. And in some cases, it changed things forever. So if you essentially said, we had all these things set up for in-person, COVID hits and then you have to completely pivot your roadmap. You say, here's where you are and here's where we need to go now based on this new reality. Because at the end of the day, product management is a game of incomplete information. And as the information becomes more complete, some things become more relevant and some things become less relevant. That allows us as product leaders to then pivot our approach and pivot our strategy in kind. 'Cause if you essentially say, I'm just going to completely move things forward in spite of all evidence to the contrary, you're likely gonna have a product or a project failure. And then it's just a matter of you look back and you say, oh, well we should have done that. Well, that's a lesson that all product managers learn.

  - But yeah, it's interesting 'cause I've long advocated for in particular with an external customer-facing roadmap, including that this is what we've just delivered or recently delivered, because there's too much excuse from the sales team or from the customer in reality to say, I'll tell you what, I will just wait till that next version or the even later version because that's the value I want, I really want that. As opposed to all that value they could have today that's sat there, and available, and ready, and just a delaying tactic.

  - Yeah, it can be a delay tactic and it also erodes trust. I think trust is super important, especially in our role where we have high responsibility and oftentimes very low authority. Especially when you think about an enterprise, especially large enterprise sales-led organisation. It really puts you in a situation where you can't just find another IBM to use that example again. Like you lose IBM that is substantial, but if you get an IBM or keep an IBM, that becomes a real opportunity. So oftentimes those sales folks are in these very complex and long sales cycles and kudos to them. I mean I have tonnes of empathy for them and you need to find a balance of sell what you have today and if you need to do things tomorrow you could put it out there. But making those kinds of commitments can really put you in a bind when it comes to capacity, when it comes to really doing what you need to do. If you have a contractual commitment and then COVID hits, that's a really tough situation where what do you do? Do you break the contract? Do you not pivot with the market? Do you try and do both poorly? Do you invest and try and do both? And these are the types of really difficult decisions that product people need to make and executives also need to make as well, having some empathy for them as well.

  - So it's interesting. So you've talked about a few people are circling around this roadmap and kind of seeing versions of it and caring about what's on there. You mentioned customers, you've mentioned the sales team, and you've mentioned execs as well, but just kind of unpack who's the audience, who's maybe at the same time who owns or maintains this thing as well? 'Cause I think they're interrelated.

  - They can be for sure. It makes a lot of good sense. I think this is a really interesting question, two questions that you paired together. So I'm gonna borrow a turn of phrase from Steve Johnson. When you talk about, oh, who's the audience? Well, it depends. I think that you're gonna have, for me, I always prepare multiple different views of the same roadmap for different audiences. The whole preamble around here's what we've done lately tends to be pretty consistent because what we've done matters, it's just a matter of what do you actually highlight for each person. So if you're highlighting something for your chief technology officer, you probably wanna talk about the cost savings related to hosting. But if you're talking about a customer, a series of customers, you would say, all of you asked for this feature and then we delivered it and here's the value to you, which comes into product marketing. So the audience is going to, you're gonna have different roadmap variations on the same theme for different audiences there as well. When I think about a story, it's almost like it's story told from the hero's perspective and then the story is told from the sidekicks perspective. So you could have a sales-focused roadmap, a dev-focused roadmap, executive-focused roadmap, investors, et cetera. And that's why those automated tools for roadmapping out there, of which there are many, becomes so important because you have one single source of truth when it comes to what is happening. And then you can offer those variations with less work, involves for the product manager. So you can stay market-focused, and user-focused, and do the research that's needed to do the job well without losing the context that you need to provide to these stakeholders that you need to influence. So that's my audience answer.

  - Yeah. Yeah. And it's interesting 'cause likewise, I tend to talk about views for the different audiences and the different needs. I love that thought of telling the story from different points of view. Actually, the sidekick, the hero, the sidekick obviously is the sales team in this context and the hero is obviously the product manager. But then yeah, thinking about it from different points of view because I'm sure I remember a number of TV series where they told the same story, where you had the same story but they did four runs of the same story in the same episode from different points of view. And you saw the different perspectives and how different they were. And so I can totally see that for how you might think about it for a roadmap.

  - And one of the things that I realise as I've grown older and matured unfortunately, in addition to losing a little bit of hair and getting a little bit of grey hair as part of that. It really puts me in a situation of like, I'm not the hero of every story. The product manager, put it this way, the product manager's not the hero of every story. This product manager's the storyteller as I believe it. And that's not to say that you can't present data, information in a different way. You need to do it your own way. But at the end of the day, really you're producing this document to allow people to have trust that you know what you're doing, that you will actually do what you say and that what you do is achievable and relevant as well. And if you miss on any of those, it erodes that trust and it actually increases the amount of time you need to explain and re-explain, make adjustments, that kind of churn can really eat away your week. And that in itself causes a very interesting challenge that I think a lot of product managers fall into. It's a bit of a trap where you don't tailor it enough or you tailor it too much if you're not hitting it right down the middle or getting people what they need. That creates this whole whiplash effect where you get emails, and messages, and calls asking for this kind of context, often one right after the other. That really puts you in a really difficult spot where you almost need to roadmap or bucket your time where if you're spending all this time fielding calls, providing context around the roadmap, all of that means you're not doing research with your customer, you're not thinking about the market, you're not researching customers in terms of, sorry, competitors in terms of what they're actually trying to do. So really the roadmap is your opportunity to reclaim your time where people understand what your intentions are, they know it will get done and that gives you the power to take that time to do what is needed to build that next roadmap.

  - So many things to unpack there. I mean I love the thought of the product manager as the storyteller. 'Cause I was only joking when I said the product manager's the hero, the customer definitely has to be the hero. I mean they are Mario and our product is the fireflower where we suddenly get this superpowered Mario coming out the other side because they have our products as well. And yeah, so there's the storyteller or sometimes I talk about or Justin talks about 'em being the guide. So with maybe the Obi-Wan to their Luke and so on. But yeah, they're great analogies to help us think about we are here in the background to help. We're not the hero of the story, we're not the protagonist.

  - Yeah, if you try and make yourself the protagonist, I just don't think that's the right way to go. And this is coming from somebody who did this for many years as I came along and it finally came to the point where when I stopped trying to be the hero I actually achieved a lot of things that I was looking to do. So a coach of mine from my twenties and early thirties always used to tell me, you give up control to get control. And I finally listened like 10 years later and it actually allowed me to have a greater sense of purpose and a greater sense of achievement in what was done without making it about what I was trying to do or what I did. It was a lot more, we, and that led to a lot of really interesting results and really at the end of the day, a lot more joy from our customers, which is worth way more than being right in this one instance.

  - And using the roadmap as a way of showing your intention to help field and almost be a little bit of a shield against some of those constant noise of this escalation that escalations like we're trying to get there, but every time you interrupt me, you're slowing me down helping you get there, is sometimes how I feel.

  - It can be that way, but ultimately they're coming to you because they have a problem that they need solving and maybe you're the person to solve that problem. So you either need to help them solve their own problem, you need to solve the problem for them or direct them on the way using that guide metaphor that can be used. It's not necessarily a roadmap tactic, but it is a tactic to allow folks to keep their focus and that allows us as product people to deliver the results.

  - We've got this roadmap, it's taken us in a direction, we're communicating it to these audiences. How do we decide what to put on there?

  - Having evolved my overall process, Phil, that's probably the million-dollar question, that's a real tough one. It really comes down. You talk about intentionality, like what are you actually intending to do? I've certainly played, when I think about some of the errors that I've made, maybe it's what not to do, put things on there because the corp, the executive said this was important. Just put it on there and say it'll be done. And then continuing to stair-step it. That certainly erodes a lot of trust, that's a problem. Putting something on there because large customer said it, that's not good either, putting something on there just to sell a deal and then essentially bait and switching it, that's a short-term win and a long-term major problem. And these are all errors that I've done. So when you think about what should be on there, it should be the purest statement of intent in terms of what the problems are and what problems you're gonna be working. So that is a general or a generic piece of advice, but it needs to be interpreted differently based on what your product is. And I think that mantra could work well for hardware, software, enterprise software, B2B, B2B2C, data products, social media, crypto, whatever it might be. It's just a matter of what problems are you working on, why does it matter to that audience? And really roughly what is the prioritisation? That is essentially what needs to be on every roadmap. Without those you probably don't have a roadmap and then it's just a matter of what extra things do you wanna put on there in order to build your case, make your case, justify your decisions, help people get where they need to be.

  - But I guess it doesn't happen in a void, right? We've got something bigger like vision and strategy, I assume guiding us. How do those all interrelate?

  - Absolutely. So it's my turn to do an analogy now, I think about products themselves. If you have a multi-product organisation, I think of it at SNR model. So you have a bunch of different ships there. Some are big, some are small, some have very specialised requirements, some are more general, then you have your flagship, and the flagship are the big products there as well. The overall strategy of the organisation is set by the executives of the organisation. They need to set that priority, they set the core values, they set the vision for the company. And then when you think about the different groups of ships within the armada, you're gonna have functional areas that are run by GMs and VPs and they need to set the strategy for their chunk of the armada and that needs to fly. It needs to work well with what the executives have set out. And then they also need to align horizontally with all of their other VP, GM level folks to say we're gonna go in this direction and we don't wanna bump anyone else. And then within that, when you think down into a large product organisation, you then get into the group or directors of product and then individual contributors as well. They need to go from there. So they need to think up meaning, the strategy of the company or the strategy of their division or their platform. And that needs to work all the way up. But they also need to look side to side to make sure they're not doing something that is duplicating something else, that is not going to crash a system, that is not going to essentially, you remove a piece of functionality that could completely bomb someone else's entire product and things like that. So really it is a very complex triangulation exercise through everybody and it is the ultimate spinning plate type of situation. Using that armada analogy.

  - I love the use of the armada analogy. Interestingly, one of the companies I work with, they use the term fleet to mean, as the equivalent of a tribe in the, so-called Spotify model. So it's like a large group of multiple pods. And I just found myself smiling, thinking of those guys as you said, the armada, and talked about ships, and fleets, and things in there.

  - Yeah, I just think it's important because you don't want to, no one wants to have a collision, no one wants to have friction. But if you think about, you actually have to ask and have the conversation with other product people that puts you in a really good situation that everybody can win. Especially because you're reducing that waste and you're increasing communication. And when you have that clarity and everybody is on the same page, it really puts you in a situation where multiple teams can win. And then you also develop those relationships that allow you to then win again in the future. Because again, it all comes back to that trust.

  - So we said, what do we put on the roadmap? Well, go to a quite high-level answer. What are the key elements? What are those building blocks of a roadmap? Can you unpack that?

  - Yeah, I think about the story. You have your preamble, you have your once upon a time, you have all of the, here's what's happened there as well. And then it's just a matter of what, I think about like now, next, later in a lot of ways. But what are we working on right at this very instant? I really liked the idea of saying we are working on this right now and then I'm not really a proponent of giving dates, but if you know that there's gonna be something coming out literally in two weeks you could say this month we are actually delivering these things for you. It's been asked for and here's the benefit from there. Then when you think about intentionality and what are we actually trying to do, it really puts you in a situation where you can then set the future. So you can say, based on the past and based on the present, this is what our future is going to be now, next, and later. I'm a big believer that that setup works really, really well. And then you, I really like putting in, here's what we're not working on. Because if you don't say no upfront, people ask and then you have to say no. But if you say no, here's what we're not working on. That allows them to at least set themselves up for maybe a difficult conversation, but at least they know where you stand and why that matters. And then it's just a matter of how do you make these determinations? And that's where data comes in. So appendices with data can really help back up the decisions that you're making. So if you have a strong opinion, that's great. If you're using your gut, that's fine. But if you have data and all of these things align, you're almost certainly on the right track based on what information you have.

  - I think you towards the end there, you hit the key thing that I was wondering. It's like you've gotta get the why across it. We're not doing this and the why, we are doing this and the why so that people can understand where we're going and why we're going there, how it's contributing for us and for them, hopefully.

  - I agree, and thanks for calling that out. I essentially didn't, I buried the lead, I didn't say the why is included there. That was implied. Why should always be what we are communicating with the roadmap, whether it's being presented over a site via tool or presented by you in person or over a digital media.

  - And in fact, you talked about tools earlier and how they're super powerful 'cause they give you that one source of truth, but the ability to produce multiple views with minimal effort. And I think the key there was the minimal as opposed to zero.

  - Yes, yes. So a couple things around that. The first is that it does require initial setup. These tools require initial setup where you need to get the information in. The import tools and the integrations that are available are incredibly powerful to get that handled. But you need to actually really set the vision there as well. You probably aren't importing your vision necessarily, but you need to set that intentionality across all the different levels that are out there. And once you get that set up, it can then flow and then you have that minimal effort. I remember when I first used Aha!, the company I was working for was going through an acquisition by multiple different private equity groups, and there were a couple weeks where I was literally working a hundred hours a week just updating PowerPoints for each of the things that were needed. And every time one thing changed on one piece of prioritisation, I had updated across multiple different products there as well. Once I got things set up in Aha!, that work was literally done with one change and then I needed to do the double check, but instead of spending 80 hours a week on roadmaps, I was spending five. So literally it probably saved my life in a lot of different ways. And that was why that particular tool stood out to me. That's why I applied to work there as well and meet Justin. And the rest is history as they might say.

  - Yeah, interestingly, I encountered Justin through a similar sort of vein, I was considering applying there, so I wanted to chat to someone who was doing the job. 'Cause I also looked at sourcing Aha! in my previous corporate role. Ultimately, that's what my team decided on. We looked at lots of different options. Probably not the tool I choose personally these days, but I do believe that just launched a Now, Next, and Later capability as well. And I mean that was always one of the big barriers for its adoption for me.

  - That does make sense. And again, Aha! I think pioneered the space in a lot of different ways. And then other competitors came in and they attacked different niches that are out there. So it really depends on what you're actually trying to do. And there are tools that are right for you, but a tool that is purpose-built for product managers is going to be better than Excel and PowerPoint or the Google variations every time just because of the ability to do that slicing and dicing automatically as opposed to having to do it yourself. Even with scripts, and generative AI, and whatever's out there, these tools are going to have an advantage in the intermediate term.

  - I mean the view, the goal of one source of truth was definitely high up on my priority list. I just never find the outputs pretty enough.

  - I don't worry about that. I'm not fancy in that way. I save my fanciness for eating and food when it comes to my slides, plain works well for me that's my own personal perspective. But I tend to adapt to and adopt whatever organisational working sports philosophy on slides of that nature.

  - Yeah, it all comes back to one of your earlier points of storytelling for me, I want the flex. So I often find myself thinking the tools are super powerful, but they're only gonna get me to the 90% point at the moment, I hope that they will ultimately get me the full way, but I often end up still going back into slideware of some variety.

  - Yeah, that does make sense. And I think that's part of, maybe that's part of the tool. Maybe we're not destined to get a hundred percent with these tools. Maybe it's destined to help get us most of the way there, but that last mile effort maybe should be done by product managers at this juncture. 'Cause the thing that came into my mind when you made that point, Phil, is that if we get to a hundred percent our product managers ever, would they then become obsolete? Like if the tool can do a hundred percent of it, does that mean product management is no longer needed? So in my mind maybe there's a self-preservation aspect of, well, I don't wanna be irrelevant and there's a function of do I not wanna be irrelevant or are we destined to be irrelevant? Maybe we need to find something else in the long term.

  - Yeah, I mean I think there'll always be an element of the critical judgement in terms of figuring out what goes in there even with AI and things coming in. But I hope that I can get to the point where I don't need to present it or don't have to create the presentation myself. 'Cause it's managed in the tool and I can get it into a format that's then right for me to use in the context I find myself.

  - Yeah, that would be massively freeing. I mean when it gets to roadmap season or planning season and things like that, you're talking about saving 50% or more of your time. And that's just coming from me, who's been in a group and director role, large organisations just trying to extrapolate that out to someone who's the head of product, solo head of products or somebody who's running an entire division at a major software company. That is a massive value statement when it comes to not having to do the visualisation or pay someone to do the visualisation. Just being able to do that and then focus on the work, that's incredibly freeing to then attack all those other aspects of work that sometimes fall by the wayside.

  - So I think we're gonna switch tack here now, Elliot, what do you consider best practise when it comes to road mapping? I love this question. I could talk about this all day, but what I really think about some of the lessons I've learned is less is more. That's number one, less is more. Because the more you put on a page or the more you talk, the more opportunities you are to essentially get people misaligned with what you're actually trying to do. Be very, very careful and very, very intentional to use that word again around what are you actually trying to convey and then why does this matter and why does this matter to the audience you are presenting to or sharing information with. That's number one. Number two is when it comes to strategy, have that level of alignment, be the ship that is on the right heading and not bumping in other ships in that armada, what does this actually matter and why does this matter to those other people? Why does this matter in terms of delivering value and why does this actually make a difference in their lives when it comes to either day-to-day, week to week, quarter to quarter. Especially, when you're thinking about an ERP, quarter to quarter, quarter to close is really difficult. And then the third thing I would think about is, I think best practises is like have fun telling the story, right? You need to tell that past, present, and future, but you need to believe it. My best practise is it needs to be believed, but you shouldn't believe it just because you put it on the page. You should believe it because you have that why, that data, and that information available to actually call on. And if someone challenges you and they're going to challenge you, you can then say, here is how I got to that information. And all of this is an opportunity to have a good conversation. Just because you disagree, that actually is an opportunity that allows you to essentially either change your perspective to theirs, which shows humility, grace, or you could have a good conversation and stay the course and maybe they change their mind, and that shows grace on their side, and you build that trust, you build that relationship for the next time. Nobody is going to be right all the time. Really what's important to me is getting it right and the roadmap is a way to show that you have done your work, done your homework, and gotten it right or as right as possible given available information.

  - So let's flip it around. What's the biggest mistake you see?

  - I think maybe it's the big, let's maybe I'll flip this around on you a little bit and I'll say, these are the biggest mistakes that I've made. I think the biggest mistakes that I've made have definitely been putting too many words on the page and too many features down there as well. I think there's also the aspiration of, yeah, we can do that, yeah, we can do that. And essentially overloading the roadmap and setting yourself up for failure. Not delivering a plan that is actually going to be achievable with the assets that you have, the people that you have, right? You say like, oh well we'll just throw this in here. And then essentially stair step. And that's the idea of like, oh, we'll do it next quarter. Oh, we'll do it next quarter. And it just never gets done. And at a certain point, people don't trust you anymore. And then the a third big mistake that I really think about is the idea of just living in your own silo. Just thinking about your own ship. Well, I don't worry about the heading because we're this, we're special. Yes, your product is special. You are special and you are part of a larger organisation. Unless you're a one product organisation, you need to think about the other ships out there in the ocean and then the other obstacles that you might hit. If there's a iceberg coming up, you want to know about it there as well. You can't just say we're gonna keep moving. So maybe that's another lesson. It's a matter of like, don't fall in love with your own story. Your story might sound good now, it might be the best you can, but when there is information that needs to change that requires a change, you need to make that change. And you need to have the humility to essentially say, I was wrong about this because, or this has changed and we need to change because, and then get back to work. It's just a matter of just because this is where it was right now does not mean that you need to be there later. And that in itself requires a level of humility that can be important. And it's something that I struggle with in my earlier years and it's something that I embrace now is really just saying I don't have all the answers or I don't know the answer to this and this is my best guess or I was wrong. And that in itself I think has allowed me to advance my career, build really good relationships, and build really good products as well.

  - That's such a powerful lesson, Elliot, and definitely one that I struggled with earlier in my career as well. That ability to know that you don't know and admit that you don't know.

  - That just like hits me. It is like the whole idea of not knowing something is really tough for me, personally. The idea of like, oh, if I don't know it, I'm not smart enough to do this. I can't do this job. It triggers all these different things in me and just it's something I struggle with even now. So yeah, it's good to know that I'm not fully alone.

  - Yeah. Oh, I mean I've built my career on being the person with the knowledge. You see me in my normal office and it's full of books and it's like, because the message is I've read these things, I know them, I can apply them, I bring knowledge, I bring understanding. But so often I find myself saying, well, I've never been in exactly that situation. This could be the case, this could be a way of approaching it, but I don't know, let's try and figure it out. Let's run an experiment

  - And then having that vulnerability really helps people embrace you. It really helps build those relationships. 'Cause if you think you have all the answers all the time, it can really come off as arrogance even if it's not, even if it's well-meaning and-well intended. And that in itself limits your ability to influence.

  - Means we know that our roadmap is our best guess, I guess. So Elliot, whose advice on roadmapping do you listen to?

  - Well, I would certainly go to the product growth leaders, tag team or dream team of Steve Johnson and Grant Hunter. We do have weekly conversations every Monday, there's a new conversation about product management, in general, oftentimes hits on roadmapping, then Friday conversations with a panel. That's awesome. Of course, I take my advice from talking roadmaps with Justin and Phil. And then I really enjoy Lenny's podcast, of course, as we all do, just getting some interesting tidbits. The way that he's able to pull nuggets of knowledge and growth out of everybody is just phenomenal. And of course, his first guest was Shreyas Doshi, who is a phenomenal Twitter or X follow, as well as on LinkedIn for all things product management, strategy, and leverage. So those are my recommendations that come to mind right now.

  - And yeah, that's interesting. Yeah, Lenny has just kind of come outta nowhere in the last couple of years and yes, I'm a subscriber as well because it's always interesting to listen into for those little nuggets of golden advice. So as I'm sure you're familiar with, I like to save a couple of hardball questions to the end, Elliot, first of which is, if you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - Well, first let me say that need distilling anything down to one or two sentences is a massive challenge. But I would say it is number one, it is tell the story. And number two is do your homework. Those are essentially all that's needed. You need to tell the story and then the homework needs to be done in order to back it up. That is the long and short of it as far as I'm concerned.

  - See that wasn't that hard. I've had people kind of ramble on for two or three minutes and then get to an answer. I think that's exactly what I did and I knew the question.

  - Yeah, I'm working on it. I feel like my family would be so proud of me right now.

  - What's your biggest roadmapping failure?

  - I think my biggest roadmapping failure was actually my biggest product failure there as well where I was working doing expense management software. And it was in the early 2010s when the iPhone was AscendEX and Blackberry was still dominant and things like that. And one of the big things everyone wanted was a mobile app. Competitors had a mobile app and they were pushing that and we did not, we had mobile UI and that was it. So essentially, I just put it on the roadmap because it needed to be done and needed to check the box, didn't even do any research in terms of how we were gonna get that done. Didn't talk to development about what that actually meant, didn't talk to anybody about it. I put it on there because I felt like we needed it to sell deals and we did sell the deals, and then I had to actually deliver. And none of my engineers knew anything about developing mobile applications at all. So they had to go and learn it. So it was late, it was not good, I believe, I remember I looked at it a few years later and it had seven reviews, all one star, essentially, saying useless. So it was both my biggest roadmapping failure and my biggest product failure there as well. And really, I wasn't telling my own story. I didn't do my homework, I didn't collaborate with anybody. I wasted probably $100 to 200,000 worth of people's time and effort that could have been spent elsewhere. Wasn't the right strategic choice, probably in an enterprise software environment, but I didn't do the work that was needed to get it done and I was telling someone else's story. So I essentially violated the very short best practises I outlined just before.

  - Love the fact that you also, you didn't just stop with this is how I failed, but you got to, this is what I learned from it essentially, there. Which to me that's the most important part of any failure. It's like, let's take it for what it is, we're all gonna make mistakes as we go along, let's learn from them and come back better. So Elliot, as we wind this up, always like to give people a chance to pitch themselves. How people can get hold of you and so on. Fire away.

  - I'm very, very active on LinkedIn, following lots of things in the product community. Again, looking for my next opportunity in product management and product leadership. I have 16 years of enterprise B2B product management. I'm a real believer in strategy and vision, not afraid of gnarly problems. And I'm also really big on empathy, collaboration, and mentorship. I'm in my 22nd year of working with a local high school youth group here, kind of teaching them some product management thinking in terms of applying like different events and fundraising and things like that there as well. But really I'm looking to work and solve some really tough problems with great people. Those are kind of my two things I'm looking for in my next role. And look forward to getting back to work and doing some great work there as well.

  - Thanks, Elliot. It's been awesome having you here today. Great conversation. Love to every minute.

  - Thank you.