Skip to main content

Product Management Webinar: Product Management in Practice

Product Management in Practice with Matt LeMay

What does the day-to-day life of a successful product manager look like? How do you avoid burnout? What does the role now look like in the era of remote and hybrid work? 

Watch our webinar, as we explore product management in practice – none of this in theory malarky, but actually getting into the nitty gritty of what the day-to-day life of a product manager actually looks like.

You’ll be joined by special guest, Matt LeMay, Co-Founder of Sudden Compass and author of ‘Agile for Everybody’ and ‘Product Management in Practice’, and host Janna Bastow, CEO of ProdPad.

About Matt LeMay

 Matt LeMay is an internationally recognized expert on product management and Agile ways of working. He is the author of Agile for Everybody (O’Reilly Media, 2018) and Product Management in Practice (Second Edition O’Reilly Media, 2022), and has helped build and scale product management practices at companies ranging from early-stage startups to Fortune 500 enterprises. Matt is the creator of the One Page / One Hour Pledge, a commitment to minimize busy work and maximize collaboration that has been adopted by over 100 individuals and teams at Amazon, Walmart, CNN, BBVA, and more.

Matt is co-founder and partner at Sudden Compass, a consultancy that has helped organizations like Spotify, Clorox, Google, and Procter & Gamble put customer centricity into practice. In his work as a technology communicator, Matt has developed and led digital transformation and data strategy workshops for companies like GE, American Express, Pfizer, McCann, and Johnson & Johnson.

Previously, Matt worked as Senior Product Manager at music startup Songza (acquired by Google), and Head of Consumer Product at Bitly. Matt is also a musician, recording engineer, and the author of a book about singer-songwriter Elliott Smith. He lives in London, England with his wife Joan.

Key Takeaways

  • How to ace stakeholder management
  • Stories from working product managers across industries and company sizes
  • Actionable answers to product management’s most persistent and confounding questions
  • How to implement the One page/One Hour model
  • And so much more!

Dots watching a webinar

[00:00:00] Megan Saker: Hello folks. Welcome to our webinar today on convincing your stakeholders that Now-Next-Later works best. I’ll just introduce myself very quickly. I’m Megan. I’m the CMO here at ProdPad. And yeah, what we’re going to cover today is how to go about winning buy in from your stakeholders, from your team, to make the move to the Now-Next-Later roadmapping approach.

How to get everyone convinced that it is the right decision for your organization. But first Just a bit of housekeeping. We are going to make sure there is time at the end for a Q& A. So please, whenever you think of a question whilst Jana is talking, please pop it in the Q& A box. So you’ll see across from the chat.

There’s a box there specifically for those questions. So throw them in at any point during the webinar. We’ll make sure there’s time at the end. We’ll come back to them and go through them on. Janet will answer them. Also, just to say that this webinar is just one hour. Apologies to any of you that have a daunting 19 minute slot there in your diary.

It’s not. We’re going to keep this to an hour. Obviously feel free to use the chat at any point. We will, after this webinar, send you a recording and the content that Jana is going to be sharing today is actually a slide deck that you can download yourselves as a template and use it, edit it, adapt it, do whatever you want, use it with your own stakeholders.

So let me introduce you to Janna Bastow. Many of you will be regular ProdPad webinar attendees and know Janna. Jana is a product management guru. She’s in fact, along with her co-founder of ProdPad Simon Cast, the inventor of the now next later roadmap. She’s co-founder of Mind the product.

So today, as I say, she’s going to walk you through all the arguments you’ll need to present to your team and your stakeholders to win their buy in, to move to agile roadmapping, and then our next later format. As I say, Jenna is going to take you through a ready made presentation slide deck that you’ll be able to download.

Edit and use yourself and we will email that link to you at the end, but you’ll also see a QR code that you can snap at the end. Without further ado, I will hand you over to Janna. 

[00:02:32] Janna Bastow: Excellent. Hey, thanks so much, Megan. And hey, everybody. Thanks for coming along today. Reason why we chose this subject is because it’s the one that vexes product people the most.

We talk about now and X later until the cows come home and product people get it. But when they try to bring it. Into their teams. This is where they start hitting objections and friction. Now we have coached literally thousands of teams, helped so many teams move from timeline roadmapping to now next later, we’ve got a few tricks and ways that you can start, bringing them on board with this. So we’re going to share that with you today. And as Megan said, we’re going to be using a particular part of the slide deck that you can take for yourself to use in house to convince your product people or your, the rest of your team. Sorry, not the product people, the everybody else that now next later is the way to go.

So let’s jump in. But before we get too far, I just want to introduce you to ProdPad. Some of you are already using it, which is great. Thank you so much for your support. Some of you, this might be new to you. ProdPad is a tool that was built by myself and my co founder, Simon, back when we were product managers ourselves.

Basically because we needed tools to do our own job. We needed something to keep track of all those experiments and all that customer feedback and to create a roadmap that would show people on the team where we’re going. So we built something. And so what we realized is that ProdPad was something that was going to give us control and help us organize our work and provide transparency into the product management space.

So people stopped wondering what us product people were up to and why we kept making decisions like we do. And what it does, it helps you create a single source of truth for your product decisions, for your product work. So nowadays it’s used by thousands of teams around the world. It’s a tool that you can try for free.

We have a free trial. You can jump in and start using it right away. And we also have a sandbox mode in ProdPad. That’s basically a version of ProdPad that’s preloaded with example data, like lean roadmaps and OKRs and feedback and experiments and all this other stuff. Sat in one place so you can move it around.

You can try it out and you can see how it’s going to work for you. And our team is made up of product people. So it was founded by a couple of product people and we’ve got product people throughout the team as well. And so we are constantly looking to learn and iterate and adjust. So we’d love to hear your feedback, jump in, give it a try and let us know.

And I also want to highlight some really cool stuff that we’ve been working on, right? We’re constantly iterating ProdPad, as I said but one of the really interesting areas that we dove into. Last year was AI, right? We got our hands on the the GPT API and started playing around. And we realized that we could enable product managers to reduce so much of their grunt work by making it easy to generate ideas and to flesh those ideas out, have it answer questions like how you might measure target outcomes or whether this idea is actually any good, you can compare those ideas to your vision.

You’ve got your objectives. You probably, a lot of you are probably working on your OKRs right now. You’ve got your high level objectives. This will help you brainstorm key results and not just any key results, but we’ve tweaked it to be to give you results that are outcome focused and leading metrics to measure your objectives by.

And it gives you feedback on stuff, right? We didn’t just want something that generates stuff. We wanted something that can be like your sidekick, like your coach. And so you can take things like your product vision, which you’ve gotten product pad, and it’ll give feedback on it and tell you how to strengthen that vision and iterate on it.

And we’ve also built out, this is the newest piece of it, a chat bot that you can talk to and get product insights, product advice, but also it knows what’s going on in your product pad account. So you can ask it questions like. Hey what should we work on based on what our customers have been asking for?

Or can you help me give, can you give me feedback on this roadmap? Or can you help me identify things that we could put on the roadmap that would match with our objectives? So it has this sort of insight and it’s available for you to jump in and give it a try. So we’d love your feedback on that.

 And ProdPad is a tool that you can start a free trial for. So jump in, give it a try and let us know what you think. Now on that note, I want to start talking you through how to get people over to the now, next, later format of ProdPad, right? Because of a roadmap, which is the format that we use within ProdPad.

Um. The thing is that you’ve got to think about who you’re presenting to, who is it you’re actually trying to get on board. You’re going to have a lot of people often within your company who don’t want to move away from a timeline roadmap for various different reasons. And so we’re going to look at how to get your exec leadership team on board, show them the benefits of Why you should be working in an agile roadmapping format, like now next later, as opposed to the timeline that you’ve been using for the last few years.

But also we’re going to help you get other departments on board with this, right? So let’s say it’s your sales team who is holding onto that, that timeline roadmap and those delivery dates that you, they used to promise. And what about your marketing team, or what about your customer facing teams?

So there’s different stakeholders within your business who might have different reasons why they object. To moving away. And so we’re going to give you some tips on objection handling. So really you need to understand who it is you’re going to appeal to, who it is in your particular company, like who is your tricky stakeholder and you might have more than one.

And from there we can start looking at ways to successfully win them over. So before we craft our arguments on to persuade these stakeholders let’s try and understand the reasons why. They’ve got preferences for timelines. What is it that they think timelines give them? What makes them think that they’re necessary?

Let’s start at the top here. The, your big bosses, bosses, your exec team, they like deadlines. Deadlines give them a sense of control or at least a sense of security that everything’s going to go according to plan and timeline blankets are like a security blanket for them. They’re a comfort blanket.

They reassure them that everything is working. In some organizations, you can find that the business leadership will lack trust that any department is not explicitly commercial, so your sales and marketing teams that they don’t trust that they have a mature enough appreciation for the commercial imperatives of the business.

They think it’s necessary for the non commercial teams, those who don’t have enough revenue, who don’t focus enough on revenue to appreciate the urgency to have deadlines and dates. So those people who do understand this urgency can push them and drive that pace. So this is how leadership can easily enforce pace and help them clearly see when it’s not being delivered.

But it’s also important to understand that sometimes leadership, especially in organizations who are transitioning from that traditional business model to more of a platform or SaaS model can have a mindset. That’s a bit of a hang up. From the days of selling individual one off project products or instances of a product to individual customers, right?

They’re doing custom work. so It’s not uncommon to have deadline expectations coming from your exec team as a hangover from that, I call it the agency trap, right? When companies are working in more of a an IT project or agency model. And put it this way, software agencies need dates and deadlines because they’re running with a very defined.

Project right? A client gives them a scope and a time and a cost and they deliver to that. They have billable hours and a specific quote to meet. And these are paying customers waiting for delivery of the product by a certain date and possibly contractual obligations to meet. But if you’re not an agency, this isn’t how you should operate.

It’s what I call the agency trap when product companies act like agencies taking on custom work, and it takes away the time that they have to spend in discovery work. So we’re going to address that one. Um, also bear in mind that some of the pressure you might be feeling from leadership. Is actually transferred pressure, right?

It’s from outside forces. They might have stakeholders of their own. It might be investors or customers who are pushing on them to get these dates. So you’ll need to show the execs how they can manage investor or board reporting, or, manage other teams around these dates as well. So this is why getting your execs on board is so important.

Now, sales teams are the. Other particularly vocal stakeholder group when it comes to ditching the timeline, right? This is the other group that’s going to give you problems. And why is that? What is their problems? tHey might run into fears. They might have fears like they’re no longer able to make commitments to their prospects, which screws up their plans on how they’re going to close deals.

This is particularly. Painful if the company is running in that sort of agency style mode, as opposed to thinking about themselves being a product company. They’re worried that delivery is going to slow down if there’s no deadline pressures. So similar to what your execs sometimes think. And.

They’re also sometimes afraid that they might look foolish if the road map pivots, if you change something that’s on the road map. So we’re going to talk about these types of fears as well. And then you get marketing, right? So marketing might be concerned with how they’re supposed to plan campaigns and launch stuff without a timeline, if they don’t have an idea as to when something is going to be out there.

But we can talk about how we can work with these fears as well. And then your customer teams are going to be primarily concerned with how they can confidently respond to customer questions. Customers are going to be wanting, wondering what it is that you’re actually up to and whether you’re building into the direction that makes sense for them.

