Skip to main content

Product Management Webinar: Product Decisions

Making Better Product Decisions

How can teams make better product decisions?

In this fireside chat, Joe Leech and Janna Bastow will jump into the tricky topic of how teams can make better product decisions. They’ll explore frameworks like Jobs to be Done and how to optimize for speedier decision making, and give you instant insights you can start using in your day-to-day product world.

About Our Guest Speaker

Joe Leech coaches founders and leaders at large organisations and start ups to help them build the right things in the right order for the right reasons.

He is also the author of the book ‘Psychology for Designers’ as well as a keynote speaker at International conferences like Mind the Product and Business of Software. He is also the author of the upcoming book based on the podcast ‘Making Better Decisions’, where he interviews leaders from Instagram, YouTube and others.

He has worked with big organisations like MoMA, Trainline, Disney, eBay and Marriott as well as helping to supercharge high growth businesses and startups.

Key Takeaways

  • Examples of some bad product decisions seen in the wild
  • How Jobs to be Done can be used to make better decisions
  • How to switch your focus from competitors to what really has impact
  • Asking better questions, getting actionable insights and feedback

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

[00:00:00] Janna Bastow: Hey, everybody.

[00:00:01] Joe Leech: Hello everybody!

[00:00:02] Janna Bastow: Welcome to the ProdPad Product Expert webinar. This is a series of webinars and we have a ton of past talks recorded, so you can always go back and watch the other ones.

We have a mixture of presentations and firesides, and we always invite amazing product experts from around the world to come and join us and talk about the insights that they’ve gathered from their experience. And there’s always this focus on the content and the learning and the sharing and just making sure that you all have great takeaways from the day.

And so it is a chance for us to have a great conversation, as well as you all to jump in on the conversation. So make use of the chats, make use of the Q&A, let us know what you what you think and what kind of questions you have. In the meantime, I am going to introduce you to Joe in a minute, but I am going to talk you through and show you a little bit about ProdPad before we get started. This is a tool that was built by myself and my co-founder we were both product managers ourselves, and we needed tools to do our own jobs.

Essentially, we needed something to help keep track of the experiments we were running to hit our business objectives and to solve customer problems. We were trying to keep tabs on all the ideas and feedback that made up our backlog and building ProdPad gave us control and organization and transparency.

And so it wasn’t long before we started sharing it with other product people around us. And today it’s used by thousands of teams around the world. It’s free to try. We even have a Sandbox mode, which is like a preloaded version of ProdPad that has example product management data, so you can see how things like lean roadmaps and OKRs, experiments and how everything else fits together in a product management space. And we’re going to use it to learn how you might use this to help your own product management processes. And our team is made up of product people. So if you ever have any questions, let us know. And of course, let us know your feedback. Enough about myself and what we’re working on. I really look forward to introducing you to Joe Leech. So Joe is a friend of mine and a great product person in the scene.

I know Joe through the product management circles—he’s been working with the Mind the Product, being doing talks and workshops there for quite some time. And runs an amazing workshop. I think some of that comes from your background as a teacher, right?

[00:02:20] Joe Leech: That’s right. Yeah. I was an elementary primary school teacher for a while. It’s always lovely to go back and wear that teacher’s hat, especially with product people. 

[00:02:29] Janna Bastow: Translates really well to guiding a class, guiding a room of people. And we were just talking about the fact that the last time Joe and I, Joe was actually one of the last people I saw in the real world.

We were on the stage together at Mind the Product Engage in Manchester back in February 2020 before everything shut down. And so I’m thinking back to that with big heart and just really loving that experience and really loved Joe’s talk. One of the phrases that really stuck out to me was “The hole is not the goal!” And he’ll probably tell you a little bit more about what that, and get some context to that. 

[00:03:10] Joe Leech: That’s a really interesting one. Cause that was me reacting to the everybody knows all that cliche and product management of people don’t want a quarter inch drill.

They want a quarter inch hole. It’s that kind of that quote is actually came from economics. And to me. I don’t want a hole. I want to put a picture up or I want to put some shelves up. The hole is not the goal for me in terms of that things. That’s where the hole is not the goal came from, for me, is that always, when I look at what people’s requirements are for anything it’s never. One level deep, it’s always two or three or four levels deeper. The hole is never the goal for me. Never. 

[00:03:43] Janna Bastow: Yep. That the hole is not the goal. It’s not what people actually want to do. And I love how you tied it back to what jobs to be done means to us making a better product decision. And so Joe is also the author of Psychology for Designers and worth pointing out that he’s the author of the upcoming book, Making Better Decisions, which is the topic of the day.

This is what we’re mostly gonna be talking about today. It’d be really great to hear from you, Joe, let’s bring everybody up to speed. Do you want to tell us a little bit about your background? 

[00:04:17] Joe Leech: Yeah. Yeah. So my background before I was a teacher, I studied neuroscience.

