Q&A on Discovery

Marty Cagan at UXDX Europe. Video: https://www.youtube.com/watch?v=dYMtc-c3qxY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and defining discovery

[00:00:00] Rory: First of all, I'm assuming for our product people in the audience we don't need to introduce Marty, but I will give an introduction for those in the UX, design and development communities. Marty is one of the founders of Silicon Valley Product Group, but probably more famous for being the author of the books Inspired and the new forthcoming book Empowered, and the blog on the SVPG.com website is kind of the go-to resource for a lot of people in the product management community. So first of all, we'd like to welcome Marty. Thank you.

[00:00:32] Marty: Thanks very much.

[00:00:37] Rory: And so what we want to talk about today is discovery. It's kind of touching a little bit on what that last conversation just finished up on, which is making sure that what you're building is something of value to customers and not just building for the sake of building. As a lot of organizations are adopting discoverability, or discovery, as a term, I'd love to get your insight, Marty, just on your definition. What do you define as discovery?

[00:00:58] Marty: Yeah. Well, just to be clear, discovery has been a concept forever in our entire industry and I think it always will be.

[00:01:10] Rory: Sorry, just one thing, it's quite low volume. Is there any chance to increase that? Apologies, Marty.

[00:01:16] Marty: No, no worries. Is that a little better?

[00:01:19] Rory: Yes. Yep. Yeah.

[00:01:22] Marty: We've got a couple of dogs near me, hopefully they'll be quiet. But so, I was saying discovery as a concept has been there forever, it's been there for our entire industry and I think it always will be. The term might be relatively new, it's about 15 years old, but the concept has been there forever and it's not a complicated concept.

[00:01:47] Marty: If you believe you need a workflow for your application, which we do pretty much every day all across the world, you need to figure out what that right workflow is and then you need to deliver that workflow. Those are the two activities that go on in every product team: discovery and delivery. Discovery is the term for figuring it out. And the way I define discovery is, we need to come up with a solution that's valuable — people will buy it or choose to use it; usable — they can figure out how to use it; feasible — we know how to build it with the skills we have, with the time we have, with the technology stack we have; and viable — it will work for our business, it will actually be something we can market effectively, sell effectively, it complies with the laws, legal compliance, privacy, security, and we can also monetize it, we can make some money and we can actually afford it.

Which of the four risks teams get wrong

[00:02:46] Rory: Great. And with those four kind of areas that you mentioned there, I guess your market fit, your usability, feasibility, viability, where do you find people are lacking most, or where do you think a lot of people that are saying that they're doing discovery are missing out? Which area do you believe is the worst offender?

[00:03:08] Marty: Well, the hardest is almost always value. It's not that hard to do a usable solution. I know I say that to a design community which works very hard to do that, but the truth is if a company uses best practices for design and does things like usability testing, then we can make sure it's a usable solution. There's no excuse not to. It's also mostly safe on feasibility. There are some real challenges, like machine learning, which has got very hard usability and feasibility assignments, but mostly it's value and then viability that are the two hardest.

[00:03:53] Marty: The reason this is complicated is because in most product teams the team is not actually asked to look at value or viability, even though those are the hardest. They're not asked to do it because some stakeholder has put on a roadmap a feature that the product team has been asked to build. And so if somebody asks you to build a feature, they are presuming value, they are presuming viability. Sometimes they've thought that through, rarely have they tested it. But we just know — and it's not about where it comes from, it could come from anywhere — we know that value and viability are hard. And so it's only a true empowered product team that is asked to look at value and viability. If it's just a feature team, for example, they're just asked to design and build. And in that model there really isn't discovery at all, because you're not discovering anything, all you're doing is designing and implementing. As just a practical rule of thumb: if you're not discarding at least half the ideas you start trying, then you're not doing discovery.

[00:05:12] Rory: Great. Is that your kind of definition of the difference between a feature team and a product team, that you're handed some requirements versus you're handed an outcome, or do you see them different again?

