Alignment Through Product Roadmaps (with Brandon Blackman from Crema)

Michael Luchen Roadmaps, the key document that can empower collaboration on so many product teams or diminish their potential through misalignment. We're all familiar with Roadmaps, but what if it could be used to foster true, authentic collaboration? What if instead of viewing them as a static document, they were organic, transparent and iterative. Today, we have a top of class product manager with experience ranging from healthcare to enterprise product development joining us to talk about product Roadmaps and how they can best be used to create great products. Stay tuned. 

This is the product manager podcast, the voices of a community that's writing the playbook for product management, development, and strategy. We're sponsored by Crema, a digital product agency that helps individuals and companies thrive through creativity, technology, and culture. Learn more at crema.us. 

Keep listening for practical, authentic insights to help you succeed in the world of product management.

So I'm so excited today to welcome

Brandon Blackman to the podcast. Brandon's product management expertise began in a healthcare tech startup and expanded into overseeing development for e-commerce stores, mobile apps and working on enterprise-level web applications, passionate about bringing ideas to life.

Brandon's passion is on motivating high-performing Agile and cross-functional product teams. In addition to having the fortune myself of being able to collaborate together with Brandon at Crema, he is also a member of the board of directors for HealthSplash, a healthcare platform focused on solving the problem of denied medical claims due to incorrect data.

Brandon welcome to the show. 

Brandon Blackman Hello. It's so good to be here. 

Michael Luchen Thank you so much for joining us. So product roadmapping, ready to get into it? 

Related Read: How To Use User Story Mapping To Improve Agile Backlog Prioritization

Brandon Blackman Yes. I'm so excited to talk about it. 

Michael Luchen All right. I am so excited about this too. This is like one of those topics I feel that there's a lot of opinions on and a lot of right ways to do it.

So I guess kind of just starting at the foundation, what's your personal background with Roadmaps? 

Brandon Blackman Yeah, so I've obviously had a lot of experience with them out of necessity as a product manager. So, that is, it's a key part of our product development process and workflow. I would say that the background though is very much trial and error learned from experiences. I remember some of the first Roadmaps I was putting together. They were very date-focused very, almost Waterfall really is what they came down to and nothing was ever hit on time, according to the Roadmap. And so they were always more of a nuisance and a cause of stress and anxiety for me, when one of my stakeholders or someone from inside the company at the C suite level would reach out to me and be like, "When can we expect XYZ or can I see the Roadmap?" And I'm like, Oh geez, I'm backing myself into a corner here, but I've got to share it with them and so that's how I initially started with Roadmaps. And it led me to start thinking that there's got to be a better way. And so. I've done a lot of reading and research on it and a lot of experimentation as well on the product teams that I'm involved with and really happy with where we're at now.

I actually really enjoy the Roadmap. It's been, it's become an invaluable tool for me and my team and our users or stakeholders, both internal and external and it's something that I've really enjoyed learning to put together. 

Michael Luchen That's awesome and so you talked about your background and kind of how you started with like the really fixed Waterfall type Roadmaps and ran into limitations throughout all of that.

What's like your own personal philosophy on product Roadmaps that you developed, just kind of going through that experience. 

Brandon Blackman Yeah, that's great. So, it's not beautifully written a little bit choppy, but I would say the tenants, the key tenants of my philosophy is keep it high level. The more granular it gets, the more areas of missed expectations that you're probably going to have and always keep it groomed so always be maintaining it and the last one is always be releasing. I am on the in the camp of release early release often when it comes to digital products. 

Michael Luchen So let's start with some of the basics of product roadmapping. What should be the ultimate goal of a Roadmap?

Brandon Blackman

That's a great question. So I would say the ultimate goal of a Roadmap is that it needs to communicate the direction of the product. Even really the community it should re it should communicate the direction of the product, but it should be a reflection of the direction for the company or the enterprise as a whole and the reason why I say that is because the core of what the Roadmap is supposed to do is to gain alignment for anyone involved with the product. This could be external alignment with our users or it could be internal alignment with your own product team or with your leadership at your company but the whole key to a Roadmap is that we're trying to align a bunch of different people from a bunch of different perspectives all around what they can expect in the future. And that's a really big challenge and so, the goal with it is to, in a way that's clear and concise directionally tell all of your stakeholders where we are going with this product.

