Skip to main content

Product Management Webinar: Product Discovery

Uncover the Secret to Continuous Product Discovery

How do you achieve continuous product discovery?

Join our fireside chat with special guest, Teresa Torres, Product Discovery Coach, speaker and acclaimed author of “Continuous Discovery Habits”, and host Janna Bastow, CEO of ProdPad and inventor of the Now-Next-Later roadmap.

Teresa Torres

About Teresa Torres

Teresa Torres is an internationally acclaimed author, speaker, and product discovery coach. 

She teaches a structured and sustainable approach to continuous discovery that helps product teams infuse their daily product decisions with customer input. She’s coached hundreds of teams at companies of all sizes, from early-stage start-ups to global enterprises, in a variety of industries. 

She has also taught over 7,000 product people discovery skills through the Product Talk Academy and is the author of her new book “Continuous Discovery Habits“.

Key Takeaways

  • The mindsets required for your team for succeed with continuous discovery
  • How to use the Opportunity Solution Tree to generate better ideas
  • Using interviews, prototypes, experiments and more to evaluate your solutions
  • Aligning your team around a shared understanding of your desired outcomes

[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: Hello everybody. Welcome. Welcome. Come on in, you’re joining us here at the ProdPad Product Expert webinars, and the reason we call them that is because we have a different expert each time. They always come with different insights and the focus is always on the content and the learning and the sharing.

The past talks are recorded, so you can go see those on our site. And what we do is either presentations or just fireside chats, like today’s going to be, so today is going to be recorded and shared, and you are going to have a chance to ask questions.

Before we dive into things, let me just tell you a little bit about ProdPad, which is what we do.

This is a tool that was originally built by myself and my co-founder and we were product managers ourselves, and essentially we just needed tools to do our own jobs. We needed something to keep track of the experiments we were running. We needed something to help keep track of the objectives we had and how we were going to solve our customer problems, and just keep tabs on all the ideas and feedback and everything that made up our backlog.

So building ProdPad gave us the control, and the organization, and the transparency that we and our team needed. And it wasn’t long before we shared it with the product people around us. And so today it’s used by thousands of teams around the world, and it’s free to try.

And we even have what we call a Sandbox mode, where it has example product management data, so you can see how, lean roadmaps, OKRs, experiments—how it all sort of fits together in a product management space. Our team is made up of product people, so, start a trial, let us know how it works. Give us your feedback.

Today is actually going to be a really interesting conversation because I love talking about discovery, because ProdPad at its heart is a discovery tool. We’ve reframed the roadmap from being a tool that essentially holds you back and holds you to dates you never really wanted to commit to in the first place, to being this place where you outline the problems and the opportunities that you might tackle and helps you track the experiments and the outcomes that you’re learning from along the way. So we’ve really helped rethink how product management can be used for more of a discovery type of process than purely delivery.

 So jump in, give ProdPad a try and let us know how you get on with it.

And in the meantime, I want to jump in and introduce our guest for today. So this is Teresa Torres. She’s an internationally acclaimed author, speaker, product discovery coach, you probably know her as the author of her new book ” Continuous Discovery Habits”, which she’s got a ton of them behind her there. I’ve got just one of them right here with me. Great book, highly recommended. She’s taught over 7,000 product people discovery skills through her Product Talk Academy.

And she’s actually here today to talk about how to build a continuous discovery habits. So everybody say welcome, say hello to Teresa and, from me, welcome Teresa! Thank you so much for joining us here today.

[00:02:47] Teresa Torres: Thanks Janna! Thanks for having me. I’m super excited to be here.

[00:02:50] Janna Bastow: Yeah, absolutely great to have you here and great to have a chance to chat with you, I think back to when we first met you inducted me into SF, you’re the first person to take me to Blue Bottle coffee in San Francisco.

[00:03:01] Teresa Torres: Yeah! So you had your introduction to San Francisco sort of third wave fancy coffee.

[00:03:08] Janna Bastow: Yeah. We met up, then we had a properly geeky conversation about product and discovery and things like that. And that was going back like some many years ago now.

 Yeah. But probably worth giving some people here an idea about your background, anything that I might’ve missed, to get everybody on the same page here.

[00:03:25] Teresa Torres: Yeah, you did a pretty good job. Probably for the last kind of, depending on how you count for the last 8 to 10 years, I’ve been working as a discovery coach, really just helping teams make better decisions about what to build. That work has evolved in that time period because our discovery methods have evolved.

It’s been actually really fun to see. I know that 10 years ago, the prominent conversation in product was user stories and managing backlogs, and it was all really grounded on the delivery side. And it’s really fun to see the whole industry, embrace discovery and recognize that customer centricity is a big part of the work that we do.

And before that I did, what a lot of probably listeners are doing, as I held different product management and design roles at different early stage startups. I ended up in some leadership roles. I ran a startup during the ’08 economic downturn, which was one of the most challenging things I’ve ever done.

That actually directly led to me becoming a coach because I realized being an executive was not the best fit for me. And really what I was passionate about was helping to develop a really customer centric product. So here I am.

[00:04:35] Janna Bastow: Excellent. Yeah. And you’re an excellent coach, I know that from the stuff that you’ve been putting out, that you’ve taught so many people and you ask really good questions.

This is one of the things that I like about the book that you’ve published, is that it helps product people ask those types of questions of themselves and take a look at the habits that they do have.

You want to tell us a little bit about this book that you’ve recently published?

[00:04:56] Teresa Torres: Yeah, so I think we’re at the point in the industry where most individual contributors in the product space know about discovery, they want to do it. But we have very few companies that have a strong culture of discovery. And so the challenge is you could be eager and willing, but you don’t know what good looks like.

And so I recognized this problem a few years ago, I started writing on my blog, trying to write about teams that were working this way, just to paint a really clear picture of what does good look like. And then I started to notice that like, when I would work with coaching teams, they would come into our first session and they’d say, Hey, we already do continuous discovery.

And then we’d get into their tactics. And they were doing a lot of discovery activities, but they’re still doing them from this big project mindset—in bursts. And I just recognized that really there’s just a know-how gap. It’s not a, we don’t need another why we need to work this way book. We just need to paint the picture of what does the day-to-day look like and teach me how to do it.

And so that was my goal in writing the book was to give a practical how-to guide for a product trio to really start to adopt these habits, and really change the culture, starting with their own team.

[00:06:06] Janna Bastow: That makes a lot of sense. And so you mentioned this product trio, who is the product trio?

[00:06:12] Teresa Torres: Yeah, I didn’t think this was a controversial topic, but since the book has come out, I have learned it is kind of a controversial topic. So I defined the trio as a product manager, a designer, and a software engineer working together from the beginning to make decisions about what to build.

And I’ll contrast that with what we’ve historically done, right? Historically, the product manager gathered requirements or wrote a Product Requirements Document (PRD), or even user stories, handed them off to a designer who did the design work, and then the requirements and the design got handed off to engineers who implemented.

And what we saw with that, basically, even if you were doing Scrum waterfall model was a lot of lost context and nuance and a lot of rework. And so we’re starting to recognize that, like, these are three critical functions for collaborating on what to build. Let’s just get them together from the beginning, let’s get them engaging with customers from the beginning, so that we just get better solutions and we meet and we build better products.

The reason why this has become somewhat controversial is that, as we see discovery become more important in companies, we’re seeing a bigger like specialization and diversification of roles, and so I’ve heard from a lot of people about like, Hey, I’m a user researcher. Why don’t you include me in the trio?

Or I’m a UX writer or I’m a data analyst, so I will say the trio is not designed to exclude anybody. The idea really is flexible based on the roles available to you on your team and the types of decisions that you’re making. It’s just a trade off, right? Between speed of decision-making and quality of decision-making.

So the speed, fewer people involved in the decision, the faster you’re going to go quality, you want the right cross-functional roles represented. So you’re leveraging the expertise on your team. And so the idea flexes based on who you have and what type of decision you’re trying to

[00:07:57] Janna Bastow: So the product trio could differ based on the context of who’s already in the team as well, right?

[00:08:03] Teresa Torres: Yeah. So I’ve worked with teams where maybe it’s a really data heavy machine learning based product. They probably have a data scientist on their trio, that’s now a quad. Some people argue that those types of teams don’t need UX. And I disagree. I think everybody needs a UXer.

Or let’s say a team is a trio most of the time, where they’re starting to do discovery around their go-to-market strategy, they might invite their product marketing manager to be a part of that discovery for that subset of discovery work because they have expertise they can leverage, right?

The big one I get all the time is, My company’s investing in user researchers. What role do they play in a trio? And it kind of depends. If your user researcher is full-time embedded on your team, so they’re not going to be a bottleneck, you have a quad and that’s awesome because your user researcher is going to really help you with a lot of those decisions, and is really going to help you with getting collecting more reliable feedback throughout discovery.

Most companies don’t have that many user researchers and that’s a shared resource. So now if we include them on our trio, that person will be the bottleneck and will slow the team down. So I don’t recommend if they’re a shared resource, putting them on your trio, you need to still consult them when the decision is relevant to them.

So that’s this idea of it flexing, is that your trio can grow and shrink based on the types of decisions and the types of roles on your team.

[00:09:24] Janna Bastow: Right. That makes a lot of sense. And Kim in the chat just asked a question. What role does sales play discovery? Do they have a place in this trio?

[00:09:33] Teresa Torres: I’m a firm believer that good sales is the same exact thing as good product discovery. So what are we doing in discovery? We’re trying to uncover unmet needs, pain points, and desires. What should a good sales rep do in the sales process? Try to uncover unmet needs, pain points, and desires, and then show how your product addresses those unmet needs.

So I would love it if this idea of the cross-functional product team started to grow, to include our business roles. Very few companies are there, right? We’re just starting to talk about like agility across the organization. I think the product mindset is what our business mindset will eventually be.

I really think the way product teams work is the future of business. But I don’t think we’re there yet, anywhere close to there.

[00:10:20] Janna Bastow: Yeah, that makes a lot of sense. I hear people talking about the problem that they have, where their sales team is constantly selling stuff that they don’t have, right? They need to have a roadmap. They need to be able to deliver on that roadmap because the sales team is expecting it, because they’ve made these commitments of things that need to be built in the future in order to keep the business up and going . And the way that I’ve always started turning that around is to point out that the sales team should be selling what you have, right?

You should only sell what you have and not what you don’t have. And if the sales team can’t sell what you have, either your sales team isn’t good enough, or your sales team is really doing the wrong job, right? If you don’t have anything to sell today, your product literally doesn’t have the features and it doesn’t have what you need, then redeploy them as researchers. Get them out there to help you figure out what kind of things could be needed by the market.

[00:11:08] Teresa Torres: Yeah. I see a lot of parallels between sales and product. So if we look across the industry, the vast majority of product teams are solution-first. We’re very solution focused. We live in output world, which is why we have analogies like Feature Factories and Melissa Perri’s Escaping the Build Trap, right?

We have a culture of starting with ideas and starting with solutions. The best product teams are moving away from that and focusing on outcomes and focusing on value. In my world, I call them opportunities. Customer needs, pain points and desires. We see the exact same parallel on the sales. Your average sales team is selling features, selling solutions and they’re selling today’s solutions and what they think tomorrow’s solutions are, and that’s where they get into trouble.

I think the very best salespeople are selling not a solution, but a possibility of addressing a need. So it’s less about “here’s this widget”, it’s more about “our product or solution will address this need”. And then what that does is it gives the product team the leeway and the flexibility to figure out the best way to meet that need, rather than this really off the cuff prescribed solution that occurred on the fly in the sales meeting that probably wasn’t the most well thought out solution.

I actually do think some salespeople do need to sell beyond what your product currently has. This is particularly true in early stage startups, right? Your sales team is your missionary. So you’re selling the vision of the product.

And I don’t think there’s anything wrong with that. As long as it’s aligned with the product team’s vision of the product, and it’s a vision, it’s not a list of features.

[00:12:49] Janna Bastow: Yeah, exactly. And that’s the key thing is, you know that iron triangle of scope, time, cost, sort of thing, right?

They can’t sell this, the scope and the time and the cost and say, this is what you have to go deliver to. Because at that point in time, you’re going to lose the quality. That’s where you tend to get in trouble. If they’re willing to say, actually we’re going to give on the scope, but what we can do is say that we can solve this problem for this type of cost, right? We validated this is in fact, a problem worth this much to this type of customer, but you figure out how you go about doing that. That’s actually all we really wanted. That gives us lots of room to go figure out how to solve that.

And, there’s lots of things that our product team can do with that information.

[00:13:27] Teresa Torres: You’re making me think of, probably the best thing I’ve ever said on a stage from an audience reaction standpoint, and I loved it so much, I put it in the book as well, which is during my talk at Mine the Product San Francisco.

I said, and it was off the cuff. Martin had told me right before I went on the stage that I had more time than he had originally told me if I wanted it. So I added a little bit at the end of the talk and I said, you’re not one feature away from success. And it literally, like I’ve never received an audience reaction like I received that day. It was unbelievable. And I think it’s because that resonates, like we product teams have such a strong belief that this next release, this next feature is just going to solve the world. This is directly analogous on the sales side. A salesperson has the same belief that this one feature that the customer is asking for is going to close the deal.

And it’s really poisonous on both sides because that’s not really true what we need to learn. Both the product teams and salespeople is that that feature request represents an implied need and that we have to do the work to uncover that need and find a better way to solve it.

[00:14:36] Janna Bastow: Yeah, that makes a lot of sense. Excellent. So actually you mentioned something, you said you call them opportunities and I wanted to ask about that, one of your concepts that you’re best known for is the Opportunity Solution Tree. And I don’t know how many people in the chat here are familiar with the Opportunity Solution Tree, but maybe you want to tell us a little bit about that work. How did this come about and how are you seeing it?

[00:14:58] Teresa Torres: Yeah, so I hate jargon and I really hate that I’m part of creating jargon in our industry. So I’m going to apologize for the ‘Opportunity’ of language. I didn’t invent it. It was already in use. I just borrowed it. But, and I think it’s important, I think the reason why we call them opportunities and not problems is really important.

So I don’t completely regret it, but Opportunity Solution Tree is a terrible name. It should’ve been called ‘outcome map’, but whatever, I’m over it, it’s out there. It’s a thing. So let’s break this down a little bit. So most people are familiar with this idea of the problem space and the solution space.

So the problem space is, how do we really get clarity around what problem we’re solving? How do we make good decisions about the most important problem to solve? I think it’s really easy for product teams to have this bias towards our job is to fix things and to solve problems. And that’s part of the equation.

We do do that, but we also build things that address desires that create delight, that create joy. And so the examples that I give are like, I really like ice cream. Ice cream does not solve a problem for me. In fact, it creates more problems than it solves. But, my life would be less awesome without it.

And I want that product to exist in the world. So it’s like a really good example of a product that’s not solving a problem. It’s addressing a desire. Right? Entertainment products, usually don’t solve problems. I mean, we could kind of stretch it a little bit and say like, I need to fill my time. Come on really, like I’d be better off going and working out or doing some work than being entertained.

So I think the idea of the language ‘Opportunity’ is to get you to think beyond just fixing problems and looking for opportunities to positively impact your customer’s lives, whether that’s by entertaining them or creating delight, or by addressing a desire. So it was meant to be more inclusive language.

It’s a little bit of a barrier and the real problem with the word is it conflicts with business opportunity and that’s not, they’re not the same thing, right? So that, so the language is a little messy and I apologize for that. The Opportunity Solution Tree visual is designed to help teams chart the best path to an outcome.

So most product teams start with, ‘I’ve got a fixed roadmap. I got to deliver these features by this timeline. And even though we’re not good at meeting timelines, we are good at delivering features’. And so that was a very clean lines, easy world. Put your head down, grind out the work.

Now we’re asking teams move this metric. Figure it out. That’s a completely different way of working. It’s a wide open unstructured problem, and we need a way of putting structure to that problem. And especially when you’re doing it collaboratively as a trio and staying aligned as a team about how we’re tackling this challenge. And so the Opportunity Solution Tree helps you map out what are the opportunities, the needs, pain points, and desires that we’re hearing in our interviews so that we can get a big picture view of all the ways we might reach our outcome.

And then, it also helps you align, make sure your solutions really do address the opportunity you’re trying to solve. And then also keeps track of the assumption tests you’re running, to help you evaluate those solutions. So it’s really just a visual diagram to make sure that you’re working in the right scope and you’re staying aligned.

[00:18:15] Janna Bastow: Yeah, that makes a lot of sense. One of the things I’ve always loved about the Opportunity Solution Tree is that it gets teams out of this habit of getting stuck in the details of trying to prioritize at the solution level. Or as you say, falling in love with their idea. It’s so easy to just say, well, this is the right solution. This is the one. And it sort of blinds them to all the other things. And the Opportunity Solution Tree helps identify where it sits amongst all the other things. And so, if it’s just sitting there and it doesn’t actually solve an opportunity, doesn’t have an opportunity that it sits neatly with, or if it’s sitting there and there’s no other potential solutions you’re like, are you sure that’s the only way you would solve that? Or is that not tied to an outcome? If you can’t tie your solution to an opportunity into an outcome, why is it there?

[00:19:05] Teresa Torres: And if you think about it, that’s I think one of the big benefits. Ideas are cheap. We have a million ideas. I love one of my favorite things to do. It’s kind of mean, but I feel like you got to have this lesson at some point, is I meet a startup founder that’s like totally in love with their idea. And I want to just rip and come up with 20 alternatives. Like yeah, your idea is great. Here’s 20 more. And it’s because we have this such a strong culture of like, it’s about the idea we have this creative myth, that beautiful idea is just born, that’s not true, right?

Good products start out as really crummy ideas that we iterate on, and blood, sweat, and tears over to really turn it into something. And I think that work is driven by understanding the opportunity space.

The one thing I wish I could tell everybody working on digital products is that ideas are cheap.

It’s not about the idea. It’s about the outcome you’re trying to drive and the opportunity you’re trying to address. And honestly, you could generate a hundred ideas tomorrow if you really had to.

[00:20:04] Janna Bastow: Yep. And this is what’s always bugged me, is that all of our prioritization solutions for the most part are all tied around prioritizing ideas, like RICE and ICE and weighted scoring and stack ranking, and all these things are all about taking these ideas and shuffling them around. But if that’s not the biggest problem or opportunity for your business, then the real one might be over here at which point you’ve just reshuffled a whole bunch of things over here. It’s like fixing the pixels on a button that isn’t even the right button.

[00:20:32] Teresa Torres: And there’s a kind of double whammy here. Not only are we just having the wrong conversation, like we’re missing the strategic question of where should we even be playing, but also all humans fall in love with ideas. It’s just how our brains work. Like ideas are shiny and they’re exciting and they’re new, and so it’s also where we’re going to have awful opinion battles. And it’s also where we’re going to see the HiPPO come in and dictate what we should do. And it’s where all the mess is. And it’s actually where we spend 90% of our time. And I think we need to flip that on its head. I think ideas are cheap.

Ideas are the easy part. The real work is really understanding how we’re going to create value for our customers by discovering opportunities and really understanding how we’re going to create value for the business by setting good outcomes and aligning those two things. Yep.

[00:21:20] Janna Bastow: Yep. Somebody actually asked, what language for the elements and the tree would you choose now if you could go back in time?

[00:21:26] Teresa Torres: I think ideas are simpler than solutions. I think the problem with solutions is people think big, project-based solutions. And I want you thinking about really teeny tiny solutions for a very specific target opportunity. I’m not changing it. It’s out there. It’s theOpportunity Solution Tree, so that’s the first thing, but I do think idea maybe would have been better than solution. I don’t have a better word for opportunity, but now that I’m like doing a virtual tour and I do a talk every day. Seriously, the number one question I get is what’s an opportunity, even though in my talk, I did define it like seven times.

Every time I say the word opportunity, I say, it’s a customer need pain point or desire. And then I still, in the Q&A, get a question about it so I can tell the language is a barrier. And that’s one of my personal goals in my blog, writing in the book, is I’m trying to make these ideas as accessible as possible because I don’t believe in obfuscating things through like horrible business jargon and even an outcome is jargon.

But here’s what I’ll say. I do think outcomes are important and I do think opportunities are important. I think these terms are going to become part of our vernacular. They’re going to become accessible. And so I’m not losing sleep over it. Talking about this literally every day, since the middle of May has made me acutely aware that not everybody has the handle on the language.

[00:22:48] Janna Bastow: Yeah. That’s totally fair. And actually funny that you mentioned moving from, solution to ideas, I mean, take it from me. I built a tool called ProdPad and we have Ideas and we had a huge discussion years ago, about whether we’re going to call them ideas or something more nebulous or whatever, and sometimes I have regrets going, maybe we should call them experiments, right. People away from this shiny idea, and solutioneering type of stuff. But they’re ideas for now.

[00:23:14] Teresa Torres: That’s interesting because, a few people have noticed this, that I need to clean up my artifacts, but I have moved away from experiments. So on the original visual of the Opportunity Solution Tree, it’s still says experiments. And if you go to Product Talk, it still says that I have not cleaned it up, but in the book I moved from the language experiments to assumption tests. And for a very specific reason. So most teams, when they hear experiments, they think large quantitative A/B test. And that’s not the experiment I want you to starting with.

And we forget that the goal is to test a very specific assumption and not the whole idea. So I shifted to the language assumption test to remind you, you are testing a specific assumption and it’s much smaller than this idea of a scientific experiment. So it’s really interesting. It’s really deepened my thinking about language and what we’re trying to communicate and what people need as they’re doing this work to remind them of their focus.

And I had originally chose solution because I started with problem space, solution space. That’s a concept that already exists in the world. But I do think that, over time, it’s really important that we continue to sharpen the language and really help people set the right scope for their work.

[00:24:30] Janna Bastow: Speaking of language, somebody in the chat just asked the question HiPPO?, and I think it is something that a term that we use in our space. And I don’t think it is universally known. What does HiPPO mean?

[00:24:45] Teresa Torres: So the HiPPO was a horrible acronym because it’s HIghest Paid Person’s Opinion. So technically the H and the I come from highest, but the concept represents this idea of a product team does great work or whatever. And then the CEO or some other business stakeholder helicopters in and said, No, we’re going to build this and they’re the highest paid person in the room. And so that’s who gets listened to.

[00:25:09] Janna Bastow: Yep. That makes sense. There’s now chat going on in there about some terrible acronyms people complaining about Minimum Viable Product and Minimum Viable Experiment.

[00:25:17] Teresa Torres: Those acronyms do not appear in my book and and very deliberately. I want to call out because, I think it’s Adeep, just highlighted that it seems like I’ve been performing continuous discovery all my life, even with readers and viewers. And here’s what I will share.

I remember in 2011, when the Lean Startup came out, I was, see if I can do some math. I was 12 years into my career. All of it was early stage startups. I read that book and I was like, wow, somebody is finally writing a book about how I work. Ever since then, my focus has been, how do I develop and refine these practices?

And I really do think that for me, the reason why this has been such a good fit is it is fundamentally how I think like, it’s really like, I do everything this way, but I was trying to figure out where to live. Like I was in the San Francisco bay area. I was over it, that place. Got lunatic, insane. I needed a new home.

I went to four different cities to try out living in different cities. Because moving is a big waterfall, permanent decision. And that to me is really important because what it allows me to do is I feel like I get to show up authentically as myself in all of the work that I do. And even the book, like even writing the book, I was like, this is just, explaining how I think. So, thank you for acknowledging that because that’s very true.

[00:26:40] Janna Bastow: Excellent. Yeah. And I just read your article about how you did continuous discovery on your book, and followed that flow, which makes a lot of sense. And I know you’ve been writing about this topic for a long time and I know from our past chats, this stuff has been coming together for a long time.

Excellent. All right. When working with early stage startups who should be leading continuous discovery when there isn’t somebody leading products, is that the CEO COO, we were talking about micro startups here.

[00:27:06] Teresa Torres: Yeah, startups are hard. Startups are hard. I love startups and I love founders. I feel like to take that kind of risk and to really believe you can change the world by starting from scratch is an amazing thing. And 98% of founders are solution-focused and not customer-focused.

And early in my career as a consultant, I wanted to work with startups because that was my full-time employee experience. And I very quickly moved away from it. And it’s because founders are really ego-driven and that’s a good thing and a bad thing. The good thing is, is that it convinces them to change the world and to take risks and to do things that most of us would not do.

And the bad thing is, is it’s a giant blinder to serving your customer. Now, there are, I would say there are probably 2% of founders that are truly customer centric. And instead of—maybe it’s higher than that. I’m just kind of cynical —is that they truly start with a cost target customer segment, a value proposition, and they iterate their way to the right solution. And that’s amazing.

So that’s the first thing is that like a lot of people ask me, how does this process work in a startup? If you have a very solution-focused founder. It’s going to be really hard to be outcome driven and to really understand the opportunity space. It doesn’t mean you individually can’t do it, but you’re going to have a hard time getting your company to rally around it because in a very solution-first context, it’s really hard to change that culture, but you can still do the whole second half of the book.

You can still story map your ideas, break them down into underlying assumptions, run assumption tests, catch the gotchas before you ship them out the door. So it’s not hopeless, right? You can still do all that work. But I think the heart of the question was you’re a five person startup team. Maybe you have a CEO, some engineers, a designer, hopefully.

Who’s on the trio. I would say most of the time, your founder is the product manager. And what’s hard is does that person have the ability to let go of their baby if they learn the baby’s wrong? And that’s the hard part of startups. My experience is that first time founders need to fail before they’re willing to get away from, ‘I have this brilliant idea. It’s going to change the world.’ And that’s unfortunate. I wish we could change that, but it’s going to take a pretty big culture change.

[00:29:23] Janna Bastow: I’m also thinking like the product trio can help keep you honest. If you’ve just got one person who’s running the company and says, you know what, I’ve got this idea and we’re just going to hire some people and get some funding to go do it.

You’ll end up going to do it like that is possible. There are lots of ways to just build a bunch of stuff and get it out the door, but having a product trio, having a group of people who work in this way, this continuous discovery process is all about figuring out what those assumptions are and checking those assumptions.

And if you’ve got multiple people around you who are there to bash apart your own assumptions and each other’s assumptions, you’re less likely to fall prey to your own biases.

[00:29:58] Teresa Torres: So I do think discovery as a team sport. I think the reason why this idea of the trio is taking hold is because we don’t see our own assumptions.

So the more diversity you have in the room, the more likely you’re going to cover more assumptions, the more likely you’re going to catch your gotchas before you release. I would love it if we could get to a startup culture where we have a trio is the founding team, right? It’s not just about the one.

Again, we culturally have this really strong myth in the lone creative genius. Right. We see this with Apple, with Steve Jobs. And Steve Jobs, maybe he was a creative genius, but he also had a creative genius in Johnny Ives with him, his designer. And I’m sure there’s an engineer that was elevated at that level because their hardware manufacturing is first-class.

I’m sure we have the same myth with Elon Musk right now. We have the same myth with Jeff Bezos, although as Amazon matures, we’re recognizing there’s a lot more people that were involved in the success of that company. And so I think that’s part of it is that we have to move away from that myth and recognize that building companies and especially, doing good discovery work is a team sport.

It requires multiple roles—it requires multiple perspectives.

[00:31:07] Janna Bastow: That’s a really good point. I’ve said to people before, like you’re not Steve Jobs and actually, Steve Jobs wasn’t even Steve Jobs, this idea of somebody on a pedestal, but you know, he didn’t do this alone and he had amazing people around him.

[00:31:20] Teresa Torres: I would argue Steve Jobs’ first Apple, he was trying to be the lone creative genius and he got pushed out of his company.

[00:31:27] Janna Bastow: That was his first fail that you talked about. Right?

[00:31:31] Teresa Torres: Yeah. And I think because of his work with Pixar where they have an amazing collaborative culture, and then, his work at Next, I know it was also a much more collaborative engagement. And so as a result, he comes back to Apple, and I think what we see is a much more collaborative approach. Still the like amazing standard of quality, which I think was his real superpower, which was, we are not going to release something that we’re not entirely happy with, it meets this ridiculous standard. And that’s, I think what truly inspired people to, as he say, put a dent in the universe, right.

[00:32:03] Janna Bastow: Yeah, that makes a lot of sense. That’s actually really key, building these MVPs or these tests or whatever it is, whatever you want to call them, doesn’t mean shipping things of low quality, right? A lot of companies try to get away with just shipping something fast and cheap and terrible, and then saying, oh, well it didn’t work.

We’ll go back to my idea. And that’s not what it’s about. You still have to have the quality there, but in order to have the quality, you have to sometimes, slow down and spend more time in discovery, more time thinking about how you’re actually going to build and deploy something and actually less time in the delivery cycle than you actually imagined.

[00:32:39] Teresa Torres: Yeah. This is one of the things, the Opportunity Solution Tree has helped me with a lot. And that’s that it’s really hard to communicate this idea of we’re talking about agile or MVP or starting small, or getting into the heart of the idea.

People interpret that as low hanging fruit or the crummy first draft. And it’s like, we’re taking this quality hit. And I don’t think that’s the idea at all. And this is where I think the Opportunity Solution Tree helps. The opportunity space onOpportunity Solution Tree is structured in a tree structure.

Here’s what that gives us. The opportunities at the top of your tree are big, hard evergreen opportunities. So the example I give is a Netflix example. Netflix probably has this evergreen opportunity. If I can’t decide what to watch, no matter how long Netflix is in business, they’re going to be trying to solve that problem.

Right. I can break that opportunity down into smaller and smaller opportunities. So I could say, why can’t people find what they want. I don’t know how to search for a specific movie. I don’t know if this show you recommended is good or not. I don’t know what my friends are watching. I don’t know what kinds of things I like.

Right? Like those are all sub opportunities. I could take something like, I don’t know if the show is good or not, and break it down even further. How do people decide if a show is good or not? Who’s in this show? Is it like something I’ve seen before? Does it have good character development or is it plot driven?

Right? Those are all sub opportunities. Now when we get to a sub opportunity, like who’s in the show. That’s a really small opportunity that we could design a really elegant high quality solution in a couple of weeks, but that’s not a hard thing to build. And so what that does is it gives us a teeny tiny starting point.

We’re fully satisfying a small opportunity and satisfying that small opportunity helps contribute to solving the higher level opportunity. It doesn’t solve it entirely, but it helps to contribute to it. So it helps to unlock this continuous cadence where we’re looking for iterative as small pieces of value that we can deliver where our quality stays high, but we’re unlocking this continuous cadence.

[00:34:44] Janna Bastow: Yeah. That really resonates. And I like how you talked about the fact that the opportunity won’t entirely be solved. Cause I think that’s true for so many cases. And this is one of the things I come across when people talk about the roadmaps with me is, if I put this on the roadmap, at what point in time does it come off the roadmap? Or what point in time is it solved? And it’s like, well, you don’t have to do everything. You don’t have to 100% solve every problem. Your job is to minimize the problems or maximize on opportunities. And then move on to the next thing, because if you’ve minimized a problem, then chances are the next problem is now bigger and relative order. And so you can move on to the next problem. And, eventually you might come back to that problem of that is then, the place that you optimize and that’s where you get to companies where they start optimizing, like the micro pieces here and there, but don’t get tied up and trying to micro optimize something, trying to finish off every last tiny piece, if there are other problem to go solve.

[00:35:39] Teresa Torres: Yeah, I think you’re spot on.

So this is also where I think having the visual of your primary goal is to drive your outcome. And when you’re assessing in the opportunity space, your assessment is which opportunity do we think will have the biggest impact on our outcome. And when you release a solution, you have to go back and reassess, okay, we’ve changed the landscape.

We put a new solution out there, which means that opportunity may no longer be the most important opportunity for us to work on because our customers might be satisfied enough that now there’s a more important opportunity. And so I like to see teams like literally after every code change, go back and reassess because you may, yes, there may be more work to do on that opportunity, but it may not be the highest impact place to work.

If your goal is to drive your outcome.

[00:36:28] Janna Bastow: Yeah, absolutely. And this is exactly why roadmaps should be flexible, right. They’re designed to be bashed apart every time you change something major, right? So you push something, you solve a problem, even part of the problem. You look at the list of problems again, you go is this still the main problem? Or actually, should we shuffle this back to the back of the list and go work on the first one? Somebody just asked the question, how could this flow be run in ProdPad? And this is how the Now/Next/Later lean roadmap is mapped.

It maps very much closely to the, the Opportunity Solution Tree, where what we call initiatives on the roadmap are opportunities, problems to be solved or opportunities, and you can attach ideas or solutions, each opportunity is attached to outcomes or what we call objectives.

And you can see how it all maps together. And if one of those opportunities moves, you can drag and drop it. You can see where they all sort of sit and flow with each other. So if anybody wants to take a look at that, happy to walk you through and, give you a demo, show how it all fits together in context of this tree.

[00:37:24] Teresa Torres: I’ll also share that, this past January on Product Talk, I shared a subset of my roadmap and I did it using the Now/Next/Future format. And the way it works is now, next, and future all had opportunities, right? So I have a Now opportunity. I have a Next opportunity and I have a Future opportunity.

Now also had a solutions in flight. I think Next had some ideas of what the solutions might be. I think Now actually even had some release dates. Like I think one of them—my Now opportunity was, at the individual contributor level, I need to know what to do when in discovery—and one of my solutions in flight was the book.

And I think I had a release date by that point. And then the other opportunity, the other solution in flight, which I don’t think I announced the details of in January was our membership program that we launched with the book. And then in the Next column, I had a different opportunity, my Next opportunity was, I’m an individual contributor and I wanted to build up skill in a specific discovery habit. So we have online courses in defining outcomes. It continuous interviewing and an opportunity mapping. And I’ve had on my roadmap for over a year now to launch courses in identifying hidden assumptions and testing assumptions.

And my plan was to get those out by the end of this year. So that was my next opportunity with solutions in mind, but no dates because I’m not working on them right now. I don’t have release dates. The audible version of my book is probably in that category as well. People keep asking me when it’s going to come out, I want to narrate it myself. I need a chunk of time to do that. God knows when that’s gonna happen, hopefully by the end of the year. But I can’t commit to that because it’s not in flight right now. Right. And then my Future opportunity was I really want to help leaders learn how to manage teams who are working with. I have no idea what solutions I’m going to build for that opportunity, because in the future, I haven’t even started thinking about it.

And what I like about that format is that you stay focused on opportunities, which is what really matters. But in the near term, you can give visibility to what’s in flight and when you might be releasing things, so the rest of the organization can plan around it, but you’re also communicating there’s a lot of uncertainty. Yeah.

[00:39:33] Janna Bastow: Yeah, that’s exactly right. And that’s why the Now/Next/Later works, it’s mapped to some people might’ve seen the cone of uncertainty charts. And that’s really where, one of the concepts that was built into the Now/Next/Later when we first built it, which was this idea that things that are close to you or things that you can see you’ve got granularity, you know how close it is or something that’s really, really far flung, you don’t know how far away that is. And it doesn’t actually really matter right now. Cause it’s not about to hit you in the face.

And somebody actually just asked, Ryan just asked us , for the Now/Next/Later, is there an expectation for dates in the Next column? And you know what, it depends, we don’t live in Lala land.

We don’t live in a world where there are no dates. Right. Sometimes there are dates that are inflicted upon us. We like to think that companies can be fully discovery led. And if we learn something interesting, we can all pivot tomorrow. That would be great. But we do have constraints and commitments and other things that sometimes mean that we end up having to move in certain directions.

Like for example, if there’s a new privacy law, like when GDPR landed, everyone had a card on the roadmap that had that date. You had to have something ready for that. But it doesn’t mean that just because you have a date for one thing that you have to force yourself to put dates for everything.

So you might put a date on something just to tell the team and communicate that, but don’t force yourself to put dates on everything, if you can actually take advantage of and be, more discovery-led.

[00:40:56] Teresa Torres: I also think we think of dates as bad. And I think there’s a distinction between a hard date and a soft date. GDPR was a hard date. It was a regulation. We had the follow and that you can’t even change the scope. You got to follow the law. I mean, there’s a little bit, you can change the scope, but you can’t change the scope beyond what the law requires.

And so I think that’s an example of a hard date. You got to rally the troops, everybody’s all hands on deck, whatever analogy you want to use, you have to hit that date. I think we also need to get better at recognizing like soft dates can be helpful because again, they allow everybody to plan and to coordinate efforts, but building software is complex and those dates might change.

I saw this in my business. If you had asked me in January, when I was going to launch my identifying assumptions and testing assumptions courses, I would’ve said June right after the book comes out. What I didn’t forecast was by June, my course business would have grown tremendously—It’s the upside of COVID—and my course infrastructure, which literally was put together with duct tape and shoestrings, was falling apart. And that I was going to spend my entire summer being a software engineer again, fixing my infrastructure problems. Right. So instead of getting to do course design, I got to become an engineer and I’m now literally rebuilding all of the software that underpins my business.

And that’s great. I feel now that we’re in August, I feel great about that. Cause I feel like I’m on a stronger foundation, but I probably won’t even start work on those courses until after the new year. There’s no way I could’ve known that back in January and there’s no need for me to commit to those dates.

Right? Like that was a soft date in my head. What’s the harm of pushing it out. Okay. I know people are eager and wanting to take those courses. I know I’m taking a revenue hit because I have fewer products in the marketplace, but if I had released them in June, I would have exacerbated the logistical problem having right now in my business.

And what’s going to be better for the long-term growth of my business, cleaning up those underpinnings and then launching on a stronger foundation.

[00:43:01] Janna Bastow: Yeah, that’s exactly right. That’s what I’ve heard. And the way that I differentiate between a hard day to not a soft date is, you know, a true deadline is a date after which if you launch after that date or do something after that date, the value is dropped.

You don’t have any value for doing something after that point, right? Like if you launch something the day after Christmas and you’ve missed the Christmas rush and like, well, what was the point? Right? Like that’s too bad. Maybe we’ll get the value next year. But, most of the time we don’t have those types of things we’re continuously updating.

And so one of the things that product managers can do best is create a space within our company and advocate for continuous deployment, continuous integration, a space where we can regularly get tests out and get insights back from those tests, so that hitting a particular delivery date.

Isn’t really painful, like pulling teeth to get the release out on time, just because the release has to be this particular date. So don’t inflict hard due dates on ourselves, cause sometimes they will be inflicted on us, but we don’t have to inflict them on ourselves. We can try to minimize them.

[00:44:04] Teresa Torres: And I think in a lot of companies, soft dates are treated like hard dates. Like if you miss them, you’re punished, you’re seen as failure. And I think that’s why dates get a bad rap. I think soft dates are a really important tool in our toolbox, but they have to be supported by a culture of, this is not a hard date.

[00:44:23] Janna Bastow: Right. So I’ve got a question here. Somebody says that they get push back when they’re explaining these ideas of continuous discovery, what’s the developer’s role in all this?

[00:44:33] Teresa Torres: Let’s see if we can pick this apart. So I want to start with this idea with scrum, where this is idea that the sprint is sacred, right?

So you’re creating two weeks, most of the time of user stories, and then it’s locked down and you can’t change anything during that sprint. I get why that was part of the scrum process because we saw stakeholders constantly changing requirements. I think it’s baloney. If you learn something that tells you you’re not building the right thing, you should not spend another day building that thing.

So that’s the first thing we got to let go of that. But don’t let this pendulum swing so far the other way, which is where we were before, which was people just change things, willy nilly based on their whim. That’s definitely not what I’m saying. If you learn something from your discovery from customers and you start to recognize what you’re building is the wrong thing, you should stop building it, regardless of whether you’re in the middle of a sprint or not.

So that’s the first thing, does discovery happen ahead of this sprint? This is a really hard question to answer because it’s really rooted in a project world. And I don’t remember how to think in a project world anymore. When your discovery and your delivery are truly continuous, there isn’t a discovery phase in a delivery phase.

I tried to give an example of this in the book. So in the book I tell the story of I was working at a startup. They were a job board for new college grads, or they worked like every other job board where on the homepage it said, what type of job do you want? Where do you want to live? The problem with that is for a 22 year old, fresh out of college, they don’t know how to answer either one of those questions.

So what we wanted to do was we wanted to build an interface where they could just tell us, where did you go to school? What did you study? When are you graduating? And we were going to put a machine learning algorithm behind it to match jobs to them because they just didn’t have the knowledge of what types of job titles were available.

We had this idea, we learned it from interviews. We learned from interviews that students didn’t, or they wanted to live. They didn’t know what type of job they wanted. And so by the end of the, it was literally like my week, one of working at the company. And by the end of week, one working at the company, I was sitting down with our engineers and I was like, What would it take to test an idea like this?

We didn’t have a single engineer who had a machine learning background, not a single one. And everybody was like, we have no idea. And I was like, okay. But really what I want to test is the interface is that if we ask students to tell us what they studied and where they went to school, will they engage with our job recommendations?

So we needed a way to prototype responses to that entry point. Right? Where did you go to school? What did you study? How do we show them jobs? Here’s what we do. We literally spent the weekend taking our list of majors areas of study in our program and generating ourselves can’t keyword searches for every single measure, because we as working professionals and the ability to Google and use Wikipedia could construct a better search query than the average 22 year old, who literally doesn’t even know where to begin.

So we literally spent a weekend re researching, like what kinds of jobs do economics majors get and what kind of jobs do English majors get? And we created these canned searches. And then we on like a Monday or Tuesday, we launched, we split our traffic and had a percentage of our traffic go to this other homepage where we just ran a canvas search in the background.

Here’s what this allowed us to do and allows us to learn well, more people start their search in this new interface and this other interface, will they even engage with the job listings? Because like they didn’t pick those two. It worked. We saw amazing results on our old homepage. We had like 35% of people start a search because most people didn’t know how to answer those questions.

On the new homepage. We saw 85% of people are, those numbers might not be exactly right, but roughly start their search. Okay. Where did discovery start and delivery start? I don’t know. We have a production product. Is it production quality? No, but we have a production product. We have real traffic engaging with our prototype and we’re collecting data.

We had a product in production. I have no idea where discovery started and ended and where delivery started and ended. And here’s what I do know. We started with a teeny tiny piece of value changed the way you start your search. And we found a way to test it in a couple of days. What did we do from there? We iterated on it.

We were like, okay. We can’t rely on canned searches forever. What’s our crudest algorithm we can put behind. And we literally like, we had our fresh out of University of Washington, math major start learning about machine learning. And he started doing all these like machine learning contests, trying to build his chops.

And he started working on like the crudest algorithm that we could put behind it. And we split our traffic. We still split our traffic between our old homepage, our new homepage. On the new home page, we split the traffic between our cans searches and the crude machine learning algorithm. And we literally just kept iterating.

There was no line between discovery and delivery, and this is true for most products, when you get to a continuous cadence, your assumption tests might start in prototypes and surveys and data mining, but eventually they’re going to iterate to live production tests.

So I don’t know how to answer this question. I just think it’s all the same work.

[00:49:56] Janna Bastow: Yeah, I think that’s a really good point. And you know what, it comes down to the process itself and how the team is working and one of the things that I’ve always done to approach that is, think about the process as a product itself. Like you’ve got a process, it’s the starting point.

We’ll treat it like a product, something that you can learn from and measure and iterate upon and improve, right? So each time that you work with the team, each retro that you do—retros are hugely important—you can improve on it and get better and better. And, over time your team can move from being more delivery focused and into being more discovery focused and get this blended approach that Teresa talks about.

[00:50:38] Teresa Torres: We’ll share, like I know most teams work in a project world, even if they’re doing scrum. So what I would recommend is, if you have to start by doing the discovery first in a sprint ahead, and then do the delivery, just keep working to close the gap between those activities.

[00:50:54] Janna Bastow: Yeah, that’s a really good point. Teresa, thank you so much for answering these questions and going into so much detail. I really appreciate that. I want to give a quick shout out for anybody who hasn’t picked up Teresa’s book. Definitely grab yourself a copy, I’ve got one here.

 Thank you all for joining us. This session was recorded and will be going up on our YouTube channel.

Teresa, thank you so much for joining us here today. Really good to have a chat about this and I look forward to the next time we get a chance to connect.

[00:51:22] Teresa Torres: Yeah. Thank you so much for having me the hour flew by!

[00:51:25] Janna Bastow: It did. Yeah, absolutely. Thank you all. Have a great day, morning, afternoon, wherever you are and talk to you all later.

Watch more of our Product Expert webinars