Building better roadmaps | Janna Bastow (Mind the Product, ProdPad)

[00:00] The whole point about a roadmap is that it's not designed to be your plan. I think about it as being a prototype for your strategy. [00:08] What I mean by that is we talk about prototyping all the time in the lean world, and a prototype is essentially a way of checking your assumptions. [00:16] generally we think about it in terms of a design or like a model, but think about it at the strategy level. So at the [00:23] feature level, you'd prototype by doing a design, a mock-up. And you'd take that mock-up and you'd share it with somebody and say, "Here's a mock-up of the feature that I'm trying to build. What do you think?" And they tell you what's right or wrong. And you'd add some new copy or a button to make it more clear. And you'd throw out the original [00:38] prototype because it wasn't very good and you make a new one. [00:42] So the value isn't. [00:43] The. [00:44] prototype, the values in the prototyping process, the value isn't in your roadmap, the values in the roadmapping process. What you're actually doing is laying out your assumptions of the problems that you're solving. So you're saying, I think we have this problem, then this problem. [00:59] What do you think? The whole point is that you just share your early assumptions with other people on the team with customers even like anybody to listen and just check that you're on the right path. [01:11] Welcome to Lenny's podcast. I'm Lenny and my goal here is to help you get better at the craft of building and growing your own products. [01:19] I interview world-class product leaders and growth experts to learn from their hard-won experiences building and scaling today's most successful companies. Today, my guest is Jana Bastow. Jana co-founded Mind the Product, which I believe is the largest community of product people anywhere. She's also the inventor of the roadmapping framework Now, Next, Later, and the founder of Prodcat, which makes it easy for you to do your roadmapping in this new, simpler world.

[01:49] and going from product manager to founder. With that, I bring you Jana Bastow. [01:55] This episode is brought to you by Formsort, the leading low-code form builder for product teams. If you work at a startup, you've probably experienced the pain of building forms. Product managers come up with an idea for new onboarding flow, and then engineers have to build it and then maintain these flows forever. Even tiny changes to the flow can take weeks to get implemented, slowing down your team's experimentation cycle. [02:25] marketers full control over the form building life cycle. With FormSort, anyone can build highly customizable forms, implement complex logic, and send data to destinations like Postgres, BigQuery, and Segment. Companies like GoodRx, Candid, and Balance Homes build their most important forms on FormSort. Think patient intake data, surveys, and fintech onboarding. They've seen conversion rates increase by over 30% and have saved thousands of engineering hours. [02:55] improving onboarding is one of the most powerful ways to optimize activation and increase retention. Formsort makes this process as easy as possible, and it's why I'm a proud investor. You can sign up for a free account on formsort.com and use promo code LENNY for 20% off a Formsort Pro plan. [03:15] This episode is brought to you by Coda. Coda is an all-in-one doc that combines the best of documents, spreadsheets, and apps in one place. I actually use Coda every single day. It's my

[03:25] It's my home base for organizing my newsletter writing. It's where I plan my content calendar, capture my research, and write the first drafts of each and every post. It's also where I curate my private knowledge repository for paid newsletter subscribers. And it's also how I manage the workflow for this very podcast. [03:55] doc gallery, including resources for many guests on this podcast, including Shreyas, Gokul, and Shashir, the CEO of Coda. Some of the best teams out there, like Pinterest, Spotify, Square, and Uber, use Coda to run effectively and have published their templates for anyone to use. If you're ping-ponging between lots of documents and spreadsheets, make your life better and start using Coda. You can take advantage of a special limited time offer just for startups. Head over [04:25] to sign up and get a thousand dollar credit on your first statement. That's C O D A dot I O slash [04:36] Lenny to sign up [04:38] and get $1,000 in credit on your account. [04:43] Jana, welcome to the podcast. - Hi, thanks so much for having me. - It's my pleasure. Just to start off and set a little context for folks, [04:51] Could you give listeners a 55 second background on what you've [04:55] been up to you in your career?

[04:57] Yeah, absolutely. So I'm a product manager by background. I started my career falling into product management like a lot of people do accidentally. I worked my way up to be head of product at a startup in London and then saw the need for product management tools because there wasn't really anything like that out there. So I started building Prodpad, one of my co-founders who I also happened to start Mind the Product with and Mind the Product turned into the world's largest community of product managers. So I ended up founding two things at the same time and that's [05:27] decade or so. And currently you have a company, maybe just mention that before we move on, because I think it'll be important. [05:33] Yep, absolutely. So that tool that I was talking about turned into ProdPad, which is software for product people. So it's a tool that allows you to build roadmaps and do your OKRs and capture ideas from your team and feedback from your customers and just organize all your product management stuff in one space. Awesome. So you mentioned Mind the Product and Product Tank, which is kind of this associated component. I'm not exactly sure the difference, but I know they're related. One's a community component, right? Is that right? [06:03] And as someone that's building their own community around the newsletter and the podcast that I have, I'm always curious just to learn what folks have learned about building communities, especially for product people. So a question is, [06:14] And my mind is, what do you think has been most important in getting [06:18] mind the product community right early on and then also just maintaining the quality of the community? Honestly, it wasn't so much that we set out to build a community. It was that we