Michael Luchen So it's kind of like a, almost like a story that's like always kind of changing in a way, because

Brandon Blackman Absolutely.

Michael Luchen It serves multiple stakeholders. 

Brandon Blackman Yes, that is it exactly. Yup, and with any kind of to riff off of that with any good story, you don't want to bore someone with too many details and so I love the idea of it being a story because you want to keep it engaging and you want to deliver just the right enough information to achieve the goal, which is to gain alignment but don't get so detailed so granular that it's actually, causing us to miss certain requirements or miss certain deadlines because we got so, so detailed with it. 

Michael Luchen Yeah, definitely. So we've kind of started to get into these waters, but just to ask it directly, should a Roadmap be like a static artifact that's just created, we've created the Roadmap, it's over here. We look at it throughout development, or is it something more organic, something more iterative? 

Brandon Blackman Yeah, I am definitely on the side that it should be more organic, more iterative. If it is something that's static, I think we've made some wrong assumptions probably about users and about how the product's going to work in the wild once it's released. Because at the end of the day, the Roadmap does communicate something in the future. It's forecasting something that honestly, it doesn't matter how much you plan or how much you put into it. You don't ever know until you get there. So, the Roadmap should be taken as it is. It's a forecast it's a view into the future and the best way to always have the most accurate forecast is to look at the present day and adjust your forecast based off of that. So I think it should always be iterative and never assume that there's a final version of something out there. 

Michael Luchen Yeah. I mean, and basically assuming it also as, as a final version can work against the ultimate outcomes that it's striving for.

You know, you, it, I like the word forecast that you're using because it's based on our current science, so to speak at the product. Our current understanding of users and needs the business environment, the competitive environment, but as we're building, all those variables are changing, which means that ultimately the Roadmap should service those variables and change and evolve as well.

Brandon Blackman A hundred percent. Yep, I completely agree with you on that. 

Michael Luchen So overall, like I am sitting down to create a product Roadmap for my awesome ABC product. What should it be focused on? 

Brandon Blackman That's awesome question. So, you really want to focus on the why and the what that you're building. I really believe that the temptation especially if you don't have much experience with roadmapping is to focus on the how because that's the that's really the question that good Roadmaps probably beg is like, how are we getting there?

And you're going to want to avoid that. How question leaves that to the backlog. The backlog will describe how we're going to do it, but the Roadmap focus on the why and the what. Why are we moving in this direction? Why are we focusing on these certain items? What are we focusing on? The answer, those types of questions with the Roadmap and avoid the how question.

Michael Luchen So one of the things that we pull into a lot of our Roadmaps are statuses themes and kind of outcomes. Can you talk about those in the context of a Roadmap? 

Brandon Blackman Yeah, that's a good question. So status is if a Roadmap has statuses on it, those are things like, this is what we're working on now. This is what we're going to be working on next and this is what we're going to be working on later. Notice that those statuses have zero dates attached to it. The moment you put a date and I know that there is necessity to sometimes include a date to some degree. But the moment you put a date on something, you have cornered yourself into a requirement that may not have been necessary had you left the date out of it. 

So with a status concept, it's this idea of, this is what we're working on right now. So that could be today and it could be tomorrow and it could be the day after, but right now we're working on this and then having a next status is giving the users or giving the stakeholders an idea of what's up to come.

And again, no date attached to that. You could start it tomorrow or you could start it next week. All we know is that this is where we're going next and then later is to kind of show more direction further down into the future. So this idea of we know what we're working on now, we know what's going to come up next and then at some point we're going to arrive at these other issues as well. Themes is another common Roadmap perspective. So themes would be something like client relationship. So a theme is client relationship, and now you can start thinking through items, epics, or user stories that contribute to the theme of client relationships. And then an outcome focus, re Roadmap or a Roadmap with the outcome perspective is to say something like increasing client interactions by 30%. And that's an outcome that we can come to expect and maybe that attaches to the theme of client relationships, but this outcome of, we want to increase client interactions by 30%. 