My background is really in psychology. So big part of my early career was using psychology really because I came from a user experience background. It was applying psychology to product and digital design way back when, and that was early days with people like eBay. I helped support and led the relaunch of Trainline in 2010 in the UK, which is the UK train ticketing system. Marriott was one of the big ones, I worked on the 2014 relaunch for that in 18 languages, 36 countries. So I’ve done some really serious heavy-weight product relaunches in my career for people like Disney, as well as other people like MoneySuperMarket and yeah, most recently, I basically, what I do these days is I supercharge product managers and teams and leaders. So I work with often with CEOs through to CPOs, through to senior product folks, just to supercharge them and their teams to do good things. That’s really where my background. So via user experience to product, to where I am now working with senior leaders in tech.

[00:05:19] Janna Bastow: Excellent. Very good. And so tell me about this new book that you’re writing—this new angle that you’re on around making better decisions. 

[00:05:26] Joe Leech: This was interesting. So I, had this thing where I would talk a lot about people about decision-making in organizations and because I’d had that quite a varied level of background.

People always say how, do people make choices and decisions in this world? And actually it started when I, in a period when I was working an agency actually, and I, over the period of a year, we worked with two organizations. We worked with hotels.com and we also worked with another hotels company called LateRooms who were very similar.

And this is about when the UK, when these two folks where we’re competing with each other, for hotel bookings in the UK, I remember going one day into Laterooms, Hotels.com have launched this amazing new feature. We should absolutely copy it and take it and we should do this. And it’s okay, doesn’t seem like a great idea, but let’s do it anyway.

And about six months later, I was in the opposite. I was in hotels.com and they were like, yeah, LateRooms has done this amazing new feature. We should totally copy what they’re doing. And it just opened my eyes to the fact that these organizations were just basically copying each other and it’s like this one-upmanship and nobody’s really coming in and transforming that industry.

And so many years later, I got the opportunity to work with Booking.com, who dominate, really now, in the hotel booking space. And what was interesting about them is they don’t focus on the competition. They’ve got an eye on the competition, but the competition isn’t the primary focus.

And that, for me, was really interesting as it was, I’d always suspected that because everything they did was based around customers and their needs. And so that started me on this journey of understanding how do organizations make decisions and choices. And so I started with Booking.com and I was working with them and I interviewed one of the product directors there—one of the lead product directors for that rental car operation, actually here, in the UK. I interviewed him and we worked it out as a podcast and it’s really fascinating to me and I thought I’m going to do more of this. So I, again, having worked on the internet for so many flippin’ years now, I had a good black book of people I could call up and talk to.

And so since then, I, on the podcast, I’ve spoken to folks from WordPress, from YouTube, from Instagram, from The Knot, which is this huge wedding website, just loads of really interesting smart leaders within tech and product, and I just interviewed them and asked them, how do you make decisions then? Tell me, how is this done?

What is your secret sauce of this? And because I just wanted to know it was just really fascinating for me and everybody else wants to know. So I started with the podcast. The podcast really was a place to start. And so what I’m doing now is taking that podcast and distilling that into a book. And we’ll talk about that today.

Some practical tips, really for you lot, to make better choices in the world that you’re in and how you can support your business, your team, and whoever, and making better decisions in the business. 

[00:07:59] Janna Bastow: Excellent. I love that. And I love how the podcast is basically like an MVP of the book, like a way to test the premise. 

[00:08:04] Joe Leech: I wish I planned out to do that. Yeah, that was okay. But yeah books, I feel like, honestly, like you’re shipping an enormous product and it’s one big launch. It’s one big waterfall project and it’s it’s scary, really. So I’ve been blogging lots about it in sprints, but yeah, writing a book. Yeah. Anyway, that’s a different thing, but yeah, definitely the podcast has been the MVP of that. 

[00:08:26] Janna Bastow: Yeah. And you’re talking about those different hotel travel companies that were copying the competitors. And it’s really interesting that dynamic, where they were saying “they’re doing this, we have to do that.” And you, as the product person on the team, you end up feeling like you just have to do it because somebody on the team comes up with this prerogative to do it. And I remember being in those positions as well, where I just assumed that somebody higher up in the business had some knowledge that this was the right thing to do. And so you go along with it and in hindsight, you look back going, I should have called BS on that. ” Where did that come from?” 

[00:09:02] Joe Leech: You assume your competitor’s got an insight that you haven’t got. What was interesting about going to the two of them is neither of them had that insight.

Neither of them had that ability to experiment, to really get to the heart of what the user wanted, like Booking.com do. They didn’t have that. So they were just always one-upping each other. And it was like an arms race between them, which is, don’t get me wrong, it’s a great way to succeed in certain industries, but it doesn’t allow you to leapfrog and to really push and forge ahead, like Booking.com does.

They totally dominate now because of that absolute focus on user need and experimentation to get them there. It was fascinating being in that world, really. 

[00:09:36] Janna Bastow: Here’s a question: Going back, what would you have done different if you were working at, was it LateRooms that you were at? And they were the ones that were copying the competitors?

[00:09:42] Joe Leech: Because LateRooms are gone. They were the big in the UK now, big in Asia as well. And they’ve gone kaput. They were there, their domain was sold for like 40,000 pounds recently. They were multi, hundreds of millions of dollars, hotel booking company across Europe and the UK and Asia as well.