[06:29] got together with some product people with the idea that we didn't know what we were doing. And so we figured if we got together with some other product people and started chatting it through, we'd all learn together. And so it was just the sense of sharing and collaborating and learning from each other and just keeping it as grassroots as possible as it grew and consistency as well. Like just always being there every month, holding a product tank, every year of holding an event, and just being there whenever there was a chance to be there. So what I'm hearing is just putting in the time, [06:58] doing it consistently. I imagine a big part of it was having the right sort of people involved early on that are maybe the right exemplars of the type of community you want to build. Is that roughly right? [07:08] Yeah, absolutely. I mean, surround yourself with the people who are going to help you [07:13] continue that community and are going to help you with that consistency and going to help you surround you with more and more of the right people. You know, one of the things we learned really early on was that we only had so wide of a network. And so being able to get other people to help us curate and bring in other smart people to help find other speakers outside of our network and help find people to write on the blog when we run out of things to rant about, you know, similar to what you do, Lenny. You've got people from all over your community helping to contribute to the wider picture. [07:42] Awesome. What's the scale of the community at this point? That's a good question. I don't have the exact number. What you might not know or what you might know is that mine, the product was actually sold earlier this year. So I don't have a handle on the exact numbers now. And it did go in flux when COVID hit. I know at one point in time, the product tank was like 200, going on almost 300 cities around the world. I don't know what that number is today. I know that it sort of went up and then down and then back up again. Some of those are digital

[08:12] of product people around the world who are taking part in the community in one way, shape, or form, or the other. And of course, people take part in the big conferences as well. [08:21] I imagine there were some mistakes that you made along the way building this community. Is there anything that stands out as, oh man, we shouldn't have done that for folks that are thinking about building communities these days? [08:32] When running a conference, it's one of the most expensive and unleanest things you can possibly do. It's really difficult as a product person to pull that off because it pulls at your part. You want to do something that's iterative, but you can't. If something screws up with the lunch order, for example, you can't fix it. You have to wait until the next year and you just have to pull out whatever you can to make it good enough for that particular year. There was a year once when we ordered food and it didn't turn out to be enough because the caterer is underdelivered. [09:02] and we ended up having to [09:04] get all of volunteers to go to the local sandwich shops and buy all the food up and bring it in. Stuff like that, that was difficult at the time, but we made do with what we could. And we ended up sending cash cards to our attendees saying, "Here, let's make it up to you." Stuff like that, that just becomes logistically really, really difficult when you're just thinking, "Oh, we just pay [09:25] supplier and they make it happen. It's not that simple. Got it. Okay. That's a plus one for me to never run a conference. Something I never want to do. [09:34] And this is a reminder of all the pain that goes into it. [09:38] Conferences are ridiculously hard. I mean, the thing that I've learned is when something goes wrong in a conference, it doesn't happen in the hundreds of dollars of cost, it happens in the thousands of dollars of cost. A speaker who decides they can't make it for one reason or the other, totally legitimate reason, sure, but you've already paid for their flights and their business class flights. And so you've got to find another speaker last minute and get them over. That's thousands of pounds in the hole. It could be things like the printing went wrong and you found out the day

[10:08] dollars gone. There's lots of things that could go wrong. Our venue once went bust, the after party venue once went bust three weeks before the conference. That was year one. Super. You know, all of these things. Yeah, that's what we said. Super, what are we supposed to do? We ended up having to just make do and found somewhere else and roll with it. So lots of things that go wrong at that sort of level. But the thing is that we built up a lot of goodwill with the community and were able to get help from people around us, get suggestions from [10:38] And things ended up like, actually, it turns out we ended up with a smaller venue than we expected, or this was slightly different or whatever else. We had people forgive us, right? It worked out okay in our favor. Just following this topic, I'm most curious, are conferences like a good business? Do they make a ton of... [10:53] money in some occasions? Is it always just like super thin margin? How does that even business work? It's not for the faint hearted. It's hugely risky. In hindsight, I'm highly surprised we actually made it through some of those first ones. If you can do it, there are some amazing [11:10] ways that you can monetize them, but it only starts making a difference at larger figures. And it takes a lot of effort to actually get to that point. Somebody once asked me like, "Oh, we're struggling to sell tickets. How do you sell all those tickets?" Well, start a community, [11:23] several years before and invite people and run a thing, some sort of community meetup every month. [11:30] time and time again beforehand, and that's your marketing. If you undersell tickets to a conference, for example, it can absolutely break it. And you see sometimes conferences, they run one and they don't have enough people turning up and it's gone. That can just be

[11:44] break it. It's ridiculous. Something like COVID comes by and it can break it. It's a ridiculously hard business. It's really hard to insure against. It's really hard to think of all the things that could go wrong and protect against. So while there are some upsides, it's not for the faint-hearted. Okay, cool. That's another plus one. I have a friend who runs events here in San Francisco, and I'm always just like, how can someone be excited about running events over and over? It's so [12:14] fun at these things. So it's always a different personality. Yeah. Event organizer or event manager or something like that was once listed as one of the most stressful jobs out there. And you can see why. It's because it all just lands on you all at once. And once the event is over, there's some sense of ennui, as in like, it's over. And now, [12:31] Like now what the next day you're just like, hey, like, [12:34] can look at the tweets, everything that happened, you can look back at the photos and then you're like, what do we do next? Start prepping for next year. Start prepping for next year. Off we go again. And it's really hard work. Yeah. But there again, product management was also listed as one of the toughest jobs, one of the hardest jobs out there. I'm not sure if that still stands, but I know product management as it stood 10 years ago, 5, 10 years ago, certainly did have a different vibe to it and was a really tough job. Continues to be a very tough job. On the topic of conferences and speaking, [13:04] before we started chatting today. And a couple of things I noticed. One is you're just an awesome speaker and you're an awesome storyteller. And something that comes up a lot on this podcast is just how important communication skills are to product leaders and product managers and storytelling. And you've also seen a bunch of people do awesome talks at these conferences. So I'm just curious,