And so your customer teams are going to want to cite as to what’s going on as well. So we’re going to look at how we can win over each of these stakeholders and get them all on board with the now next later way of working. The way that I really recommend doing this Is to get your stakeholders in a room and show them the light, show them what they’ve been missing because oftentimes they don’t understand why you’re making this change.

And so if you can explain to them. Where you’re coming from, what the value is for their particular function, and for the business, you can start getting people on board. One of the best ways to do this is to get people into a room together, a Zoom room is fine, right? And what you want to do is share with them the values of a Now Next Later roadmap and make sure that they’re on board with it.

So what I’m going to do is I’m going to show you some slides that we’ve created that we’re going to hand out to you afterwards that you can use. For your own stakeholders. So these next slides are ones that you can take home and the slides themselves also have cues in the slide notes, presenter notes.

So you can follow along and use that to get people on board. So keeping in mind that we are coming from a place where we have convinced or we’ve helped people, thousands of companies convinced their bosses and their teams to get on board with it. This is basically the formula the points that you can use now, because this is a take home thing that you can use for your own company.

Feel free to make adjustments, right? If there’s a different stakeholder you want to take in or take out or, address a particular concern, change these around, right? Chop and change these as you see fit. But here’s a way that you can start doing it. So imagine that you’ve got your hands on this deck and you’re convincing the rest of your stakeholders.

Here’s where you might start. So first of all, you want to bring them in and start talking about why Better Roadmap is going to get you better results. This isn’t just about you removing the pressure of having to put dates or you’re not too lazy to go get estimates from the rest of your team.

You’re doing this to get better results for your team. This is about driving high value outcomes for your company. So this is the frame of mind that we’re going to start this argument in this conversation in uh, and what you’re looking to do is help them move from timeline road mapping to agile road mapping.

So point out. What it is that you’re trying to do your proposal here is to move from one format to the other format. And what we’re going to do is talk them through what the now next later format is, and how the timeline roadmap format hasn’t been working for them point out the cracks in this facade and start.

Bringing forward this new idea. So again, this is very much an outcome focus. This is all about delivering solutions that are or to strategically important problems and measuring those results. So you’re going to provide more to them. You’re not taking something away. So what you’re going to be doing is you’re gonna be making a promise, right?

You’re going to be promising these different things that you could do for the company. One, like delivery will speed up. You will be able to deliver faster using a a timeline sorry a now next later roadmap, but you’re not caught up in trying to do all of the project management estimations before you jump in and try to solve the problems you’ll be shipping more.

You’ll be driving better results, right? You’re driving towards outcomes rather than just a whole bunch of outputs, a bunch of features. You’ll be responding faster to new opportunities and therefore not missing opportunities in the market, which is so important in this world when everything just changes on a dime every.

A few months, it seems, uh, you’re going to be better strategically aligned. So you’re going to be using cases like this to make the, you’re going to be making a case around how it aligns the whole team around it by having a simpler roadmap that identifies what your strategy is, as opposed to just having a list of features and things to do, and you’re going to be operating with greater efficiency, less waste.

There’s a reason we call it the lean roadmap format is that it’s less wasteful. And finally, you should be getting, you should be able to make the case that it will help you retain staff, right? No more sad developers who are leaving because it’s full of tech debt and, they’re sick of building just feature after feature with no real cause.

So I’m going to expand on each of these more later so that you have the points to drive these home. And those are going to be included in this deck. So first of all, make sure people know what you mean by agile road mapping and we use the term agile road mapping now next later road mapping and agile road mapping.

They go all by different names. Call it what you want, right? Call it whatever seems to work for your particular company. But I like the term. Agile because it speaks to that broader approach, the Agile methodology, which is, it allows for flexibility. It’s there for continuous improvement and rapid response to change.

And so therefore Agile road mapping has been adopted into road mapping or the Agile methodology has been adopted into your road mapping methods. And that’s how you get this now next later. So we’re definitely going to try to focus and sell people on the fact that this is outcome, not output focus, right?

You’re not just taking away dates. You’re actually giving them something, the outcomes here. You’re bringing the company into a more customer centric way of thinking so that the problems are organized around. Customer problems to solve. yoU are structuring with broad time horizons rather than rigid deadlines.

And so this is really important because this gives you that flexibility, but still gives people a sense of direction and pace and, distance how far something is from being done now. And really most importantly, it’s flexible. It gives you space for learning. So these are the things that you’re going to want to share with people as you are getting them on board with your.

Now next later way of working so you can then introduce that now next later road map as a specific way of doing agile road mapping. So this is the approach that was invented by myself and Simon. It actually came out of the fact that we were building prod patents early days and started looking at ways that we could build a road map that wouldn’t track people.

And so really we wanted to end the focus on features and deadline in favor of a greater emphasis. On discovery and it’s now being used by literally thousands of teams around the world. So many product managers are now using this and we’ve got proven cases of how this has helped team deliver more and be more outcome focused.

It’s also an easy to understand format, right? It’s it’s not convoluted with a whole bunch of junk. It helps you, it’s inherently strategically aligned, because I like to think of it as a prototype for your strategy, a way to outline The, your high level strategic steps before you dive into deep it gives you that flexibility so that you can change things on the fly based on insights that you get at the strategic level.

And it’s inherently outcome focused, right? Each of the things on your roadmap are going to be tied back to the outcomes that you’re looking to get for each of them. And it’s the most customer centric approach to roadmapping. bEcause what it’s doing is giving you clarity on what those customer facing problems are and outlining how you’re going to go about solving those problems.

So then you can start diving into deeper, right? So how does the the now next later roadmap work? As I’ve said, it’s often referred to as a lean roadmap or a time horizon roadmap. Now next later are the time horizons. The ones that are in the now column are your well understood problems with defined solutions and committed Development resources.

This is stuff that team is working on right now. You’ve got your next column, which is the problems that are generally at design or discovery stage with some assumptions that you need to validate before committing those resources. And then you’ve got your later column, right? These are your aspirations.

These are the things that are a bit fuzzy and are still taking form. They’re on the horizon in the distance. Although we do know that we want to solve them if we want to get to. That, the big vision for our company. And so basically, as you start working on things, you’ll take things from your later and you’ll break them down into more detail and they’ll move into your next.

And then you’ll break them down in more detail and they’ll become part of your now, and it’s not fully linear. Anybody who’s made a roadmap knows that your roadmap is not linear. And this isn’t trying to be, what it’s doing is mapping out what you understand. The product space in front of you looks like if this is what we tackle now, then what are we going to tackle next?

And what are we going to tackle further off in the distance? And as you take steps, think of these cards on the road map is stepping stones. As you take steps and you get closer to that future vision, you’re going to adjust and you’re going to say, Oh now that we can get, we can see more, we might actually take this direction instead.

And you shuffle the direction of these cards depending on what you learn. So it’s inherently a flexible roadmap that changes as you learn more. You also might call your roadmap columns different things, right? I, one of my favorite takes on it is calling the Now, Next, Later columns Doing, Discovering, Dreaming, because they outline the things that you’re going to be doing.

At those particular times during the, that far out on the roadmap, the things that are in the doing or what you’re doing right now, things in the second column or what you’re discovering. And the later column, the third column is you’re dreaming, right? Here’s where you’d like to get to, but you’ll figure it out as you get a bit closer as well.

Other teams like to wean themselves off the timeline roadmap. One way that really helps to work, helps people move over is to move from their usual timeline roadmap into something that has more of a fuzzy this quarter, next quarter, Q3 plus, right? And that way you’re getting people used to this sense of, time horizons, and they’re getting fuzzier as they get further away but not taking away those dates on day one. Once they get used to the, the Q1, Q2, Q3 sort of format, you can start bringing them closer and changing the wording to now, next, later, and that way you’re not stuck with things within particular columns.

But, what’s important is that understanding that the maturity of initiatives in each and in each horizon. So now is where you’ve got a granular area of focus. And whereas initiatives that are in the. Later are broad high level. They’re subject to change as you discover more about them.

And as initiatives move from right to left, they develop, they evolve, they, the mature and by the now column, they’re known pieces of work specs that are being written. Delivery dates are being planned. Development work is being done. aNd I can see that somebody Chris is saying in the the chat here that they found that Q1, Q2, Q3 to be a good safety feeling for people, right?

It feels more tangible to them. And I agree with this. It’s a really good way to get people on board with this. And there’s no shame in having. dates like that on your roadmap, on your now next later roadmap, because you’re still going to be getting most of the benefits of it. It’s still going to be outcome focused.

It’s still going to be customer centric. It’s still going to be easy to understand. And it’s always something that you can change later as people get more used to the three column view. So how it works, you’re gonna be talking to people about how you’re going to be populating this roadmap with or basically instead of populating your roadmap with features to be built your now next later roadmap contains what we call initiatives or roadmap cards, or, these chunky blocks, the big white blocks on the roadmap.

anD I like to think of them as problems to solve, or opportunities, or areas of focus, and within those initiatives are then a series of different ideas that could be worked on to try to solve that problem. We call them ideas in ProdPad Land, but I like to think of them as experiments as well. Because what you’re basically saying is we’re going to find several ways to experiment and solve this problem in order to reach the goal that’s on our roadmap.

And by using experiments, it gives you a little bit more flexibility to to think about how you’re going to solve this problem. You’re not meant to do all your experiments. There’s a bunch of ways that you could solve this problem. And so really you’re changing it from our roadmap is a list of things that we will do.

And instead, it’s a list of problems we want to solve and then broken down into how might we solve this problem. We could try this, and this. And as you work your way through, you get better at understanding how that problem is going to be broken down. And you start tackling that problem. You start working towards your outcome.

So the other key thing is that initiatives on the roadmap should be linked to at least one of your core product or company objectives, right? Those objectives are the that the green line or the blue line or the pink line at the top. These are all things that help you identify the why.

Why are we doing this? Why would we solve this problem? And so you should be able to create a roadmap that you can collapse down and ProdPad offers these collapsed views. You should be able to collapse it down and squidge your eyes and just get a sense as to what your roadmap is about, what your product strategy is.

Are you growing your user base up front and then getting revenue? Or are you going to tackle revenue and then market share or tackle the churn problem first? So you should be able to see these almost trends within your roadmap. That will help outline what your overall product strategy is. And then you break it down into more detail about what problem you’re going to solve.

And then break that down into even more detail about how you might solve that problem. So that’s the gist of how it works. Now there’s more on this that we can teach you. But we’re not going to dive into that because there’s a lot of nuances about how to do road mapping. I’ll show you a course.

Afterwords that allows you to dive into this stuff in more detail. But we’re all at this level when you’re bringing this to your team, they don’t need to know all the nuances. What you want to do is sell them on the benefits. So what is it that they actually get from this? Let’s go through these.

I mentioned this is the same list that I mentioned earlier. So we’re going to dive into these in more detail. bEcause NowNextLater does not rely on exact deadlines for its structure, teams aren’t asked to plan schedules ahead of time and commit to exact dates which are, for the most part, entirely fictitious this far out.

