Lenny's Podcast: Product | Career | Growth - Building better product roadmaps | Janna Bastow (Mind the Product, ProdPad)

Episode Date: October 16, 2022

Janna Bastow is a former product manager, and currently the CEO and co-founder of ProdPad. She also co-founded Mind the Product, a community for PMs, which has grown to 300,000 members across the world. In today’s podcast, Janna discusses the limitations of timeline-based Gantt charts and her “Now/Next/Later” framework. She also shares stories about hosting conferences and gives some great tips on how to improve your presentation skills and cope with performance anxiety.—Find the full transcript here: https://www.lennyspodcast.com/building-better-product-roadmaps-janna-bastow-mind-the-product-prodpad/#transcript—Where to find Janna Bastow:• Twitter: https://twitter.com/simplybastow• LinkedIn: https://www.linkedin.com/in/jannabastow• The ProdPad newsletter: https://www.prodpad.com/newsletter/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• Twitter: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—Thank you to our wonderful sponsors for making this episode possible:• Formsort: https://formsort.com/lenny• Coda: http://coda.io/lenny• Amplitude: https://amplitude.com/—Referenced:• Mind the Product: https://www.mindtheproduct.com/• The Trouble with Traditional Roadmaps: https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/the-trouble-with-traditional-timeline-roadmaps/• ProdPad’s Sandbox: https://www.prodpad.com/sandbox/• Geoffrey Moore’s product vision template: https://www.prodpad.com/blog/product-vision-template/• The Art of Profitability: https://www.amazon.com/Art-Profitability-Adrian-Slywotzky/dp/0446692271• The Sandman on Netflix: https://www.netflix.com/title/81150303• Startups for the Rest of Us podcast: https://www.startupsfortherestofus.com/• Christina Wodtke on Twitter: https://twitter.com/cwodtke—In this episode, we cover:(01:10) Janna’s background(05:28) How the community evolved at Mind the Product(08:22) The tricky logistics of putting together a conference(10:48) Are conferences profitable?(13:00) How Janna developed her storytelling and presentation skills(16:44) How to fight performance anxiety(19:25) Mistakes are humanizing—how to power through and deliver your presentation(22:11) The limitations of traditional timeline roadmaps(25:00) Janna’s Now/Next/Later framework(28:08) How to work without the structure of dated timelines, and why soft launches are important(32:57) What great product teams are doing well(35:05) The importance of retrospectives(36:45) How to shift the culture at larger companies(39:43) How ProdPad creates better product management practices(42:04) How to learn the Now/Next/Later framework(46:59) Geoffrey Moore’s product vision template(48:36) Lessons for PMs interested in becoming founders(50:48) Lightning round—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail]. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.lennysnewsletter.com/subscribe

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. 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,

a mock-up with a feature that I'm trying to build. What do you think? And they tell you what's right or wrong and you add some new copier button to make it more clear. And you throw out the original prototype because it wasn't very good and you make a new one. So the value isn't the prototype. The value is in the prototyping process. The value isn't in your roadmap. The values in the road mapping 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, than this problem. 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 will listen and just check that

you're on the right path. 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. 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 Basto. Jana co-founded mine the product, which I believe is the largest community of product people anywhere. She's also the inventor of the roadmaping framework Now Next Later, and the founder of Prodcat, which makes it easy for you to do your road mapping in this new simpler way. In our chat, we talk about public speaking, community building, road mapping, vision, and going from product manager to founder. With that, I bring

you Jana Basto. 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. FormSort removes the engineering bottleneck and gives product managers and marketers full control