[00:05:23] Marty: Well, it's a little more involved, but that's the gist of it, yes. So in a feature team you're given features and projects to build, usually on a roadmap. You're responsible for output, which means launching a feature, sometimes on time, sometimes on budget, it's all about output. In an empowered product team, rather than being given features and projects to build, you're given problems to solve, and because you're given problems to solve you're held responsible not just for output but for an outcome, a result. So you're given a problem to solve like, we've got to reduce onboarding time, and the outcome is it's got to get down to less than a day. That is a real problem to solve, that is a real outcome, as opposed to, implement online tutorial videos to help our customers — that's a feature that may or may not do anything.

Learning is not the goal of discovery

[00:06:24] Rory: Great. Yeah, it's going to lead into my next set of questions, I guess, when you're given that outcome. There's uncertainty, because you don't actually know, as you're saying, if you're not failing 50% of the time. So a phrase that's kind of growing in prominence is, you either win or you learn. But you've recently come out and said that learning actually isn't the goal of discovery, that learning is just a step along the way. So can you elaborate on that and what you mean by that?

[00:06:50] Marty: Yeah, there's really two issues going on there. Well, first let's talk about what I was talking about, which was, in discovery you are constantly learning. Mostly what you're learning though is that your idea is not a great idea. That's mostly what we learn. I mean, that's just the reality. Not a great idea: either customers don't like it, it's too confusing, it's not worth it to them to do this, whatever. For whatever reasons it's just not there. And so the point is not to learn, the point is to solve the problem. An insight is a learning that actually we can do something with. So it's not just that we learned that it doesn't work, we learned also something we could do that might work. So the point is, it's all about insights and solving the problem.

[00:07:41] Marty: There is a broader issue though. The truth is most teams, in my opinion, have no idea what they're doing as far as agile. There's a phrase, which is, if the only tool you have is a hammer, everything looks like a nail. When you hear this "win or learn," what they're assuming is that, look, all we have is developers on a sprint, so let's give them something to build, put it on the backlog, let's have them build it, and look, if it works, great, we win; if it doesn't work, oh well, we learn. That is so sad. That is an example of a company not having any idea what they're doing.

[00:08:22] Marty: Using their engineers to learn that way, by the way, is an incredibly slow and ineffective way of doing it, expensive and slow. We could learn those same things without spending a full sprint for our engineers to build out a production quality, scalable, fault tolerant version of this product. So that's a sign, it's more of a sign that they really don't know modern techniques. Discovery is all about figuring out if it's worth building, in hours or days rather than weeks or months. So we don't want to use our engineers for that. We need our engineers to do much higher order things, which is building highly scalable products and helping us invent a great solution.

How much developers should be involved in discovery

[00:09:12] Rory: Right. Now, that's a good point too. I've seen a lot of people that have commented on the challenge that often it's kind of a hybrid of feature and product team, but you still have this concept where the designers have to feed the developers, so they're constantly just kind of trying to get something in front of them to keep them busy.

[00:09:36] Marty: Yeah, that's not really a hybrid or anything. It is true that product managers and designers often struggle to keep up with their developers. That is true, especially if they are trying to make sure they're providing good work, things worth building. But that said, I always tell the developers, it's a good problem to have, move to technical debt work anytime you start running out of things that are good. The engineers should push back, by the way, if they think they're getting ill-conceived work on the backlog. They should push back, they shouldn't waste their time building it.

[00:10:16] Rory: Right. And how much should developers actually get involved in discovery?

[00:10:20] Marty: Every day, but this is what's important: it only takes a few minutes a day. And also you have to be realistic, it's not always every developer, we don't need every developer. It is true that in a lot of the best companies they try only to hire developers that want to do this. But the truth is there are a lot of very good companies that just make sure that their tech lead, their most senior developer, is involved in discovery. But that depends a little bit on your hiring for your engineers.