So that requirement for dates almost nearly nearly always sees teams Bake buffer time into their estimates in the hope of mitigating missing those deadlines and then being blamed and then feeling the pressure for that. Um, What often happens if you’re adding a whole bunch of buffer time to your work and putting that on your roadmap is that if you’ve ever heard of Parkinson’s law, it’s the law that states that work expands to fill that time.

And so what was once a cautious estimate becomes the actual time taken. You rarely hear of teams finishing things early and then cracking on with the next thing. Things are always coming out just about on time or a little bit late, regardless of how much time you said up front you were going to spend on it.

So the broader time horizons of pro of the NADx later means that no one is baking in buffer time just for the sake of having it. And things actually get delivered faster. If things move faster, then more work can get done, right? More features are built. What you’ll find is teams using NowNixLater deliver more, more often, and get things out the door faster than teams who have to spend all that time doing the planning and figuring out exactly how long they’d want it to sit on the roadmap, and then try to line them all up in a row.

Agile roadmapping and the nanoslator roadmap means that your team is going to move faster and ship more. This is a really key selling point and it’s sometimes a bit counterintuitive. People think that having deadlines is going to get them to move faster, but it’s not true. Deadlines have never inspired people to move faster.

What it’s really going to do is mean that you’re having to protect your butts and not get as many things put on that roadmap and therefore deliver less.

One of the other things that you can emphasize here is Talking about the outcomes that you’re going to be getting rather than the output that you’re going to be focused on, right? So each roadmap item is focused on a particular outcome, solving a particular problem for the customer and for the business.

So this emphasis means that the product team is accountable for an outcome, not just those outputs. This is really key because, remember, delivered does not mean done. Results have to be measured and iterations and improvements made where needed. Products bloated with ineffective features essentially become a thing of the past, right?

You’re not going to want to worry about that. So with Now Next Later, teams are motivated to drive real value and deliver against their objectives, not just have a feature because the roadmap said to have a feature. So you’re declaring the problem. Not the solution and the roadmap is a space to discover what’s actually best and the best way to solve that problem.

So roadmapping and the now next later format, what you want to really enforce is the fact that it’s there to help you deliver greater value to the customer to the business.

Other really key thing that you want to drive home is the flexibility afforded by having this timeline or this time horizon way of working, right? You’re focused on those outcomes. You’re focused on the time horizon, but really you’re focused on the order in which you’re looking to tackle things.

And you can adapt that order, right? You might finish one thing and then realize that the next most important thing is not what you thought it was last quarter. It’s something new because. The market’s changed or people reacted differently to what it is that you built last quarter. So the roadmap format should give you space to adapt.

Naturally, as you learn more, so there might be ways that you need things you need to respond to. So there might be new discoveries from user research. There might be market research. There might be a competitor analysis. That’s been done. There might be shifts in the markets, just in the economy. Lots of things happen.

We know this now. There might be new opportunities like a. AI comes out or the next big thing comes out and you realize that there’s a huge opportunity to build that in where you no longer beholden to building, whatever it said you to build in June, just because June is here. You should build what’s most important for the business as that point comes up, as that time comes up, as that opportunity comes up.

And there might just be changing strategic priorities, right? The company might have to shift its goals and therefore your roadmap needs to be able to shift as well. So the now next later roadmapping approach, what you really want to drive home is that it’s going to be, allow you to respond faster to threats and capitalize on new opportunities, right?

You’re going to be able to adjust your plan as you go.

Other key point is that the now next later format. requires all initiatives to be linked to a product objective or a company objective, right? This is an IR clan way of ensuring that the team is prioritizing and working on things that actually bring strategic value to the business. You can’t put things on the roadmap.

Just because you wanted a new feature, you’ve got to be able to say what features does this problem solve? And why do we want to solve this? If you can’t answer those two questions, then it probably doesn’t deserve to be on your roadmap. So it’s a really good forcing function to get your team thinking about the strategy and aligning the work that’s being done to that company or product level strategy.

So really drive that point home about that alignment and then it’s also going to help you operate with greater efficiency. Everyone loves to save a bit of time and not waste their time doing stuff that ends up not being used, right? So the now next later time horizons stop product teams from wasting time planning out super detailed schedules that are far in the future about, what’s going to be delivered and when oftentimes that stuff.

Just ends up getting reworked or thrown out or ignored because they naturally have to change along the way. And it’s also hard to estimate that far out. And so the more that you’re doing it, the more that you’re making it up and that’s not a useful. Way to spend your time as a product manager.

You can be spending that time talking to customers or learning about the market or, figuring out the best thing to build next, as opposed to trying to figure out how long something’s going to take in three months time, it doesn’t matter and you don’t know. So it drives efficiencies and it’s going to unlock more time for higher value product management work, really drive this point home as well.

And then the last one, this is really key for people who are in the exec team are Drive home the fact that it makes for happier teams and therefore better retention. What you’re really getting here is the fact that you’re, when you remove the practice of setting deadlines too far in the future, you alleviate the pressure and fear that comes with hitting unrealistic dates.

The delivery dates. Put in place with now next later way of working are only set once work has been defined and specifications have been written. You’re not trying to plan way out and then hold people to these dates that haven’t been that aren’t realistic. 

What you’re really looking to do here is to what you’re actually looking to do here is also it reduces the amount of tech debt, right? If you have a whole bunch of. Projects that end up getting delivered one after the other, but you end up cutting it close at each turn, you’re going to start accruing tech debt.

And that tech debt stacks up, creates a tech code base that becomes unworkable. And you end up with teams that have just tons and tons of difficulties building things, unhappy developers who end up. Leaving, right? And so having this way of working helps to retain your staff and reduces your hiring spend, right?

You don’t have to replace people, you don’t have to train people up. fLip this around the other way as well, right? You want to tell them about the benefits, but you also want to give them the warning about what happens If they don’t, right? So delivery is slower, tech debt builds up, and you end up with a tech project, a tech stack that needs to be rewritten opportunities end up being missed, right?

You’re too blinded by what you said you were going to build at the beginning of the year, and you’re halfway through the year now, that you have to go build whatever it says to go do in June, that you don’t look outside and say, oh maybe we should be building this instead, because this is going to solve the right problems for us.

You end up with people being less accountable for the results, and you end up with your brand reputation sometimes being damaged if you build the wrong things, or if you end up missing promises that you’ve made in this roadmap, you end up losing people in the team if they’re not able to work in a autonomous way to solve the problems in the best way, rather than just cranking out feature after feature, which is soul destroying and oftentimes money is wasted building the wrong thing.

So many teams end up just building stuff because it seemed like a good idea when they mapped out this road map at the beginning of the year and aren’t actually building the right stuff. So other really key thing is that you want to make sure that you’re getting certain you want to make sure that people on the team are feeling this win, right?

So a lot of what we’ve spoken about so far are benefits for the wider team or for the exec team. You really want to be driving those benefits home. But also you can use these slides here to tell, to talk the sales team through or talk different mark different Stakeholders through, and we’ll go through a bunch of different ones as to how they’re going to win doing this.

So this is a win situation. You’re not taking something away. So for sales team. They’re going to end up with better objection handling, right? So presenting your roadmap through problems to solve can provide your salespeople with a simple way to handle objections and answer needs, right? If a prospect says a competitor has one feature that we don’t, the salesperson can drill into the problem that the feature is trying to solve, and then they can scan.

And then they can start explaining a different feature that we might have or soon to have that solves that problem and, maybe suggest that it’s a better way of solving it. So it’s driving salespeople to think about the problems that people are having, as opposed to just saying tick box, do we have this feature or not compared to our competitor?

You’re really truly getting people to think about the problem view. It’s also a safer way to share the roadmap, right? You might have two different types of salespeople, right? You’ve got one who is smart enough not to show the timeline roadmaps with prospects. But we all know some salespeople will just take that roadmap and share with prospects and go ta dum, go Take your pick.

What would you like to buy? And when would you like to buy it? Because we’re going to have all these cool features, which we know the roadmap never gets delivered. A timeline roadmap never gets delivered as. It was written out. And so it’s dangerous, right? You end up with salespeople who get mud on their face because they’ve made promises that the team can’t keep.

And so with using a now next later roadmap, you’ve taken the dates off. You’re not talking about specific features that can be delivered by specific dates. You’re able to turn that around and say Hey, here are the problems we’re looking to solve. We’re going to go from here to here, these types of problems.

And you’re not making promises of specific things that are going to be delivered for them. But you can use this as an opportunity to discover whether these problems align with your customers. And if one customer comes back and looks at your roadmap and says, Oh, this isn’t right for us. It’s probably not a big signal.

If a lot of customers look at your roadmap and say, Whoa, I can’t believe you’re solving this problem before you solve this problem. That’s good insight. And that might be a time that you can adjust that roadmap. So you can work with your salespeople to share the roadmap as you have it, get feedback on it and use that feedback to inform you as to whether you’re heading in the right direction that your customers care about, that your market cares about.

And it’s a huge misconception that now next later roadmaps cannot have dates at all, one of its biggest misconceptions. And this is the thing that often holds sales teams or even execs back. If a huge deal hangs on a particular feature being live on a particular date. Then you might be able to work that out, right?

You can it doesn’t mean that you don’t have dates on that roadmap. It means that you’re not driving that roadmap by dates. So something has to have a hard date. You can show that on the roadmap. Now, what you’re giving up is that your team does need to do the project management work to line up to get that.

But you’re still able to show specific dates. You’re still able to communicate dates where they are strategically important. And externally driven, right? So it’s not just about putting arbitrary dates on everything, but if something does need to be communicated, you can still communicate that on a now, next late, now, next later roadmap.

iF you’ve got a sales team on board with, or if you’re trying to get the sales team on board with the now, next later roadmap and they’re pushing back on it, You might find that they’re struggling because they’re not used to selling the product that exists today, right? This can be a tough conversation to have because sometimes it means that the sales team just isn’t up to the job, right?

They’re selling something that doesn’t exist yet because it’s easier to get somebody to just come along and state what they want rather than working. Harder to find the types of leads that they actually do that actually are going to make use of your product as is. So really key thing that you can be doing is working with your sales team to identify your ideal customer profile, your ICP, and they should be able to.

Target the right types of leads that are going to find your product useful for what it is today, rather than just constantly throwing it out to anybody and bringing in anybody. So you’ve got to be that, that that voice to say, here’s who is going to use our product. Here’s the jobs it does solve. Go find people who need to solve those jobs.

So that’s a a really key point is that you’ve got to work with your salespeople on what your ICP is. The marketing team is often afraid of moving to the now next later format because they think that they need a deadline so that they can launch their. Features they can launch their campaigns on the same day that you’ve launched your features.

And that is always fraught with difficulty because what you’re trying to do is you’re trying to line up a development project to land on the same day as a marketing project. And if that development project gets pushed back, your marketing project. has jumped the gun, right? Or they’ve lost money or they’ve lost time.

What you want to do is you want to separate your hard and soft launches, right? So your soft launch comes out and from that point you’ve got a version of the product that is in a feature flagged area of your product or is in a beta subdomain or is, turned on just for specific customers. And what you want to do is you and then you can turn this thing on just for your internal users or a specific set of users, maybe a beta group of people, and then from there, marketing can pick it up and they can plan out the biggest bangest launch that they can imagine, right?