[13:24] Whatever you have in mind, what has helped you become a better speaker and storyteller? And then also, what have you seen is important to folks that are really good at storytelling and presenting at a conference, let's say? [13:37] Right. Yeah, such a good question. I mean, I have learned by watching a lot of other people. One of the things that I have been super lucky in my career is that by being part of Mind the Product, I've gotten to watch every last Mind the Product speaker, top-end speakers. I've been able to see every Product Tank London speaker and a lot of the other Product Tank speakers around the world. We don't see what people react to, what works, what doesn't work. So I've been able to [14:07] But also one of the things that Mind the Product has been able to provide to speakers is a speaker coach. So when I was invited to speak on Mind the Product stage in 2017, one of the things that they provided to me was an actual speaker coach, somebody to take my talk and improve on it. And it was really nerve wracking taking my half written talk, which I started months and months before. It started off with just [14:30] post-it notes scattered along the wall, which I tried to turn into something. And I think it was probably six hours worth of content. And I brought this to the speaker coach, and I had a vague script idea of what I wanted to say. [14:43] And she said to me, one of the first things, she said, "Well, I've taken your script and I've, you know, I've turned it around, I've rewritten the jokes to land a little bit better. [14:50] I was like, that's great. I had jokes. And she helped turn the stories around so that they carried through. She helped with posture. She helped with delivery. She helped with even just phrasing of words, just making sure that everything landed in particular ways. And one of the things she did was make me

[15:11] listen to it and play it back, which I had not done before. And I still hate doing to this day, but I'm now more used to it than before. And I don't think anybody likes listening to the sound of their own voice. I don't think anybody likes doing that, but it does help with it, with you got a large presentation, a big presentation, and you've got to get up to that [15:29] level. If you're nervous about doing in front of 1000 people, then getting to that level that you're actually willing to [15:36] able to hear yourself do it and you're able to do the talk flawlessly in the shower and as you're walking to work and as you're doing your groceries and all that sort of stuff, then it makes a big difference. So one tactic that I love that you shared is record yourself, watch yourself. [15:51] keep refining, but watching your actual performance. Looking back at the lessons your coach taught you, [15:58] for new presentations that you do. Is there anything else that sticks with you? Just let's make sure to get XYZ. [16:03] nailed because that'll help make this talk better. [16:06] One of the things that I've stopped doing is I used to sit down with a PowerPoint. [16:12] and start writing my deck in PowerPoint for slides now. What I now do is I start with my story points. I start with my narratives. I try to figure out what I'm actually trying to say, and then I fit it into the deck. [16:29] Because what I was doing before, I'd get stuck in this mode of the presentation mode and trying to make the presentation, the slides fit my narrative as opposed to the opposite way around, having a great narrative and that slides should follow more naturally.

[16:43] What about just like the presenting, the physical anxiety of presenting? Is there anything you've done there to get better with that and get more comfortable? So one of the things that actually really does work is the power pose standing with your hands on your hips. And it really does, I'm not sure if it's adrenaline or endorphins or something, it releases some sort of chemicals. That really does just help boost your confidence and make you feel better as you're getting ready to stand on stage. It's something that me and other Mind the Product speakers, and I've done [17:13] just that I've done in recent years, stand there with your hands on your hips and just feel [17:19] better about it as opposed to sitting there falling up in that that tenth pile of stress. One of the other things that I always do if I get a chance to is get out onto the stage sooner rather than later. So when they do the tech check, just walk out onto the stage and just wander back and forth and look out to the audience and greet it. There's no one there, it's the day before, it's completely empty, but look up at the audience and just enjoy that sweep [17:49] that doesn't matter, but just imagine them there so that when you actually do see them the next day, [17:55] It's not so stressful. One of the other things I try to do is find the people in the audience who are your fans. And you'll find them in the course of your talk. There's always going to be some people in the audience who just look forward and they're on your phone. Just ignore them. They're always going to be there. Find the people who are nodding along and smiling and going, "Yeah, that's me. That's me." And just speak to them. And if you find one up there, one over there, one down there, no one's going to notice that you're doing your talk just to them. And just keep delivering your

[18:25] people. They're having a great time, you're having a great time, and you're doing a great talk as a result. [18:29] That's such a good advice. The power pose piece, you said that it's like hands on hips. I think there's also like when we raise your hands up and you're like Superman or something. I think, that could work. Yeah. Yeah. I think people do different ones. Also, I've seen that there's like all the science that showed that was effective. And I think it was one of those experiments that wasn't replicatable. People are kind of like worried that there's not real science backing that up. But I've done that myself and it actually works. And so it doesn't matter if it works for [18:59] Honestly, I feel better at the end of it and get on stage and do a better job. [19:03] Yeah, placebo is like someone made this point. Placebo is this magical thing that we have in our brains that. [19:08] gets things to change by not having anything go. You just change things. It's amazing. It's magical. Yeah. Placebos are as effective as the actual drug, whatever. I'm happy with the placebo. Just don't break the placebo effect for me. That'll be fine. Right. Yeah. That's right. One last question on the speaking stuff. How bad were you initially [19:29] Just because folks probably see you, see Simmery talks and they're like, "Oh my God, I'm never going to be this good. I'm screwed." I used to be shaky little fawn, shaky voice, terrified at the front. Okay, so it was one of the first ever product camp events that we were running. And the first one I think I did okay at, but it was a smaller group. It was only like 50 or so people. And the second one, it had ballooned to 200 people. Like this is more product people than I'd ever known. And they were all super professional and they're all looking at me.