[00:10:58] Marty: What we're asking our engineers to do is really one thing, but we look for two characteristics. The only thing we really need them to do every day is play with the prototypes of the day. We typically have at least one new prototype every day and we want the engineers to spend a few minutes, it's usually on the order of 15 minutes or so, to play with those prototypes every day. And the two things they're looking at: number one, is there anything in that prototype that makes them nervous as far as technical feasibility? Is there something we don't know how to do? The most common one I often see is, does this imply changes to a legacy system that would be a massive amount of tech debt issues that would show up and it would end up taking way longer than it deserves? We want to know that before we decide to build it, we don't want that at sprint planning, that is way too late.

[00:11:58] Marty: And the second thing we want them to do is to see if they can see a better way of solving the problem. Because they know the enabling technology so well, they may know that there is a much better way to solve this than what they see in the prototype. So just a few minutes a day from the key engineer is what we're looking for. Similarly, we expect our designer and product manager to have a few minutes a day, or sometimes it's 30 minutes a day, to be able to answer questions that come up in engineering, like use cases that weren't thought about. So they need to be available as well. But I want to be clear, this is one product team. All we're talking about right now is two activities, we're talking about discovery and delivery activities. If we were talking about quality assurance, then that applies to all of us, right? The product manager, the designer, we're all trying to find bugs, but it's not really the product manager and designer that are going to fix the bug, engineers are going to be the ones in the code base.

Shape Up, and tracking discovery

[00:13:05] Rory: Yep, that was great, a great kind of analogy approach. The one thing that you touched on there was the lead only being part, or potentially that's one option, if the lead only. We have Ryan Singer joining us tomorrow, who's going to talk about his book Shape Up. I'm wondering, have you read that, or if you thought anything about that kind of model where you have the people who shape the solution and you have the builders who build the solution?

[00:13:35] Marty: I have it on my list to read the book, because I've actually talked to him recently and I wanted to read it. There's a lot of things being attributed to his book that I found very surprising, and clearly he's being misquoted, I think, in some of these areas, but I promised him I'd read his book so I could understand. I will tell you, as a principle it's really bad to have one group of people figuring out the product and another group of people delivering the product. We learned that a long time ago, and this is because the people who have to build it really need to understand, they need to understand the learnings, otherwise they're mercenaries and they're not into it. And frankly this is why those innovation labs fail. Now, I doubt very much that's what he's trying to say, but without having read the book yet I can't say for sure.

[00:14:41] Rory: We'll hear from Ryan tomorrow, so he can clarify for himself. Back to, I guess, the learning or the insights that we talked about with discovery. So how do you track the effectiveness of discovery, and if we're not tracking learning, what do we track in discovery? Because it's before we've actually built something to release it to get the outcome that we're looking for. So how do you track that you're on track during discovery?

[00:15:14] Marty: Well, one of the higher order principles is that what matters is results, not activity, not output. So tracking your activities is worse than not helpful, because it actually gets people... they're called vanity metrics, right? They are not what we're trying to do. You have to realize most discovery is measured in hours or a couple of days. You don't need a big report or dashboard to monitor your progress in something that takes a few hours. What we're doing is we're assessing the risk. Is this thing we're working on valuable, usable, feasible, viable? Is it risky in one of those areas? Maybe we're not sure on feasibility, so we're going to dive on that. Maybe we're not sure on viability, so we're going to dive on that.

[00:16:03] Marty: So depending on where the risks are, it'll take anywhere from no time, where you literally just say it's not risky, put it on the backlog, we're done, to, if it's a big complicated thing like autonomous vehicles, months. So it could be anything. The main thing I try to say is don't focus on tracking your discovery work any more than how ridiculous it is to track your story points on delivery. That's all output. What matters is, are you solving the problems? And we know that by business results.

[00:16:40] Rory: Great. So it's kind of by trying to keep it small enough that you can iterate quickly.