Yeah. What would I have done differently? I mean that, just that obsessive focus on customer needs really is number one, what absolute do our customers need? And that’s not only, because again, they’re a marketplace, it’s not only the customers themselves, but also the hotels at the same time. And back then they had quite an antagonistic, and don’t get me wrong, there’s still a lot of that, an antagonistic relationship with their hotels. And so if I was going to tackle that problem today, if I was going to compete with Booking.com. I would start to build extremely strong relationships with hotels. If you can build a strong relationship with the hotel and you’ve got supply, the market will follow, okay? Any clue with any marketplace, I would do that, but I would have a rigorous focus on matching both sides of that marketplace, because at the moment it’s balance too differently. So absolutely customers and their needs. It’s classic stuff. And often this point, it feels like a cliche to, just to say that you should do that.

But often what’s interesting about decision-making is why people don’t do things based on user need, why they don’t do that sort of stuff. And that for me is more interesting than why, cause everyone knows you should, but what’s more interesting is why don’t organizations do stuff around users and what they need.

[00:11:03] Janna Bastow: Yeah, that’s exactly it. The thing is we’ve been talking about this concept of doing your customer discovery and asking the right questions for years and years and individuals get it. You talk to any individual and they’re like, yeah, totally. I can do this. But when you look at organizations— that company failed back then, but there’s still companies failing today for the exact same reasons, because you have people in the company who are making bad assumptions, and there are other people in the company who may or may not spot these patterns, but aren’t empowered to call it out. Aren’t able to say, Hey, should we go back and do something about this? And what they actually need are the tactical, practical things that they can do to call it out and do something about it so that they don’t end up with some story like you, 10 years later going, yeah.

Company went kaput and we sold it all for pennies. 

[00:11:51] Joe Leech: And I’ve got lots of those stories of bad decisions and failures. I’ve got lots of them and they’re not shared much in our world, but I’ve got a lot of them. And a lot of them share some very similar themes in that they don’t have that.

So I talk about this concept of, I call it the Decision Diamond. And it’s it’s, based around Henry, I can’t even pronounce his surname Henry from, he works at Minecraft now and he was at Spotify for awhile. He had this concept of how decisions are made, he had a triangle.

 Henrik Kniberg. Thank you, Janna. That’s exactly who it was going to be. Anyway. There’s, four points to this diamond. One of those is user research and user insight discovery, classic qualitative user research at one point of that. And there are three of the points where the other one is of course data. Data is key. Really. If you understand what’s going on at scale on your product, that’s really important to know that you’ve got two elements of decision, right?

And there were two more. One of them is obviously business drivers is something. If there’s a business need, there’s a business opportunity. If something’s going wrong in a particular business area, you’ve got some focus through a business lens to go. We should be doing more of this, or should we be doing less of this there’s business as well?

And then the fourth one, which is often I think, overused or underused, if anybody can guess what it might be, as you’ve got your business, you have user research, you have data. And the fourth one, which I think is over often over focused on in some organizations, under focused on the other ones, is instinct or gut feel.

And to make a good decision, you need data points from all four of those things. So often what can happen in organizations that make bad choices is they might come in and instinct or gut feel. Boss says we have to do X right now, or competitor wise just launched this. We’ve got to do it. That is just instinct.

That feels like something we should do. What you need to do as a product manager is stop and go. “Okay, great. What other points have you got on the decision diamond to make and support that choice? Have you got any user research data to prove that this is something that people want? Have you got any anecdotal stuff from user discovery or interview, so as to understand that this is something people need. Is there a business case for us doing that?” And you look at that decision diamond and go, “Okay great. We’ve got one point on there. We need two, and if he got two points of the diamond, okay. It’s probably an okay decision. If you’ve got three points on the diamond, like you’ve got data, you’ve got user research and you’ve got business. Great! It probably should mean, you should definitely do. All four are there—gut feel, user data, user research, and business, get on it.” That’s the point to leap onto it. And what this tool is really great for is not only doing that, it’s making it obvious something you should do by pushing you forward because you’ve got four points, but stopping those elements where you’ve just got one point on that decision diamond, just one piece of data.

So I speak, I’ve spoken a lot, worked a lot with Google over the years, Google are heavily data-driven and typically they would just react to data. And that’s great and that can get you a certain way through, but it’s not going to be a completely solid decision if you don’t. In fact, I speak to in the podcast, a very senior user researcher at Google, who’s trying to empower managers and product managers with the right information to make better choices.

But again, often these things can come from just one data point. And if one point on that decision diamond, if they come from one point, probably not a good place to start, you need to go and get more information before you jump into that decision. And that choice. 

[00:15:02] Janna Bastow: Yeah, I love that, because that actually echoes some of the things that I’ve thought about in terms of you see companies going out there and say, oh, we’re data driven and you go “Is data driven the thing that you really want to be? You want to be data informed. Are you customer driven? And you don’t want to be customer driven. You don’t want to just build things cause your customer say so, but you do want to be customer informed. And so I like that, cause splits it out into the other things that you’re actually considering the business side, as well as the gut-feel side, because some of our job really is just listening to our gut.