But now, instead of trying to tie their launch date with your feature launch date. They’re starting from a point that the feature already exists. They can get pictures of it. They can get videos of it. They can start getting testimonials of it in this soft launch format. And then from there, they can plan out a huge launch, right?

Whether this takes them six days or six weeks or whatever it takes them to do this launch. It separates your soft launch from your hard launch. And at that point that hard launch goes out, you know that feature is going to be there because. It’s in a feature flag mode. It’s in beta. It can just be turned on as opposed to you trying to figure out if you can actually get things out on that date and possibly losing scope and quality along the way.

So make sure that you use the soft launch to give your marketing team heads up on Where they’re going with it use that soft launch to give them confidence in the feature and, show them what the feature is actually going to be as opposed to them hoping it matches the original design specs from earlier on.

And basically this means that your campaigns have a better chance of success. You’re always going to have a constant stream of campaigns going out. They’ll just be shifted by Whether it’s six days or six weeks or six months for the marketing team to make their their launch happen. But it then has a list of really solid campaigns that always work and the product’s always there for them backed up with great testimonials and videos and everything they need to create to make that campaign really pop.

And then with customer teams, right? One of the really key things we have customer teams. We’re talking support, customer success, account management, customer service. They no longer have to deal with complaints when dates are missing, when dates are missed, right? Cause you’re not sitting here making promises of what’s going to be delivered and when you’re focused on solving the right problems for the business.

And things are constantly going out the door because you’re shipping faster, but. If you have a customer facing roadmap that shows a whole bunch of due dates and delivery dates, you’re beholden to either hit those dates or let somebody down, and you’re no longer going to be letting people down. You’re just going to be shipping the right things that make sense for your business and just constantly keeping your customers updated on what’s coming or what’s been launched.

yOu no longer have to field endless feature requests. It’s more focused around which problems to solve, right? So you’re still going to feature requests, but you can align them with the problem to solve and be able to give people a sense as to whether these are the types of areas that you’re focusing on or whether these are areas that aren’t congruent with your strategy.

And you’re no longer taking in customer. Requests and constantly thinking, Oh, should we build this one or should we build that one that we heard last week? You’re focused on solving problems that are important for the business. And then the roadmap itself, the now next later roadmap, as I said, with the sales team, it’s safe to share, right?

It’s easier to understand this roadmap. You can basically say, here’s where it is. We are now. Here’s where we’re going with it. And here’s the reasons why we’re trying to hit. We’re trying to solve these types of problems and build this type of company. And that helps your customers understand whether your product is aligned with their longer term vision.

So it’s not about getting their pet. feature in there. It’s about whether it solves the right types of problems for them, regardless of which feature you actually end up building to solve that problem. So you can use this opportunity to get customer validation and to get buy in on your product strategy and your vision.

You can show them the Now Next Later road map and get that buy in. And then you can iterate your road map based on insights that you glean from these customer conversations. So make use of your roadmap, get it in front of customers and use it to get your get insight as to whether you’re heading in the right direction that, that works for where the market needs you to go.

Justin in the chat had a really good point here. He said, your customers can often be more forgiving than your internal teams. So once you’re able to show people that. You are building towards a solid vision. You are solving key problems. They’re not going to get picky over which feature gets delivered.

When they’re going to worry that you’re actually still constantly building. So show them what it is that you are building and what have been building and then show them the problems that you’re solving that you’re solving for as you move forwards. So let’s really drive this home for your team.

We want to finish your, your presentation to your team here with some stats. And you want to say, let’s not be a statistic, right? We know that 75 percent of businesses anticipate that software project will fail. That whole planning things out in. Many projects lined up on your timeline roadmap.

75 percent of them aren’t going to meet the time scope or cost or quality requirements upfront anyways. So what is this whole planning thing that we’re doing anyways, it feels like a big waste of time. We also know that 32 percent of it projects face challenges because they’re, they don’t have clear objectives.

So let’s solve that by making sure that roadmap is tied back to an objective. If you can’t tie it back to an objective. Don’t put it on the roadmap. We also know that 45 percent of features and functions in software projects are never used. So let’s try to solve for that problem, make sure that we are building stuff that solves real problems and aren’t just being put on the roadmap because somebody asked for it to be on the roadmap, which frankly is how a lot of that stuff gets on your timeline roadmaps.

And we also know that 17% Of projects run the risk of failing so badly that they threaten the existence of the company. So let’s not put the business out of business. Let’s make sure that we’re focused on solving the right problems in the right order and tying our problems, our strategic steps the problems we’re trying to solve back to strategic goals for the business and not wasting any time, not risking the business by building projects so badly that it takes down the whole company.

So with that, I recommend that you wrap up. This is why we’ve got a a slide deck here for you to use. You wrap up and then ask questions, right? Get people’s feedback. Product management process, a roadmapping process is something that you can build and then you can iterate on. This is why we have things like in ProdPad the now next later columns can be renamed.

It’s not a dogmatic approach. It doesn’t say you have to put this on the roadmap in a certain way. You can use it in a very flexible way and take this feedback from your team. Figure out what works for you. If you need to do Q1, Q2, Q3 or some variation of that to get people on board, do that. But take this time to ask questions and get people on board with it.

So this Grab a screenshot of this, if you like, this is a course that you can take. We’ve written this course that outlines what a NowNextLater roadmap is, what are the benefits in a lot more detail than what we’ve covered today, and then practical steps to transition from your timeline roadmap to your NowNextLater roadmap.

So take this course and prepare yourself with. This learning so that when your team is asking questions, you’re prepared. Lesson four is all about convincing your stakeholders, right? Getting those tricky stakeholders on board. We have shared this deck with you as well. So grab a screenshot of this page too.

This deck is basically the same deck that I was just showing you a minute ago. But it has notes in this, in the Speaker section that you can use to talk your team through and get them on board. It’s completely editable, so take out the parts that don’t work for you, add in parts that you think will work for your particular context.

But this is a tool that you can use to get your team on board. Lauren’s just asked as to whether we’re going to be sharing this with the recording. Yes, absolutely. So you’re all going to get a copy of this. Feel free to share it with your teams, share it with your fellow product people, share it around, make use of it.

We want to just help people get away from timeline roadmaps and move them to NowNix later. aNd on that note, I want to invite questions. 

[00:49:44] Megan Saker: That was great, Jenna. Thank you very much. We’ve actually got a lot of 

[00:49:47] Janna Bastow: questions. All right, let’s tackle them. 

[00:49:50] Megan Saker: In fact, Ryan says it feels like we need an after party.

There’s so many questions to come in. So listen, we’ve only got five minutes. We might not get to all these questions. If we don’t, I’ll collect the questions, extract some answers from Jenna’s head and maybe include those in the email afterwards. Okay. So where shall 

[00:50:08] Janna Bastow: we start? Um, there’s so Ryan asked, do we have any good visuals that show how attempting to the team make more at the same time causes them to slow down?

I have seen something like this, so I don’t have one in this deck but I can definitely point you to something that I think might be helpful. Or if not, I can scratch it out. I’ve done it, that same sort of thing on a piece of paper before and showed it to people to make that case. So really what you’re looking for is something to.

Really nail home that point that having people work on multiple things at the same time actually makes them slower. And that is a truism, right? What often happens with the timeline roadmap is that they end up trying to tackle a whole bunch of different things and they don’t actually move faster.

And this was an interesting 

[00:50:59] Megan Saker: question, Janna. How would you respond to the claim that it won’t work for B2B software because enterprise customers require reliable time and feature based roadmaps or they won’t buy 

[00:51:11] Janna Bastow: in? So I’d actually push back on that because most of the time enterprise customers don’t require that, right?

Enterprise customers, just like any other customers, buying the product that you have today. If you’re not able to sell that product as it is today, either the product isn’t good enough, And, shouldn’t be out on the market with a big sales team trying to sell it because it’s not ready. Or you’re selling to the wrong types of customers.

Enterprise customers like to throw their weight around. They like to say, hey, we’re so big that you should go build this one thing. But what you should be doing is turning that around and saying, that’s good feedback. And we’re going to take that on board. But focus on building the thing that’s best for the wider market and is going to get you more.

Of the right types of customers, whether those are enterprise or not. So if you’ve got like a whole bunch of enterprise customers asking for the same thing, you might want to prioritize that, right? You’re moving something up in the roadmap. But each time you take a custom piece of work and you say this enterprise customer wants to buy a product, but it needs this one custom thing that no one else is ever going to use again, that is work that you’re going to spend for that month or several months building that thing that you won’t be able to spend doing.

Discovery work and experimentation led work that’s going to drive the product to the right types of customers in the future. If you’re just constantly building these custom pieces of work that don’t fit with your product roadmap, you’re going to end up with a Frankenstein of a product that can’t really be sold by to anybody and can’t be supported well either.

So it’s really important to actually think about whether these things are worth doing or not, and oftentimes teams who are in the habit of doing that aren’t spending enough time finding the right customers, that ICP were stuck in that agency trap, right? What they’re really doing is they are selling off pieces of their time in order to get small bits of cash or sometimes large bits of cash.

But they’ve got to be and I’ve got a whole talk that I can share on this, the agency trap, you’ve got to make sure that you’re not falling into this agency trap and building stuff just because someone said to jump, right? So you’ve got to find that line. 

[00:53:10] Megan Saker: Janna, we had, A couple of people wanting to know your thoughts on jobs to be done. And that’s sitting as part of the now, next, later. 

[00:53:18] Janna Bastow: Yeah, absolutely. So jobs to be done worked really well with the now, next, later. Basically it aligns with the problems to be solved, right? If you’re saying that there’s a whole bunch of customers who want to have who want to solve for this particular job and your product doesn’t do that now, then the problem to solve is well to.

Allow for people to solve that problem, to do that job. And so that becomes the placeholder on your roadmap. And within there, you might have a bunch of different experiments or things that you can do to help them get to that point to be able to solve that particular job. So jobs to be done is a really good way of thinking about things.

Cause it aligns your customer problems with your business problems. 

[00:53:57] Megan Saker: And this, we’ve got Kayla and Catherine are both experiencing the same problem. How do you set limits on what classifies as now? I have stakeholders that try to push a lot of items into the now when we simply don’t have the resources to tackle every item in the now 

[00:54:12] Janna Bastow: column.

Yeah. Everything is now, nothing is now, right? Exactly. There’s a couple of things you can do. Treat it very much like a Kanban board with work in progress limits. In ProdPad, you can see how many initiatives and how many ideas you have in each column. And if you have only one team working on stuff, you probably shouldn’t have 10 different, um, now things.

Cause are you actually working on that many right now? Or actually, are they just trying to make them look like they’re happening closer by not putting them in the next. So use that forcing function. What are you actually working on right now? What is in active discovery and active delivery? That’s keeping your team busy right now.

Everything else put into the next and prioritize in there. The other thing is trying not to go too granular. Some people break their problems into really granular, little tiny problems, and they’ll have 20 different problems. And actually, if you took a step back, take a step back, you’d realize this is one problem area, and this is another problem area, group them together and tackle them.

And, as they move into your now column, you can break them down into more detail. But try not to have. hugely granular roadmap that becomes a pain in the butt to read. Ideally, your roadmap shouldn’t be any more than what fits on a screen or two, maybe a scroll but not a big scroll. You want something that if you printed it out, it fits within a printed page or two.