[00:16:46] Marty: You'd be surprised at how... In fact there is a terrific book you may have heard of called Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. And these are big, hard problems. They talk about like 50 different case studies in the book and these are non-trivial problems, and in all of them they're doing it inside a week. They're doing the discovery work, not the delivery work, but the discovery work inside a week. So this notion that these are long things is not a true thing.

Techniques, and why there's no recipe

[00:17:18] Rory: So, you use that kind of sprint framework or approach. Is there anything that you recommend to people? Because there's design thinking, there's jobs to be done, there are design sprints, there's lots of these frameworks out there and approaches. What would you say to a team who are just looking for a bit of guidance on what they should be doing in their discovery phases?

[00:17:43] Marty: Well, just to be clear, discovery is not a phase, any more than delivery is a phase. You are discovering and delivering all the time until the team shuts down, the company shuts down, but you're constantly working. So you don't want to think of it as a phase. There are many, many techniques. You just listed a few of them. Jobs to be done is a framing technique, design sprints are kind of a discovery technique for big problems, but there are so many techniques. I've already been mentioning several of the different kinds of prototyping techniques for these problems. But whatever. Just like in delivery, there's different processes and different techniques, whether the team is using Scrum or Kanban, totally different processes, both accomplishing the delivery work.

[00:18:39] Marty: So, any good product team, the first thing I would tell them is there is no recipe. If that's what you're looking for, you're not going to find it. Product takes more thinking than that and more work than that. You have to consider each problem that you're asked to solve and then pick the right techniques for the job, and so that requires education. It's not that hard. I mean, that's the purpose of the book Inspired, to share the major techniques that every product team should know, and with those techniques you can solve pretty much anything that you're going to run into.

Who owns viability risk

[00:19:13] Rory: Great, it's good coverage. And yes, I'll be careful with my language around phases and continuous implementation. And I'm going to actually throw in, I'm just seeing some of the questions pop up from the audience. I'm going to throw in one of the questions from the audience. Now, this one's from John Clair: can Marty please expand further on the role of design and dev in viability, to reduce uncertainty and risk?

[00:19:45] Marty: Okay. Well, we can talk about all four of the risks if you want. Viability is actually not design and development's responsibility, that really falls on the product manager. Now, obviously usability falls on the design and feasibility falls on engineering, and we all help especially on value. But viability... I mean, you've all heard the product manager has to deal with all the stakeholders. That's referring to viability. The product manager needs to understand the constraints that the lawyer is under, understand the constraints that the chief security officer is under, understand the constraints marketing has, sales has, product marketing has, finance has.

[00:20:31] Marty: And once they understand those constraints, they are making sure that the solution the product team comes up with is going to be viable, it's going to work for the different parts of the business. Normally, if they've done their homework, they understand enough what needs to be done. But if they're at all unsure, what they do is they show a prototype to, say, the chief legal officer or whoever's doing the legal stuff, and say, I just want to double check that this is good, you have no issues with this, you don't think we're going to cross a line here. And they appreciate that, of course, because if there's a mistake it could be very costly. So that's how we deal with viability risk: it falls almost exclusively on the product manager.

Training product managers

[00:21:24] Rory: Great. I'm just going to tag onto that. So this is the responsibility of the product manager, and if we want to go with a product team, a small kind of two-pizza product team, how do product managers gain the experience to be able to, I guess, have the insights and the overview of the whole organization, if the product managers are broken up into smaller teams? So how do you train product managers?

[00:21:54] Marty: Well, it's not all that different a question from, how do you educate your designers and how do you educate your engineers? There are lots of hard and similar problems. Engineers have to know the architecture: do you really want them making major changes when they don't know the whole picture on the technology base? That's going to be very dangerous. Do you want designers to just ignore the rest of the customer's experience and just do whatever they want within one little bubble? No, of course, you care about the whole experience. And it's similar with product. They have to understand the product strategy as a whole, they have to understand the vision. And like designers and like engineers, there is a ramp up for new product managers.