And it does sound a little bit unscientific, but keep in mind that there is something that, when it comes to our gut, it is driven by a multitude of decisions that we are making when we actually get to that point. Uncountable number of things that you can’t just quantify and say “this one times this one equals this decision”.

There’s a reason why product managers are not going to be replaced by AI, anytime soon. It still requires humans to make the final calls and say, this is actually the right decision. I can see this far ahead. And here’s where we need to go.

[00:16:08] Joe Leech: I think it fits back into the kind of management style as well. So one of the podcasts I interviewed Jeff Gothelf, as well, author of Sense & Respond, and Lean UX.

We talk in that podcast a lot about how senior managers struggle with managing the uncertainty of product teams. Then certainty of “Yeah, we’re going to run a few sprints and some stuff’s going to come out at the end of it”, where senior managers have been told, so many years in business programs and throughout the kind of 70s, 80s, 90s, and early 2000s to have the answers, to be able to tell everybody what they should be doing right now.

“I’m not a good boss if I can’t tell my team what they should be working on now.” And that is some behavior that needs to be absolutely unlearn from bosses, as they can’t go around saying I know exactly what we should do. And that’s gut feel often for a lot of them and they don’t have the ability to adequately make good decisions because they don’t have that same access to the data and the user research and discovery that product teams have. So what’s great about the decision diamond is it can work really well. When as you, as a product manager, you sketch it out on that Mural or whiteboard, or whatever it is, to the boss, you give them that tool to help them make better choices. Okay. It’s, not just about you. It’s also about empowering the layers of above you in senior management, to make better, choices and not because somebody has a good idea, like a gut feel, instinct idea from senior management.

You’ve got to support that and work towards that, but you’ve got to give them the tools to understand that they’ve not got the full picture of what’s going on and that can work. If you sketch this tool, you could just use it back with those folks as well, which is great. And you’re successful as a product manager when you see your thinking being taken and used by the CEO, when they’re doing a presentation on something as well, that’s the strength of this, is it can flow through the organization. 

[00:17:52] Janna Bastow: I love this. This is actually one of the things I’m really passionate about, is that product management isn’t something just done by the product managers, product managers are the ones who shepherd in a good process for good product management.

They’re not the ones with all the right answers themselves, right? It’s not your job to have the answers. It’s your job to ask the best questions. And the best thing that product managers should do is help people in their team come to the right answers by giving them the tools, giving them the same tools that they would use to come to those decisions so that they’re not sitting there constantly just with this pile of ideas and suggestions on their shoulders and trying to weigh them up themselves.

If, your execs, if your team members can all look at the same framework and say actually this is how Janna would break it down. Therefore, we’re going to put this idea forward and we think this one’s strong, that takes so much weight off you as a product manager and just empowers your team to make better decisions across the board.

[00:18:44] Joe Leech: Yeah. And do you know what the other thing is, I often these days I get called in to help with product vision or product strategy. And often when you come into somebody come asked me to come in to help with that. The number one cause of the product strategy, being, not being in place, not being strong it’s because the business strategy isn’t strong, there isn’t a strong business vision or core provision for what your organization should be doing.

And so it’s very hard to create a product vision. Or strategy because that’s not there above you. And so what I’m finding myself doing a lot more these days, and this is, Hey, career advice for all of you product folks is the skills you’ve got as Janna quite rightly said right now, I’m going to set you up so well for that point, when you’re the CEO and you need to come up with a business strategy or strategy for the company or hold on a minute. I’ve got the skills to be able to do this. This is the same thing, a product strategy. Hey, dirty secret: product strategy is a business strategy. A business strategy is a product strategy. They don’t have to be separate things. The two should flow from each other because, again, the majority of businesses we’re working on these days are heavily tech focused and product focused. The two should be the same. So anything you’re good at as product managers is going to carry you forward into your future career when you’re creating that business strategy. So yeah, every time I get called in for product strategy, the first question I ask is what’s your business strategy?

Oh, we haven’t got one. All right. Okay. That’s the problem. Let’s sort that out. And then probably, meet your boss, let’s go and chat to the CEO and let’s fix this. And then once the business strategy’s done, the product strategy’s straightforward. 

[00:20:10] Janna Bastow: Yeah, that’s perfect. And that’s such good advice because that’s the type of thing that can really help lift somebody up in their career.

If they’re able to identify problems that their executive team has and how they can solve that. I always recommend to people when they are joining a company or rethinking their role within a business as a product manager. Your job is often think about what problem your product solves for the customers, but also think about what problem you solve for your business.

When they wrote that job, they were articulating a problem that they had and you have a particular skillset and you can solve unique problems for them. How can you solve those problems? And if you are spotting that they have problems articulating their vision and their, business strategy, you can help them with that because the same things that go into product management are the same things that go into organizational design and business decisions, really. It’s all the same stuff all the way down, to be honest. 

[00:21:05] Joe Leech: I’ve got a great story, actually. I’m publishing a video on it next week. I’ve been working recently with a senior Director of Strategy, big multi million dollar global business Director of Strategy. “Joe. We haven’t got a strategy” and I’m like, “Oh, that’s interesting, Director of Strategy, been in your job for a year now, why not?” 