So you can hand it to somebody and they can read it. You don’t want an overwhelming roadmap with all the things. It’s not a replacement for your backlog. Otherwise it doesn’t actually tell people what your strategy is.

[00:55:39] Megan Saker: We are now out of time. We still have a whole bunch of questions here that we haven’t answered.

So I think the best thing we’ll do is, like I say, I will collate them all and we will write out the answers and make sure you can all see what was asked and indeed Jenna’s reply to that. Thank you very much, Janna. That was great. Like I say we will email round both the recording and the course and the the slide deck so you can take that away and use that with your stakeholders.

So best of luck making the move to Now Next Later and do let us know how you get on and if you want any more help. 

[00:56:21] Janna Bastow: Yep, absolutely. So everybody’s looking to make this transition. Get in touch. Let us know how you get on with it. Let us know who your tricky stakeholder is, and we’ll be happy to help you through, provide any guidance on that.

We’ve probably written something for it. And as Megan said, that we are going to take your questions and make sure that we we get those answers out for you because this is a an area that is fraught with contention. So let’s help you get through it. Good luck with everything, grab that presentation, and we’ll see you on the flip side when you’ve got your NowNext later.

Good luck everyone! And bye for now.

Janna Bastow: Hi everybody and welcome. Thank you so much for joining. This is the product expert series of webinars that we run here at ProdPad. And as I said, it’s a series of webinars. We’ve run a bunch of these in the past. They’ve all been recorded, so you’ll be able to find that on our YouTube channel. There’s been a mixture of presentations and firesides like we’re having here today, and it’s always with a focus on these amazing experts that we bring in, who bring their insights their learnings, their experiences, and it’s always with the focus on the content and the learning and the sharing. So today is gonna be recorded and shared, and you are gonna have a chance to ask questions, and we’re gonna follow up and send that recording to you afterward as well.

Sound good? All right, so a little bit about it before we get started. So this is a tool that was built by myself and my co-founder, Simon, when we were both product managers ourselves we needed tools to do our own jobs as product people. So we definitely felt the same pain that a lot of you are. We needed something that’s gonna keep track of the experiments that we were running. We were asked to, hit a bunch of business objectives, solve a bunch of customer problems, and keep tabs on all the ideas and all the feedback that was building up in our backlog. So building ProdPad gave us control and organization and transparency, and it wasn’t actually long before we started sharing it with other product people around us. And so today it’s used by thousands of teams around the world.

It’s completely free to try. We do have a sandbox mode as well, which you can access, where it has example product management data, things like lean roadmaps and OKRs and experiments, and everything else all fit together in a product management space. So really helpful for trying it out for yourself, seeing how it all fits together, showing it off to your colleagues, that sort of thing. Our team is made up of product people as well. So we’d love your feedback. Get in there, start a trial, and hit us up. Let us know how you get on with it. And on that note, I wanna introduce you to my product expert peer and my good friend Matt LeMay. Hey Matt. I know I know Matt through the Mind the Product network originally like I know a lot of good product people. And I think I first saw you doing a talk at the product leadership event in San Francisco, so I’m casting my mind back. And I, there was one particular idea that stuck out to me from that talk, which was the one page one hour that you mentioned there. But I also remember that your talk was just engaging and funny and it tore down a lot of these product management concepts that we talk about. And you’ve since encapsulated those in, in your book here, we’re gonna be talking about as well.

 We also had a bunch of times that we’ve crossed paths since then. So, very recently we hosted Matt at the ProdPad HQ when he was speaking at Product Tank about how product management relates to Layer Cake. So we might be able to get him to talk us through that ’cause there is a connection and it’s not just ’cause cake is tasty. And also we shared a stage together recently at UX Brighton. Matt closed the show and it was awesome. He had this great gift game and truth bombs that just s- stole the show. So we’re gonna be talking about his book Product Management Practice as well as Cake one-pagers and probably a lot more here today. So, Matt, do you wanna jump in and give an introduction of yourself?

Matt LeMay: Sure. That was a better introduction than I could give. Thank you so much Janna.

 So yeah, like a lot of people I got into the product completely by accident about 12 years ago now. And like a lot of us, I can’t seem to quit it. For all the challenges and all the setbacks and all the bad days, I’ve had ’em, all the literal and figurative tears I just think it’s so exciting to get to work with people to do things together. I think a lot of my journey has been going from a place of being frustrated that my work can only be realized through the collective efforts of a team to really embracing that and learning to accept that in a lot of ways product management is a very high stakes, very low control environment. And if you can learn to accept and embrace that, then I think you can learn to roll with the punches of this crazy thing we call life a little bit more. So that’s [laughs] that’s what I’ve been thinking about lately.

Janna Bastow: That’s a really good way of putting it. And actually, you just touched on something that makes me go quite a lot. Because product management was once called, one of the unhappiest jobs, I think is an American survey of one of the unhappiest jobs in America. And yet I talked to product managers all over the place who have a mixture of feelings, always strong feelings about their job. They either love it or they hate it, or both at the same time. Like what is it about product management that, that makes people love it and hate it and have all the feels?

Matt LeMay: So it’s funny, I was just in Paris last week speaking at a product event and a French product consultant, gave a really great talk and he said, “I don’t think product management is actually intrinsically hard work.” He was like, “Nobody’s forcing you to do anything that’s, too physically demanding. You have predictable hours in a lot of cases, you have a good salary. It’s not actually intrinsically challenging work.” And through our conversation, we got to a point of agreeing that a lot of the challenges of product management are challenges to your ego. There are challenges to your sense of self, to your sense of the ability to accomplish things and, to feel like an effectively accomplished person in the world. I think product management has a tendency to attract very type-A people who like to get things done and who like to do a good job and tend to confound and frustrate us at every possible turn.

But once I think we start to recognize that, okay, this is the nature of the work, again, there’s very little I can actually accomplish on my own and many of my attempts to go off and accomplish something on my own will actually be to the detriment of my team and my business and our users. There’s a radical acceptance in product management where I’ve seen a lot of folks reach a point where the things that once frustrated them, that once left them feeling exhausted or feeling like they needed to stay late and fight every fight until the bitter end. Once they’ve learned how to pick their battles a little bit to say, “Okay, I did my best. I made the stakeholder aware of this, they made their choice. I trust that they might have information. I don’t, I trust that they have their reasons. It’s not my decision. I’ve done my part. I’m gonna disconnect and sleep well tonight and live to fight another day.”

I think once that clicks for people, it can actually be, I don’t wanna say easy work ’cause I don’t think it’s easy, but those challenges can become rewarding and generative challenges rather than just purely frustrating and disappointing challenges.

Janna Bastow: Yeah, that’s actually really interesting. Your idea around picking your battles, understanding what sort of things you can win, and can’t win. I, one of the things that you put pretty early on in the book, which I really appreciated was managing senior stakeholders, and managing up.

 Which I know is just, it’s so difficult and, you hear people giving advice, but it’s only when you’re actually really in, on the ground doing it. What are some of the things, some of the pitfalls you’ve seen with it and how do you, y- you talk some of the product people that you work through work with through it?

Matt LeMay: Yeah, so when I started working in product, one of the first things I was told is that your job is to basically bat away executives. Like they’re gonna come to you and say, “Build this, do that.” And your job is to say like, no, go away. My team is doing this thing.” And I did that and I got quite good at it, but ultimately my team suffered for it because for better or worse, the reality is in most business environments, those senior stakeholders probably know things that you don’t. They might know that a conversation took place for the company, the goals shifted a little bit. They might know that there’s a big acquisition about to happen that they legally cannot tell you about, but that’s gonna shift the way that the company does business.

I think the biggest mistake I made early on was feeling accomplished whenever I got a senior stakeholder to leave me alone or leave my team alone and let us do our work rather than saying, “Okay, if they’re coming to me, there’s something here. They’re interested in something, they have some information.” My job is to approach them with that same curiosity and be like, “Okay, cool. What about this is interesting? Like, we prioritize these things, but here are the goals we’re working towards. Have these goals changed? Is there something else that we should be aware of? Is there something we can’t be aware of but we need to, at least account for in some way?”

I think a lot of the stories I heard when I was interviewing product managers came down to the grudging, but an unshakeable acknowledgment that again, senior stakeholders might know things that you don’t, and they might be privy to conversations that you are not privy to. And rather than trying to get them to leave you alone and let your team just do what you agreed to do, every opportunity you had to engage with a senior stakeholder is an opportunity to learn more about what matters to them, what their goals are, what they’re working towards to help build that understanding, to help get a better sense of how they work and what they want and to help them understand the trade-offs that are going into your work because in a lot of cases they don’t understand that.

So I think learning to approach those interactions with humility and with curiosity… I mentioned this a little bit in the book, but I’ve even cooled on the word influence because I see people going and like, “I’m gonna influence executives to do what I want.” And it’s like, “U- ultimately, w- what you want them to do might not actually be the best thing.” So if you can inform them, help them understand the tradeoffs that are being made, make sure that they know everything you would want them to know and that you know as much as you can about what they’re thinking about and working towards that’s when I think those interactions become really valuable.

Janna Bastow: Yeah, I think that’s a really good point. In the same vein, you wouldn’t wanna influence your users to tell you something in discovery, ’cause that’s not good user research, right? Just like you wouldn’t want to influence your senior stakeholders to go in a particular direction by, maybe not giving them all the information or, by framing things in your way. I, think about the stake- senior stakeholders like users, right? They have information and so you can pull it out of them.

Matt LeMay: Exactly. And there’s a sickness in modern organizations around the presentation and the clapping at presentation and, and the extent to which people prepare to present ideas to executives and they become these enormous shows with fanfare. And it’s like… “Present to the executive.” And the executives ask serious questions. And if you survive the gauntlet of the executive challenges, then everybody goes, “Yay, you did it. You presented, you had answers to all the questions.” It’s like, yeah, but like, did anyone actually learn anything? Did we actually have a meaningful exchange of information? Were new questions asked that would not have been asked otherwise? Or did you just go out there and per your point, kind of cherry-pick data and try to present a case that’s gonna make you feel good about yourself, even if it doesn’t present the complicated realities of the situation you are building into, the customers you’re building for, the markets you’re building for?

Everything is a trade-off. There’s very rarely if ever a clear right answer in product management. And yet I think so many of the ceremonies and rituals around business feel almost like, like a demented game show where we’re trying to win the approval of the executive who will tell us that our slides were pretty, and our arguments were airtight and we effectively play acted this thing, rather than just going in and asking questions and trying to learn and make the best decisions we can together.

Janna Bastow: Yeah. But who’s perpetuating that? Is that the product managers and the mid-level people coming in saying, here’s the big presentation, or is that more of the expectation of the senior management who, are actually expecting this ’cause this is what everyone else is doing, that’s the bar?

Matt LeMay: Oh, I think it’s everybody. I think it’s like five Spidermen pointing at each other. [laughs]. And I think, shifting the center of gravity around people, how, around how people are rewarded and recognized, that work is incredibly hard to do.

 It’s incredibly hard to do and it takes a lot of discipline and a lot of courage from everybody to actually shift that. And it’s really hard to do that. And honestly, in a lot of cases, it’s not because people are hoarding recognition or trying to resist change, it’s because they don’t want to withhold recognition from others and they don’t want other people to feel like that big presentation they gave was a waste of their time or wasn’t valuable or wasn’t awesome.

