Episode 064
The one and only Janna Bastow joins Product Voices. Highlights of the conversations...
On roadmaps:
What is a roadmap?
What are the prerequisites for a roadmap? (hint: you can’t have a really successful roadmap without having a vision)
A roadmap is a prototype of your strategy (wow! what a great way to think about it)
How do teams use a roadmap?
How often do you update your roadmap?
Advice for current and aspiring product managers:
Core skills that a great product manager needs
How to stand out from the crowd when trying to move into product management
SHOW NOTES:
Connect with Janna:
Resources:
Episode Transcript:
SUMMARY KEYWORDS
roadmap, product, work, timeline, team, feature, love, product manager, vision, problem, marketing, company, prototype, solve, spend, stakeholders, piece, customers, great, sell
Intro (the incomparable Sandra Segrest) 00:03
Welcome to Product Voices, a podcast where we share valuable insights and useful resources to help us all be great in product management. Visit the show's website to access the resources discussed on the show, find more information on our fabulous guests or to submit your product management question to be answered on our special q&a episodes. That's all at product voices.com. And be sure to subscribe to the podcast on your favorite platform. Now, here's our host, JJ Rorie, CEO of great product management.
JJ 00:36
Hello, and welcome to Product Voices. I am so incredibly excited about this episode, I am joined by one of the preeminent voices in all things product. So gonna be a really, really fun conversation. Janna Bastow is with me. She is co founder and CEO of ProdPad. She's also one of the founders of Mind the Product, one of the largest and most influential product communities in the world. Again, she's just all things product all the time. And I'm so excited to have her with me. Janna, thank you so much for joining.
Janna 01:09
Wonderful, thank you so much for having me. I'm really excited to be here.
JJ 01:12
So what I want to talk to you about roadmaps because obviously you are truly, you know, one of the most important thought leaders out there when it comes to how product teams you know, use roadmaps, leverage roadmaps, etc. So I want to start with the basics. I'd love to hear your philosophy on roadmaps, what they are, why teams should use them what their main purpose is. I still think there's a little bit of confusion there. So tell me your thoughts on roadmaps?
Janna 01:44
Yeah, absolutely. I mean, a lot of people. When they start thinking about roadmaps, they go back to the old school roadmap, they go back to thinking about a roadmap as this list of things to do and the due date for it right? This this list of features and timelines in this Gantt chart, colorful are not this is I wouldn't blame them for thinking that as well. Because if you do a Google search and flip to the images, and you look up Google, or you look up product roadmaps, you'll get a whole bunch of timeline roadmaps like that. But I think we need to turn our turn our definition of roadmaps on its head and really take it back to basics, which is, you know, what is it, it's something that helps us layout our understanding as to how we're going to meet our product vision, the steps we're going to take to meet that product vision. And there's nothing in there that says that it's going to be a list of features or a bunch of things that we're going to do and when. And so that was actually the realization that we came to, when we threw out the first version of the prodpad roadmap which we built it, I was replicating what I was doing in my old job, which was timeline roadmaps. And when we showed it first customers, we realized what wasn't working, we ended up having to throw it out and rethink what we're doing. And really think about, if a roadmap shouldn't have this time line at the top, what should it be? And that's where we got to this idea of, well, it's more like, how confident are we in each of these steps. And let's take a step up and think about these larger, more nebulous problems to solve and the order in which we're tackling them. And so a roadmap really is just about giving direction, making sure people understand what the high level goals are. And then underneath that, they can break those down into those more concrete pieces. But the roadmap is that step above, to make sure that everyone understands the lay of the land. And that's really how I like to think about roadmaps is that lay of the land, it's that that that that space in front of you where you can see where you are now, that's the near term, the stuff coming up. That's the now we've got the stuff that's coming up. Beyond that, that's the near term, and then you've got that far off in the distance at the leader. And it's much more centered around you as almost a human versus this linear path that you have to follow.
JJ 04:15
Yeah, I love that. Tell me about your thoughts on like, what are some of the prerequisites to get to a decent roadmap, right, you've mentioned having a vision, and you know, knowing that direction, so what are some of the steps that you've seen successful teams take in, in order to get get kind of that vision in the first place to have, you know, the the inputs, if you will, to that roadmap?
Janna 04:42
Yeah, of course, it's really important that the team does have a clear vision and that vision is aligned with the company vision. You know, if your team isn't able to say what those gold top mountains are in the distance that they're aiming towards, or if they can't say we're standing here Aren't we're trying to get to that, if they're disagreeing on what that is and the distance, then they're probably going to head off in the wrong direction, it probably doesn't matter what you put on the roadmap, because, you know, if if, if you're all heading off in different directions, it doesn't really matter which way you go, you're all going to be right, you're all going to be wrong. So you need to know what that gold star is, what that mountain is, and the distance that you're all heading towards. That is your vision. And it should align with the company vision if if you've got this higher level company that you're building within. And so that's the first thing to do is stop and just ask, what is the company vision? What is it that we're trying to do here? And you've also need some sort of high level objectives or high level goals or something to identify what success looks like, you know, are you a profit making company? Are you going for market share? Are you gunning for revenue early on? Like, what is your what does success look like? And again, these are often things that can come from above and be given as direction to product teams, or if they don't, then this the questions that you can start asking to help tease those questions out or tease those answers out from your exec team. So that you can be given those grab that bit of groundwork, so you can start working towards it.
JJ 06:17
You know, I think that's it's such an important part of this conversation is that I see so many teams and product managers, you know, being asked to create a roadmap or or knowing that they need to create a roadmap, but they don't have that foundation, they don't have that vision, either. They're there, frankly, the organization is not set up to, to empower them right to to do that. And to have that, or they don't know how, or their, you know, whatever it is. And so I think that is so important to tease out of this conversation is that, you know, you can't have a really successful roadmap without having that vision, because that's what it is. It's basically kind of the illustration of that Visio vision, if you will, and some of that, I like what you said, like, literally stop what you're doing, and do the work to get to that vision, I think is is a really important point.
Janna 07:10
100% agree with that. And I think it's really important that product managers take the time to, as I said, stop, but also ask the right questions of their execs, right? I think as product people, we spend a lot of time we spend forever talking about delighting our customers figuring out what's technically feasible, but we don't actually spend all that much time discussing or asking the right questions doing discovery work about what the business needs. And that is just as important, right? I mean, this is why the mind the product van, was about the, the tech, the user and the business is the intersection of the three because really what you're thinking about is, well, what does the business need from us? And sometimes you need to tease the questions out from those execs above you, because if they're not giving those answers, you need to go get them just like if your customers aren't giving you those answers, you need to go tease those questions out piece those answers out of them by asking the right questions. And so if you're not being given that vision, you can go get that it's a discovery process, just like getting the right information from your devs or from your customers is so important.
JJ 08:16
So so true. I mean, there are a few things that can derail progress and and you know, ability to get funding and prioritization, you know, quicker than if you're trying to do something that's not in line with what the business needs, right? So it's, it's, it really is just as important as what you're going to do for the customer, the external customer is what you're into for your quote, unquote, internal customers and the businesses as a whole. So I love that. So so when a team has a roadmap in place, and they've they've done the work, and they have a fairly, you know, decent roadmap that shows kind of where they're going, how do how did teams best leverage it? Right? I mean, how do they use it themselves? Kind of the core team? Is it just a reference? Is it a prioritization input? I mean, communication tool, all of the above, like, how do you see it being used once that roadmap is kind of in place?
Janna 09:15
Yeah. I mean, this is why the roadmap is so powerful it is all of the above. It's a reference, it helps people refer back to and say, Are we still on the right track? I actually like using the roadmap, not just as a forward looking tool, but also as a backward looking tool. So as you go and complete things, you're able to say, we did this, let's move this to a space adjacent to the roadmap or say, here's what we've completed, did it actually solve the problem? So things aren't just falling off the roadmap and being lost to the world? But you're able to say, Okay, we did these ones, how's it going? These are the things that are coming up. You know, are we still on track with our expectations? It's a space to check progress. It's a check space to check that you're on track with things and it's a space to send Let's check your assumptions, right I like to think of the roadmap as a prototype, but for your strategy. And I really like that term prototype for your strategy. Because as product people, we're familiar with prototyping, we do it all the time. Even if we're not designers, we've done a bit of design work, as in when you have an idea for a feature, you sketch it out on a piece of paper, and you show it to somebody, and they give you feedback on it. And that prototype, that piece of paper gets thrown out, but you take the feedback on board and you improve on that piece of paper, you get a nother fresh sheet of paper, and you put down a better version. And each time you do that you get closer and closer to this better version, the complete version of this feature, this idea that you had had in your head, you certainly wouldn't take this idea and just start immediately coding it or telling the developers to code it because it probably wouldn't come out quite right. The prototyping is this process that helps you move from idea through to the betterbirth version. Well, you can prototype at the strategy level, not just at the feature level. And the roadmap is the tool for doing that. What you're basically doing is taking your assumptions of where you think you're going. And you basically say, Well, I think we're going here and here and here. And the assumptions that are in the now column tend to be more crystallized, because you've been looking at them longer the right in front of you, the ones that are in the later column, pretty big guesses, and that's okay. But you're sort of saying we think that's over there. And we think that's over there. We think they're in that kind of order laid out in front of somebody, it's not perfect. Your first roadmap should be wrong, you know, a bunch of different ways. But you should just be willing to put something out in front of somebody, just like you're willing to take a sketch drawing paper prototype and put it in front of somebody and say, What do you think? And they'll tell you why it's wrong. And they'll say, Oh, I actually think we need to go that way. That way, that way, and then that way, or maybe they'll say, Well, what about that problem, or this problem isn't a problem, we can get rid of that. And you might remove things from your roadmap entirely. And maybe you add important things in. But there's nothing more lean than, you know, completely rewriting important chunks of your your strategy and removing pieces of work before you even think about cutting code.
JJ 12:09
I absolutely love that. That phrase, that analogy, a prototype for your strategy. It's so powerful. And and, you know, one of my, my thoughts or questions was was going to be like, how often do you update your roadmap? Because I think that's another problem that teams have is they put it out there? And then it's like, Oh, don't touch it. Don't change it. And I think your, your thoughts on that is, is so amazing, because it should be we should be changing it when we learn more. That's what we do. Right? So I absolutely love that prototype of a strategy. So So when an organization I know you've, you've probably gotten this question a lot and worked with companies a lot on this, but I would say probably, at least, you know, half or maybe even a majority still use those Gantt charts, you use those timelines, you know, that's their roadmap, that's what they think it is. So when you've got a product manager or product team who wants to move to more of a, you know, now, next later, you know, better form of roadmap, but the business, the stakeholders, etc, are still expecting a timeline. How do you how do you suggest that they try to change that culture? Try to change that that, you know, viewpoint in the organization?
Janna 13:32
Yeah, absolutely. I mean, changing a viewpoint in an organization means changing individual viewpoints, one by one, because when you teach somebody about their next leader approach, individuals get it. I've never met an individual that says, Now that doesn't make any sense intuitively, because it does, right. I mean, why would you make up a whole bunch of guesses and then run at it blindly, like people get that the old way of doing things isn't working. But the timeline roadmap as part of an institutional and organizational way of working, it's like a comfort blanket for the execs. It's a way that they always used to work. And so they look at it going well, if you're going to take this away, how we're going to do are always working, you got to look at each individual and say, Well, why is it that you depend on this? And let's look at that and see if we can improve on that. Like, for example, maybe there's a boss who likes having the timeline roadmap because it was always like that. And they look at it as a comfort blanket, right? It sort of proves to them that you are doing work if they can't see that, that timeline, that list of things you're going to be doing, how do they know that you're doing work? Well, reality is that you're not actually doing work any faster. Reality is that actually you're doing works more slowly, because you're having to put in all this buffer time to prove that you're doing all this stuff. In time, are you having to build in extra time just to make You don't slip on any of these dates, teams who work in leaner ways actually get more done. They just can't tell you exactly when they're gonna get all this stuff done. Because that takes time to go do if you just let that team loose to say, go tackle all these problems, or these right problems in the right order as fast as you can, they'll get more done. So, in reality, what is it that the boss actually wants? Do they want to know that you're going to do certain things by certain time? Or do they actually want more return on investment out of that team, which one's going to actually make them look better when they're reporting to their boss? Probably the return on investment. So if you can speak to that, which is usually what they're after, then speak to that, right, really speak to what their incentives are. Maybe it's the marketing team, the marketing team wants to make sure that they can market things on time, right? real fear, they're, they're afraid that if they spend all that money on the billboard campaign, your feature is not going to be out on time. Well, what you need to do is separate hard launch from soft launch. I think it's ridiculous that we stack up these risky projects, which is developing code, we don't know how long it takes to develop code, it's a bit more of an art than a science, we stack those up to try to line them up exactly with these expensive marketing projects, and try to line them up. So they land on the exact same day so that when marketing launches their marketing campaigns, they happen at the same time. But then if the development campaign slips by a week, marketing has wasted all their money and looks terrible. And then they're really mad, well, why don't we just line it up so that development finishes their work and puts it into some sort of soft launch mode, a feature flag, a beta mode, or something like that, and then tells marketing and then marketing can spend as much time as they like prepping for the biggest bangus launch that they want, right, they can spend six hours, they can spend six weeks, they can spend six months and all the dollars in the world, knowing that that feature is there and just needs to be switched on. So they can spend their time marketing. In the meantime, they're marketing features that already exists. So they're marketing, all this stuff that was launched several weeks before, several months before. And they've got lots and lots of talk about because our development is still constantly pushing stuff out. And development is always still able to turn stuff on and off. And in the meantime, marketing has some really cool features that are in beta, that they can test with clients, so they can get real video of this stuff, working testimonials. They've got all the assets. They're not depending on what design said it was going to look like. And then all of a sudden, it looks different. So you're actually making this into a better story for marketing. Right? Sales sales is one of the big ones who sometimes worries about, hey, if you take away these timelines, what am I supposed to sell? This one's a tough one. Because this sometimes strikes at the heart of a company culture, right? A sales lead culture can be really difficult because sometimes a sales lead culture means that your company is actually acting more like an agency than it is a product company. And unfortunately, agencies don't scale because what they end up doing is they just spend their time selling one feature after the other after the other individual companies, they never actually figure out what your product actually appeals to. Your salespeople aren't selling what exists today, it means that you often have a weak sales team, if they can't sell what exists today, what are they doing, they should be focusing on sell selling what exists today, they can use the roadmap to help show people, here's the where we're thinking of going with things. But don't show dates on the roadmap, here's the vision that we have for this company, they can use the idea of future stuff to sort of discover as to where the product can go. But they should never sell a deal based on some future feature, because that feature may never exist, they should sell the product based on what exists today. And that way, you never end up in this condition where you've sold something that doesn't exist if they're selling things that don't exist. And your job is to just go fill that, that that need your product project manager fulfilling an agency need not a product manager or solving for a wider market need. So all of these things can be addressed. Sometimes it does require addressing a deeper problem, like if it's a very Sales Lead company who just does this, but sometimes it's a matter of just saying, Hey, here's how we're operating. We're just going to separate things out. We're going to separate hard launch for self launch. We're going to focus on building as many experiments as we can, and not less on telling you as many delivery dates upfront this weekend, and we're going to be more effective for it. Each one of these stakeholders can be tooled, and can be sold on this new way of working.
JJ 19:54
I love this because it's basically product managing your stakeholders, right? It's like getting to the The core of their problem like what are they really need? And then showing them that a different solution can Yeah, solve that better?
Janna 20:08
Yeah, I've actually written a guide on this because I realized that this answer gets very long and drawn out because it depends, there wouldn't be a real product management answer if it wasn't a big, that's right. But there are a bunch of different stakeholders, we're all gonna have different needs. So I wrote a guide, it came out to six pages. And the last page specifically focuses on different stakeholders how to handle their objections to this. So I'll drop you the link, if you want to share that around. But it's the ditch the timeline guide. And yeah, very much tackles these cases and a handful of others as well.
JJ 20:42
Awesome. Yeah, I would love that, we'll share that with the the audience that will be on productvoices.com linked to that. So I want to turn our attention just just a little bit more, kind of, to General Product Management. So I spent a lot of my time working on some foundational qualities of product managers across industry across product doesn't matter. You know, you know what, what they're working on these are, there are some common common skills that are needed. So I would love to hear your thoughts on, you know, what are you? What are two of the qualities that you've seen in all successful product managers that you've worked with? What are some of those core skills that that any great product manager needs?
Janna 21:24
Yeah, absolutely. I mean, product managers, they need to be curious. I think we all know that they just need to be innately curious. And, you know, interested in looking under the hood of the product under the hood of the you know, what's going on with the data under, you know, why are people buying the product? Why are people not buying the product? You know, what happened over here? What happened over there? And, you know, curious about everyone around them. So the people on their team, the people who working, you know, who are running the business, you know, why is this product existing, you know, basically, from all different facets, and also tenacity, I think good product, people need to nasty, it's a tough role. And it comes with tough break, sometimes where you know, what, you're gonna hit dead ends, it's not just you're going to be digging into the data and find out that you just don't have enough to tell you the information or something wasn't hooked up, or you're gonna have a great idea and then realize it falls flat, because somebody else tells you no, or somebody legal tells you no, or some being dev tells you no. Or your tests tell you no, you know, you're gonna it's going to fall flat for a number of reasons. Your, your bets are going to fail over and over and over again, right? Like the stuff that you think is right is gonna be wrong. And then it's just a tough job. Like it takes a lot of work to, to get to the bottom of things. And I think the best product managers have a certain level of tenacity.
JJ 23:00
Yeah, curiosity and tenacity. Wow, those are really good. Because you're right. It's just, it's such a fun job. But it is a hard job there. There aren't a whole lot of jobs out there. That that you fail a lot. And that's okay. Right. I mean, that's part of it. And so I think that that's one of the hardest things that I think people who are who, you know, get into product management, one of the hardest things to realize about about the job is that the, you know, if we're doing it, right, we're actually curious about enough things and doing enough experiments that are going to fail so that we get to the right thing. And that that scares a lot of people. I think that's really hard for folks. But But I love that curiosity and tenacity are very key. So, so speaking about kind of people getting into the role, I mean, I'm sure you've seen this too. I mean, product management's been around for a long time, but there's just a huge amount of visibility on it right now. Lots and lots of people trying to get into product management. It's just a, you know, a highly visible and, and attractive craft, and career path for folks. So, so if you were talking, if you were talking to someone who wants to move into product management from another, you know, either from straight from university or, you know, from another, another career path, what would the piece of advice you, you would give them someone to move into Yeah, to break into product management?
Janna 24:33
Yeah, absolutely. I mean, there's a lot that I think product people can be doing to gain a leg up in the actual application process. So your cover letter is your friend. It's the way that you can stand out above and beyond a lot of the others. And I think a lot of people miss this step which is taking a really good look at the job itself and the company because the comp When he is trying to solve a problem by hiring a product manager, what is the problem they're trying to solve? And how can you uniquely help them solve that problem? Dig into your own history, and whether you've got a background as a product manager, or whether you washed dishes and walked dogs or whatever it is, right? Figure out what you can bring to the table and write a cover letter that tells them why you are a unique fit for that job and are going to apply your skills to solve their problems. Because they're going to get a whole bunch of generic applications of people who say, Yep, I don't get to talk to customers, I'm good at doing data, I can get to doing this stuff. Cool, cool. Cool. And everyone's saying the same thing. But how are you going to? Like, can you identify their problem? Based on what you've learned about them? Okay, you know, maybe you have to do some research on them. Maybe you have to go talk to some of the people who work with the company, get on the LinkedIn and, you know, figure out what they're up to. Maybe you need to dig through their blog and see, see what kind of things they've been talking about what the challenges are. Maybe they outright say so on their job, ad, but whatever it is, find that and then match that to how you can position yourself for their role. And that'll get you a leg up in standing out to them and their hiring manager and getting into the interview is, I mean, half the battle when you've got that many other people applying for that role.
JJ 26:24
Great advice on kind of how to stand out and, and again, show product chops even before you get there. So I love it. Great advice. Janna Bastow, this has been an amazing conversation. I've loved it. Thank you so much for joining me on Product Voices and for sharing all of your vast wisdom.
Janna 26:41
This has been great fun. Thanks so much for having me, JJ.
JJ 26:43
And thank you all for joining us on Product Voices hope see on the next episode.
Outro (the incomparable Sandra Segrest) 26:49
Thank you for listening to product voices hosted by JJ Rorie. To find more information on our guests resources discussed during the episode or to submit a question for our q&a episodes, visit the show's website product voices.com And be sure to subscribe to the podcast on your favorite platform.