“We don’t need a strategy.” I’m like, “You don’t need a strategy?” 

“No, We don’t need a strategy. We haven’t got a strategy, cause we don’t need a strategy.” 

And I’m like, “Okay. So what’s that?” And I was like, “Why is that?” 

“Well the strategy is obvious.” You’re like, okay, this is this warning signs, klaxons go off in my head right here, is that often what you can see in organizations that make bad decisions is they are lacking in senior levels, strategic thinking and it’s really interesting. That seems to be the biggest issue that I’m facing at the moment. It’s a lot of organizations are growing rapidly, especially in this kind of world, post COVID and lockdown where the world is completely different and certainly, a lot of the tech businesses I’m working with, are like absolutely supercharged by the changes— societal changes—that are here and they’re growing out of control and they don’t feel like they need a strategy to cope with that. And it’s like bad decisions are happening everywhere. And the business is growing despite the bad decisions. And what’s interesting about that is that growth is not it’s not matching market growth, they’re growing, but they don’t match the market growth.

And so there’s lots of sets of challenges around ultra fast growth in any organization. And it’s, again, I spent a lot of my time working with companies that are growing about how, why they need a strategy, why their strategies could help them grow responsibly. And in that kind of way, because again, what happens in companies that are growing super fast with such a high velocity is the person that struggles the most is the product manager, because they’ve got so much pressure to build and to create, build things, but there’s no business strategy for them to be able to base their product decisions around other than “we’re going to grow fast”.

“We need to build all of these 200 things. Here’s some great ideas that we brainstormed last week. Just keep building!” and this lack of business strategy in high growth companies, the most dangerous place to be. Yeah. Interesting times. 

[00:23:09] Janna Bastow: Yeah, absolutely. You see so many companies who, as you said companies who are succeeding, even though they don’t have a strategy you actually see a lot of companies out there, who hit on something quite luckily, right?

They, just have something that drives them forward and they strike gold. They strike gold for a little while and they don’t actually learn discipline—the processes and every company goes through that, whole thing of growth and maturity and then decline. It’s just a matter of when, and you can chart it out with every company.

And so these companies that are doing this right, sometimes that’s a huge. Thing upwards. And sometimes it’s a tiny one upwards. But I’ve been in companies that have been on this huge ride upwards, and I could see it slowing down and I was like, hold on a second. This company has no discipline. This company, I don’t understand how this company makes money, this is all going to dry up. And it did. 

[00:24:03] Joe Leech: And you hear it, you hear about it. People talk about it, “Oh yeah. We’re surfing the wave” and I’m like “No, you’re not. You’re skiing in front of the avalanche, is what you’re doing. Is that thing’s coming for you”, and you’ve got to make a point that that’s there. And when I worked at Trainline in 2010, I can tell the story, cause it’s 11 years ago, Trainline were like that, they had enormous rapid UK growth, right? No strategy, nothing, no real idea other than we’re going to build something that people can buy train tickets from. And they had an enormous growth because the internet was growing. They were on that wave. 2010 here, two competitors got came along and then suddenly they realized, holy moly, this is not going to last.

We need some serious strategic thinking about, not only our business direction, but also our product direction. At the same time in 2010, we had the, iteration then was great because it met customer needs and all of those things, but it was a real watershed for them. And if they’ve not got that right.

They would have been overtaken, the Trainline wouldn’t be in the same way that it is today in the UK. So I’ve absolutely seen it at that sort of scale, both sides of it really. 

[00:24:58] Janna Bastow: That’s interesting. This is one of the reasons why I’m always telling companies, no matter how small you are, no matter how successful you are, whatever’s happening.

Always be looking for ways to disrupt yourself because as you grow. Other companies are going to be seeing that tasty market share, that tasty revenue. Every time you get a new customer, a new logo, a new press release, a new company is going to be up and coming and looking at you going, “Oh, we could build that for half the time and build only the good features. Only the parts that we want to, you’ve already validated”, and people are going to be nipping at your heels. And so you might feel like you are absolutely riding that wave, doing great. But in reality, there are going to be other companies doing it for faster and cheaper than you. And anything that was a competitive barrier before is becoming less of a competitive barrier, right?

Product is no longer a competitive differentiation. And so you should always be thinking of ways to disrupt yourself, carve out time for R&D carve, out time to think about, “if we were to be that startup that was disrupting us, what would rebuild?” And build it before the startup does so that you can disrupt yourself and be the one—you’ve got that one swoop that you’re on—be the next swoop so that we can take that next ride.

[00:26:09] Joe Leech: Yeah, because you see the other thing with these high-growth companies as well. The other symptom they face, we talked too much before about organizations are too focused on the competition. Often that growth phase, they are not focused enough on their competition. If they dismiss other people, like dismiss the other startup that’s nipping at their heels.