[00:22:37] Marty: It usually takes a product manager on the order of three months of hard work to get ready to be able to make a good decision, and that includes a lot of work. First of all, it's really getting to know the users and customers, which by the way they typically do with their designer with them, they learn that together. They're looking at different things, obviously. Designers are trying to get inside the heads of the users about how they think about these problems, how they're going to use it, what are their behaviors. Product managers are looking at other things: how do they make a purchase decision, who has to approve, what's the dynamics of their business? We both care about learning about customers, they're just different things about those customers.

[00:23:14] Marty: A product manager also has to go deep to learn the business, like I described before, learn all those different stakeholders and what their concerns are. And then the product manager has to learn the data on how their product is actually used. That's critical, you should be the expert on the team on the data. And then they have to also learn the industry: competitive landscape, enabling technologies and trends and so on. So those four things typically take on the order of three months for a product manager to come up to speed. That's usually longer than it takes a designer and an engineer to come up to speed, but that's the nature of the game.

Is the product manager role overburdened?

[00:24:01] Rory: Yeah, it's a lot to take on. I know you try to avoid the Twitter wars, but there was one not too long ago with everybody just questioning whether product managers are overburdened and has the role taken on too much, because as you were mentioning, they have to be advocating for the customer, for the business, for the different aspects, legal, all these other things that they need to be able to put all the pieces of the puzzle together.

[00:24:28] Marty: Yeah. There is pretty much constant whining about the role of product managers, but you know what's really going on there, honestly, is very different. It really shouldn't even be called the same title, product manager. A product manager of a real product team, which is what I'm talking about, responsible for value and viability, is really nothing like the product manager on a feature team. A product manager on a feature team: these are the people they're talking about, it's sort of jack of all trades, master of none, herding of cats. What they really are is project managers, and I'm not trying to dismiss that, that's not trivial. But when you're a feature team and you are given roadmaps, then the product manager role is much more about making sure all the work gets designed, making sure it gets on the backlog, making sure it gets out there. It's very much a project manager role, and because they're project managers they have to be at all these meetings, it's nonstop. I mean, don't get me wrong, that's a big job too, it's just not the product manager job.

[00:25:52] Marty: Now, is a real product manager job hard? Yes, for sure. Is a good product designer... I mean, when I talk about product designer, I'm not talking about a graphic designer, I mean somebody that's trained in service design, interaction design, visual design, user research. At a great product company those people are gold, and companies like Google and Facebook and Amazon work constantly to hire serious product designers. That's the partner. That's a hard job too, I think your audience would appreciate that. Tech lead is a hard job. It's a very hard job and it's a great job, don't get me wrong, but it's a hard job. So doing great products is not a trivial thing and it takes some real skills, and those are the three kinds of skills we need in each of these teams.

When have you done enough discovery?

[00:26:48] Rory: Great. I'm actually going to jump to another question from the audience. So please do keep sending them in, it's a great opportunity to ask Marty whatever's been on your mind. I'm going to frame it slightly differently. The question was, how do you split the time between your continuous discovery and delivery? But I'm going to frame that slightly differently: when do you know when you've done enough research and discovery that you can then start committing to building something, and when should the team still be devoted to doing more discovery?

[00:27:19] Marty: Yeah, I wrote about this just recently because it's a really common question. So the real answer, the one-word answer, is judgment. And it's true, because here's what's going on. Every single problem you're asked to solve is different, that's just the nature of the game, they're all different, which means they have a different risk profile. And every company has a different situation: if it's a startup with very little to lose versus a large company with billions in assets, you could be sued, all these different factors. And the result is we have to consider those four risks — value, usability, feasibility, viability — and then we have to make a judgment call.

