When you have questions about roadmaps, it pays to talk to someone who has spent way too much of her life thinking about them. Janna Bastow – co-founder of both Mind the Product and ProdPad joins us to give advice to anyone ready to break up with their roadmap.
Featured Links: Follow Janna on Twitter and LinkedIn ｜ ProdPad on Twitter, and read more of her posts ｜ Troubleshooting Agile – Jeffery Fredrick & Douglas Squirrel’s episode of The Product Experience ｜Killing Zombies – Lisa Long’s episode of The Product Experience
Episode transcript
Lily Smith : 0:00
This week, on the Product Experience Podcast, we're going back in time to revisit a conversation with Jana Bastow, ceo and founder of ProdPad. We're talking all about roadmaps, that elusive artifact that mystifies everybody, or maybe just me.
Randy Silver : 0:20
The Product Experience is brought to you by Mind the Product. Every week on the podcast we talk to the best product people from around the globe.
Lily Smith : 0:28
Visit mindtheproductcom to catch up on past episodes and discover loads of free resources to help you with your product practice. You can also find more information about Mind the Product's conferences and their great training opportunities happening around the world, and online.
Randy Silver : 0:43
Create a free account on the website for a fully personalized experience and to get access to the full library of awesome content and the weekly curated newsletter Mind. The Product also offers free product tank meetups in more than 200 cities. There's probably one near you, Jana. Thank you so much for joining us on the podcast tonight.
Janna Bastow: 1:04
Oh, wonderful. Thanks so much for having me.
Randy Silver : 1:06
For the two people who are listening to a Mind the Product podcast, who don't know who you are, do you mind just doing a little bit of an introduction and then we'll jump into some questions?
Janna Bastow: 1:15
Sure, yeah. So hi, I'm Jana and I'm one of the founders of Mind, the Product, so it's a great honor to be on the podcast, and I'm also one of the co-founders of ProdPad, which is software for product managers.
Randy Silver : 1:28
And it's software for product managers that helps them with roadmapping and prioritization and other things like that, which is, coincidentally, the topic we wanted to talk to you about. So let's start at the beginning Again, for the two people who don't know what this is. What is a roadmap and what is it for?
Janna Bastow: 1:46
So I mean, I would call a roadmap a. You know, if you take a step back, it's a communication tool. It's a tool to help you communicate your strategy. You know what steps you're going to take to meet your vision. I like to reframe the roadmap and really think about it as a prototype for your strategy. And the reason I think about it that way is you know, we understand prototyping very much as product people.
Janna Bastow: 2:13
Prototyping is essentially the process that we take to learn and iterate and figure out what we're actually supposed to be doing in order to solve problems, and we do it at the fine grain level. When it comes to features, right, if you're coming up with a new feature, you would test something out by creating a small version of it, a piece of paper, a quick sketch, mock-up, and you'd show it to somebody and they'd give you feedback on that and they would let you know what works or what doesn't work. And you know, you'd throw out that piece of paper and you'd throw out that piece of paper and you'd throw out that original piece of it and you'd make a new version of it based on what that feedback came back as, and over and over again. You'd be throwing out those prototypes, but you'd be getting a better version of your prototype, better version of your design, a better version of that feature, based on the feedback that you're actually getting.
Janna Bastow: 3:01
And I think we should be doing that prototyping, but at the strategic level as well, which basically means taking your roadmap. It's a way of outlining and laying out your assumptions of what problems need to be solved and communicating them to people. So your roadmap should simply be a way of saying here's what I think the problems are. Let's lay them out for other people to see, so that you over here can give me feedback on it, and you over here can give me feedback on it, and if we disagree on it, that's good. We're learning something. Let's figure out where we disagree and figure out what order we should tackle these things in, what problems and opportunities do exist.
Randy Silver : 3:37
But companies have been doing strategy and communicating it long before there were product people or long before they were pervasive. And even with product people, there are plenty of other parts of the company that are trying to do this stuff. What makes the roadmap and product people so special? And related to that? Everything we do as product people is for a customer, and if the roadmap is something that is for an internal or potentially external customer, well, who are the customers of the roadmap?
Janna Bastow: 4:06
Well, a roadmap is something that you're using to communicate your strategy, and it's meant to align your team and make sure that everybody's on board with it. You know the goal of your product is to solve problems for your customer, but you are looking to get outcomes for your business. I mean, don't forget that If you're working for a for-profit company, you are looking to get outcomes for your business. I mean, don't forget that If you're working for a for-profit company, you are looking to get business goals, and usually the means to do that is to solve problems for your customer. That's not always the case. If you're working for a not-for-profit business or not-for-profit organization, then maybe your goals are slightly different, but for the most part you're looking to hit business objectives by way of solving problems for the customer, and so your roadmap needs to show what steps you're going to take to feasibly hit those objectives and solve problems along the way. So I see it as sort of stepping stones what sort of problems and opportunities you'll tackle that will get both of those.
Lily Smith : 5:01
Okay, so you've mentioned a whole bunch of things in there with, like problems and opportunities and outcomes. So what's actually in your roadmap, like what should it look like?
Janna Bastow: 5:13
So I think it's important to take a step back and remove our assumptions about what a roadmap should be. A lot of people get really tied up in trying to make the roadmap look perfect or look like what they've imagined another roadmap should be, which I think misleads a lot of people. I mean, I fell down this path some time ago when I was a young product manager and I tried to figure out what a roadmap should be. I looked up roadmapping templates and there's nothing worse for you, because what you'll end up with is you know, do a Google search result for roadmap templates or look at how some other tools are guiding you to do roadmaps, and it's mostly just a list of timelines and a list of things to do versus dates. And I think we should just wipe those assumptions away.
Janna Bastow: 5:57
And if you really break down what a roadmap is trying to express, it's really trying to say these are the outcomes we're hoping for, the business and these are the problems that we think we can solve.
Janna Bastow: 6:12
These are the initiatives, the things that we're going to do in order to try to take advantage of problems that are out there, opportunities that are out there, challenges that are in front of us, and here are ways that we might tackle those experiments that we might run along the way, and a roadmap itself might have different levels of granularity depending on who's looking at it. You might have different levels of detail depending on whether you are looking at it from a single product versus a whole portfolio of products. A roadmap should be something that's human, readable. A roadmap should not be something that needs a legend and a whole bunch of detail and three people to sit there and explaining what it does. It should be something that you put in front of somebody and say well, you know, this is where we are now, this is where we think we're going next and here's where we're going with it later. And you know, you can see for yourself what kind of problems you're trying to tackle and how we're thinking of breaking those down. What do you think?
Lily Smith : 7:12
So, when you're thinking about your strategy and it being a prototype for your strategy, what if you're working on a product or an area of your product which is so kind of full of uncertainty that you're just you know, you're just kind of needing to experiment a lot or you don't have a clear path forward. You know, do you just not need a roadmap in that situation?
Janna Bastow: 7:36
You're actually describing almost every product for ever. I mean, every product has uncertainty in it and it's just different levels of it and I think anybody who says that they don't have uncertainty is kind of kidding themselves and they may have prematurely committed to a whole bunch of things and that's actually dangerous in itself. The roadmap itself what are you actually doing when you're putting things on your roadmap? It's not this promise that you're going to do them, it's this way of putting them out there, saying I think if we do this, then this, then this. It's going to help us get to these goals. That's the best path. These are the best stepping stones we can take to success, to meet our vision. And as time changes, as your team learns more, if somebody speaks up and says, oh, actually, I saw this other stepping stone we could take or we learned something else along the way, that might change and that's fine. The fact that you've actually laid them out is really positive and the fact that you're able to have that conversation around the roadmap is really positive. The fact that you've got uncertainties is completely natural. What you're actually doing is outlining.
Janna Bastow: 8:39
Well, here are a few different ways we might break down this problem and each of the things on your roadmap shouldn't be a feature. It shouldn't be this list of things that you will do. It's a list of problems that you want to solve, a list of challenges that need to be broken down, and they should be open-ended enough that anybody should look at them and say, oh well, if that's the challenge, well, this is one way we might solve it. And here's another way we might solve it right, and I don't think about them necessarily as features that you do on the roadmap, but as experiments. Some of those experiments might be let's add a new feature right, adding a new feature might solve that problem, cool, right, that sometimes does solve the problem, but sometimes it might be.
Janna Bastow: 9:19
Let's try to remove this feature. That's another great experiment to try. Sometimes that can vastly improve your product. Sometimes it might be let's change this feature, make it slightly better. Sometimes it might be something unrelated to a feature entirely. It might be something like let's change the proposition, change how we talk about it, change the pricing, do something service-based, not product-based. There's lots of different things that might be experiments on how you solve these problems, and what it's actually doing is allowing you to lay out what needs to be discovered and making space for people to spend in discovery.
Randy Silver : 9:54
We talked to Lisa Long a while back about the idea of killing features and we're killing zombies and yeah, that's a great point, but one of the things that I read in every single ad for a product manager, there's a requirement that's never actually written but is expected, which is for us to be psychic, for us to be able to predict the future, because we're always being asked by sales, by marketing, by everyone, by customers, by everyone else. When can I have it? And if that's not going to be on the roadmap, if you don't have specific dates on the roadmap, what's the point? How do you get them to trust you? And where do you put dates? Are you saying we never put dates? Or is there a roadmap and a release plan to valid separate documents?
Randy Silver : 10:34
Okay, let's unpack that, because there's so much in there, all right so when somebody says that they want to see a date.
Janna Bastow: 10:43
I mean, sometimes you do need dates in a business, right? In order for sales and marketing to begin doing sales and marketing, they need to have something, they need to know when something is live. But this is why it's really important In this case, what you do is you separate hard launch from soft launch, right? Your sales team should not be selling things that you do not have yet. Your marketing team does not need to be marketing things that aren't live yet. It's a ridiculous idea to try to line up a marketing project plan to somehow miraculously line up with the tons of unknowns that go along with a development plan, because we all know that these things slip. And so if you're saying, yeah sure, have that, you know huge campaign, live, you know. Have the bus ads, live, you know next Tuesday, and you all of a sudden don't have your product live by, then you're risking your business. There is absolutely no harm and in fact, your business will do a lot better if you just say it's going to be live as it comes, live and as soon as it's live, that's when it triggers for you. You now have, whether you want six days or six weeks or six months to go build the biggest bangest launch that you can possibly think of, and they can now go do so without the constriction of when are you going to have this done. So they're now selling what is already live, when it certain dates.
Janna Bastow: 12:08
Like, sometimes there are dates that are required, right? I mean, we don't live in La La Land. Now. When we say no dates on roadmaps, what we're actually saying is take that timeline off your roadmap, right? What we mean by that is, when you've got a timeline roadmap, it basically deconstructs into, like a math chart, right, where you've got X on the X axis and Y on the and features on the Y axis, right, things to do and everything that sits underneath that roadmap has a deadline just by virtue of where it sits on that roadmap. So you're implying or giving deadlines for everything that you do. You're penalizing yourself, you're forcing yourself to have deadlines for everything, which doesn't make sense.
Janna Bastow: 12:50
Now, sometimes one thing on your roadmap will have a date. Sometimes a couple of things on your roadmap will have dates, like when GDPR happened, every roadmap in the world had a date on it. Like, I'm sorry, we had to work to that. And yes, in those cases, if something does have a date, you have to put your project management cap on. You have to plan ahead, you have to put some buffer in there, you have to make the time for it and you have a project and you do your project planning in behind and you make sure that that thing is in fact out in time and, if needed, you clear things out of the way to give it plenty of time to happen. It means that during that time you aren't able to spend as much time in discovery mode because you're now in delivery mode. It sucks, but we have to stay legal, right.
Janna Bastow: 13:33
But don't penalize yourself by giving yourselves dates that don't exist, right? So if you are in a more regulated industry, if you're in banking or something like that, you've probably got dates on a more regular basis. Those industries are more risky and they're harder to work in because you're going to have more dates. But there's the upside, right. If you can crack banking, there's money in that space. Right. If you're working in harder spaces with more constraints and you are able to actually operate in them, there's bigger upside because there's a bigger barrier for your competitors to get in there. If you're working in easier spaces where there's no barriers, then obviously other people can come in and it's, you know, easier to operate and you don't have as much of a competitive barrier. But generally speaking, lean companies don't penalize themselves by giving themselves dates that don't exist.
Lily Smith : 14:21
I think one of the reasons I've seen dates appearing on roadmaps is it tends to be a way for leadership to enforce some pace within delivery and say I'm not quite happy with the pace at which you're going, so that thing that you said you were going to build, I want you to build it or finish it by this date. So yeah, have you seen any kind of examples of being able to like, reflect pace or manage pace within a roadmap that doesn't include, like, committing to a date?
Janna Bastow: 15:02
Yeah. So I gave you some tips just now on how to push back or how to work around stuff. That sort of makes sense. Right, like you. Separate your hard launch from soft launch, great Problem solved. If you have a date, then you know. Work to that and make sure there's room for that. If the dates are being given because essentially your bosses think it's going to make you work faster, it's not.
Janna Bastow: 15:24
It's been proven time and time again that giving people deadlines and giving people constraints like that doesn't necessarily make them move faster. You might be able to get one project to go a little bit faster, but what you are doing is you're stressing out the team and you're almost certainly incurring tech debt. Because if you tell them, well, this is due on Friday or else what don't you see that they launch, even as a product manager, it might fill all the little requirements. Right, your acceptance criteria all might go tick, tick, tick. But is it documented well? Is the code commented? Is it as elegant as it could be? Was it the best version of it or did they just get out enough to make it work? So each time you do this, you're accruing a little bit of tech debt and over time you're accruing tech debt, your code base is getting worse and worse and your developers are getting more and more stressed out and you end up with this tech debt riddled code base. And then these companies are wondering as to why they have to refactor their code base every two years. And these are the companies who are trying to push their teams to go faster and faster and faster. A refactor is costly, it is time consuming. So if you allow your team, if you force your team to be pushed constantly like this, you're going to end up wasting more time down the line.
Janna Bastow: 16:41
Now it creates this vicious cycle as well, because the reality is is that if you give deadlines, no one actually delivers on time, and that's the problem. I've seen a million roadmaps, I've talked to a million product people and I've never actually seen anybody who's able to make up arbitrary deadlines and actually deliver the roadmap. It's the biggest pain point that we have. It's sort of the dirty little secret of the product world. The thing is, we give them because it gets somebody offer back today, but it results in huge amounts of stress and tech debt and it results in this vicious cycle. So, basically, what you're seeing is you're setting these deadlines and if you set a deadline it leads to what you do is you add a little bit of buffer time. So you say, well, you know, developer told me five days, so I'm just going to make that seven days, and just to be safe, let's make that eight, nine, ten, right, ten days, great, let's put that on the roadmap.
Janna Bastow: 17:39
But then you get Parkinson's law, and Parkinson's law is the one that says that work expands to fill the time given for it. It's the reason you're always running late on things. Right, scope always creeps, there's always little things to add in, and procrastination always happens as well. You're always running late. You're always running up against the deadline on things, which means things, no matter how much buffer you give, things are not delivered on time and there's always stressful and you're not going to get the great quality that you're looking for. So problems aren't solved well and you're always running late. And so the execs get even more nervous and they tighten the reins, so they give you less room for discovery. There's no trust. It results in this blame culture, which is basically the opposite of psychological safety. And so you and the team start adding more buffer because you don't want to be wrong next time, right. So you've now got longer deadlines and Parkinson's law comes back in and you're running late again, and this is why you've got companies who move way slower than your competitors who are like half the size, right, you see that all the time there is a way to break the cycle, but it means ditching the deadlines. It means ditching deadlines that are arbitrary. It means pushing back on them.
Janna Bastow: 18:47
So what I recommend doing is talk about how you want to focus on solving a problem in order to meet an objective. And the thing is, the business has set the objective. They should be really into this. They should be well on board with the idea of you saying we're going to go focus on getting user growth up for the next quarter. Tell them that you can't tell them what date anything in particular will be out, but by the end of the quarter that objective is going to be improved measurably. That's what you're going to promise them.
Janna Bastow: 19:16
Your method, like how you're going to do this, is that you're going to run lots of experiments. You're going to go into discovery mode and you're going to experiment the hell out of this thing and then just get to it and run as many experiments as possible that quarter. Now. Some will fail, some will work. You don't know which are going to fail and which will work, but you're going to do as many as possible and you're supposed to show your work as you go right, Show that you're actually doing things, show that your team is busy.
Janna Bastow: 19:38
And the thing is is that as you're running these experiments, as some work, those numbers will inevitably start going up. Teams who take more shots on net tend to find success. They just don't know how right. You only know how until afterwards. And what you're actually doing is you're building trust in the process, right? So before they were built, they had trust in this process deadline-driven roadmap that you had, even though it was lies, and instead you want them to trust the process, this discovery, experimentation-led process that you can and will do if you're given the space to do so.
Randy Silver : 20:19
Hey, we have a special message for listeners in London and Amsterdam. Mind the Product is hosting a free meetup for product leaders. Join us for an amazing evening with an expert panel and a chance to swap knowledge with your peers. These events are open only to directors, vps and chief product officers To attend. You just need to be in the Mind the Product leadership program. You just need to be in the Mind the Product Leadership Program. If you're not, just sign up at mindtheproductcom slash product-leadership-program, and that's program spelled the American way P-R-O-G-R-A-M. Sign up now and then join us on the 23rd of April in London or the 16th of May in Amsterdam. One last time. It's mindtheproductcom slash product-le dash program. See you soon. There's so much there.
Randy Silver : 21:18
But first I want to say I'm going to assume that was a Canadian hockey reference of shots on that rather than an English football reference. I'm just delighted to hear that from you. Anyway, so in larger companies, you talked a lot about smaller companies and a bit about larger companies. For larger companies, when you say well, you know, we have to refactor every two years, I've been in so many situations where the attitude is well, that's fine, because I'll be in a different job by then, so just get this out now. So let's talk a little bit about that. And, from the perspective of the roadmap, is something that you're using to communicate priority and try and get to change the culture to make this a place where it's friendly for you to do that type of experimentation, where you've got a history of no one believes the roadmap, because you know things have been on there forever and things always slip. How do you use this effectively to change the culture, to buy you the time to start doing this the way we believe is the right way?
Janna Bastow: 22:25
That's such a big question and changing culture is one of the hardest things, because culture is essentially made up of all the history and attitudes of all the people in the company. It's not this unchangeable thing, but I think about it as a little bit like calcification, like a geological phenomenon. Right, and calcification is one of these things that you can chip away at over time and it builds up over time and it builds up based on the people who've been there. So big companies tend to have a lot of calcification, a lot of things to chip away at, and if they've got a bad culture, like a bunch of bad habits, it's hard to chip away at it. Chip away at it, but it can be done. Now you know, one way of getting beyond this calcification changing culture is a reorg. But obviously those are risky and you don't actually know that those are going to work anyways. It's like the big bang release of human resources.
Randy Silver : 23:20
So usually it's also usually outside the remit of the product person.
Janna Bastow: 23:23
Yeah, exactly, and you don't generally want to be part of one of those things and, generally speaking, it's not going to work. Um, sometimes they're they're thrown under the title of, you know, transformations or whatever else, um, but in reality, um, you know, in the place that you're in, uh, you can chip away at your small area of it and start creating, um, different patterns, creating different patterns that other people can start following, and it might just affect your small area and start growing from there. You know, I'm a big believer in asking for forgiveness rather than permission. Now, in some companies, this may end up getting you turfed, but maybe those are not the great companies. Some companies, this may end up getting you turfed, but maybe those are not the great companies, to be honest. But being able to, you know, jump in there and spend time experimenting and then saying, hey, we carved out, you know, a month's worth of time and this is what we actually did, this is what we achieved. We went in there and, you know, you didn't know what we were going to build, but this is what we actually did and this is what the results were. Can we have a little bit more time to do so, you know, being able to show the results, being able to show the process about what's going wrong with the company.
Janna Bastow: 24:34
All the individuals get it. They all understand that there's something wrong with the company and that the way that they're working is not sustainable and that the company is definitely going the wrong way. But the company itself is sort of held together by all these bad habits and no one can seem to change it. And so the way to do that is to understand how the business model works, how the incentive works. Incentives, their work, understand who's getting paid for what. You know, sometimes you've got hard dates on your roadmap because that's how the salespeople it's a sales led organization and they only get paid if they're able to sell features that don't exist yet. And that's how they get their car payments and their mortgage payments. So they're putting pressure on you. Now you don't care about their car payments, but they obviously do, and that's why it's, you know, becoming so difficult from them.
Janna Bastow: 25:34
And understanding that and empathizing with them the same way that you empathize with your customers, is really important. Sometimes being able to speak the right language, sometimes being able to speak the right language just understanding that, you know as an exec in a company, you know, as a product manager, you can speak about customer delight and customer journey mapping until the cows come home. Right, we speak this language. Naturally, your execs probably don't care, right? Some of them do, but mostly they just care that their money is going towards the right stuff and that the number is going up and to the right, and that they're going to get their Christmas bonus, work on things and avoid tech debt. And you start showing them the how and why.
Janna Bastow: 26:29
The way that they're working, the way that they're forcing you to work, is actually less effective. It's more wasteful, it's a bad use of their money, it's risky. If they start seeing that, then chances are they'll start turning around and go oh why are we wasting our money this way? And it's not like this is new stuff. This isn't just cute new stuff that we're coming up with. Right? This lean method of working has been around for like a long time now. We've got case studies. We can see companies outperforming each other on the S&P index and on the FTSE and wherever else. Right, these companies, these case studies exist. You can see the ones who are absolutely owning it out there, because they do have an experimentation-led culture. So show those examples and speak that language.
Lily Smith : 27:12
Or, if nothing else, just get them to listen to this podcast, right? I definitely know some of those salespeople that are trying to pay off their car loans as well. So people that are trying to pay off their car loans as well, so that resonates for sure. Yeah, so, uh, what? There was one of the things that I thought um, you know, I always, when we're thinking about questions to ask our guests, I always try and put myself in the shoes of, like different product managers from different sort of types of businesses, and one of the things that I've always thought must be really interesting challenge is when you have like a core product with lots of kind of sub products that are whole team of product managers all working on different aspects of one big product.
Janna Bastow: 28:10
Yeah, yeah, it's a really good question. I mean, the core concepts are still there. At that level, what you're trying to do is make sure that there is cross communication and that people can understand what the different stepping stones and what the different problems are that different teams are trying to do and where it pertains to them right. And so the roadmap at that level you're looking at you know the product line or the portfolio roadmap becomes your friend. You know, the higher up the level you go, obviously the less detail that you want to include. Your goal here is to create something that is human, readable. You still want something that people can digest in one space, so you don't want to create something that is this huge, massive document that no one's going to read. Create a simplified version of it that includes more of the products you know, sort of like summary of what's going on, and share that around and make sure that the heads of product or whoever needs to know that information sort of like summary of what's going on. And share that around and make sure that the heads of product or whoever needs to know that information sort of has the details as to what's going on and then can weigh in their own assumptions and their own input on what those problems are, whether they're all aligned on them, whether there's any misunderstandings or gaps that they spot, and then can make changes at that level. And then, of course, each product person can take that back to the team and say oh yeah, so-and-so spotted a gap or spotted something that's overlapping. Maybe we should change this in our own roadmap and it just gives them that opportunity to have that conversation.
Janna Bastow: 29:37
And when it comes to things like dependencies, those things should just be declared on the roadmap, right, it doesn't necessarily need to be shown like in a literal way, with like a Gantt chart style thing with one thing stacked up in front of the other. If there's a dependency between two different teams, then just say so as a note on the initiative on the roadmap and a link to whatever it's actually dependent on. Again, it's meant to be a human, readable document that people can look at and read and share and have a conversation around. And so you know if there's something you need to show, add a tag, add something that allows you to just spot it, filter down by it. Just make sure that it can't be glazed over by somebody reading your roadmap and they don't get bored and miss something. It should be something that they can just sort of look at and go oh yeah, okay, here's a problem or here's a gap.
Lily Smith : 30:35
So in that sort of scenario would you expect, or would it work best, to have everyone have the same kind of process for developing and presenting and working on their roadmap, so every kind of roadmap in the company looks the same, because product managers sort of approach things in different ways and have different sort of styles as well. So do you have to kind of get everyone to come together on that thing, do you think?
Janna Bastow: 30:59
Ideally they should be something that are congruent with each other. You know, one roadmap shouldn't baffle somebody else. They don't have to be samey, but they certainly shouldn't need massive amounts of translation from one team to the other. If they are, then they're not human readable, they're not communicating well. So each one, regardless of how they want to format the roadmap, should have something that is able to be communicated well and when somebody needs to say, hey, well, how does this fit into the bigger picture, they should be able to see like okay, well, let's take these parts and lift them up into the bigger picture.
Randy Silver : 31:35
So something that you were talking about there actually also goes back to an earlier conversation that we had with Jeffrey Frederick and Douglas Squirrel about the idea of briefing and back briefing, the idea that you have the objective out but then you're asking people how they're going to achieve it and the roadmap is the thing that does that, and as you clash all the roadmaps together and align them, you find out is this actually going to work or are we not working towards that? So just another nice little callback for us.
Janna Bastow: 32:03
Yeah, yeah, I really like that. I mean, it's basically the idea of being able to play something out and then play it backwards, right. It's like okay, well, if this is what we were thinking we were going to do if we were to do all these things, does it do that? And your roadmap should be able to tell you that.
Randy Silver : 32:17
So so. So, building off in this conversation, you know, as product people, we generally don't do very much. That's not fair. We don't build very much ourselves, we're not responsible for actually building anything, and so we try and influence other people to build. But the roadmap is the one thing that we seem to take a lot of pride of ownership in. But should it be ours? Who should be involved in creating the roadmap? Who should be involved in getting votes in terms of the prioritization of what goes on there? You know, we may produce the artifacts, but is it ours or is it a group effort?
Janna Bastow: 32:48
I think this is something that sits squarely with the product manager.
Janna Bastow: 32:51
The product manager should own the roadmap itself, but it shouldn't be purely from the product manager's mind, just like how you know a design shouldn't be purely what the designer thought was best.
Janna Bastow: 33:05
It should be based on feedback from people who have those problems and can give feedback on it.
Janna Bastow: 33:13
The roadmap should be based on a combination of everything we've learned from speaking to people on the business side, speaking to people on the tech side, speaking to people on the marketing side, on the user side, understanding all these different places and saying, well, here's what I've understood the problems to be. I think it's this, this and this. And you know, if I play this back to somebody else and they think it's something else, then I've misunderstood and so they should be ready to have these conversations and make sure that they have understood the problems properly. But ultimately, it's the product manager to be placing those stepping stones and saying, well, based on everything we've said, yeah, I think it goes like this, this and this and this has gone through X number of iterations and everyone has had a chance to look at this. Who understands basically the space that we're in? Who has insight into where it is that we're going, because the more people who have eyes on where it is you're going, the more informed and robust your strategy is going to be.
Lily Smith : 34:17
And what about having a public roadmap then? Have you seen, you know, have you seen that working well, or are there some kind of gotchas if you're going to make your roadmap public?
Janna Bastow: 34:28
Yeah. So as soon as you step away from the idea of having dates on your roadmap, it can be incredibly freeing because all of a sudden, you can make that roadmap public, because what you're actually saying is well, you're buying our product today, that is what is for sale. But here are the problems that we think we might want to solve in the future. Which of these things jives with you? And it doesn't mean like you as a customer then get to pick and choose. It means that, if you know, you put your roadmap out there and all of your customers come back saying, hey, I can't believe that you're not tackling this before this. Like, all of your customers say that. Like, that's something that you've learned. Like, oh, maybe we should switch the roadmap around. Before you even thought about cutting code, you started learning and you're like oh, we should flip that around. Customers really want this thing.
Janna Bastow: 35:13
Or if customers look at your roadmap and they're like that doesn't seem like anything that's going to be important to us in the future, like, oh, maybe we shouldn't go that way. If people are like this is really really cool, but what about solving this problem as well? Okay, well, let's start thinking about that, right, maybe that's something we want to put on a roadmap. We're not right. You still have the right to not do things. Just because your customer's password doesn't mean you have to put it on your roadmap. But it's another vector of getting feedback and you shouldn't be afraid to get feedback.
Randy Silver : 35:42
Wait a minute. We're allowed to say no. You're allowed to say no.
Janna Bastow: 35:45
That's our job. We're supposed to say no.
Randy Silver : 35:49
Yes, I'm teasing, but from everything you say, it's almost like the roadmap itself isn't the product. It's a thing to help us have the right conversations about what we should do with the product.
Janna Bastow: 36:00
It's a prototype for your strategy at best right.
Randy Silver : 36:04
Oh, good callback, Jenna. Thank you, this has been a fantastic chat. We've really enjoyed having you on.
Janna Bastow: 36:12
Well, thank you so much for having me. It's been a pleasure. Thank you, Jana.
Lily Smith : 36:25
The Product Experience is the first and the best podcast from Mind the Product. Our hosts are me, lily Smith and me, Randy Silver. Lerun Pratt is our producer and Luke Smith is our editor.
Randy Silver : 36:40
Our theme music is from Hamburg-based band PAU. That's P-A-U. Thanks to Arnie Kittler, who curates both Product Tank and MTP Engage in Hamburg and who also plays bass in the band, for letting us use their music. You can connect with your local product community via Product Tank Regular free meetups in over 200 cities worldwide.
Lily Smith : 37:01
If there's not one near you, maybe you should think about starting one. To find out more, go to mindtheproductcom. Forward slash product tank.
Comments
Join the community
Sign up for free to share your thoughts