over the form building lifecycle. With FormSort, anyone can build highly customizable forms, implement complex logic, can send data to destinations like Postgres, Big Query, and Segment. Companies like GoodRRX, 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. I always tell startups that 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 form sort.com and use promo code Lenny for 20% off a FormSort Pro plan. This episode is brought to you by Coda. Cota is an all-on-one doc that combines the best of documents, spreadsheets, and apps in one place. I actually use Coda every single day. 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. Over the years, I've seen Cota evolve from being a tool that makes teams more productive to one that also helps bring the best practices across the tech industry to life, with an incredibly rich collection of templates and guides in the Cota Doc Gallery, including resource. for many guests on this podcast, including Shreos, Go Cool, and Shashir, the CEO of Kota. Some of the best teams out there, like Pinterest, Spotify, Square, and Uber, use Kota 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 Kota. You can take advantage of a special limited time offer just for startups. head over to coda.io slash lenny to sign up and get a thousand dollar credit on your first statement. That's coda.da.io slash lenny to sign up and get a thousand dollars in credit on your account. 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, could you give listeners a 55 second background on what you've been up to you in your career. 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 started building ProductPad, one of my co-founders who I also happened to start mine the product with and mine 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 what kept me busy for the last decade or so. And currently you have a company, maybe just mention that before we move on, because I think it'll be important.

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 customer. And just organize all your product management stuff in one space. Awesome. So you mentioned mine 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? Yeah. Yeah. So I think you mentioned it's probably the biggest product community in the world, both online and offline. 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 community,

especially for product people. So a question on my mind is, what do you think has been most important in getting mine the product community right early on and then also just maintaining the quality of the community? Honestly, it was. so much that we set out to build a community. It was that we 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 holding an event, and just being there. whenever there was a chance to be there. So I'm hearing is just putting in the time, 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? Yeah, absolutely. I mean, you know, surround yourself with the people who are going to help you 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 brought 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. 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 to handle the exact numbers now. And it did go in flux when COVID hit. I know at one point

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 still. Some of those are back in person. I know that there's thousands and thousands 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. I imagine there were some mistakes that you made along the way building this community. Is there anything that stands out as man, we shouldn't have done that for folks that are thinking about building communities these days? When running a conference, it's one of the most expensive and unleonest things you can possibly do.

it's really difficult as a product person to pull that off because it pulls it your part. You want to do something that will be an 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 cater is underdelivered. And we ended up having to 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 attendee 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 a 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. And this is a reminder of all the pain. Yeah. Comfort. 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, you know, 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 whole. You know, it could be things like the printing went wrong. And you found out the day before. That's more. dollars gone, right? 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. There's 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 we're able to get help from people around us, get suggestions from people around us. And when 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 was, it worked out in our favor. Just following this topic. I'm most curious.

Their conference is like a good business. Do they make a ton of money in some occasions? Is it always just like super thin margin? How does that even business work? I, 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 ways that you can monetize them, but it only starts making a difference at larger figures. And it takes a lot of efforts 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? We'll start a community several years before and invite people and run a thing, some sort of community meetup every month, time and time again beforehand. And that's your marketing. Just 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 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, well, there are some upsides. It's not for the fainthearted. 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 stressful and full of risk and there's always things going wrong.

You can't ever have fun at these things. So it's always a different personality. Event organizer was 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 all that it all just lands on you all at once. And once the event is over, there's some sense of on we as in like it's over. And now, like now what? The next day you're just like, way, like you can look at the tweet stream or everything

it's happening. and look back at the photos. And then you're like, what do we do next? 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, five, 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, I've watched a bunch of your talks online before we started chatting today. And a couple of things I noticed. One is you 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,

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. 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 mine 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 sort of develop a taste for a good talk and a good presentation and that sort of thing. 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 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. And she said to me, one of the first things, she said, well, I've taken your script. And I've turned it around, I've rewritten the jokes to land a little bit better.

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 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. If you've got a large presentation, a big presentation, and you've got to get up to that level. If you're nervous about doing it in front of a thousand people,

then getting to that level that you're actually willing to, 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 keep refining, but watching your actual performance.