[00:28:04] Marty: If you mess up, what's the consequence? So whenever we talk about risk, we talk about consequence. What if you mess up, but you can fix it with an update pushed live tomorrow? It's not that big a deal. If you mess up and your company could lose millions of dollars, or it could be a legal risk, you could be sued, whatever, that's a big deal, we need to know that. So you're looking at this every time. And so the answer to your question is, once the product manager, product designer and the tech lead feel like, you know what, we've got enough evidence, we know what we need, we feel like we've done enough to know it's worth building.

[00:28:49] Marty: There's a whole other level too. Once you understand the risk, you have to say, what's the easiest way for us to address that risk, what's the fastest, cheapest way we can try that out? But that's back to the skills of discovery teams and what are the techniques, which technique should I use for this? It's a judgment call. And your managers... the primary job of a people manager is to coach, and I will tell you one of the most common coaching discussions is the product manager comes to me and says, here's what I'm facing, this is the problem, what do you think, how risky is this, what is the consequence if we screw this up?

[00:29:31] Marty: And I've often been asked, do you think I'm over-testing, do you think I'm under-testing? These are totally fair questions, because what they're asking is like, okay, you've done this a lot longer, what's my judgment on that? And sometimes I'm telling you, you're fine, you've already analyzed this to death, it's fine, there's no real issue there, and even if there's a problem it's easy to fix, go for it, just get it on the backlog. Other times I'm saying like, oh, you think this is only going to take two weeks to build? You're crazy, this is going to take way longer to build, trust me on that. And by the way, if you don't believe me, just go talk to your tech lead about what's really involved here, because I'm pretty much going to bet money your tech lead will say this is way bigger than that.

Coaching, and the biggest problem in the industry

[00:30:19] Rory: Yeah. So that's a great kind of, you've mentioned judgment and then we've talked about all the different bits that people need to do. How do you see the best way of mentoring somebody? Is it that coaching approach, or is it get your hands dirty and just get in there and get your experience?

[00:30:41] Marty: Well, I do think you've got to get your hands dirty, but I think if I had to pick the single biggest problem in our industry right now, it's that there aren't enough managers that are skilled and motivated enough to do the proper coaching. I had coaching for the first 10 years of my career. Every single day there was at least one manager assigned to coach me to get better at my job. Most people I meet today have never had real coaching. And I didn't realize this, of course, until I left the bubble of HP Labs, which was sort of like a Google is today, and realized that a lot of people don't have this.

[00:31:24] Marty: But without that coaching, or even if the manager is willing to do the coaching, if they've never seen good before, if they haven't worked at a good product company that knows what they're doing... I appreciate that they're willing to spend time to try to help their people, but how much can they really help them if they don't know what they're supposed to do either? So I think the biggest issue in our industry is weak leaders, and I mean weak leaders of product management, product design and engineering. And those leaders need to up their games so that they can provide this effective coaching to their people. Without that coaching it's random.

[00:32:13] Rory: If anybody's thinking of a business idea and they're looking for a niche, it sounds like coaching of product leaders is an open season area. Is that what you do yourself, Marty? Is that what you would classify your role as in your job?

[00:32:26] Marty: A little. I mean, I mostly advise and invest in companies and I help them with their product vision and strategy and their leaders. But there are people absolutely called discovery coaches that coach product managers and designers on discovery work. They're great. I know probably a dozen of them around the world and I know there are many more, I just personally know about a dozen of them, and that is a great role. But anybody can call themselves a discovery coach, by the way, just like anybody can call themselves an agile coach, but we all know many if not most agile coaches should be nowhere near a product team. But it's the same: unless that discovery coach actually had a chance to work at a good product company and has seen it done well, I wouldn't hire the person.

[00:33:24] Rory: I'm sure there's lots of people who took a one-day course.

[00:33:29] Marty: I mean, if you join Google as a new product manager, it's about two years of real coaching before you're going to be where you need to be.

Resources for people without coaching

[00:33:43] Rory: Excellent, that's good to know. One person's asking actually, are there any good people in product? Who would you recommend if you might not have the coaching in your own company? Is there anybody that you'd recommend to follow, or anything that you can do as an individual who doesn't have access to that coaching?