When I was working at Marriot, again, I’m out of NDA for that one. When I was working at Marriott in the US they dismissed Booking.com all the time. “Oh no, they don’t know what they’re doing. They’re just small Dutch company. They know nothing about this stuff. We’re Marriott, we know hotels. And I remember being in so many conversations where they just dismissed Booking.com out of hand, and, now a huge volume of their sales comes through Booking.com and they just didn’t see it coming because they just dismissed them out of hand. Nokia famously dismissed, Apple iPhoneout of hand, Blackberry the same, there’s a lot of history of that, Blockbuster/Netflix. There’s lots of these organizations that have done that, where they’ve not—growth has happened, they’re very successful and they’re doing extremely well—but they’re not keeping an enough of an eye on competition. It’s all of these things were a balancing act, really. 

[00:27:06] Janna Bastow: Yep, absolutely. Joe we were talking about some bad decisions and things like that, but what are some good inputs for decisions? What should product managers consider before they’re making decisions. 

[00:27:19] Joe Leech: Yeah, good point. I mentioned the decisions diamond, and I’m into the things, the inputs, and take into it as well. I think one of the most missing aspects of, and this comes from the development and deployment teams generally, is not enough understanding of how the business measures and defines value. So what does, and how does a business, your business, designed to find value? That’s typically most commercial organizations, that’s money, obviously. And if you’re an organization, there’s always something that your business values and measures its values against, is truly in understanding what those findings are.

Now there’s tools, like OKRs, that can help you to get that. But it’s less about the tool. It’s more about the mindset of getting there. If you, as a product manager should be 100% focused on how your businesses defines and delivers value. And that I think is the missing link in terms of really supercharging your work.

So again, I mention that a lot of what I do is supercharge teams to really deliver results. And that’s around delivering stuff that is not, it’s not rocket science, it’s all about delivering the value to the business that’s there and that’s got to match with what the customers want, but absolutely rigorous focus on delivering business value on everything you do is I think honestly, the missing link, still these days. And I see it much more in organizations like large banks is a good example where they’ll have a development organization that they treat is an internal agency where they will tell the agency what to do. “Hey, dear internal bank tech team, can you build us this app that allows people to apply for mortgages” and the tech team, “Right, okay. We’ll build that for you. Off we go and we will go and throw it into our process,” and something will get shut out of the back of itin 18 months—is those organizations and those tech teams are not being proactive enough to tell the business what they need to be doing next. In terms of here’s tech, here’s what you should be doing next business.

We’re not your internal agency building what you tell us to build. We are here with you to help tell you what we think the business should be building based on this user value. We can make more money, 10 times more money, if we did this thing and having the confidence to go into a meeting. Make 10 times more money, if we do this thing, rather than being a service led operation within an organization, which product teams can become, if they’re not okay. 

[00:29:25] Janna Bastow: This is something that jives very much with the conversation we had with Jeff Patton, here on the Product Experts webinar. He was talking about some of the problems that you have within businesses that stemmed from early the Agile Manifesto, where, when we talk about the customer and the Agile Manifesto, what we’re actually talking about is the tech team treating the rest of the business as their customer.

Where that causes a problem is that you’ve got this team whose outcome is to just deliver what it is, whatever it is that they asked for. So if it is build an app that does this thing, all they have to do is build the app that does the thing. They’re not actually tied to the outcome, which is we’re here to make money or to change our world in this particular way.

And so, it’s like you say, about getting the, understanding the value for the business, but making sure that is spread amongst the team, it’s understood across the teams, that everyone has bought into it. 

[00:30:20] Joe Leech: You know, anybody at any level in their career, number one way to supercharge your career is by understanding how your business measures value and talking to that all the time.

That is what gets you forward, no matter what. Okay. That is the number one thing. My experience I do, I work with a lot of, I mentioned I supercharged kind of leaders, 50% of what I do is we work on the thing—the product, the process and stuff like that. The other 50% I do I work with product managers, it’s giving them the confidence to stand up in the meeting, and go, “No, we should be doing this because it’s going to generate X amount of value-add to this business”, being very confident in that ability for them to do that. So the tail is not wagging the dog in quite that same way, as you are constantly, as a product manager, standing up in that meeting and being “No, we’re going to build this for this reason, for this money.”

And that is often a lot of product managers getting out of their own way. Let me say this, Agile Manifesto. All of these kinds of agile frameworks, I’ve not even mentioned SAFe, all of these things can get in the way of you being great at your job, which is all about you as a product manager, knowing how your organization measures and delivers value.

And just doing that, talking to that in all aspects of your job, you do that. You’re going to go far. 

[00:31:26] Janna Bastow: Absolutely. We’ve got some questions coming in from the audience now I like this one from Andy short and sweet. He said, what’s the biggest thing that you used to think about making good decisions that you no longer think is the case.

[00:31:39] Joe Leech: That’s such a great question. I thought that it was process. I thought organizations had like a decision-making process, like on the executive/chief operating offices, there was the decision making process that they went through, like boxes and arrows. First we do this, then we do this. Then we do this.

Then we do this, but I thought it was a process. And I now know it’s not, it’s a state of mind. And a state of being, and a state of culture is the best way to make decisions. Everybody wants it to be a process. Everybody’s asking me for what the best decision making process is, that’s the problem. And a symptom of that, is people asking me, I need a product prioritization framework, please. Anybody asks you, if you think you need a product prioritization framework, warning! Something is wrong somewhere else in your organization, it means that you need that to make better choices. It’s not about that. So yeah, the biggest thing for me was I thought there would be a secret process in this.