Looking back at the lessons your coach taught you, for new presentations that you do, is there anything else that sticks with you? Just let's make sure to get XYZ nailed because that'll help make this talk better. One of the things that I've stopped doing is I used to sit down with a PowerPoint and start writing my deck in PowerPoint or 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. 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, fits my narrative as opposed to the opposite way around, having a great narrative, and the slides should follow more naturally. What about just like the presenting,

the physical anxiety of presenting? Is there anything you've done there to get better with that and feel 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 behind all the

big stages that I've done in recent years, stand there with your hands on your hips and just feel better about it, as opposed to sitting there falling up in that tent, 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 of the audience and just get used to it and imagine it full of people. Don't imagine them naked. That doesn't matter, but just imagine them there so that when you actually do see them the next day,

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, yeah, that's me. That's me.

And just speak to them. And if you find one up there, one over there and one down there, no one's going to notice that you're doing your talk just to them. And just keep delivering your talk around the room to the, few key people. They're having a great time. You're having a great time and you're doing a great talk as a result. 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 I think they're. I could work. Yeah. I think people are 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. So it doesn't matter. If it works for you, just do it. Yeah. If it's a placebo, hey, don't tell me that. It works. Honestly, I feel better at the end of it and get on stage and do a better job. Yeah, placebo is like someone made this point. Pacebo is this magical thing that we have. You know, brains that gets things to change by not having anything go. Like, you just change things. It's amazing. It's magical. Yeah. Placios are as effective as the actual drug. Whatever. I'm happy with the placebo. Just don't break the placebo effect for me. That'd be fine, right?

Yeah, that's right. One last question on the speaking stuff. How bad were you initially? Just because folks probably see you see some of your talks and are like, oh my God, I'm never going to be this good. I'm scared. I used to be shaky little fond, 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.

And I stood at the front of this group, and I was supposed to just, I don't know, tell them what they were supposed to be doing that day, and I'd had a little half written down. 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,

I'm really sorry, everybody. I'm just going to start again. And I started again. I said, hi, everybody. I'm Jana. Welcome to Product Camp. And I just started again. 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. Like they were totally cool with this. They didn't think anything of it. And they just rolled with it as to die. And so whenever I see somebody who's struggling on stage, just give them like 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 corpseing 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 finish your point and get on with it. That's such a great story.

And it's a good example of people have this fear of like 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. Like it's all going to be revealed on stage because you screw up in how you're talking. And the worst case scenario, like, never happens in my experience. And too, if it does, like, just, you know, just to do exactly what you said. Just try to start again.

It's easy to say, hard to do. This isn't like a conscious thing that people can get over. It's your body's just doing crazy shit. And you're like so nervous and just rationalize it to like, it'll be fine. But, but yeah, it's fine. To your point, people want you to be awesome and succeed. They're not there to like, huh? You stopped.

You screwed up. And it's humanizing when you screw up, right? People don't like people who are perfectly perfect and don't mess up and, you know, 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. I started the product camp 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.

They got it. Speaking of screwing up, you have some very spicy takes on roadmapping and roadmaps. Yes, I do. And then 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 Gant-based road mapping. Can you talk about that? Yeah, sure.

I used to do timeline roadmapping. The first version of Prodpat was actually a timeline roadmap. So to take you back. 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 Gant chart. I knew what a Gant chart was. And so I started putting one together, which 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, 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. Like something would always get in the way. But I sort of assumed that was my fault.

Like 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 the roadmap slightly better. But I figured that this is how everyone was 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 tools for roadmap, I'd envision something that would actually help me manage this format of a roadmap more easily, which I ended up creating the very early version of prod pad, 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 PowerPoint or whatever tool I'm using or drawing it up and 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 this and move all these things here over by a month in the field. We're like, oh, that's interesting.

We've heard that from a bunch of other people, too. Now, why is that? Because had we just asked our customers, how 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 in the time frame that they were saying they were.

So we're like, wait, if it's not just us, he's not delivering the roadmap and none of these better than us roadmap, product managers are building the roadmap on time. 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 three-column roadmap, current, near-term future, which we came now, next later. and it took away the simple concept of a timeline at the top. Now, the problem with the timeline 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 everything underneath is assigned a due date or a iteration.