[00:34:03] Marty: Oh, there's great resources today, for sure. The challenge of course is that there are way more bad resources than good resources. So imagine being a new product manager, a new designer, and like, where do you look? It's so random and you could easily get contradictory and also nonsensical advice and information. I got so frustrated with that at some point a few months ago, I wrote an article which is "Product Managers Start Here" and I listed a bunch of articles and people to follow. Yes, there are more people spouting nonsense about product than ever before, but there are also more good people talking about product than ever before. Teresa Torres, you may have heard of her, her writing is fabulous. Melissa Perri, Petra Wille. I list a bunch of other ones too. But there are some really good people out there that you should definitely pay attention to, and if it was up to me, don't read any of the nonsense, because it'll just completely derail your efforts. That's harder to do, the internet is not really set up for that.

Discovery in B2B

[00:35:22] Rory: Which we're seeing in lots of different ways at the moment. So just one thing I want to touch on, we're almost out of time and I'm just going to finish on one question that often gets asked to me. Discovery is great in a B2C environment where you have these massive kinds of numbers of customers and people that you can reach out to. Is there any advice in a B2B environment where you have a much smaller subset of customers to talk to?

[00:35:51] Marty: Yeah. In my experience, by the way, B2B is easier to do good work in than consumer. You're absolutely right that the main difference is traffic, just volume, although a startup B2C doesn't really have much traffic either. So all that really means is that we have, as I mentioned before, a big set of discovery techniques. Some of them are quantitative techniques that do require... when I say require, they don't really require massive amounts of data, but they work a lot better and faster when you have good amounts of traffic. But we also have all these qualitative techniques, which are just... I mean, they're not equal, they're different, right? The qualitative techniques are used for different things than the quantitative. But for B2B we usually focus on the qualitative.

[00:36:48] Marty: And the other thing to keep in mind is you will typically have fewer customers, because it's a business that's buying, but you will have many users at every customer. So we don't usually have trouble getting lots and lots of users, it's more the businesses. And yeah, there's many techniques. My all-time favorite in the B2B space is called the customer discovery program technique, and it's fabulous. It's probably responsible for more successes than any other technique I know. And if you're interested in that technique, that's talked about in a bunch of books itself, but also in Inspired.

Inspired and Empowered

[00:37:24] Rory: Great. So we're coming to the end of time, but Inspired is one of the top books that product managers should read. I actually believe that everybody in a product team should, because I think a lot of the examples and ways of working are transferable to everybody in the team. Do you want to give a quick word about your new book Empowered and how that's different to Inspired?

[00:37:49] Marty: Yeah. I mean, you're definitely right. Inspired was aimed at the product teams. I talk a lot about product managers because in my experience there aren't many resources that talk to them. There's plenty more that talk to designers and engineers, but product managers kind of don't have a lot. But it's aimed at product teams, and that's actually, my interest is in product teams because it's product teams that solve hard problems, not product managers. So that's what that did.

[00:38:16] Marty: But what I realized with Inspired was a lot of companies don't actually let their teams work the way they need to. And this drives me nuts when I find companies like that. What I described in Inspired is how good teams at good companies work. But in a company that's not like an Amazon or Apple or Netflix or something, they're just output, they're just feature teams. And so I wrote Empowered as a way to try to help those leaders understand how to change and become working like the best, because I've found that most of those companies know that they're not very good, they just have no idea how to change.

[00:38:59] Rory: Great. I'm really looking forward to it getting published. I hear it's at the printers at the moment.

[00:39:08] Marty: December 3rd.

[00:39:12] Rory: Excellent. Yeah, everybody should go out and buy that, and Inspired if you haven't got a copy already. And so I'd love to thank you for your time, I've really enjoyed the conversation. I hope everybody watching at home, unfortunately instead of being all together, has enjoyed it as well. So thank you once again, Marty, and then I'll hand it back now to close out for today.