So I think one of the things that’s really challenging is that especially for leaders, you have to get comfortable telling somebody like, “Hey, I really appreciate you putting this together, but for future reference, like, this isn’t what I need. Can we do things this way? Can we do things differently? Can you bring me something incomplete? Can you bring me something shorter than this? Can you bring me questions rather than answers? Can we actually work on this plan together rather than you going off and spending however long and presenting this and getting that hit of dopamine that you did a good job and got the recognition you wanted?” similarly it takes courage from product managers and people to show up and say like, I’m not showing up with the big fancy deck, I’m just showing up like, here is the trade-off. Here’s what we’re working on, here are the questions I have for you. What questions do you have for me? Let’s figure this out together.”

Janna Bastow: this is probably why, I- it’s so difficult to break the status quo and this is probably why it makes headlines when you see, I think it was Bezos who told his entire company that no one can do presentations anymore. They all had to do written versions of their articulate everything in written form. Which, all these doing is shaking up the status quo of how people were probably communicating in the business. Doesn’t seem like all that much, but overall, if you think about how it’s gonna get people to react and think about what they’re actually saying, could have a step change for the business.

Matt LeMay: Absolutely. And one of the books, I wrote another book called Agile for Everybody when I still had any interest in talking about agile [laughs]. And I interviewed a guy called Thomas Stubs for that book who worked at Coca-Cola because I read on a blog that, and this is timely, he had finished, his team had finished, an event marketing campaign for the World Cup 2014 early. And like it is very rare to finish an event-based marketing campaign early [inaudible 00:17:14] event-based marketing campaign. And I asked him what agile secrets did you use?” And he was like, “No secrets. I just banned PowerPoint and banned email. I said if there’s a conversation to have, pick up the phone or you get in a room and you talk it out. And that, there, there have been two agencies working on this project that did not communicate very well with each other and that tended to send this kind of long passive-aggressive emails or these long PowerPoint presentations really trying to make arguments at or around each other rather than solving problems and making decisions together. So this very simple rule wound up saving them, tremendous amounts of time. And yes, there were awkward conversations at times when things got tense, but they handled it directly and they were able to move forward rather than… And I’ve done this before. I certainly early in my career and in my personal life would, was a big fan of like the five-page email that lays out my perspective so perfectly that nobody can be mad at me. But it turns out that’s not how humans work and they still can [laughs] and will be mad at you and understandably so. Because when you try to anticipate what you think somebody else is going to say or feel or think and you have a five-page airtight argument with your projection of that person, it is not actually terribly considerate to that person’s perspective or feelings.

Janna Bastow: Yeah, absolutely. Y- you talked a bit ab- you talked a bit about this at the I think it was the Mind the Product engage stage when you talked about the documentation and how you shouldn’t how you bend comments on documents. And ever since then I’ve been really conscious of now like, ooh, am I leaving a comment, or am I actually just suggesting a change on this? Am I getting more involved with it? You wanna talk us through your thinking on that?

Matt LeMay: Yeah, so, I was working with an organization a couple of years ago where every comments thread became a pitched battle over nothing important because everybody wanted to contribute. So you’d send around a document and you’d send it to 20 people and 20 people would leave comments and each of those threads would become a big back and forth, is these the right words? Is this what we really think? Most of those conversations had very little to do with the actual purpose of the document. And yet people wanted to understand each other, they wanted to be considerate of each other, and they wanted to take each other’s feedback and comments seriously. So there was a lot of engagement with things that were ultimately very trivial.

So what I started doing was with that organization, I just turned off comments and I left a little thing at the beginning and said, “Hey, I turned off comments, not because I’m taking this document as something really precious and important, but rather because I’d rather we just make the changes together. So if you have any changes you wanna make, here’s the meeting where we make the changes. And if not, just like ping me on Slack and we’ll talk through it.” And that worked pretty well.

One thing I’ve been doing, which has worked really well, which I actually wanna write something about this week, I’ve been doing a style guide at the beginning of documents with comments that basically say, “If you are uncomfortable committing to any language or any idea, highlight it and read and leave a comment with a suggestion. If you are uncomfortable but willing to commit, highlight it in yellow and leave a comment with a suggestion. And if it’s really just you just wanna leave a thought or a comment with no action required or requested, just leave a comment.” I worked with a company recently that shared a strategy document with 60 people and I was like, “Oh my God, this is gonna be terrible.”

But it wasn’t because that many people actually cared enough to highlight anything in red. There were a fair number of comments, but nobody really felt that strongly about anything to the point where they would throw themselves in front of the document and say, “No, I’m gonna make myself a blocker.” And that presents its own challenges and I think there’s always facilitation work to be done, making people feel comfortable and helping provide space for people to provide that kind of feedback. But I think putting some structure around the way that you use comments, deliberate communication is the thread in a lot of the work that I do. Yeah.

 … but in some layer of deliberate structure around the way the comments are used I think is really important.

Janna Bastow: Yeah, absolutely. You enabled them by giving them a language by which to better articulate what their comment was. ‘Cause, otherwise it’s just, a comment that gets as much weight on the page as the next one. And sometimes it’s the comment is just, yeah, I like this. Or hey, can we change this too? And it’s like, a grammatical error or opinion versus, something else where it’s like I don’t think we can legally do this.” Like these two things [laughs] need to be highlighted in different colors. I imagine, Google Docs in the future, if there’s any product managers from Google Docs, maybe take some hints here and come up with different ways of coloring highlights so we can build this into workflows.

 Yeah. And somebody had a question in the chat here. And this one speaks to me ’cause actually, she sent it to just the two of us. But she said something along the lines of how managers have this mentality of don’t bring me problems, bring me solutions. And this one speaks to me because one of my very first bosses had very much this same line and I took it to heart like I would not go to him unless I had a solution. And I always thought I had solutions, right? I thought that my job, was to come up with solutions ’cause I was a junior product manager and therefore, knew everything. And it was a, I- it was problematic, right? Because I would end up not raising problems when I saw them. I would have to… I felt like I had to step back and go and figure out something before I actually raised something. Now, what’s your take on this?

Matt LeMay: Yeah, so this one kind of has two sides to it, right? Because I see the opposite thing happening as well where I’ll work with teams who weaponized this word solutioning, where if somebody starts proposing a solution, they’ll be like, “You’re solutioning. Stop it.” so I think anytime you’re like trying to police what kind of conversation can be had, whether that’s no solutions, only problems or no problems, only solutions it probably chills the conversation.

 One thing I found is that when I’m asked to bring solutions, I think some people understand problems better by looking at solutions. I think that’s just the way that some people’s brains work. And I always try to bring them multiple solutions because I think sometimes by evaluating multiple solutions, by staying in optionality, you can start to understand the problem better, right? So when someone says, “Don’t bring me problems, bring me solutions.” It’s like, “All right, here are three solutions to the same problem. Like, let’s walk through these solutions, look at the trade-offs of each one.” By doing so, you can sometimes start to understand the contours of the problem a little bit better and like what exactly the problem is.

So, for me, I try to always present multiple options. I coach a lot of product managers like you never wanna show up with the one idea you’re defending. I did this, I did a workshop a while ago where I had product managers play-act this. I was like, “One of you pretends to be the executive, the other pretends to be the product manager, shows up with one idea.” They’re like, “Here’s my idea.” And the executive’s like, “That’s bad. Don’t do this. Like, you could do this differently. What about this, what about that?” And then another group, I said, “All right, now you present three ideas.” the executive is like, oh, this one, like, it gives you more, it, it creates less of a battle of wills and more of you versus me dynamic and actually gives decision makers a chance to flex that decision making muscle a little bit and be like I like this about this one, I like this.”

And if you’re, trained and experienced in facilitation, you can start to level up and be like, “Okay, cool. This solution is more geared toward this problem. This solution is more geared toward this problem. So if we’re steering toward this solution, maybe that means that this problem is more valuable to us. Can we agree on that?” So again, I think the trick is always to stay in optionality and stay on that rapid kind of dialectical loop between problems and solutions so that you can use one to better understand the other.

Janna Bastow: Yeah, as a product person, I love problems and I love solutions. I see myself as a matchmaker between them.

 People come to me with all this stuff, all these, solutions, potential problems, ideas, s- suggestions, all this stuff. And I’m sitting here going, “Okay, well if I connect these dots, if I do these solutions, it could solve this problem. Or if I’ve, think that these problems are the m- most important, then it could be these solutions that I try.” and as a product manager, it’s your job not to cherry-pick one thing versus one thing. It’s looking at the set of information as a whole and trying to make the best decisions outta that. This is one of the reasons why product management is so difficult. You’ve got all of this information, all of these choices, so much optionality, so much choice.

Matt LeMay: Yes, and making a decision is often the hardest. So that’s where the layer cake comes in.

Janna Bastow: Yeah, go on.

Matt LeMay: So, when I’ve worked with folks at especially medium to large organizations, I’ll often hear from them like I can’t make a decision because we have our, like company goals and we have our company initiatives and I have my team goals and we have our OKRs and we have my… and they’re all like they’re not aligned with each other.” Like somebody showed me a graphic of how they’re all supposed to cascade with each other perfectly and they don’t. So I can’t do anything and I can’t make any decisions. And I’m sympathetic to that because again when you learn the theory of product management, you do often learn that it’s like the CEO sets the goals and then they cascade perfectly, and then the teams and there’s this per- but like, it’s never that way. There’s always tension between these different layers.

So I’ve started to think of it, I don’t know if any of you have watched the show Nailed It, where people who are untalented bakers or inexperienced bakers, I don’t wanna make any essentializing statements about people’s baking talent bake and they make these like big messy cakes. And I think it’s like that where in most organizations the different layers of organizational goals and strategies are like this messy cake. But like you have to take a bite. You can’t just be like, “No, I’m not gonna eat any cake. I’m gonna starve.” You have to take a bite of the cake and make the best decision you can with incomplete information and information is always incomplete. And once you acknowledge that information is always incomplete, forces you to think, to like see the value in some of the theories more where you’re like, “Oh, it has to be test and learn. ‘Cause, there’s never a complete enough information to not test and learn.”

Like we have to actually like ship more frequently and make adjustments more frequently because we never know that what we’re shipping is really what our customers want until they’re either using it or not using it and we can learn more about how they’re using it. So I think again, once you acknowledge that there is no such thing as complete perfectly cascading information it actually, in my experience, it freed me up a little bit to understand like, oh, okay, like this is where a lot of those ideas actually become pretty common sense, right? Like once you acknowledge that there is never a clear right path you have to do a lot of those things because there is no certainty and there is no safety. So that ability to learn quickly, to adjust course, all those good ideas at the heart of the agile manifesto that we tend to forget about all become pretty again obvious.

Janna Bastow: Yeah, absolutely. 

And I think there’s also an element of people assuming that the grass is greener on the other side or that their company that they’re in is a big mess. Their cake is an absolute nightmare and everyone else’s cake is fine. ‘Cause the reading, they’re learning from the books and the medium articles and the people who write big threads about it on Twitter. And these are the people who you know, often aren’t spending their time actually managing products and, creating these systems.