That is a good why and what. And then the how, again, is left to the backlog and really to the experts. That's the people on the product team in the moment with what we know now there could be a slew of different ways that you could increase client interactions by 30%, but all that the Roadmap needs to communicate is that we are on track directionally heading towards this outcome of increasing client interactions by 30%. 

Michael Luchen That is so awesome. Thank you so much for overviewing those potential paths and like, you know, speaking personally, like there's so much power that I've seen from taking that very Agile approach to Roadmap development. It really puts a focus on breaking down what we know to be true now, but also having kind of an on-deck area, that next area to move into in service of either themes or outcomes, if you'd like.

But also taking all like the rest of the backlog, all those other ideas that we have. Then maybe, may or may not be valuable depending on when or when, if they get implemented, we still have those, but it's not something that is committed to something that is like stamped onto a permanent Roadmap. 

Brandon Blackman Yep. The more you commit, the more you stamp that's, you're setting yourself up just for more and more requirements and expectations that have to be met. 

Michael Luchen Absolutely, and one thing you mentioned a lot was Don't put dates, whatever you don't put dates and I know that there's probably a lot of us listening who are like, I would love to not put dates, but my stakeholders are absolutely saying we've got to release to a customer by X day, or we have to do this for a stakeholder by X date. How do you navigate that? 

Brandon Blackman Yes, I if I could control everything the way I want to control it, dates would never exist on a Roadmap. I know I say that though, as more of the ideal reality, oftentimes you're right. You have your CEO telling you when can they expect something your marketing team needs to know when they can expect something. If they're going to have promotions around it your customer service teams, they want to know when they can expect something. So, unfortunately, the world works with dates and so you have to incorporate dates to some degree, but I really, I live in that tension and I'm always pushing against it and the Roadmap of giving the most high-level date that I possibly can to achieve whatever the team needs to know or the stakeholder needs to know.

So, most often this isn't every case, but I would say most often this can be achieved with quarterly Roadmaps. So, committing to a quarter saying by Q2, we will be able to increase client interactions by 30% and we're looking at having these features to help contribute to that and that gives enough to the marketing team that they can start putting campaigns together around clients, relationship matters with their product and I keep using this client. Client interactions as an example, but it could be any theme or outcome, or feature set that's applicable to your product. It also gives enough for the customer service branch to be like, okay, we need to have these customer service channels set up by Q2 to help support this outcome of increasing client interactions by 30%. And so, again, that, that Roadmap being theme oriented or outcome-oriented, communicates direction to all stakeholders, and then keeping as high level as possible dates as you possibly can communicate when these things need to be set up by, and quarterly is a really good perspective to have it gives you a, you know, a three-month margin.

So it could be beginning of quarter, mid-quarter, end quarter, end of quarter or it could be maybe the external side, it's the following quarter, but for internally it's the current quarter that you're aiming for. 

Michael Luchen Do you know I love the word margin and being able to use that as a tool when creating Roadmaps and I love going with quarterly Roadmaps and more?

One other tactic that I've found to be useful, or really rather a mental model is using what we call the cone of uncertainty, which for those who aren't aware of it, it's think of it as a sideways triangle with a bottom cutoff and you start at the largest end of the triangle to the bottom and that's where you're at today.

You have so much as you move forward so much room and margin really uncertainty that delivery of certain features or hitting the specific outcomes or themes on a Roadmap go. However, as you progress down that as time moves forward, you become as you head towards those goals or milestones or whatnot, then you're, you were closer to where your target is and so naturally there's going to be more learnings behind you, more certainty. Tactically, one thing that I really have found value and is leveraging in an Agile environment story points to be able to track our philosophy. Because after a few sprints, you start to be able to stabilize a philosophy.

You start to understand what technical risk, or UX risks, or market risks that there might be that could impact. You'll have a lot, your team's velocity and so as it gets closer and as you go down the path and you're actually able to hone in on those dates with much more certainty while also remaining Agile. 

Brandon Blackman I love that idea of that cone of uncertainty and it actually reminds me of something I just did. This last week was I took a peek at by my 401k. I know I'm way, far away from retirement, but the 401k portfolio that I've got has this forecaster on it and then a lot of ways, it's kind of like my roadmap to retirement and it shows that cone of uncertainty.