[19:59] And I stood at the front of this group and I was supposed to just tell them what they're supposed to be doing that day. And I had a little half written down. [20:07] And I started talking and then I sort of just tripped up over what I was saying and forgot everything and blanked. And I just looked up and I went. [20:16] I'm really sorry, everybody. I'm just going to start again. [20:19] And I started again. I said, hi, everybody. I'm Jana. Welcome to Product Camp. [20:22] And I just started again and they were just totally fine with it. Honestly, it was fine. And this is the thing that I've learned since then is people in the audience are rooting for you. They were totally cool with this. They didn't think anything of it and they just rolled with it as did I. And so whenever I see somebody who's struggling on stage, just give them a nod, a smile, clap them along, give them reassuring looks and hopefully they'll just pull through. And if you ever feel like you're shaking, you're [20:51] corpsing on stage, you're falling apart. Honestly, just take a deep breath and just pick up where you last remembered you were and just keep going. Honestly, no one is rooting for you to fall over and have a bad time. Everyone's rooting for you to [21:03] Finish your point and get on with it. [21:05] That's such a great story, and it's a good example of [21:08] People have this fear of the worst case scenario. Everything's going to fall apart. They're going to be seen as idiots. They don't know what they're doing. It's all going to be revealed on stage because you screw up in how you're talking. [21:21] The worst case scenario never happens in my experience. And two, if it does, like, [21:25] just yeah just do exactly what you said just try to start again it's easy to say hard to do this isn't like a conscious

[21:32] thing that people can get over. It's like your body's just doing crazy shit and you're like so nervous and just rationalize it to like, no, it'll be fine. But yeah, [21:41] But yeah, I find to your point, people want you to be awesome and succeed. They're not there to like, huh, you you stopped, you screwed up. [21:47] And it's humanizing when you screw up, right? People don't like people who are perfectly perfect and don't mess up and it makes them feel like they can't go up and go do their talk. I mean, I think that right there showed everybody else that they could go up on the little product tank stages, started the product camp. [22:04] stages that day and go do their own talks and they certainly wouldn't be any worse than that. Like as long as they just remembered their name, they'd be fine. Crack on. [22:11] They got it. Speaking of screwing up, you have some very spicy takes on road mapping and roadmaps. [22:17] Yes, I do. And generally, like the mistakes people make in organizing the roadmap. So I definitely want to spend some time here. So first of all, you have some strong feelings against Gantt based roadmapping. Can you talk about that? Yeah, sure. I used to do timeline roadmapping. The first version of ProdPad was actually a timeline roadmap. So let's take you back. [22:39] When I was a junior product manager, mid-level product manager, I used to do my roadmap like everyone else was doing the roadmap. As in, I looked up what a roadmap was and it looked like a colorful Gantt chart. I knew what a Gantt chart was, and so I started putting one together, which is where I'd take the features that I was working on and line them up against the due dates. And I would get a little pat on the head from my boss and they'd say, [23:02] good job, now go deliver it, basically. And I would do my best with delivery. And I'd never quite be able to deliver everything. Something would always get in the way. But I sort of assumed that was my fault. I just wasn't great at delivery. And I just had to get a little bit better at adding enough buffer and setting expectations and doing a roadmap slightly better. But I figured that this is how everyone is doing the roadmaps. And it was just me who wasn't finishing the stuff on the roadmap by right. And when it came to creating the first

[23:32] roadmap, I'd envisioned something that would actually help me manage this format of a roadmap more easily, which I ended up creating the very early version of ProdPad, which was a digitized version of this where you could drag and drop ideas onto the roadmap and stretch and squeeze them and pan the roadmap back and forth. And I shared this with some early product people that I knew, some early users, and they gave me some feedback and some of them absolutely loved it. They're like, "Yeah, this is great. Now I can stop using PowerPoints or [24:00] whatever tool I'm using or drawing it up in whatever, I can now start using this digitized tool. But one of the things that we started hearing from early customers is about a month later, they said, "Great, but I want to take [24:13] this and move all these things here over. [24:16] Why a month? [24:18] in the field. [24:19] Like, oh, that's interesting. We've heard that from a bunch of other people too. [24:22] Now, why is that? Because had we just asked our customers, have we just built what our customers wanted, we would have just ended up with a multi-select drag and drop. But this was all built in jQuery and it was a little bit difficult to build that. So we sort of asked the five whys. We dug in to why people wanted this thing. We found out that no one was actually delivering the roadmap. [24:42] in the timeframe that they were saying they were. So we're like, "Wait, if it's not just us who's not living the road map and none of these [24:48] better than us roadmap. Product managers are building the roadmap on time. [24:52] what's the point of a roadmap? Why are we giving them a roadmap? So that's when we sat down, as myself and Simon, my co-founder at ProdPad, and we sat down and we came up with a

[25:02] three column roadmap. [25:04] current near-term future, which became now, next, later. And it [25:09] took away the simple concept of a timeline at the top. [25:14] Now, the problem with the timeline, [25:16] is that as soon as you have a timeline, it turns it into a math chart sort of thing, right? Where you've got time on the x-axis and things to do on the y-axis. And you basically end up with [25:28] everything underneath is assigned a due date or a duration. And it seems that everything that you do has a due date or duration just by the format of the roadmap, which is painful. This is wrong because we don't have that. The further out you plan, the more you're making it up. We know this. And so we wanted more flexibility and we knew that other product managers wanted that flexibility because we kept asking what they were up to. So we decided to break it down into these three buckets [25:58] It became this first bump in our usage of broadband because people went, "Oh, wait, I can just say what's happening now, what's happening next, what's happening later. And if I want to, I can add a date to the specific thing, but I don't have to. And I can be less and less granular about that as I go forward." [26:17] Yeah. So it's taking from the concept of the cone of uncertainty, taking from the idea that [26:23] things get less certain as they get further away which is you know [26:27] kind of how reality works. So the whole beef with the timeline roadmap is just taking apart the concept of the timeline. It doesn't mean we live in la-la land. It doesn't mean that we don't believe in having dates on the roadmap if there is a date that we have to work towards. It just means not penalizing ourselves by having a date on everything on the roadmap.