They’re the ones who did it maybe some time ago and since then have spent their time coaching from the outside and telling people the best way of doing it, which sounds great. But in reality, I get a chance to see inside lots and lots of companies and most people assume that everyone else is leaner, more agile, more put together than they are and they’re all trying to get there and they all feel quite, you pick up on the sense of shame going, “Oh, I, we’re not there yet.” It’s like, “It’s okay. No one’s there yet [laughs].”

Matt LeMay: Yeah, no one’s there yet. I think what people miss when they talk about things like the Spotify model or the Base Cam model or whatever is that these are models that are named for companies because companies experimented with ways of working that at one point in time worked for them and have experimented into new ways since then. But yeah, I mean I used to… So fewer people asking about Facebook now than used to as an example of a company doing product well. But when I did workshops and training people use to say like, “How does Facebook do product management?” I’d say, “Okay, I want you to pull out your computer and a piece of paper. I want you to use Facebook for 10 minutes and write down on that piece of paper everything that’s so broken about the Facebook experience that you would fix it on day one as a product manager there,” and people would run out of paper.

And I’d say, “All right, do you still wanna know how Facebook does product management?” I, I wouldn’t say that to pick on Facebook specifically, but just to say that any organization at scale has human problems. Getting groups of people to build complex systems is not easy. And all the companies, whose white papers and recruiting propaganda you’ve read have their own challenges too. As you said, the grass is not always greener, the grass is different. And I think over time people sometimes find a set of problems or challenges or constraints that they’re more comfortable and feel better working within, but there are always constraints and learning to work those constraints rather than throwing your hands up and saying, “Oh I can’t do anything,” is I think one of the most important lessons for a product manager over the course of their career.

Janna Bastow: Yeah, absolutely. Then, one of the things that I would say to product managers, ’cause the best way to level up is to get experience, right? Is just to get in there and do it and have the years under your belt. Because over that time you’re going to run into things that go wrong and go right and you’re gonna learn from those. But the next best way is to learn from other people’s experiences. ‘Cause, you can certainly fast-track that. And so sitting and listening to other people’s stories, reading other people’s stories, it’s one of the things I really liked about your book is that it’s filled with anecdotes from, product managers. “This is so and so from this company and here’s a little anecdote of how it went wrong for them [laughs], and here’s the lesson on that [laughs].” these are all little things that you can go, “Oh yeah, we’re in a situation like this, I’m gonna not do it that way.” and these are little things that level up product managers ’cause there’s no hard and fast framework, no hard and fast rule. There are just lots of little experiences and decisions that we run into over and over again. And a lot of them are in common.

Matt LeMay: Yeah, absolutely. And that was really important to me when I did both additions of the book that, there were just stories from just pro- from product managers, from like people actually doing the work. Because I think those, you for me, like my worst fear as a consultant is that I’m gonna lose touch with practitioners and start being like, “Do things this way.” so those are the stories and the people I still learn the most from, is people who are like on the ground doing the work. It’s always gratifying to me when I’m like, “Try things this way.” And they’re like, “Yeah, that doesn’t work.” And I’m like, “Thank you.” Like, help me understand how exactly this goes wrong. Help me understand where this broke down. Because it’s in seeing where those ideas break down that you often learn more about how to apply them and when to apply them and when not to apply them.

 So I, it’s my great joy to bring stories from working product managers who might not have the time or the inclination to like write up a Twitter thread or do a post. ‘

Janna Bastow: Cause most of us are working. And I say us, most of them are working, they’re doing [laughs], they’re doing product management stuff day to day, right?

 This is one of the reasons why I tell people in the chat here, to drop your LinkedIn, and connect with other product people.

 And don’t just connect, like reach out, ask what each other’s challenges are in your product. Start figuring out what’s in common, and start going for drinks and coffees and lunches with fellow product people. You learn so much from sharing experiences with other product people.

Matt LeMay: Yeah. People will occasionally reach out and be like, “Hey, can you like mentor me and talk to me?” and the first thing I usually say is, “Honestly, you’re probably gonna get more from just r- reaching out to like working product managers in your network who work for the companies that you might be interested in working for.” Like I have my opinions and I have my experience and I think I’m quite good at the work I do when I’m consulting within organizations, but the kinds of conversations you have, just talking with folks who are doing… Yeah, like, like Kelly here in our chat who wants to talk about product management and government.

 Right. If you’re interested in doing product management and government, which I highly recommend doing, you get to work on things that really impact people’s lives, hit Kelly, up on that offer. T- those opportunities to talk to people who are doing the work are so incredibly valuable. And I strongly encourage everyone here to seek them out and make the most of them.

Janna Bastow: Yeah, absolutely. Now somebody had a question for us in the chat here around, how much of a product manager, how much product knowledge, industry knowledge how much does that play a role in the decisions, and what needs to be built into the product? Like is it important that they’ve got a good grounding in this particular space? Or is it better that they’ve got a grounding in product management practices?

Matt LeMay: I think it totally depends, right? It depends on the organization, it depends on the product, it depends on the role. For me, I think the ability to learn is really the thing that I look for when I’m hiring. Like things change, like you, when people ask me like, “What’s the technical knowledge I need to have?” I’m like, “Gosh, I don’t know.” when I showed up as a product manager 12 years ago, I was like, “I know PHP.” And people were like, “This is a Python shop. Go, we don’t care what you know, grandpa.” And I’m like, “What?” So, I think the real challenge is always being open to learning in context, right? Being willing to ask the technical folks you work with to help explain the systems they work into you. Asking, the p- people…

There are people in a lot of organizations who have like decades of incredible industry knowledge. And honestly, I feel like a lot of product managers don’t reach out to them as much as they should. Don’t say like, “Oh, I want this person to like, just t- explain to me like, how does this work?” Like somebody’s asking like, how do you [inaudible 00:35:56] willingness to learn? I ask a lot of questions like, “What’s something you learned recently that surprised you or what’s something that changed your mind recently?” I really wanna see people’s ability to like speak to the things they don’t know or the things that have surprised them or the things that have changed their mind. The number one thing I interview against when I’m interviewing is defensiveness. Like, if you’re gonna dig in and be like, “No, I’m right.” Then like, I’m never gonna hire you. … I just really look for people who are gonna be flexible and open. And I will say, you in some industries, like if you’re working in highly specialized things, like yeah, there may be situations where you, it just doesn’t make sense to hire someone who doesn’t have that knowledge. But again, I think it depends so much on the product, it depends so much on the situation.

Janna Bastow: Yeah, absolutely. Ultimately the space can be learned by having those conversations with enough customers. Like if you don’t go in and you’re not an expert, that’s okay ’cause you will be an expert within the first six months. You’ll have so many conversations with everyone around you that you’ll pick up on it. So, I’ve seen people move from legal tech to FinTech to health tech to, complex spaces and just be able to pick up the concepts. But the most important thing is around being open to learning these things.

 Now, one of the things that I really like is you’d address in the book right up front is that product manager doesn’t need to work 60 hours a week. It’s a long-standing rumor longstanding saying that product managers need to work 60 hours a week to be successful. And honestly, I think someone needs to call BS on that.

Matt LeMay: Oh, I hate it. I hate it so much.

Janna Bastow: 60 hours is a long time. I don’t work 60 hours. I’ve never, I never did when I was a product manager. That’s insane.

Matt LeMay: No, and like there are a lot of people who can’t work 60 hours a week, and excluding those people from our community in our profession is a terrible idea.

Janna Bastow: Yeah, I absolutely agree. I mean I think it’s really good news to hear that in a year full of burnout a year, quitting a year when you know actually after a couple of years of just really hard graft work that you know what to be a good product manager, you don’t need to be putting in the hours. And what can a product manager do to be really impactful with their time?

Matt LeMay: Yeah, so I was talking to Ken Norton a while ago. It was one of my favorite product people. And he said something that really stuck with me in his mind, as product managers climb their career ladder, the thing they begin to understand is leverage. Like, what are the points that have the highest leverage? What are the changes I can make, the things I can do that are really gonna have the most impact, that is gonna cascade the most through the organization? And I think that’s a really smart point. Because I think when I was a baby product manager, I’m like, “60 hours a week is so much.” Like that’s what, 12 hours a day, five days a week, that’s like 9:00 AM to 9:00 PM… Like that is so unhealthy. That’s just bad for you. Like that’s bad and dangerous and sounds horrible. I would never wanna do that again.

And I say again because early in my career I did do that, in part because I was really insecure. I was new to this job, I didn’t know what I was doing. I wanted to show that I was working hard. I wanted to show that I was, this was New York 2010 I was hustling and grinding and doing all those things you’re supposed to do. And per Ken’s point, I did not understand leverage. Like, I just did not understand the impact of the work I did. And I didn’t understand that in a lot of cases the work I was doing was creating more work for my team and was creating unreasonable, unhealthy expectations for my team. There’s a moment in my career I think about a lot. A- as with a lot of product folks, I used a lot of self-deprecation early in my career to make myself feel better and alleviate some of the pressure.

When I had to ask my team to do something, I’m like, “Bruce, sorry, it’s me, the product manager, blah, deadline, blah, product manager. I’m terrible. But it’s okay, I’m working all night and I hate myself.” And I got an email from an engineer I worked with it was just like, “Hey man, are you okay? Do you really think you’re doing a bad job? Like, ’cause I think you’re doing a good job and I want you to be okay.” And I was like, “Oh no. Like I’m really like, this is manipulative.” Like this is not who I want to be. Like I don’t wanna be the person who’s like using self-deprecation as a strategy. I don’t wanna be the person who’s staying late because I want other people to think that I’m the kind of person who stays late.

And I hit a point when I was working at Sanzo, which was one of the best experiences I ever had professionally, where, we’d have our daily Standup and I’d be like, “I’m pretty much done with stuff. So like, if you do need help with anything, come and get me. I’m just gonna be like using the product and making some notes and plan on some user interviews, but like anyone needs help, you know where to find me, got a light load today.” And people will come to me for help. And it was really good. And everybody was like, “How dare you, you’re not working 60 hours a week.”

I remember really clearly at that same company I once really wanted to take the… I think we were working in Long Island City in New York, and I wanted to take the whole team out to this amazing Thai restaurant called Super Thai in Queens. And that thing happened that happens at a lot of organizations where everyone’s like, “A long lunch, can I do this?” And our CTO was just like I’m going so I don’t know what y’all think is so important.” And like the whole team just went and it was such an important bonding activity for the whole team.

So, I used to have a friend who worked in internet radio who said, “There’s no such thing as an internet radio emergency.” And I think at a lot of startups it’s worth keeping that in mind as well that it’s so easy to take on this sense of things being so important. And so like you can take on the weight of the world as a product manager and be like, “Oh, I’ve gotta do all this stuff. I’ve gotta stay late.” But like A, you probably don’t. B, your company probably, you’re an employee, you’re not you don’t owe them more than what you are contracted to do. And I’ve had to learn that the hard way a couple of times. So take care of yourself, pick your battles balance your energy, and manage your time, and you will not only do better work, but you will set a better example for your team and you will be a happier person.

Janna Bastow: Yeah, absolutely. And I think, setting an example for the team is really important. As a product manager you’re sitting in a really key role. People see you n- not, I’m not gonna say CEO of the product, but as somebody who often is a communicator of the management values, right? You’ve got this direct line of communication to management and you’re often setting the pace. You’re often setting the examples for the people on your team.