It says with a night, we want to set up your investments, your monthly investments, and your allocations so that with 90% certainty, you will retire with this amount of money. Now, obviously, there's no way to foretell the future like, especially when it's 30 years down the road but it helps kind of decide, okay, what allocations do I want to put towards these investments? And as I make those changes, that cone of uncertainty says perhaps with a 30 cents, 30% probability you'll have this much money, but no matter what we can look at this 90% confidence and say that you'll have this much money. And I think Roadmaps fall into that very closely of you know, when someone, a stakeholder I feel like the more high up in the company that the stakeholder is, the more pressure you have to give an exact date.

When they ask, what can we expect by X date? I think it's okay to respond with like, do you want the 90% certainty answer or do you want the 30% certainty answer? And it kind of gives them that idea of like, okay, I know with some degree of certainty that we will be here and maybe just, maybe we'll be closer to that 30% certainty mark as well.

Michael Luchen That's such a great analogy. So kind of shifting over to date management, let's go over to another topic that might have some different opinions on how do you manage dependencies in a Roadmap? 

Brandon Blackman Yeah, that is such a hard hard thing to answer with a blanket statement. I would say in it from a general approach. The best way to handle dependencies is to one note them and communicate them. So they should be on the Roadmap. So as you're putting together this theme-oriented or outcome-oriented or status-oriented Roadmap, make sure you attach these items to what those dependencies might be. So although you're planning for a certain outcome by a certain time, quarter of the year, be sure to note.

Now, this depends on [00:19:00] X, Y, and Z. So that way that communicates that alignment that we had mentioned earlier. The other thing is and we do this often with front-end and backend teams. So oftentimes the front end has dependencies from the backend and the backend team has dependencies on the front end and so we put together actual contracts if you will. This could be like an API contract, which I know in developer or developer world has a certain meaning but from a product management perspective, this is a document that fully lays out everything that we can expect with the API that's being created and the front end can build off of that contract. Even if the API itself doesn't exist yet, or the backend can't support the API yet. The front end can still build knowing that this contract, this document that explains what the API will be able to do will come to fruition and when it does accord, if the contract is good and solid, it should be easy then to connect both the front end dependencies and the backend dependencies together. 

It works the other way around too. Inside of that API contract there should be what the front end needs to be able to do so that way, the back end team knows exactly how to build it and to architect the structure around it and that contract really is kind of that third middle layer between the parties and both parties are obligated to uphold their end of the contract to make sure that what the front end is building matches up with the backend.

That's just one example. This could also be a document between you know, the dev team and the marketing team or the product team as a whole and the customer service team. You just want to put together these contracts and say, this is what you can expect once this is all done and that allows the other team who's dependent on you completing your task to go ahead and start building out their processes and their systems as well.

Michael Luchen That's so good. Especially the note around like API contracts. It's not just managing business dependencies or content dependencies, it can actually be much more complex about managing technical dependencies and how do you structure your development teams to be able to collaborate in a way that, that sees that through in a very healthy development focused way.

Brandon Blackman Absolutely. Yeah, and I would say that with that too like things are going to be go wrong that's the whole idea behind dependencies is that there are things that depend on other things to happen and sometimes that doesn't work out. In fact, we should expect it not to work out and so, that's why I go back to making sure those dependencies are noted on the Roadmap. So when something does need to change on the Roadmap again, remember the Roadmap is not static, it's iterative and it's organic. You can communicate exactly why we need to change things because of a certain dependency or we got into something that it was much big, much more larger than what we were anticipating.

And as long as that's communicated upfront, you'll eliminate, I'd say 80 to 90% of your issues with forecasting the future is just communicating that uncertainty or those dependencies to everyone involved. Which is why, again, I go back to the overall goal of a Roadmap is to really gain alignment with your stakeholders.

Michael Luchen So you mentioned a, you kind of alluded to challenges within roadmapping like this. So what other challenges do you typically face, especially with like release management delivery in conjunction with Agile Roadmaps? 

Brandon Blackman Yeah, that's a great question. I would say. Some challenges, oftentimes go back to nonproduct people or nonproduct teams.