[26:48] Got it. Okay. I didn't know that you could put dates on some of the things. That's interesting, because I was trying to understand exactly how this approach works. We should also mention you came up with this whole idea of now, next, later, which a lot of people use now. Is that right? [27:01] Yeah. [27:02] Awesome. Okay, so as someone that's been using GAM timelines his whole career, I'm really curious to dig into these ideas and challenge the default assumption. I'm excited to chat with my friend John Cutler from podcast sponsor Amplitude. Hey, John. Hey, Lenny. Excited to be here. John, give us a behind-the-scenes at Amplitude. When most people think of Amplitude, they think of product analytics. But now you're getting into experimentation and you even just launched a CDP. What's the thought process there? [27:32] supporting the full product loop. Think collect data, inform bets, ship experiments, and learn. That's the heart of growth to us. So the big aha was seeing how many customers were using Amplitude to analyze experiments, use segments for outreach, and send data to other destinations. Experiment in CDP came out of listening to and observing our customers. [27:50] Supporting growth and learning has always been Amplitude's core focus, right? Yeah. So Amplitude tries to meet customers where they are. We just launch starter templates and have a great scholarship program for startups. There's never been a more important time for growing. Absolutely agree. Thanks for joining us, John, and head to Amplitude.com to get started. [28:09] There's two questions that this brings up, and you may have answered them in part. One is just without dates on things, how do you... [28:17] make sure marketing and sales and your CEO has things that they need for promising and or at least giving a sense of when a product will come out. And the other is just aligning internally with like engineers design being done on a certain date, engineers being done on a certain date, PMs being done on a certain data science. How do you deal with those in this format?

[28:35] Yeah. So there's a couple ways that you can turn that around. So one is you should still be having regular communication so they can still see what's coming up in the now column. So they have a sense of what the order of things are and that things that are in the now column are probably weeks away, not months and months away. You should probably have launch readiness meetings so people understand like this is the stuff that's going through testing and that's likely to be coming out now. But one of the other things that you can be doing for your marketing and sales teams is [29:05] So, you know, what you should be doing is basically saying your developers are able to launch something on a particular date and it's the date that's convenient for them. Right. Let's say they think that they can get something out for end of September. Now, that might be pushed to mid-October because things go wrong. Now, at that point, whether it's end of September or mid-October, it doesn't really matter to the marketers because they're busy talking about the stuff that was launched in August. Right. [29:35] link. [29:35] and marketing the stuff that's already live and out there. [29:39] When this new thing comes out, that's a soft launch. As soon as that soft launch is out, great, let's kick off this launch meeting, launch steps. Now you've got something else to go do. And it's so much better for marketing anyways because [29:53] They're not setting up their launch steps based on something that they don't have eyes on. There's nothing worse than the marketers trying to market something based on pictures from the designers that have vastly changed by the time they go out or that they don't know whether it's going to come out on the right day or not. So they've actually got a functional working version that they can share with some customers. They can start getting...

[30:13] you know, videos of it working. They can get testimonials from early beta users. And then they can spend, you know, whether it's two days or six days or six weeks or six months, planning the biggest, bangest launch they want. [30:29] they can then spend the next however long they want to launch their hard launch. And then, [30:35] that goes out. And in that period that they're doing that hard launch, [30:38] development is cracking on with their next thing. And by the time that they're done that, marketing is then, "Okay, great. What have you built? We're ready to work on the next thing." So you're just separating soft launch from hard launch so that you don't have this stress of trying to line up [30:51] two completely different types of projects, your marketing projects and your development projects, which is where a lot of those things fall apart. [30:58] Got it. So kind of the basic premise is roadmaps with timelines. [31:03] sound great and awesome. Everyone would love to know when things are going to be done. And if it [31:10] They're all made up. They don't work. You don't hit deadlines. They're always missed. So instead of [31:15] Promising. [31:16] dates for everything you're doing. [31:18] You're better off. [31:19] Generally just giving a sense of like, here's what we're going to work on now. Here's what's coming up next. And then for the things that really need a date. [31:25] We're going to put dates on those things and give it our best shot. [31:27] Is that true? Yeah. [31:29] Yeah, that's absolutely right. If something does have to have a date, we don't live in la-la land, something has a regulatory date. When GDPR came down, everyone had a due date on the roadmap, because if you didn't hit that date, then you were going to be in trouble. Sometimes you might have dates that are tied to things like the Christmas rush or to, if you're in education, it might be like, has to be out by the school year. At which point, in order to reach something by that date, you have to put in more project planning work, as in you have to plan out ahead

[31:59] buffer time to do that. And generally you have to plan to get that thing done well before [32:04] so that you can have a soft launch before and make sure it works and do some iteration and fix it before the actual full-on launch happens. Because if you leave it too late, [32:13] it's going to go wrong and you're going to miss the deadline. If you did that for all of your launches, [32:18] you're just going to end up either cutting quality because everything's just going to be big crap because you're going to be pushing it out the door last minute, or you're just going to end up spending so much time trying to plan things to the nth degree that you're just going to move super slow. This is why you end up with teams who are really big, [32:35] but can't deliver worth anything, right? Where compared to these tiny teams who are just out delivering them and just spinning things out the door, they're the ones who aren't spending all their time going, "Are we certain this is going to deliver? And how many hours is this going to take you? And let me go talk to this person, find out how many days it's going to take him." And back and forth and back and forth. They're just building and it goes faster. I love to pull on that thread. I was thinking about the fact that you're building software for [33:05] And you've seen a lot of product teams, a lot more than a lot of other folks. And so I was curious, what percentage of teams that you see are what you'd call top-notch [33:16] highly functional product teams. [33:18] That's a good question. I don't think I've got an answer there because it's going to be biased because we naturally attract companies who self-select our way of working. We put on our sites, like no timelines, come for the now, next, later. So it's going to be a much higher percentage. People don't sign up for demos with us if they know that they want a timeline nowadays to make it really clear. So I would say like 70% of them are like, we want now, next, later. And I know that's not real. I know that's not the real state of people, of product teams out there.

