Episode 97: Mapping Out Now, Next and Later with Janna Bastow
Melissa Perri welcomes Janna Bastow to this episode of the Product Thinking Podcast. Janna is the founder of Mind the Product and the CEO and founder of ProdPad, which is software that helps manage your roadmap and product backlog. Janna and Melissa discuss the story of how ProdPad came to be and why Janna was inspired to build a more robust road mapping tool, how to become the most informed PM in your industry, the process behind creating the Now, Next, Later roadmap format and why it’s caught on, how to communicate with other teams both before and after you create your roadmap, and how to influence your leadership to evolve their processes and thinking around road mapping.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Janna talk about:
Janna shares how ProdPad came to fruition. “Some of the immediate problems were the fact that we have to ask the same questions over and over again: Why are we doing this thing, what is this thing we're doing? What problem does it solve?”
Janna has always taken a collaborative approach to product management. She knows she doesn’t have all the answers, so she views her job as asking questions and using the knowledge of the people around her.
When done right, product management is the most fun area of business. You get to play with different ideas, interact with different areas, and make decisions about what gets made.
The Now-Next-Later roadmap focuses on prioritizing the most urgent tasks, identifying what needs to be done, and providing a framework for the scale of certain tasks, emphasizing sequence rather than time.
Many product managers prefer roadmaps in the style of Now-Next-Later because it doesn’t communicate time at all. They don’t want to be beholden to time estimations in anticipation of over-committing or not hitting deadlines.
ProdPad is a mix of a coach and a SaaS tool designed to help you become a better product manager. It gives you a few key views in a non-exploitative format that allows you to view the order in which you are going to solve problems.
One of the key things product managers can do to convince their leaders to adopt the Now-Next-Later roadmap is to speak their language; try to gain clarity on the core of their resistance.
Resources
Janna Bastow on the Web | LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to the Product Thinking Podcast. Today we have a great episode for you all about roadmaps, and I know that is a hot topic for everyone there. So, uh, please welcome our guest, Janna Bastow. Welcome Janna.
Janna:
Hi, thank you so much. Great to be here.
Melissa:
Jana is a CEO and founder of ProdPad, which is a product management tool and she's also the founder of mind the product. So she's got lots of really deep expertise in product management. So Janna, can you tell us a little bit about, you know, how you got into product management and I guess what, what made you wanna build a tool for all of us?
Janna:
Yeah, absolutely. I mean like, I guess a lot of people in product management. I fell into it completely accidentally. I had dabbled in a whole bunch of things beforehand. I'd, you know, dabbled in a bit of coding, I'd dabbled in some sales jobs, some um, uh, support facing roles, some retail bits and pieces. And I ended up in a customer support type role right out of, uh, right outta school. And while I was there, my boss sort of identified that I was good at talking to the customers, but also good at talking to the developers. So I was given this role that was somewhere in between and I was made a junior product manager and I was like, oh, that's cool, but what is it? And I literally had to go to my desk and Google what is product management and try to figure it out from there.
And I did it quite badly for some years cause I didn't have anybody to lean on. I didn't have anybody senior guiding me or any sort of support around me. Uh, but it was, well it was in that role that I realized that there's a lot of replication, there's a lot of, um, work that, uh, seemed to be a bit of grunt work. You know, I was making, uh, PRDs back then and I was making these roadmaps and I was having to do them over and over again. So I'd started sketching out some ideas around what, uh, would be a SaaS tool. I didn't know the word for SaaS at that point in time, uh, for, uh, product management. And, um, held onto these things for quite some time. And I moved from that role, grew in that role for a while, moved from that role into another role and realized that some of the same problems existed.
But I started learning and meeting other product people. And it was only when I met, uh, another product person, Simon Cast, who I ended up starting product camp with. Product Camp is a series of events around the world. And we had this idea of starting events to product people. And this basically was the, the, the genesis of Mind the product. Um, one thing led to another, we met Martin Erickson who's starting Product Tank. Um, that led to mind the product. But it was when I was talking to Simon that he said, oh, this idea is pretty cool if you did this and this, you know, turn into this sort of thing. And actually this would be pretty easy to build. You know, this, I could build the backend. I was like, that's really cool. You can build backend and you're a product manager cuz I could build front end. Now of course back then front end Code was J Query and Bootstrap and Pope. Um, and it kind of worked. Um, we managed to get a version of this that we could share with our team and it solved our immediate problems. It was something that allowed you to build a and collect ideas from your team and it all out together to basically make sure people could see what was going on and uh, and it from there.
Melissa:
That's awesome. So when you were thinking about, you know, let's build a tool for product managers of what we needed, how did it start off? What types of things did you feel like product managers needed at the time? What were your biggest problems you were solving?
Janna:
Yeah, I mean some of the immediate problems was the fact that, um, uh, was having to ask the same questions over and over again. Like, why are we doing this thing? What is this thing we're doing? What problem does it solve? What are the outcomes we're looking for? What were the outcomes we got from it? So some of the basics of just what goes into, uh, any idea, any experiment that we're trying to run. Um, and then also things like, uh, being able to, uh, show off what sort of things are being built, you know, or just constantly having to generate a version of a roadmap that somebody can appreciate and understand and make use of without having to fiddle with, you know, dials and boxes on PowerPoint or in Excel or whatever I was using at that point in time. I've tried everything. Uh, and also there was some particular pain points that started coming to light as I got deeper and deeper into the role.
Things like, you know, the salesperson who'd come back from, uh, from a call with a client or whatever and say, oh, I've got this great idea. This is the most important idea ever. You know, can we do this? And he wouldn't have visibility into my backlog, so he would just expect me to do this idea and would be disappointed when it wasn't done. But I had to start realizing like, well what if I showed you what was in my backlog? Cause at that point in time, my backlog was kind of hidden in the dev tool of the time it was hidden away in Jira. And that wasn't really fair cuz he couldn't see how much I had to do. And, uh, what sort of decisions were being made. You know, I also try to remember that, um, to a, uh, product manager, like if something takes six weeks, six weeks is not very long time at all.
That's what, uh, three sprints, a few things get made. A handful of things get made and only the most important stuff gets done in that time. Whereas to a sales person, six weeks is a long time. So what I started doing was physically externalizing my backlog and saying, Hey, that's a cool idea. Here's the other top 10 things that are in that backlog. Why don't you take that? We'll put it on a Post-It and you help me decide which of these things are more important. And by having them see which things got pushed around, um, and see how things connected up to what was strategically important, which things were going to drive various things, uh, helped them see that it wasn't me telling them no, it was the product management system. They could see the decisions that were being made and why and uh, you know, help them come up with ideas that were better aligned with the business as opposed to whatever was shiny that week.
Melissa:
You know, what you're talking about too, I think will kind of be shocking for some more junior product managers out there because I think there's this whole, you know, system of like, no, don't tell the sales people what's on the roadmap. Nobody can look at our backlogs, right? Like I, it's weird. I feel like there's a lot of backlash recently, not recently, I guess for quite a few years, but like there's a lot of backlash in product management about hiding what you're working on so that sales can't oversell it or sales can't go talk about it. They can't reprioritize, they can't rush it. And you just described a very collaborative approach, um, to doing things. So tell me more about, you know, working with sales and what you're trying to enable, I guess, through ProdPad and through these different ways of working as a product manager in your systems, um, to be more collaborative and to be more open with the rest of the organization. Like how does that pay off?
Janna:
Yeah, you've hit the nail in the head. My, I've always been, uh, taking a really collaborative approach to product management. It always felt kind of natural that way because my assumption is that it's not my job to have all the answers as the product person. It's my job to ask the questions and to use the knowledge of the people around me. So, you know, when it comes to, uh, sales for example, they are agents of discovery. They can help you understand what kind of problems you need to be solving. Now, as long as you've got a good understanding of what they should be doing and what you should be doing. Like, they shouldn't be selling things that don't exist. And that should be the agreement that they have with you. Uh, if they're selling things that don't exist yet, they're not doing their job, they should be good enough to sell things that already are there.
Uh, if they're not doing that, then you need to work with them on what the ideal customer profile is and help them figure out how to sell for what is already there. So make sure you've got that contract in place and they're selling what's there already. And then you can work with them really collaboratively so that when they come back saying, Hey, we talked to this what we thought was an ideal customer, but they thought that actually it needed this one thing. Cool, that's great feedback. You wanna hear that because if you know all the customers keep telling you that, well then that's probably where you wanna go build next. But you wanna make sure that they can see what kind of things are out there. So, you know, they might be feeling this burning pain for this one feature, but they're not seeing that there's also this burning pain for, you know, this this tech read right here. Which if you don't do that, then things are gonna go on fire in this other corner. Or they might not be seeing that there's a, you know, a business initiative that if you tweak something over here, you can become more profitable in this other way. So you need to be able to show them what the cards are on the table so that they can input and, you know, understand how their, uh, their ideas, the stuff they're feeding in impacts the wider picture.
Melissa:
So as you're building, you know, this tool on this, uh, in prodpad to be more transparent to help, you know, other disciplines in the organization, understand product management, give input, what have you found that really works well for collaboration? Like, how do other areas want to interact with product and the things that we do or the artifacts we create on a daily basis, um, and what, you know, how do they participate?
Janna:
Yeah, I mean one of the problems that I've heard from other people outside of the product management space is that they assume they, they think that product management is where ideas go to die. They've got this general distrust of product people. And I, it kills me when I hear that because it's completely preventable. It's something that we can actually help them with. And actually people wanna get involved with product management. It's, you know, done right? It's actually the most fun area of the business cause you get to play in all the different areas and, you know, think up new ideas and you get to, uh, talk to different areas, um, and really make decisions about what gets made. Now if you're in one of these areas that, you know, you're in sales or you're in marketing or whatever, you're not the one who makes those decisions, but you can certainly influence those decisions and, uh, by, as the product manager, by opening up these, um, these forums, by creating these spaces, this, this, um, feeling of safety that people can come to you and say, Hey, this is what I think, this is what I think.
Now you're not saying you are going to drive the product. You're saying you're going to inform the product. You're gonna help me understand what the product needs so that I can make the best decisions. Uh, what you're gonna find is that people do come to you with their insights and you're gonna become the most informed product manager in the, in your particular corner of the industry. And that's hugely powerful. You're gonna be able to outperform your competitors.
Melissa:
I think that's really important for people to understand. Um, and I, I do get kind of taken aback when people are like trying to insulate the product team from the other areas of the organization. And I found, you know, after working with a lot of teams, the ones who collaborate across functions and the product managers who talk to the sales people to figure out like what's being, you know, what's working when we go for a sales meeting, what's not working? How are you pitching this? You know, what are people saying no to? What are people saying yes to? What types of profiles are churning? Why did they say why to me? Those are like the smartest product managers cuz they're armed with all this information to go back and actually, you know, do things. So I've always been kind of taken aback when I hear people say like, they don't wanna go talk to sales or they don't talk to sales and this is, you know, this is their baby and they're going to build this product and not, not go, you know, across the organization and start to gather information and harness the knowledge of other people. I think that's like a really big detriment to other, to other companies, I mean, to, to that company.
Janna:
I was gonna say yeah, absolutely. I totally agree with that.
Melissa:
So when you are, when we're talking about collaborating with a lot of, um, you know, different team members, a big part of that is also roadmaps. And I know this is something very dear to your heart. Uh, you have been named the creator of the now next later roadmap, uh, which is I think a really popular format and a great format and something, uh, a lot of people have rallied around because it does not prescribe Gantt chart like timelines to when we're going to release things. So can you tell me a little bit more about like, how, how did you come up with that format? Where did it start, you know, and, and what led you to create it?
Janna:
Absolutely. Yeah. So this is, uh, going back, uh, an origin story. Uh, back when, uh, myself and Simon were doing the early days of building Prodpad. So that first version of prodpad that I was sketching out and that it was based on, was a timeline roadmap. The first version of Prodpad that we were using was a Gantt chart. Um, because back when I was a product manager, I used to make a timeline because whenever I, I, I was sketching things out, um, that's what I saw other product managers doing. And so I was just replicating that and I'd make it and my boss would give me a little pat on the head and tell me to go deliver it. And I was never able to deliver everything on my roadmap. And I just assumed that that was just a, you know, a failing on my part.
But everyone else clearly was able to deliver all their roadmaps. So, as you know, assuming I got better at getting closer to the dev team and better at estimating, I'd be able to do it. So it wasn't until we codified it into ProdPad that it became clear what was happening. Cause once we codified it into ProdPad, we shared it with other people around us. So this is now the early days of product tank and and whatnot. We started sharing it with product people around us. We had a version of it that you could basically take ideas from your ProdPad backlog and drag and drop them onto this roadmap and then you can stretch them to show how, uh, long they were gonna take. And it's broken down into week long increments. So you could have weekly, um, due dates for, for all the ideas on your roadmap.
And it was pretty cool. I mean, this is, you know, 2012 at this point in time, um, you know, pretty, uh, interesting to pull off with, uh, J Query I'd spent months coding this thing and getting it right. We shared it with, uh, it was about 20 or so product people and, uh, they were giving us early feedback and these, these people started coming back to us saying, love it. You know, like shared it people. And I got some good feedback, but about a month later, some feedback started coming back from a good handful of these people saying, love it, but can I take this selection here and just move it across by a bit? They wanted a multi-select tool. They wanted be able to select multiple things and move it across. Now had I had, I just, you know, done what the customers asked for, I would've had like a multi-select drag and drop, which we didn't have.
We had to do it one by one, but we asked the whys. We asked five whys and continued just asking until we got down to the bottom and realized that no one was delivering the roadmap. They were putting stuff on the roadmap. And then at the end of the month, they were reporting on the roadmap, you know, the next month and realizing that no one was delivering the roadmap. So it wasn't just me who couldn't deliver roadmap, it was no one. So we're like, well this is gonna become a problem because either we're gonna end up with roadmaps that are just constantly overdue. We're gonna have to provide ways of constantly moving it over, or we need to like, remove this timeline from the equation. It's gonna become problematic, but what does that even look like? Is it even there still a roadmap if we do that?
So myself and Simon sat down in a cafe in Onesworth London, which is basically equi between our houses at that point in time and sketched it out. And we've actually got a, um, the first version was on a napkin, but we've got a picture of the second version, which was a Sharpie sort of thing. Uh, there's a picture of it on our site, uh, where it was three columns with another column next to it, which was where it was gonna be edited and we labeled it current near term future. And it's this concept of buckets where you had these high level initiatives and you could bucket things in there saying, you know, what was in front of you, what was coming up after that and what was later on. Uh, and one of the questions we had was, well, we've already built the page and it's, you know, app dot.com/roadmap and it says roadmap and the title, and we're just replacing the, the thing there with this other thing.
Can we still call it a roadmap? Like we're gonna remove that part of the code or not. We decided just to keep it and see if anybody called us out on it. See if anybody you know, said this isn't a roadmap, you're not allowed to do this. And no one did. Actually, we, we, you know, people actually looked at it and said, oh, this is a legit roadmap. This works. I'm allowed to do this. And, uh, it went from there. So one of the things we ended up doing was we changed the, um, the, the headers to be editable cuz we had people saying, oh, well I wanna change it to, you know, q1, q2, q3, uh, I wanna change it to whatever. And it wasn't long before, um, uh, somebody used the term now next later, which we ended up adopting as we're like, that's much better. Um, so we ended up adopting that as like the official format of the time horizon roadmap.
Melissa:
I love it. And it's really caught on. Like, I just was at, um, a conference in Norway by net netlife with, uh, Gibb Biddle and he had their Netflix roadmap up there and it was now next later style. And everybody was like, oh, you can, we can do this <laugh>. I remember I posted it on Twitter and I was like, look, it's getting around <laugh>, but I, I see it pop up more and more, which is great. One of the, one of the feedbacks that I get that I, on this type of roadmap, which I'd love to hear from you is, you know, not everything in the roadmap buckets are going to be of the same length in size, right? So each item, if you have like a whole list of prioritize stuff and next, you know, something might take a month and the other ones might be six months long, how do you communicate to the rest of the organization, um, how long those next items might be or the current items might be? Uh, because you still need to communicate some kind of time, right? Not just like, you don't wanna get too specific on the dates, but how do you balance that?
Janna:
Yeah, I mean, what I like to think about is, um, the, the columns not necessarily as, uh, equal columns or equi distant columns. I like to think of them in terms of, uh, distance away from you. So the now is like the immediate stuff that's in like the, you know, 20 meters from you, right? Whereas the next is like the next, you know, um, chunk of distance away from you, right? It's the next two kilometers sort of thing. And then beyond that, it's like the next 200 kilometers, right? And so it's as if you've landed on this new shore and you're looking at the stuff that's right in front of you, the stuff that's right in front of you, you can see in lots of granularity, you can tell how big it's, you can tell how far away it is. You can tell how you're gonna tackle that problem.
You know, so if you've landed on a new shore and there's a bear right there, it's like, well that's the first problem, you know how to deal with it, you know, whether you're gonna fight it or run away from it. Whereas, you know, something that's in that middle distance, you know, you're like, well, is that a, is that a a bog we have to climb over? Or is that, you know, a forest we have to get around? Or what is that right? Whereas the things in the far distance, you're like, well, is that a hill? Is that a is path up there? You know, is there gold at the top of that mountain? So you've kind of got these differing, um, scales of, uh, columns that you're looking at. And so you've gotta take them in that sort of sense. Whereas the things that are in the later column are naturally going to be these large chunky boulders that need to be broken down, uh, and will have less detail.
And so when you've got something in there, chances are this could be a multi-month problem, and you don't even know how big it is. Whereas things that are in the now column are, you know, quite literally the size of a release or two. Um, now if you have details of how big it is, if you have a sense of how big it is, then put that in the card, right? Like say, this is something that we think we can tackle in a release or two, if you think that this is a big chunky, multi-month problem, then say, so, you know, identify that on the card, the placement of the cards in the roadmap sort of insinuated anyways. Um, but you can also identify that directly in the cars themselves.
Melissa:
I think that's really important for people to hear. Um, one thing that I've, I've been observing is that when people adopt, now next, later roadmaps, right? They, they, I almost picture it kind of like a Trello board, right? Where they've got things in the columns that way that they're visualizing it, where they're just like, oh no, it's like a stacked backlog and I'll just pull the things into now as I'm working on it with no visual representation of time. And what I hear from a lot of product managers is, I want this type of roadmap because it doesn't communicate time at all, because they don't wanna be beholden to any dates or estimations on those things because they think that they'll either not hit it or they don't wanna over commit or, you know, all the reasons why we don't love to estimate. Um, but what I've found, you know, working with a lot of leaders and especially in B2B companies, you know, like ProdPad and others, um, the sales teams wants to know, want to know like, is this, is this gonna be like a this year thing? Or is this gonna be in a three year thing so that I can, you know, communicate that we are working on that problem or we're not working on that problem in sales. Um, which kinda goes back to what we were talking about earlier. So how do you, you addressed it a little bit, but how do you make sure that people in other departments are very clear on what those timelines are? And I guess what's, what's too much detail and what's the right amount of detail for putting in your roadmap when it comes to time?
Janna:
Yeah, I mean, the reality is, is it's as much detail as you reasonably have and as the business needs to have, right? Like, we don't live in la la land. Like if there is, uh, an important date, something that's strategically important to the business or is externally driven like a regulatory date, like if, uh, GDPR comes up again or something like that. Or if you are working in a particular, uh, sector that requires it, if you're in, um, uh, the education space and you need to have things out in term in time for a, um, semester start, you might have a due date that, uh, called that, that's called up, you know, once a year for that. Now, just because you have a due date once a year or a couple times a year, doesn't mean that everything on your roadmap has to have a due date.
And this is one of the main problems of having a timeline roadmap is that that line at the top makes it so that everything you put on that roadmap is forced to have a due date because everything underneath that timeline, it has a date by the placement of it on that, uh, that, that roadmap. So the now, next later format of the roadmap gives you that back. It gives you the ability to say, this one is flexible, it doesn't have a data sign to it, this card, this one is really important. We're gonna put a date right on the card and we're gonna make sure that everyone can see that it's blaringly obvious. So we don't miss that date. And everyone knows that it's being communicated. So some teams have, you know, are more date driven, they're more regulated that are in hard spaces.
Um, and that comes with some benefits and that comes with some drawbacks. Uh, you know, maybe they are, you know, 80% date driven, but that means the 20% can still be lean, right? That that means they might be able to outperform some of their competitors who are unfortunately acting a hundred percent date driven. Uh, maybe they can get it down to 70 30 in the future. Maybe there's a company who's 50 50, maybe there's a company who is, you know, 20, uh, 80. Um, you know, very few companies are a hundred percent, one or the other. I mean, I was talking to somebody from, uh, NASA's Jet Propulsion Lab about now, next, later roadmaps the other day, and they have, I mean, literally hard launch dates, uh, but now, next later type of roadmaps are possible there. So, you know, it's definitely possible to still have lean roadmap in just about any sort of environment.
Melissa:
What I love about what you just said is it's really a pragmatic approach to product management. Um, and I think it's something that people forget when we get into a lot of the dogma about how we should be operating. You know, what's, what do we call best practice? Um, sometimes these types of conversations like, you know, sometimes there are due dates, sometimes we have to do it this way. Sometimes we're, we're not gonna get everything that we actually ask for. You know, that's the reality of what we're living with in product management. And I, I think a lot of people don't think that's good product management, right? It, but to me that's just product management. Like there you have to take a pragmatic approach. Like sometimes there will be things that you prioritize differently because you have to make a sale and the company has to keep going and sometimes you get to do it exactly the way that you want it to do it, but it's, it's not so cut and dry and I love that, um, is your philosophy when we talk about this too.
And I think it brings like a really good realistic approach to road mapping. So I'm curious too from you, you know, we were talking about how's ProdPad different than product board or aha or the, all these other ones out there, and you said it's the opinionated <laugh> product management platform, which I really love. And you were, you know, you're an expert on product management, you've been doing this for a long time. You ran all these product groups, you've met product people from all over the places. When you say that you are the opinionated platform, what are the things that you're most opinionated on and how do you, how do is that come out in your product?
Janna:
Yeah, absolutely. I mean, we're the one tool that's actually designed to help you become a better product manager. So it's almost like a coach as well as a SaaS tool, right? And so what that means is, for example, we don't give you dozens of different ways of mashing up your roadmap, half of which are gonna actually hurt you down the line. We give you a couple really key views, one of which is a now, next later format that allows you to view by the order in which you're gonna solve the problems. And the other one is a now next later view, which is grouped by the objectives. So linked to your OKRs, uh, when you try to enter in something onto your roadmap, it very much focuses on what's the problem you're trying to solve? What's your hypothesis? What are your target outcomes? When you go to add an idea, it asks about the problems you're solving, what the target outcomes are, why you're trying to do this idea.
When you try to finish up an idea in there, it says, well what did you actually get outta this? So it makes it difficult to forget to do these things. It's the only tool out there that actually has a completed roadmap so that you don't just do things for the sake of doing them. It actually gives you a space to say, Hey, how did we do? Even if this didn't go well, let's mark that down so we've got this log of the decisions made, the things learned so that we can constantly improve as a product team.
Melissa:
I think that's really important. And I love that cuz I've seen a lot of other tools, you know, JIRA included. Um, were people who are not super up to speed on product management, they're just learning it. They go to, they go into another tool and then they try to like recreate it into what they need, but then it never ends up being the right tool for that situation. Um, and I think no matter what, you know, there, there's a lot of tools out there you could be using, but if you don't know how to do your job well, you're not gonna use a tool well either. So I really love that you bake a lot of that learning in there. When you're watching people get started with ProdPad or you know, get started with these types of tools, what do you see them struggle with the most?
Janna:
Yeah, I mean one of the toughest things is getting the rest of your team on board with it. So product managers, individuals get it. Um, what I find is, uh, making sure that they're getting the rest of their team on board and uh, you know, making sure that they're opening it up to the rest of their team. You just talking to somebody yesterday who, uh, loved it but was really reticent with the idea of actually making sure that, or actually sharing it with their sales people and, you know, um, actually saying, Hey, we're gonna let our salespeople add ideas to our backlog. Um, you know, one of the things that we have to uh, I guess you could say protect the, the backlog is we have a, uh, a holding place. So whenever ideas are added, they don't go straight to the backlog. They go to an unsorted area where the product manager can kind of gate keep, I guess they can look at them first and just say, okay, these ones are good, these ones are junk.
Um, and then we have some AI matching to make sure that, um, the, the, you know, finds duplicates and matches them all, all up for you. So it uh, helps on that front. Um, other times it's people who go, Hey, love it, but, uh, my boss is never gonna wanna walk away from the timeline roadmap. They think the timeline roadmap is gonna make us move faster. They wanna see those dates and you know, it's a tough argument cuz the boss often has their final say. But you know, the the truth is, is that the timeline roadmap doesn't have anything on it that a now next later roadmap can show on it, right? Like if something does have dates on it, you can put that on your now next later roadmap, you can show all the same granularity of information and even more so on an now next later roadmap and basically have your cake and eat it too. It's just a matter of getting that mindset change. And that's one of the hardest things in the world is shifting minds.
Melissa:
Yeah. What, what have you seen work well for those product managers? Cuz this is one of the biggest questions I get asked on this podcast is, you know, I really, I, you know, I heard Janna speak, I read Melissa's book, I did all the things and now I really wanna use this now next later roadmap, or I really wanna work this way, way, but my leaders, you know, they won't let me or they're really against it. What types of things have you seen, um, product managers do to help, you know, change those mindsets and open them up to the other ways of working?
Janna:
Yeah, absolutely. I mean, one of the key things to do is to speak their language. So really, uh, dive down and understand why they're acting this way, right? So, you know, maybe there's a, a reason why they are holding onto the old way working. Maybe it's because they have, uh, sold a whole bunch of work to some outsourced, you know, sales contracts and you're actually working for an agency and you're not actually working for a product company. Like, that's actually good to know. But if you dive down and ask that, you want that clarity, more often than not it's a comfort blanket for the execs, right? They have this feeling that if you're able to point out all the things that you're going to go do, then you're gonna go do your job and therefore they're doing their job by having you report in that way.
Now the reality is, is that you're not gonna be working faster or better. You're actually gonna be working slower and providing more tech debt because everyone knows that if you have to outline what you're gonna do first, you're gonna add a little bit more buffer so you're not wrong. And also if you're ending up, you know, always up against a deadline, you're gonna end up rushing things out the door and rushed work means quality gets squeezed out. This is where tech debt comes from, especially if you've got release after release after release. So talk to them about the way, talk to them, the way that they talk, talk about risk, talk about their financial drain, right? They are running this company in a way that is putting their money at risk. They are investing in this business. They've got a team who maybe costs them a couple million dollars a year and it's costing them more to get the same thing done than if they had a comp. If they had a team who was working in a lean way, that lean team would be able to deliver more and in higher quality that have less risk of rewriting in a couple years time, they'd have fewer developers leaving out of frustration that have less li risk of you leaving for lean team. So talk about the, talk to them about the things that speak to them, which is the risk and the investment and the, the, uh, the, the ROI that they're hoping to get outta the business.
Melissa:
I think that's so important. And I also think it's really powerful coming from you because you are the CEO, you are the founder, um, you are, you are that person, right? So it's like I get product, but also this is how I want people to talk to me <laugh>.
Janna:
And I wish I had this vocabulary when I was younger. Honestly, I did not call bullshit enough when I was a, a junior and a mid-level, uh, product person because I now know I could, I now can see the patterns that previous companies were falling in. I watched a company dig itself into a hole they couldn't get out of. I call it now, Um, the agency trap, you know, when companies, uh, basically are trying to be a product company and they, they hire a product team, they've got a a, the product team is designed to, or it's meant to discover the most interesting problem and any day now they're gonna, you know, take off, get that traction, that hockey stick growth. Uh, but what I discovered once I joined was that most of the time I was spending my time taking that platform and doing custom work on it and delivering it for clients that we'd signed up to. So like the month of May was sold to one client and the month of June was sold to another client and the month of July was sold to another client. So basically like all of my discovery work was outsourced to some other clients who I was just building their ideas and I didn't realize how unhealthy that was. I sort of trusted them that once we sold to one customer, we were gonna be able to just resell it to this next customer. And it never happened. Like ultimately this business tanked, it went outta business.
Melissa:
Yeah, I've seen that a lot. I actually call that, um, sales debt when I talk about sales debt, product operations and tracking it. But I, I see that so often where, you know, and I, I think it also hurts companies that are just starting to scale more than anything. Like they have that one product, um, and they might have that one really big customer or a couple big customers and they just spend all their time tweaking it for that one customer cuz they're afraid that they're gonna churn cuz it's most of their money, but they're not thinking about how do I get five or six more of those so that if that customer does churn, I never have to worry about that cause I've got all these other clients too and that's such a dangerous trap to get into. Um, yeah, but it's funny that we think about like product all day long where you're like scalable, repeatable, SaaS all this stuff and then you still end up in that trap.
Janna:
Oh yeah, exactly. Cuz at the end of the day, making money and cashing checks is addictive. Yeah, right? I mean, you know, they're, they're sitting here going, yeah, but we'll pay you or, or you could sit back and do some research and maybe, you know, in six months time you'll find a hundred other customers who might pay you, but you don't know that. Whereas if you do this, we will definitely pay you. You're like, you know, we gotta keep the lights on. It's tough.
Melissa:
Yeah. And you know what, as a, as a founder and a CEO, right, you are in that position now where you gotta make those calls <laugh>, whether you're gonna do that or not. How, how have you balanced, you know, being a founder and CEO with everything is now on the line, right? Like you are, you're the top person, you write the checks to pay the people, you take the money from the customers. How do you balance that with being a product leader and not falling into that trap? What are ways that you talk to yourself about this?
Janna:
So, um, yeah, I've been really lucky that I've had a chance to work for other companies that have made mistakes and so I've been able to learn from those and now I have a list of hard lines, like things that I know to say no to and sometimes it has been tough, it's been painful having to turn down bits of custom work or, you know, custom bits of um, uh, how we run our services or how we do things. Um, but it has meant that it has, uh, freed us up to be able to build a product that is workable for the wider audience.
Melissa:
So also in addition to that, you know, you are a product person and now you've got a team. How do you make sure that you are not just dictating down what everybody should build? Because you've got probably the most product knowledge of a lot of the people there and it could be super easy to be like, I'm gonna do this all. Um, but how do you kind of take a step back as a super product focused CEO and make sure that you're empowering the team?
Janna:
Yeah, such a good question. I mean, there was a, uh, uh, tough conversation that myself and Simon had to have at, uh, pretty early on in the, the life of the business, which was we're both product people. Which of us is gonna be CEO, which of us is gonna be CPO? And just based on our natural aptitudes, it made sense for me to be CEO and for Simon to take CPO. Um, and uh, you know, one of the best things that we did was we hired a, um, head of product who's actually better than both of us at product management, right? Somebody who's more disciplined, more, um, research focused. Uh, I've always been very intuition focused, uh, which I don't think is the best way to necessarily, um, uh, build product. I think you do need, uh, some discipline in terms of research and uh, uh, and, and that because I think we're so discovery focused these days.
Uh, and so Kirsty is a brilliant head of product and um, really helps temper my side. So what I do is I get out there and I learn times and I bring back lots of information and I am very much that excited HIPPO, right? I, I say, here's some things I've learned, uh, but it goes in as the same as any input from anybody else in the team. And so we have a list of objectives, we have a list of problems, and so it goes in with the same weight as anything else. Now, you know, what I do have is the ability to say, here's all the stuff I'm learning, I'm having all these conversations. Um, and so I make sure that that input is heard, but it gets weighted with the same as the, you know, research that she's doing. So she's, um, validating it. She's making sure that the stuff is actually checked and uh, right.
Melissa:
So I'm, I'm working with um, a bunch of different founders and CEOs recently who, uh, are pretty visionary product people, right. And I'd say they're not classically trained product people, so they know they need to have a head of product, right? So not that they've been a product manager before, but they've got deep market expertise, but they've got a lot of ideas of where the product needs to go.
Janna:
That sounds like me. Yeah.
Melissa:
Yeah, exactly right. So, and then, but they, they know they wanna be CEO so they're asking themselves, well if I hire a chief product officer, is that person going to take away all of my stuff that I like doing and, and am I no longer allowed to work with the team? Am I no longer allowed to do product stuff? As you were navigating this with Simon and you know, your head of product and everything, um, what types of things have you found allow you to, like what activities do you do with the team? What, what do you contribute that allows you to like flex your product muscle and feel like you are still involved but still give them the space to go do what they need to do? How do you balance that?
Janna:
Yeah, I mean, I get a chance to go out and talk to customers all the time. And so this is actually something I've always loved to do as I talk to prospective customers, I talk to people who don't even know that they will be customers yet. I get to get a chance to talk to product people all over the place. So I do a lot of informal discovery and I bring back those learnings. And so my input is always appreciated on that front. But then when it comes to interfacing with the product team, I do uh, weekly one to ones with <inaudible> product team. And then I also have a, uh, weekly check in with the product team where they present to me, you know, what kind things they've been working on. I also get to participate in the, uh, team wide company cycle review where they show off what kind things have been built and what kinda things are coming up and that sort of thing. Um, everyone gets to pitch in and see what kinda things are being built and kinda stuff is coming out. Uh, and so we've just got this constant cycle of, you know, inputting what we're learning. That all goes into pro naturally. Um, but also just constant chatter about um, what's being built, why, um, how we're progressing with the problems that we're trying to solve at the time
Melissa:
And how do you make sure that the feedback that you're giving and you know, the directions that you give aren't taken extremely literal <laugh>, right? Where people still have, feel like they have space to have question, like, question things and have debates. Cuz I find that sometimes really hard, especially for junior people to, to speak up and ask questions or push back and not just assume that everything that comes out of, you know, the leader's mouth is a hundred percent the way they should be going. And I've also found that, I've talked to leaders where they're like, I don't want them to do this. Like, please, like, I don't know why they're not asking me questions or pushing back like everything that comes outta my mouth doesn't mean it's necessarily good. I thought they knew that. So what do you do to encourage that healthy debate in your team?
Janna:
Yeah, absolutely. I mean there's a few things. Um, one is straight up tell them like I come in very, I try to come in very humbly and say, I don't know the answer to this. I try to tell them, you know, day one and you know, anytime we do workshops or anything like that, um, what I do and what I don't know, um, you know, that I'll, I'll be the first one to say, I dunno the answer to this, but here's some, here's my gut, um, here's a bet that I have and I use language like that. Like I'll say this is a guess. I bet that, um, my hypothesis is, um, you know, I'd love to hear your hypothesis, you know, what are some other thoughts on this? And just try to open it up to other people. Um, I'm very careful about not saying things like, this is the way it should be unless I have strong conviction that this is in fact the way it should be.
Melissa:
That's great. I think so important for a lot of leaders to hear about that too. Uh, as you've been looking at the product management domain now for quite some time, you're building tools for product managers, so you're talking to them all the time. What do you think has been changing recently, um, in the landscape of product management and what should we keep our eyes on?
Janna:
I think product management is maturing and in a really good way. So, you know, 10 years ago, 15 years ago, product managers were almost just roadmap, jockies, pr, d jockeys. We were just told to, uh, take stuff and turn it into PRDs, feed the developers and then make roadmaps to um, to please the team. And we've been getting away from that and getting more and more space to spend time in discovery and research and it's been this slow step. But I mean, even today you still see more and more, you still see more people coming in through um, uh, looking for to solve problems around roadmapping. But fundamentally where product managers are making the most impact on their team are the ones who are spending their time actually doing discovery and checking the assumptions on the roadmaps, right? The most powerful roadmaps aren't the ones that are the most beautiful, aren't the ones that are the most correct. Cause roadmap is meant to be flexible. The roadmap is kinda unimportant at the end of the day. It's the roadmap in process and what's the roadmap in process besides discovery, besides research, besides constantly having these conversations and you know, pulling in these insights from the wider team and just understanding, you know, what are all the things you could be working on and uh, you know, what do you know about these problems and what order should we be tackling these problems? And the whole thing is really just discovery more than anything else.
Melissa:
Great, definitely wise words for everybody, uh, to listen to. Your job is not to be the roadmap or PRD jockey anymore. You gotta really focus on the discovery. So thank you so much Janna, for being with us. If people wanna learn more about you or reach out, how can they find you?
Janna:
Uh, come say hello on Twitter. I'm @simplybastow there. Uh, I'll be there until the whole thing goes down. And if that does go down, I'm on Mastodon. I'm bastow at Mastodon Social, uh, I'm on LinkedIn, I'm Janna Bastow there. So easy to find there. And of course at prodpad. So I'm janna@prodpad.com. Drop me a note if you'd like a demo or a walkthrough. I'd love to chat to you.
Melissa:
I gotta get a mastedon on is it worth it? Is it good?
Janna:
It's good. You know what the engagement in Mastodon is more so than uh, Twitter and they're talking about things other than the downfall of Twitter on Mastodon. It's wonderful.
Melissa:
Fascinating. I'm gonna go do that now <laugh>. So we'll see you there.
Well, thanks so much for being with us, Janna. And for those of you listening to this episode, if you enjoyed the Product Thinking podcast, please uh, subscribe to us wherever you listen to podcasts and we would really appreciate it if you could leave us a review. Otherwise, we'll be back next Wednesday with another Dear Melissa, and if you have any questions for me, like always, please submit them to dear melissa.com and I answer them every two weeks. We'll see you next time.