These would be internal stakeholders, particularly within enterprises that they're just not familiar with the Agile process and so, a challenge is just always communicating and really educating along the way of what Agile is, why we have to build this way. And the analogy that I like to use with that is we're not just building a house like houses have been built for ages.

We know how to build a house. Therefore we can kind of Waterfall that out. We're oftentimes building something that's never been done before, or maybe it's been done before for someone else, but we're doing it in a unique way for ourselves and so there's just no way to tell the future with that and so, I kind of, I use that analogy there to help educate and bring the rest of the team along with that.

The other thing with challenging with Agile Roadmaps is you we admit the obvious, which is that there is so much unknown. We have, you know, the known knowns, the known unknowns and then we also know that there's unknown unknowns and so with Agile, we live in that tension and that friction, knowing that there's things that we just don't know, and it can be challenging.

I don't think Agile necessarily makes that easier it just makes it to where Agile can deal with it and work with it and consume that type of chaos and order it in a way that you're still building really cool stuff for your users that ultimately it makes their lives better. 

Michael Luchen That's so awesome. You know, one of the other things that comes to mind tangential to what you just shared is just the reality that especially when you're working in software development by nature is about knowledge creation and gathering.

It's there's that the metaphor that's so often used is, and I'm glad you kind of shot this down as the building a house metaphor is usually brought over to our world, but it's really so much more than building a house. It's like, well, how do you relay the bricks? How do you actually create the bricks? And then how do you learn to create the bricks? And what if there's a different type of material that this particular app or software that we're building requires and how do you go learn and build that? And so, so much about actually software development is about just that whole exercise of building our own knowledge along the way as we're actually building the product, which just adds that much more variability to the Roadmap.

So I'm so glad that you covered just those types of ambiguity, that type of ambiguity that can so easily be present.  

Brandon Blackman No, that's great. 

Michael Luchen So shifting gears a bit, let's go down from the 50,000-foot view of Roadmaps and to just kind of the next level, the 30,000 foot, which is really sprints and breaking down that, those big chunks of the Roadmap. So Brandon, how do sprints help break down the Roadmap? 

Brandon Blackman Yeah, so a sprint. They, let me first go to this idea of what a sprint should have, which is a goal. Every sprint should have a goal in mind that by the end of the sprint when you hit, when you finish the sprint, this goal will be achieved and that goal should always be driving the product and the team and the users further along the Roadmap.

So the, if your goal is ever disconnected or misaligned with the Roadmap, then what you're working on is not contributing to the direction of the Roadmap. And so you've in some ways forsake in the Roadmap in that way. So what I typically do is on our sprint planning and sprint kickoffs is I always start with that like you said, you're 50,000-foot view of the Roadmap before even getting into the actual sprint planning, committing to certain stories, and then ultimately writing out the goal for the sprint, because I always want us to bring it back to that Roadmap. 

So, when we're looking at the next two weeks, we choose the stories of what can be done and we write out the goal and that goal should clearly point to whatever aspect of the Roadmap we're in at that moment. And if it's not directly said inside of that, it should be some sort of indirect step. Maybe it's a half step before we can actually deliver something that's on the Roadmap. We have to do some backend experimentation, and therefore we have to kind of bring in a user story that it doesn't make a whole lot of sense for the Roadmap necessarily, but it's laying the backend groundwork so that we can then get back to a user story that's directly tied to the Roadmap. And so I always start with that sprint goal. That's really the bridge from what you're working on today to the Roadmap and it should be really clearly stated in a concise way inside of that sprinkle. 

Michael Luchen That's really good. I love sprint goals and really starting with that and letting that inform what the sprint should be. So one of the challenges that I think has been really elevated in our space over the last few years is that sprints can often risk becoming many Waterfalls of sorts.

It's like that kind of a two-week period. Let's go ahead and we have to get things done for that sprint goal or else everything's wrong. So how do you keep sprints from being those mini Waterfalls and context of the broader Roadmap? 

Brandon Blackman Yeah, that is a really good question. So I would say that the sprints need to be made up of independent and usable user stories.