[33:48] So yeah, that makes sense. I do have a sense that it's increasing. So what I have found is like years ago when we first started this thing off, no one was talking this way. It was a whole new concept of people like, no, this is crazy talk. You can't do it this way. And over the years, it has just become the natural way that people are working on it. People are going, of course, this is the way that it works. Why would it work any other way? It's becoming the expected way. Definitely changed the discourse and changed the expectations of the audience, I guess. [34:13] Putting the now, next, later piece to the side for one moment, I'm curious, what else have you seen separates the best product teams from mediocre product teams in terms of how they execute, the people they hire, processes? Is there anything else that you've noticed of just like this team? When I think of teams that are functioning super well, other than implementing this process you're recommending, is there anything else that often comes up? [34:37] Yeah, a couple of things. A focus on discovery. So this ability to spend time in discovery and asking questions of customers and constantly being able to iterate based on that and psychological safety. [34:49] So teams who are able to question each other, speak up when they see that things are wrong, question what's going on at the senior level, question what's going on at different team levels, and generally just have a good sense of what's going on across their business because they're allowed to ask those questions. Less silo teams. [35:05] What's a lasting change that [35:07] a team has made that made them significantly better at building product is it these two things doing more discovery and maybe more safety i imagine part of your answer will be implementing this way of working up now next later is there anything else that

[35:20] comes to mind, wow, this one team did this one thing and it made things so much better for them. Like retrospectives. [35:26] Retrospectives make such a big difference because they are indicative of psychological safety. [35:32] which underpins so much, right? Once you start building in this psychological safety, the ability to ask questions and to start saying, "What are we doing that's working? What are we doing that's not working? Okay, determine that something doesn't work. Are we allowed to go change it?" [35:48] "Okay, we are allowed to go change it. Okay, this is a team who's now changing their situation. They're talking to each other, they're learning from each other, and they're making a concerted effort to do so." And so these are the teams who are constantly learning, iterating, and moving forward. And they naturally move towards things like now, next, later. They naturally move towards things like doing discovery because these are just, I don't know, they're kind of common sense. They're not setting in stone expectations of what's going to be done and when, because that was really only done [36:18] head honcho wanted to see that information. That wasn't psychological safety. That was somebody pinning them down by the neck saying, tell me what's going to be done and when. [36:26] you know, psychological safety is just saying, "Hey, tell me as much information as you know, [36:30] and then do discovery to learn as much as you can so that we can move forward with this. You know, it's all about just talking to your teammates and getting the most information as you can from the resources you have, making the most of the collective intelligence that you have within your company. [36:46] Coming back to the now, next, later approach, you're often doing something really hard at companies, which is changing their way of working and changing their product culture. And

[36:56] I'm curious what you learned about what it takes to change [36:59] product development culture and product culture and the way of working at larger companies. [37:04] Larger companies are [37:06] tough. They're tougher, right? I think of culture, [37:10] as calcification. So calcification being the limestone that is built up as water run over and that sort of thing. And in order to fix it, you can kind of chip it off over time. You can't just [37:23] fix it all in one go. And so in order to fix it, you've got to chip away at it. You've got to find a small pocket somewhere. [37:32] you've got to make use of the tools that you've got. So sometimes it might be finding a small subset of the company and saying, "Hey, here's the startup lab within the business. Let's let them run off and go do something." Because changing the mindset of the whole company is [37:47] just too difficult right it's set in stone and it's stuck where it is and can't change them all at once but we can change this one little [37:54] space right here because we've got a shithot leader who knows what they're doing. We can take this pocket of people and go do something here and then they're going to teach the rest of the company. They're going to teach this section and then this section and then this section. You don't have to go and change the whole company all at once, but it does take buy-in from above. And sometimes that can be really difficult to take because the incentives from above are often misaligned with the incentives that it takes to get a company moving in this direction. [38:21] Ultimately, a lot of these larger companies that are incentivized [38:24] to keep the company as stable as possible, to keep the company just growing quarter on quarter.

[38:30] which is great for the stock market. [38:34] right? They love that stability. They love that quarter-on-quarter growth. But if the company is actually under threat from [38:41] startups, right? If you're a big bank, [38:44] you're in health tech, something like that, you'll certainly have startups nipping at your heels. And the reality is that you probably have enough cash to make it for [38:53] the next 20 years or so. But over time, it's going to get bitten away at and you've got smaller startups who are going to take the juicier, more interesting parts of your business and leave you with the tougher parts of your business. [39:06] Take HSBC versus all the companies who are coming up with, I've got a Starling account here and I've got a mortgage with somebody else and I've got your savings account somewhere else. You've got all these smaller startups nipping at their heels. These companies are going to nip away at these larger businesses and if these larger companies don't actually do something with it, they're actually going to end up losing this ability to innovate themselves. And so these companies are essentially stuck in this pattern where they want to continue [39:36] and yet they're not going to. They're going to end up not being willing to take the dip to move upwards. [39:42] What's the biggest company that you've [39:45] implemented this new way of building. [39:47] And is that how you approached it? You found a team within the larger company? [39:51] To roll out because you had a framework. [39:54] Yeah, so that's how it generally works with the way that we work with our enterprise rollouts. It's like we've worked with large enterprises, governments as well. It generally starts with an advocate, somebody who gets the way that we're working, a division, a department, and then it starts from there. Sometimes what we'll find is that we'll get one or two, sometimes three or four,