[00:32:36] Janna Bastow: Excellent. I love that. And thank you for saying that, because I’ve heard that before we needed a decision-making process and something in me, just freezes. And I wasn’t able to put my finger on why, but but you’re right. It is more of a mindset. It’s about understanding how and why we’re making these decisions and how it’s framed back to what we’re actually trying to achieve, but not tight process that means that we’re going through this flow diagram before we make any decisions. We don’t want that. 

[00:33:07] Joe Leech: One of my most interesting interviews was with Instagram. So one of the leaders of the Reels program. And I asked him about this and Instagram was, this is my favorite podcast.

I’ve just put it in the chat, go and listen to it, after this. Tim is a great, wonderful human being at Instagram. And anyway, they talk—it’s all in the culture there. Then what’s interesting about how he talks about his team making processes: they talk about jobs to be done. They talk about. Rocks and pebbles and sand, if you’ve used that one, they talk about bets. They talk about lots of these frameworks to help you make decisions. But what’s interesting about them is they take the best bits of all of them and they make them their own. And so what’s interesting is again, I saw this, is a big trend, is that they take all these organizations take the best bits, and they create their own way of talking about decision-making—the best bits of thinking in bets, they take the best bits of which is again, similar to some stuff that the Spotify use. It take the rocks, sand pebbles, which is something that PayPal have famously talked about as well. I’ve got links to all of this stuff as well, on my blog, I can share all this with you, Jobs To Be Done, which is obviously something I would talk about as well, but they take all of these processes and just take the best bits and make their own way of doing it. And what’s interesting about Instagram, is the teams are encouraged to make their own ways and processes of working on certain things.

HelloFresh do similar things as well. So there’s lots of organizations who design and create their own approaches to making decisions. Okay. And that’s the best way, is you just take the best bits of all of them and make something that’s your own. 

[00:34:31] Janna Bastow: Excellent. So there’s another question in here from Colin.

And this is reflecting back on something we were talking about just a little bit prior and he said funnily enough, we’ve been having this conversation at work. He says a large UK government department, just today about the importance of really having a good high level view of our products and a clear pathway to how this breaks down into low level features.

How do you recommend we put together and document this pathway? 

[00:34:59] Joe Leech: I’m going to be truly honest with you, Colin. There’s a lot—if anybody knows this—in the UK, the government, working for the government is—there’s so much government work available at the moment in the UK. US, I think, is the same way. I don’t do government work and I’ve done a lot in the past.

And the thing that I struggle with government organizations is they don’t have a clear—and I talked about this earlier on—how they measure value and success in that government department. And that’s what makes all of this stuff really acute in those areas, is how does your department measure success and deliver value?

And that’s ultimately where you talk about products and clear pathways, is you need to define and understand truly how your department measure success and delivers value. What are those two things? And that will give you that clear pathway. If you don’t have those things or those things aren’t abundantly clear to everybody in the room, especially the senior decision makers, you don’t want to address the fact that, in part, that’s keeping ministers happy, part of that is political, part of that’s based on consumers, whatever those things might be. You need to map that out. And once you have that decisions are easy to make. Okay. That’s the challenge in working in government is that, that stuff’s not always clear people. Don’t like to talk about it. And that’s always been my weakness with working in government is I asked for that.

I pushed for that and that doesn’t always exist. So I’ve been—is sacked the right word? Yeah, I have been by a number of folks. A lot of my friends have been through the Government Digital Service in the UK, and I’ve worked with a few of them, but I’m not the right person for that because I ask those difficult questions and those difficult questions, don’t, aren’t always answerable. I know that’s not your question, Colin, but I would look for you to map success and value and then it will flag. 

[00:36:36] Janna Bastow: Excellent. Excellent. This actually reflects back to a conversation I was having with a fellow product friend of mine who works in a UK government area.

We were talking about how they they lacked discipline. And this is in regards to the expense, the expenditure. Government agencies often don’t have the same constraints on spending that public companies do. Having been in startups—what a contractor costs, what a freelancer cost, what an in-house person costs, and how long something is going to take and how much it costs, and oftentimes they don’t see how much money and how much time is going to go into something, and therefore don’t reel it back. And therefore things just run on and on because they don’t have the discipline.

[00:37:22] Joe Leech: That’s why they often, they hire these really expensive management consultancies, or service companies like Capita or Serco or Accenture, or any of those, they bring those goes in because they expect those guys to bring it. But those guys don’t come in. They come in with clever contracts and smart ways of working that means that they don’t have that accountability either. And it’s a real struggle to get that, because again, nobody’s measuring successes or value or setting goals for that stuff. It’s starting to change, don’t get me wrong and it really is starting to change, but it’s a slow process to get there.

And I have my issues with the large management consultancies, especially in the world of product and business strategy and tech strategy, especially cause they don’t really know. And this truly understand what they’re doing for that blanket statement there. So feel free to disagree with me, but yeah, it’s a real challenge of government Collins.

I absolutely feel your pain. If you want to reach out or another therapy session, I’m here to chat to you about it. My friend. 