And it seems that everything that you do has a due date and a 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 these three buckets and provided that as an option. And people loved it. 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 and 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. Yeah. So it's taking from the concept of the cone of uncertainty, taking from the idea that things get less certain as they get further away, which is, you know, kind of how reality works. So, you know, 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. 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? Yeah. Awesome. Okay. So as someone that's been using GAN 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 even just launched a CDP. What's the thought process there? Well, we've always thought of Amplitude as being about 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 and CDP came out of listening to and observing our customers. And supporting growth and learning has always been Amplitude's core focus, right? Yeah, so Amplitude tries to meet customers where they are. We just launched 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. 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 make sure marketing and sales

and your CEO has things that they need for promising, 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 a certain date, PMs being done a certain data science. How do you deal with those in this format? 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 separating your hard launch from your soft launch. 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. They've got lots of stuff to work on. They're they're selling and marketing the stuff that's already live and out there, 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 meetings, launch steps. Now you've got something else to go do. And it's so much better for

marketing anyways, because 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, 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. They can then spend the next however long they want to launch their

hard launch and then that goes out. And in that period that they're doing that hard launch, 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 or 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 two completely different types of projects, your marketing projects and your development projects, which is where along those things fall apart. Got it. So kind of the basic premises, roadmaps or timelines sound great and awesome. Everyone would love to know when things are going to be done. And if it worked, it'd be great. Oftentimes, they're all made up. They don't work. You don't hit deadlines.

They're always missed. So instead of promising dates for everything you're doing, you're better off, 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, we're going to put dates on those things and give it our best shot. Is that true? Yeah. Yeah, that's absolutely right. Like 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, you know, 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 of time. You have to put in more buffer time to do that, and generally you have to plan to get that thing done well before 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, it's going to go wrong and you're going to miss the deadline. If you did that for all of your launches, 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 end's degree that you're 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. going to move super slow. This is why you end up with teams who are really big, 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 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 that thread. I was thinking about the fact that you're building software for product teams. And so you have a really unique perspective on product teams 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 like top-notch, highly functional product teams? 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 site, 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 to 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. That's not the real state of people, of product teams out there. Cool. 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. And people, 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. People are going, of course, this is the way that it works. Like, why would we work any other way? It's becoming the expected way. Definitely

changed the discourse and changed the expectations of the audience, I guess. Putting the now next later piece to the site 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 are 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? Yeah, a couple 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. 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 silos things. What's a lasting change that 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 of Nanx later. Is there anything else that comes to mind? Wow, wow, this one team did this one thing and it made things so much better

for them. Like retrospectives. Retrospectives make such a big difference because they are indicative of psychological safety 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? 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 because some 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. You know, psychological safety is just saying, hey, tell me as much information as you know. 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 get in the most information as you can from the resources you have, making the most of the collective intelligence that you have within your company. 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 I'm curious what you've learned about what it takes to change product development culture and product culture and the way of working at larger companies. Larger companies are tough. They're tougher, right? I think of culture 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 could kind of chip it off. over time. You can't just fix it all in one go. And so in order to fix it, you've got to ship away at it. You've got to find a small pocket somewhere. 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 just too difficult. 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 space right here because we've got a shit hot 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 take 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. Ultimately, a lot of these larger companies are incentivized to keep the company as stable as possible, to keep the company just growing quarter

on quarter, which is great for the stock market, right? They love that stability. They love that quarter and quarter growth. But if the company is actually under threat from startups, right, if you're a big bank, 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 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. You know, I 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. Right. 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 growing, and yet they're not going to, they're going to end up not being willing to take the dip to move upwards. What's the biggest company that you've implemented this new way of building? And is that how you approached it?