[40:14] mini group starting, and then they'll start banding together and saying, "Hey, no, we're starting a thing here." Once that starts happening, it's easier to start that conversation saying, "Okay, yeah, we've got a whole thing going here. Let's talk to the person who is the VP of strategy or who owns the tech area, and then we can have a bigger conversation." [40:33] What's the impact that you saw at that company having taken on this new... [40:37] way of building product. [40:39] So we're in the middle of a key tool in the middle of transformations right now, which is fascinating to see. These are multi-year pieces of work where you're seeing it being used for ongoing products that are being used and delivered as we speak, as well as like, [40:56] part of a mindset shift within the business. Because one of the things about Broadbent, [41:01] is that it's not just a tool to help you deliver products. It's actually a tool that helps you become a better product manager. It sets in stone better product management practices. Once you start using it, it makes it difficult to go back to bad product management practices. When you create a roadmap in ProdPad, [41:18] it makes difficult to add, [41:20] features and dates to the roadmap. It makes it difficult to make a timeline based roadmap. It makes it difficult to add ideas to the backlog that are not thought through because it asks questions, thoughtful questions like, "What problem does this solve? And why would you want to solve it? And what are the outcomes? And what did you get?" It makes it difficult to fall into a build trap with just saying, "Here's stuff to build and we built it and move on to the next thing," like a lot of dev tools are designed to do because it has spaces in there to say, "Did you measure

[41:50] thing is completed. What was the outcome of it? [41:52] So by creating all these spaces, it creates all these reminders for the team to go back and think about this stuff before they do work and after they do work. So it actually actively helps them become better product teams and more cognizant of this sort of work. [42:05] If someone wanted to experiment with now, next, later, what would be a good place to go and just start to play around with it? [42:11] I mean, you can start a free trial in ProdPad. You can start playing around with it. We even have a sandbox mode. You just go to sandbox.prodpad.com where it's got example versions of roadmaps, best practice roadmaps that you can just start playing with. [42:23] You don't even need a login or a credit card. It's got OKRs and roadmaps and ideas and experiments, feedback. You see how it all sort of fits together. But honestly, a Now, Next, Later roadmap can be done with post-it notes on the wall. It's just about saying, [42:37] What? [42:38] problems do you have? [42:40] Let's lay them out in order and just check them with other people. So the whole point about a roadmap is that it's not designed to be your plan. I think about it as being a prototype for your strategy. What I mean by that is we talk about prototyping all the time in the lean world, and a prototype is essentially a way of checking your assumptions. [43:01] Generally, we think about it in terms of a design or like a model, but think about it at the strategy level. So at the feature level, you'd prototype by doing a design, a mock-up, and you'd take that mock-up and you'd share it with somebody and say, "Here's a mock-up of the feature that I'm trying to build. What do you think?" And they tell you what's right or wrong, and you'd add some new copy or button to make it more clear, and you'd throw out the original

[43:24] prototype because it wasn't very good and you make a new one. [43:27] So the value isn't [43:29] The. [43:29] prototype, the values in the prototyping process, the value isn't in your roadmap, the values in the roadmapping process, what you're actually doing is laying out your assumptions of the problems that you're solving. So you're saying, I think we have this problem, then this problem. [43:44] What do you think? The whole point is that you just share your early assumptions with other people on the team, with customers, even like anybody to listen and just check that you're on the right path. [43:54] And if they say, [43:55] Oh. [43:56] "Actually, I thought that it was going to go this way, this way, then this way, or that way, then the other way. And what about this problem?" You've actually learned something. You can adjust your prototype for your strategy. You can adjust your roadmap there, and your roadmap all of a sudden becomes stronger, becomes better there. [44:11] For folks that are listening and they're just like, nah, this is never going to work, where [44:15] I work. It's just like too out there, too radical, no deadlines. That's crazy. I know you're not saying no deadlines, but less deadlines. What are like the [44:24] most powerful three bullet points you could share with listeners are just like, here's why you should have confidence. This might actually work at your company. [44:32] Other teams are already working this way. Product people are the only ones who seem to be pinned down to be required to give concrete dates as to when things are going to be delivered in this way. Your sales team, [44:44] isn't asked to give exact delivery dates on their work. They work in a very experimentation-led way as well. Your VP sales or VP revenue or whoever doesn't go to a board meeting and say, "We're going to close the Acme deal at the end of October for a million pounds."

[45:01] They don't know that. What they do know is that they have a process by which they're going to fill a pipeline [45:09] And almost certainly, they're going to be able to close a million pounds worth of or a million dollars worth of sales, but they can't tell you who it's going to come from or how that's going to work. What they're going to say is, "Give me a quarter million dollars worth of investment into my team, which I'm going to spend that on my account executives, my sales team." They're going to pick up the phone and do a bunch of calls. Think of these calls as experiments. These calls, some of them are going to work, some of them are going to fail. [45:36] They don't know which ones are going to work and which ones are going to fail. What they do know is that by using a script and by picking up the phone and calling people, some are going to work. And by the end of the quarter, someone's going to buy. And they know this because last quarter, someone bought. And the quarter before that, someone bought. They just don't know who's going to buy. If they did know who was going to buy, then they would just call those people and not everybody else. Same thing. You're not asking for any more leeway than your sales team. [46:06] investment and you're going to spend it on your team who's going to run experiments. It's going to be trying this change on the interface or that tweak to the pricing or that change to the positioning or whatever you're going to do. Some of these experiments are going to fail and some are going to succeed. You don't know which ones, but that's okay. You know that by the end of the quarter, enough are going to succeed that you're probably going to move the right numbers in the right direction. [46:30] So you're not asking for any more leeway than your salesperson. What you should be able to do is point at how many experiments you ran the previous quarter and what numbers moved in the right direction. You should be accountable for your experiments and how you're spending the money and what you're doing. But you shouldn't be accountable for saying,