Now for my true Agile listeners who are listening to this, they're like, Oh yeah, that's exactly what a user story is but I speaking transparently, even myself, I get lazy with my user story writing and I forget that they need to be independent and they need to be testable and they need to be usable.

And so keeping your sprint focused so that goal is independent and it's usable from end to end. So you're never at the end of the sprint with something that can't be used until you get two more sprints done. That should never be the case. Right. There is a Waterfall Sprint example where in order for something to be usable, you have to complete three different sprints.

Instead, really try to do your sprint planning in a way that every single sprint is independent. It's releasable if you wanted, it's usable. Users could actually get in there and use it if it was in a prod environment and this kind of gets to that idea that I mentioned earlier with Roadmaps is release often.

That doesn't necessarily mean you're releasing to users often, but releasing to some sort of pre production environment that is usable to some degree, like a user could actually get in there hypothetically and use it and get some sort of value from it. If you're always releasing that way, then it doesn't matter what due date arrives. 

So I just want to make sure that's communicated though, that those user stories are always independent and when you're releasing that a user could use it even if it's not in a production environment the hypothetical nature is that the user could use it. 

Michael Luchen Yeah, and that's really good and I think also too, something that you mentioned your user stories and without getting too deep into user stories cause I think we could do a whole podcast on user stories. As it relates to roadmapping, well, there's definitely this line this very fine line to balance on where you don't want to be too detailed with those stories, because then you could risk like really making that almost a Waterfall by itself but you want to have enough clarity that the team can move forward, but enough ambiguity that there's flexibility in the team to be able to pivot and try to, you know, be creative as we work towards those sprint goals. 

Brandon Blackman Yes, that is really important to highlight. I think if you, like you said, if you get too detailed with it, you've really gotten back into that how nature, and as a product manager, I have zero dev insights, zero design insights, and if I can just stay focused with like what you're saying, kind of that high-level leaves, some ambiguity around it. So that way, the experts that developers can actually think through, okay, this goal has been stated here. We can do whatever we need to do to achieve the goal and you've really at the end of the day, empowered your smartest and brightest people to solve those problems and it doesn't fall on you with your limited perspective. To try and figuring out how to hit that goal. 

Michael Luchen Absolutely. So we've talked about the Roadmaps, the types of Roadmaps and just how to actually break those down and within sprints move forward towards it. How often should that Roadmap be reviewed?

Brandon Blackman So I, as a product manager, I probably see it daily. If not every other day, I open that up and look at it. I would say from a product team standpoint, though, that should be reviewed every single kickoff or every single planning period. Again, it is the thing that should help determine your sprints, your sprint goal, and therefore determine what user stories get pulled in or what epics get focused on.

And then from a company from a broader perspective, Anytime the product manager or the product owner or anyone on the product team is communicating certain aspects of the [00:32:00] product to the larger stakeholder community. I think that's a great time to bring in the Roadmap to always give context. So you're not just displaying this one little window but you're actually giving the entire forest of perspective and it really helps the users and the stakeholders really understand why this release might be important or why this Epic was important for us to focus on. So I would say bring it up as often as you can, definitely, any time you are talking about the product itself from a product team perspective, that would be on the kickoff and the planning meetings and then as a product manager, you should be inside of your Roadmap every single day, every other day, reviewing that and making sure that you're all still on track and nothing needs to be adjusted. 

Michael Luchen Awesome. So overall stepping back and kind of asking you personally. What's your favorite type of Roadmap and approach? Where did, what is your default when it comes to roadmapping? 

Brandon Blackman Yeah. So it depends on the product. I would say most products that I'm on its theme-oriented Roadmap. I love this idea of being able to see the theme that's then also tied to like the company's vital few goals or something of that nature and it really empowers us as the product team to pick and choose what we want to work on then and moreover, it empowers the developers and the designers, the true experts in their craft to decide how they're going to achieve those themes. And so that's really cool. I think you see the most empowerment and the most enablement with a theme-oriented Roadmap on the more on the smaller products. So like I'm on a venture lab product where we have, I think I did the math. I think we have like 14, 14 days of the year that we get to actually work on this product out of 365 days and so, the Roadmap has to be very concise. It has to be very high level will at the same time in order to communicate just what will be delivered in one year, because we only get to work on it 14 days of the year and so, those type of Roadmaps. I like the statuses to be able to communicate very quickly and effectively to everyone involved. This is what we're working on right now. This is what we're going to be working on next and this is what you can expect later. 