You found a team within the larger company to roll out this new, yeah, this framework. 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, department, and then it starts from there. Sometimes what we'll find is that we'll get one or two, sometimes three or four mini groups 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 BP strategy or who owns the tech area and then we can have a bigger conversation. What's the impact that you saw at that company having taken on this new way of building product? So we're in the middle of like 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 part of a mindset shift within the business. Because one of the things about prod bad 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 product pad, it makes difficult to add 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 follow. all 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 success? And was it successful or not successful? This roadmap thing has completed. What was the outcome of it? 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. 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? 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. You don't even need a login or a credit card. It's got OKRs and roadmaps and ideas and experiments and feedback. You see how it all sort of fits together. But honestly, a now next later roadmap can be done with Post-It, Novel. on the wall. It's just about saying, what problems do you have? 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. 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 mockup. And you'd take that mock up and you'd share it with somebody and say, here's a mockup with a feature that I'm trying to build. What do you think?

And they'd tell you what's right or wrong and you'd add some new copier button to make it more clear. And you'd throw out the original prototype because it wasn't very good and you make a new one. So the value isn't the prototype. The value is in the prototyping process. The value isn't in your roadmap. the values in the road mapping 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.

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 will listen and just check that you're on the right path. And if they say, oh, actually, I thought that it was going to go this way, this way, then this way, or that way than 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, it becomes better there. For folks that are listening and they're just like, nah, this is never going to work where 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 most powerful three bullet points you could share with listeners?

They're just like, here's why you should have confidence. This might actually work at your company. 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 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.

they don't know that. What they do know is that they have a process by which they're going to fill a pipeline. 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. 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's 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. You're saying that you want a quarter million dollars worth of investment. And you're going to spend it on your team who's going to run experiments, right? It's going to be trying this change on the interface or that tweet 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. 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 what is going to work before you know what's going to work yet. And that's the problem with this timeline delivery, magic eight-bomies. that we're asked to give. I like that. Two last questions before we get to a very exciting lighting 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 really handy little framework. And vision is always this thing that people are like, man, how do I come up with a vision? How do I even visualize my team's mission? can you share that with us if you have that in your head? The product vision template, you might actually recognize it from the Jeffrey Moore's

Crossing the Casm 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 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. 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. 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. Yeah. Okay, cool. The last question, you were a PM, now you're founder. So you moved from PM to founder.

And a lot of PMs, imagine being founder 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. 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 a 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. 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 it's not as hard as it looks. And it's also harder than it looks. There's things that you get started and you go, oh, 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 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. Like, 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 in the case that you had when you are product manager as well.

And just be ready for those and be ready to take it on the chin and deal with them as they come. The best thing you can do is surround you. around 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 to time. Certainly don't stop yourself from starting a business or starting your own thing. 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.

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 mine, share an answer. If nothing comes to mine, 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? Art of profitability, I thought was a really good one. What's a favorite recent movie or a TV show that you watched? Oh, Sandman. Ooh. And that's like a British show, right? Oh, it is British, yes. at Neil Gaiman. Yeah, very good. Definitely not for children. Thought it might be. Definitely not.

Noted. What's another favorite podcast of yours other than the one you're currently on? Ooh, startups for the rest of us. Wow, I haven't heard of that one. Tell us more. It's for, basically, it's Rob Walling's 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, 1% 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? I like asking people what problems that they're looking to solve. Why are they coming to this table? Very PME question.

Yes. Who else in the industry do you most respect as a thought leader who comes to mind? I've got to give a shout out to Christina Wadke. 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 there's also just an all-round, amazing product person and amazing person all in one. 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? Wonderful. Hi, I'm Jana Basto. you can find me on Twitter. I'm Simply Basto there. Or come find me on LinkedIn. Connect with me. I'm Dada Basto.

I'm easy to find there. And come check out Prad. 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.

We'd love to hear from you. Amazing. Thank you for being here, Jana. Of course. Thanks so much. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast.

You can find all past episodes or learn more about the show at Lenny'spodcast.com. See you in the next episode.