And if you’re sitting there working 60 hours a week, other people are gonna feel like they do that, they need to do that. Then the company creates this culture of like, it just has to work harder and harder. And if doing that, like ultimately means that the company, the bosses, the execs, they’re never going to pitch in and hire more people when the company needs it. 

Matt LeMay: If you’re having to work they’re gonna hire people and those people are gonna get upset. So there’s a story in the book about this, which kind of blows my mind where I was interviewing a product leader and he was like, “Yeah like we have these product owners, all they do is complain about how overworked they are, so I’m gonna hire more product owners.” He came back to me a couple of weeks later, he was like, “I hired more product owners freaked out. Like, ‘Why are you taking things away from us? Are we doing a bad job?'” And I was like, “All right, what goals are they working towards?” He was like, “Oh my God, we don’t have our goals defined.” Which is almost always what the, Oh my God moment, winds up being. Whether it starts with a question of role clarity or it starts with a question of like how people measure their own success.

If people don’t know what success looks like, they’re gonna find proxies. People wanna be successful. So this team had taken on overwork and like, “Look at all the products I own,” as their sort of informal proxies for success because they didn’t have a way of looking at the impact of their work. So I think about that a lot because I’ve seen that bizarre dynamic where executives are like, “All right finally, we’re gonna hire more people.” And people freak out and like, “Why are you hiring more people? Why are you taking work away from us?” And it’s like literally last week you were crying about how overworked you are and now you’re upset that there are people coming in to take away your work. And again, I think so much of it just comes down to like, can you be clear about what success looks like and specific enough for people to understand that?

Janna Bastow: Yeah, that’s a really good point. It’s really good to have that insight. Something else you said in the book wanted to ask you why are, it’s fine, phrases, the phrase, it’s fine. Why are they the two of the most dangerous words in product management?

Matt LeMay: Yeah. So, one of my guiding principles for product management is clarity over comfort. And looks fine or like, that’s fine, is not a statement of clarity. It’s a statement of like, it’s like a dismissive statement, right? It’s like, yeah, sure. Only specific affirmative buy-in. That’s part of why I like giving people choices, right? ‘Cause, you can’t give people a choice and get a response of, yeah, that’s fine. You are forcing people into actually engaging and looking at different options and making a decision. I’m actually putting together, if any of you are joining from Hamburg or Berlin, I will be there for product bank events next week, and I will be given a talk about how to say no without saying no. Because I also think that no is actually not a terribly clear statement, right?

I remember in high school when we would have exams, my least favorite questions were always the really complicated yes, no questions, where it’s like, “So and so was born in this year and moved to this city and this year and did this and this, and then died in this year. True or false?” I’m like, “What? Any number of those things could be true or false. This is impossible.

 And I feel like a lot of product management conversations play out the same way, where it’s like, “All right, we’re gonna build this feature for this customer and we’re gonna ship it on this date, and it’s gonna be this and this, yes or no?” And it’s like, “What? No, this should not be a yes or no question. This shouldn’t be like a sure or no.” Like, we need to really get into optionality and stay in optionality. So, one of the things I learned the hard way I thought naively early in my career that if I showed something to executives and they said yeah, it looks fine.” I was like, “My ass is covered. They said it looks fine. So if it turns out it wasn’t what they wanted, I can’t get in trouble.” Spoiler alert, I could and I did get in trouble. So that was real.

Janna Bastow: [laughs]. Yeah. Oh, you’re absolutely right. Oftentimes if somebody says it’s fine, they just haven’t been paying attention, right? They’ve just gone it sounds like you’ve come up with something good enough. We’ll just let it, we’ll let it slide. Yeah.

 … whereas if you, as you say, you pull in those options, you get them looking at it, thinking about it, you’ll be able to get some engagement with it and then probably some actual thoughts and way to improve it.

 You’ve got a particular tool that I love using. I mentioned this earlier on, which is the one-page, one-hour thing, which is really great for getting that early engagement. You wanna talk us through that?

Matt LeMay: Yeah, so this started in my own work with my consultancy in the states where, was talking to product teams and I was like, “Work smaller, work incomplete, share stuff with each other.” And my business partners would laugh at me and I was like what’s so funny?” And they were like, “You still show up to us with like 50-page workshop plans and just want us to tell you how great they are.” I’m like yeah, but you’re like my business partners and you’re really smart and I want you to see how hard I’m working and how great I… oh, I see.” So again, I feel like in a lot of cases the challenge is to shift the center of gravity around rewards and recognition. Again, many of us learned in school that if you’re given a 10-page paper right, and you write a 12-page paper, you’re probably not gonna get a C on it.

So I was in the habit of over-delivering as a way of getting rewards, right? Getting recognition. So in an attempt to combat that, I wrote out a pledge and shared it with my business partners and said, I promise to spend no more than one page and one hour working on anything before I bring it to the team. Please hold me accountable to this. And sure enough, when I would then come to them and be like, “Oh yeah, I knew we were on the same page, so I went ahead.” They’d be like, “Why did you do this? No, you made a promise. Don’t do that.” So part of the idea was that if you actually make an explicit promise to each other, you can start to shift that center of gravity. You can start to go from like, “Wow, you worked really hard on this a hundred slide deck that I now need to read and share with other people.” To like, “Hey, why didn’t you share this with me when it was just one page and you had only worked on for one hour? Like, I thought we had a deal together.”

So, I think the idea of like working generatively and sharing incomplete things is an idea that we can all agree on in theory. Again, the real challenge is shifting an organizational culture so that people actually have the incentive to work that way. And so they can still get that recognition for working in an incomplete way rather than getting recognition for presenting finished, polished, fancy things at each other. So you can take the pledge at onepageonehour.com. I periodically update the website with anyone who wants to have their name and organization listed. a lot of folks from a lot of fancy organizations have signed it. And it is one of my joys in the world to help share this very simple mechanism for taking an idea that, again, I think most of us can agree is a good idea in theory and giving teams just a shared language and a sense of grounding in how to apply it together.

Janna Bastow: Yeah, I absolutely love it. So I’ve shared the URL there, onepageonehour and absolutely worthwhile pledge to take worthwhile e- exercise to get involved with. It just cuts down on all the presentation-making and all the time wasted in people sitting alone at their desks when they could be having conversations with each other. And speaking of which there’s been some chat in the chat here around roadmaps. And I know that there’s some stuff that actually goes along nicely with this one page one hour, ’cause we had this conversation think it was in Hamburg when we were hanging out around how a roadmap should be something really simple, right? Don’t over-complicate your roadmap into this huge beautiful document that’s, gonna blow the minds of your execs. Instead, keep it really simple. I like to think of the roadmap as being a prototype for your strategy.

Matt LeMay: So I just did a workshop in Copenhagen, which was really fun. It was the first time I did this workshop. And it was called Generative Road-mapping. And I’ve done this in companies, but I’ve never done it as a workshop before where we basically, we were talking about Twitter ’cause it was on our minds. We’re like, “Alright, let’s imagine you have to present a roadmap to Twitter’s investors to make a case for how you’re gonna get the company profitable.” and everybody had 10 minutes to just paper prototype what a roadmap could look like. And then we did a bracket-style. So two people would join up, and they’d be like, “Do we like yours or mine? Let’s make some changes and integrate them.” And we just kept doing that bracket style until we wound up with two of them. And it was so interesting ’cause the ways that people visualized information were so creative and so surprising.

One person did theirs as, like a tree where they were like, we’re gonna lay- we’re laying the roots now and then the tree’s gonna grow. And I was like, “Oh, I really like that because that’s a visual metaphor that can help people understand a [inaudible 00:52:09] horizon.” Somebody else imagined it as a wheel with like different pieces. So I’m really into just like doing rapid generative visual prototyping for roadmaps just to be like, what is the right and visual language to communicate what we’re trying to communicate right now, keeping it really quick? And it’s been so fun to just see like the fun, interesting visual metaphors that people come up with like, Yeah.

Janna Bastow: Yeah, I love that. I think the roadmap should be more creative. You, I think we fall in on some of the usual looks of them. But honestly, I mean it’s whatever allows you to get your assumptions outta your head so you can check them with other people and have conversations around it.

 Now you also mentioned in your book uh, something called the Roadmap README.

Matt LeMay: Yes. That is the first step I always do. And that was part of this exercise as well. Before making a roadmap, I sit down with the team and we write a README document, which is like, who is the audience for this roadmap? What is the purpose of this roadmap? What are they to take away from this roadmap? What are they to not take away from this roadmap? So, per the conversation in the chat right here, like, the distinction between a product roadmap and a delivery roadmap is one that might mean something different in every organization. So rather than assuming that like everybody has the same idea of what that difference is, just write out here’s what this communicates, here’s what it does not communicate.

Like it might say, it says for example, like the broad themes we tend to [inaudible 00:53:36]. It does not say exactly when we are going to deliver these exact features. Or you might say, it does say when we are gonna deliver these features, it does not say what problems we’re solving. There’s a different document that does that. So really think through what is the purpose of this and making sure that README travels with the roadmap. I tell people like, that is the first page of your roadmap argument. The roadmap does not travel without it. I found to be a really helpful exercise.

Janna Bastow: Excellent. I love that. Now we probably have time for just one more question ’cause I wanna be conscious of the hard stop that you’ve got here.

 So thank you so much for taking the time to chat with us. I had a question here from Saielle, our friend Saielle, via Mastodon. She said “What would you say is the most overlooked general practice in product organizations today?”

Matt LeMay: Oh, I’m so glad Sael asked this because my question is gonna come by way of [inaudible 00:54:31] Sael made at the product which is facilitation. The practice of facilitation is so undervalued, and that is as Sael pointed out because it is largely fem coded. Facilitation is seen as something that like women and fem people do. Like, it’s like kindergarten teaching. It’s the soft stuff as opposed to the horror visionary stuff that like the real visionary leaders do. Facilitation is everything. You cannot do any of the things we are talking about without facilitation. The ability to actually get people in a room together to align on a decision and to talk through those things is far and away the most valuable skill you have in an organization. Like I’ve seen so many organizations completely ignore and like condescend to and not recognize folks who excel at facilitation.

And if there is one thing I could change in the product management world, it’s that we would have more folks in leadership positions who are facilitators and who value facilitation. Because it is so, so, so, so important. And it is so not taken as seriously as it should be and not valued as much as it should be for reasons that tie into a lot of the egregious biases that we deal with on a day-to-day basis in the business and technology world. So, thank you Sael for that question. For any of you who are Mind the Product Mind the Product subscribers, please watch Saielle’s talk the F words on product management from this year’s Mind the Product. ‘Cause, it was a barn burner, it was amazing.

Janna Bastow: I’ll definitely drink, drop the link for that in the transcription and the notes. But thank you so much for raising that point. It’s such an important point and I think it needs to be amplified. So I really appreciate that. On that note, I wanna say a huge thank you for taking the time to chat with us today. Matt, it’s been wonderful having you here today. So thanks again everyone for joining. Great to have you here. Matt and everybody take care and see you next time. Bye for now.

Matt LeMay: Thanks ,y’all.

Watch more of our Product Expert webinars