Michael Luchen That is so awesome. So, all right we're nearing the end of our time, but before we wrap up, I'd like to ask some personal lightening round questions if that's okay. 

Brandon Blackman Go for it. 

Michael Luchen All right. First, which of your personal habits has contributed most to your success? 

Brandon Blackman So I am a little bit old school with the analog note-taking. I don't always take notes and, you know, anna in an analog way. In fact, most times I have to consume it very quickly or record it very quickly so I digitally type that out but the ability to track those notes in an analog fashion, or to digest the notes in an analog fashion, just the idea of like actually have it here, writing, writing it down in the notebook helps imprint it in my mind. I think, and moves it from that short-term memory bank to the longterm. I can also have a lot of fun dreaming about the future using analog versions.

I can sketch out to do lists and goals and track certain things and get really creative with it on a blank sheet of paper. So I would say that is the thing that I always go back to is just a good old notebook with a pen and being able to track the past, organize the present and playing for the future design the future. That's a stealing that from the bullet journal method. 

Michael Luchen That's so awesome. You know, and actually just real quick, stepping outside of of notebooks and pens. What is your other favorite tool that you use regularly? 

Brandon Blackman Yeah, so this probably won't come as a surprise to you. As we use it very often at Crema, but Miro the virtual white boarding tool.

I could plug them all day long and say, go start a Miro account. They're an amazing tool. Roadmapping? I don't think I've road mapped outside of Miro since the first day I discovered Miro. So all of my Roadmaps that are all in Miro and what makes that so great is I can have an, a frame for the Roadmap and I can also have images or Figma integrations of all the designs that, that contribute to that Roadmap.

I can write user stories inside of that whiteboard that then integrates with Jira. And so Miro is, was life-changing when we discovered it, or I discovered it and I've used it every day since for every Roadmap that I've had to make. 

Michael Luchen Yeah. It's yeah, you appreciated the choir. There. It is a, like the best contextual Roadmap you can possibly create.

Brandon Blackman Yeah. 

Michael Luchen So last question for someone at the start of their product management journey, what's the one piece of advice that you would give to them? 

Brandon Blackman So this is how, if I could rephrase, and if I can look back at it younger Brandon at the beginning of his career, What would be the advice to him specifically?

It would be to take the startup job and be a product manager with zero experience at this technology startup. I'm not sure what product management is involved or anything like that like it's a completely unchartered course I had no idea at the beginning of it what agile was I didn't know any of the terms and just jumped in. And so, two other aspiring product managers out there. Find a startup, maybe create your own startup that does not mean leave your nine to five. I'm not saying that, but maybe from that what is it? 5:00 PM to 2:00 AM, work on your own startup, and really learn and lean into the Agile process and apply that to creating something that doesn't exist for yourself.

It could be a service business, could be a digital product business, could be anything. Just think through the agile process and apply that on creating something for yourself. And then at best you become a $1 billion unicorn sellout with your startup or at worst, nothing ever comes of it, which is my story with the startup.

But you've got all of this experience and now you can land yourself at a nine to five job doing what you love and being able to embrace those skills that you've been gifted with. 

Michael Luchen Very wise words. Thank you so much, Brandon, and thank you so much for coming onto the podcast today to just not only cover your expertise on roadmapping, but just as we branched a little bit outside of that as well into your other areas of expertise and product development.

It has been very great finding for myself for those listening. You can find out more about Brandon's work at crema.us, or you can find him on LinkedIn. Again, thank you so much for joining today, Brandon. 

Brandon Blackman That's great. Thank you so much for having me. 

Michael Luchen And everyone thank you so much for listening.

Be sure to leave a review of the podcast, let us know what you liked, what you'd like to see more of, or if there's something that we didn't cover that you'd love us to follow up on. Otherwise, definitely follow and join our community@theproductmanager.com. Thank you again, everyone, for listening. We'll catch you in the next one.