[46:48] What's [46:49] is going to work before you know it's going to work yet. And that's the problem with this timeline delivery magic 8-ball that we're asked to give. I like that. [46:59] Two last questions before we get to a very exciting lightning round, which I didn't tell you about. We'll see how it goes. So one is you have an interesting framework for coming up with a product vision. And I don't know if you have this in your head loaded up, but I'm curious how you think about coming up with a product vision. You have this like really handy little framework and vision is always this. [47:19] thing that people are like, man, how do I come up with a vision? How do I phrase a vision? How do I even visualize my team's mission? Can you share that with us if you have that in your head? [47:30] The product vision template, you might actually recognize it from the Jeffrey Moore's Crossing the Chasm book. It's the elevator pitch template, but I like it because it answers the same sort of questions that you need to answer for a product vision template. So it asks things like for your target customer, who the statement of need or the opportunity, the [47:52] Product name is a product category. What's the reason to buy? And then say, unlike this alternative, our product, and then say what the statement of differentiation is. [48:04] So it's actually a template that we have available on our site, and you can actually sell out as part of our product canvas in BroadPad. So happy to share that link with you so you can link it up and send it to your audience here, Lenny. [48:17] Cool. Yeah, we'll put that in the show notes. I think that's the same framework as the positioning exercise. I might be wrong, but if so, that's cool. So basically, you could use your positioning work to help figure out your vision. And just like a vision, it's basically a vision statement. It's not necessarily the vision for your product. It's just kind of how you think about where it's going to go.

[48:35] Yeah. Okay, cool. Last question. You were a PM, now your founder. [48:39] So you moved from PM to founder. And a lot of PMs imagine being founders someday. I'm curious if you have any advice for folks that are currently PMs that may want to be founders in the future. What do you think they should be working on, focusing on skills, they should be building things they should be doing to help them in that future career? [48:58] Being a PM actually provides you with a lot of the skills and background to be a founder, to be a CEO. It gives you a lot of chance to work with a lot of the different teams and see a lot of the underpinnings of how business works. I was really lucky in previous roles where I got to work very closely with leadership in a few different roles before I took the step up to take on my own thing. So I felt as if I'd seen it in a few different ways, done well and done badly. [49:28] And so I got a chance to sort of say, "I think I could do this." Yeah, go on. One of the things that struck me is, [49:34] it's not as hard as it looks and it's also harder than it looks. There's things that [49:41] you get started and you go, "Oh, [49:43] no one's going to stop you from doing this, right? You've got lots of leeway, you can just do it. And you've got lots of freedom to run your business how you want to do it. There's lots of [49:53] resource out there. As long as you surround yourself with people, you're always going to be able to find people to advise you and to help you along the way. And there's always going to be bumps, [50:03] You don't know what they're going to be yet. There's always going to be things that are going to come by and sideswipe you, but that's always the case that you had when you were a product manager as well. Just be ready for those and be ready to take it on the chin and deal with them as they come.

[50:17] The best thing you can do is surround yourself with people so that you've got somebody to go to for each thing going, "Oh, when I run into a problem that has to do with this, I can talk to this person. When I run into a problem that has to do with this, I talk to one of these people." And figure it out as you go. Take each thing a day at a time, [50:33] Certainly don't stop yourself from starting a business or starting your own thing. [50:38] Just because you don't think that you know how to do it yet, you will figure it out as you go ahead. People less capable than you have figured it out. [50:46] Awesome. Okay, we've reached our lightning round. The way it's going to work, I'm going to ask you five questions real quick, whatever comes to mind. [50:54] Share an answer. [50:55] Nothing up to mind. It's also cool. Sound good. What are two or three books that you've most recommended to other people, whether they're product leaders or just generally? [51:05] R to profitability. [51:07] I thought was a really good one. What's a favorite recent movie or TV show that you watched? [51:13] Oh, Sandman. Ooh. And that's like a British show, right? Oh, it is British. Yes. Neil Gaiman. Yeah, very good. [51:20] Definitely not for children, thought it might be, definitely not. [51:24] Noted. What's another favorite podcast of yours other than the one you're currently on? Ooh, Startups for the Rest of Us. [51:33] Wow, I haven't heard of that one. Tell us more. It's for, basically, it's Rob Walling's. [51:37] podcast and it's for startups that are either bootstrapped or alt-funded or basically you know the startups that aren't the you know one percent

[51:48] top and funded unicorns, but the startups for the rest of us. Awesome. What's a favorite interview question of yours that you like to ask? [51:57] I like asking people what problems that they're looking to solve. Why are they [52:01] coming to this table. [52:03] Very PM-y question. [52:04] Yes. [52:05] Who else in the industry do you most respect as a thought leader who comes to mind? [52:10] I've got to give a shout out to Christina Wodka. I had a great conversation with her yesterday, and I've had a chance to chat with her a number of times over the years. But she's just got this illustrious career. She's been part of so many amazing teams, built some amazing things, written some amazing books, and is also just an all-round amazing product person and amazing person all in one. [52:32] Jana, this has been amazing. I think we covered a lot of different topics more than we often cover in a podcast like this. Two final questions. Where can folks find you online if they'd like to reach out and learn more? And how can listeners be useful to you? [52:45] Wonderful. Hi, I'm Jana Bastow. You can find me on Twitter. I'm simplyBastow there, or come find me on LinkedIn. Connect with me. I'm Jana Bastow. I'm easy to find there. And come check out ProdPad. It'd be wonderful to get your feedback on it because we are a team of product people and we love hearing what other product people think of the product. We're always open to feedback. We're constantly pushing new releases. So check it out. Try the sandbox. [53:10] We'd love to hear from you. [53:11] Amazing. Thank you for being here, Jenna. [53:13] Of course. Thanks so much.