[00:38:15] Janna Bastow: That’s wonderful. Thank you. 

[00:38:18] Joe Leech: Anyway, other questions. 

[00:38:23] Janna Bastow: Excellent. Colin did actually mention something about documenting stuff.

And that brings a question to my mind, which is how do you think about documenting decisions? 

[00:38:34] Joe Leech: Good question. I’ve been writing about this in the book at the moment. The ways I’ve seen this being done is, I really love the way Amazon do it, with they, do things like write the press release for the thing that they’re building and designing and doing it.

And that’s often a great way to do it because that uncovers a lot of what you’re working on. I really liked that way of doing it as well. Other people do things like they’ll do a pre-post mortem, they do a post-mortem so all the things that can go wrong in that decision making there’s lots of ways you can start documenting it by pushing yourself forward and— is it called a pre-mortem? I think it is—a pre-mortem of what what could go wrong and documenting that stuff as well.

But I really liked the way Amazon do it in such a lightweight way of just doing that press release of what it can look like and how it can work. But yeah, again, other things, decision documents, great for that as well, because that gives you accountability again. Oh, we’ve done what you’ve got. All of those four things.

Wonderful. You’re going to work really well. So the decision diamond can help also with writing those documents, but honestly you make them as visual as possible because senior folks don’t read them and make them as pithy and as well-written as you possibly can, like the way that Amazon do it with their press release that they write before they design and create some thing.

[00:39:34] Janna Bastow: Yup. Yup, absolutely. Thanks for that. Amanda asked a question and she said what are some good examples for strategy when the biggest pain point for the company is the cost of running a legacy platform? So all the efforts are for creating a new platform to transition to the existing features. 

[00:39:50] Joe Leech: Yeah, I’ve been here with this a couple of times. Actually I worked at a startup—they’ve just gone, retired in their legacy platform for something new. It depends really where, what state you’re in, terms of that stuff. If it’s a brand new platform based on— so again, this is more of a technical issue, I think, than probably a product thing.

I don’t know what your technical strategy is. Replacing that existing product, that legacy platform. If it’s a swapping of one for another, that’s dangerous. So again, having worked on large legacy products that work, the best approach is often, and this is getting technical, is using and developing things called microservices, which are based around individual features.

You build a microservice of one feature that plugs into your existing legacy platform when you do it that way, and you keep plugging in. And cutting it off. So you’re not boiling the ocean. You’re cutting that thing up into smaller pieces, replacing small bits of functionality as you go. Because again, that minimizes risk in terms of dependencies. It’s going to work, so you’re not like on Friday turning one off and Monday turning the new one on—is small microservices to do it. So I’d imagine Amanda, if you’re asking me this, that perhaps your tech strategy is the one that’s weak here, not your product one. I don’t know if that’s true. But it makes it harder for you as a product manager, if you’re waiting for six months for the new one to be released and you can’t build anything on the old one, because the old one’s out of date and you don’t want to put any cost already into the old one, you’re gonna spend all your developer resources for the new one, the symptoms there, you recognize those symptoms that nobody has to do any work on the old one and saving all your good stuff for the new one.

And you’re not going to ship anything for 18 months. Get in touch. We can chat about it Amanda, I think, yeah. That’s probably a tech strategy issue that. 

[00:41:24] Janna Bastow: I would echo that, which is this idea around rethinking the refactor.

A lot of people will think when they’ve got a refactor, they’ve just got to take the old product and rebuild all the functionality and relaunch it as it was. But, rethink that what you should be doing is taking imagine that you are a startup coming in and disrupting You the original existing company in that space. Which features would you build first?

Would you build that feature here? Would you build that feature there? Go and build those one pieces. As Joe said like a micro service or whatever it is, a small piece of that, and just prove that you can build a nice new version of it with nice new tech and get a few people moving over to that new beta.

And of course it won’t do everything if they still want to configure stuff and do all their, all the other stuff, they need to go back to the full app. You can reduce the dependency on your one product versus the other one.

And so over time you move people off the one to the other, and eventually you can make your other one deprecated, all while building up your other one and what then happens. You might actually find that you don’t have to rebuild the entire app as it was in the first place. The chances that you rebuild your entire app as it was in the first place, it’s actually really slim. 

[00:42:35] Joe Leech: If you’ve got any questions, just get in touch. Any of the things you’ve seen today, you’re like, struggling, I’m here. 

[00:42:42] Janna Bastow: Wonderful. Thank you so much for your time here today and thank you everybody for your questions.

If you have other questions, feel free to reach out to Joe directly or to us and we’ll absolutely take the time to make sure that those get to Joe and in the meantime, this has been recorded. It’s going to be up on our YouTube channel and will hear from us soon.

[00:43:03] Joe Leech: Wonderful, amazing questions. 

[00:43:08] Janna Bastow: All right. Take care, everybody have a good one. 

[00:43:10] Joe Leech: Bye.

Watch more of our Product Expert webinars

You’ll also enjoy reading these articles

Platform Product Strategy & Scaling Product Systems
Embracing Lean Product Development
Introducing the ProdPad Partnership Program