Q&A on Discovery

Rory Madden: 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. So, Marty is one of the founders of Silicon Valley Product Group but probably more famous for being the author of the books Inspired on the new forthcoming book, Empowered and being seen as really 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.
Marty Cagan: Thanks very much.
Rory Madden: And so, what we want to talk about today is Discovery. And it's kind of touching in a little bit on what that last conversation just finished up on which is kind of making sure that what you're building is something of value to customers and not just building for the sake of building but 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?
Marty Cagan: Yeah. Well and just to be clear, Discovery has been a concept forever in our entire industry and I think it always will be.
Rory Madden: Sorry. Just one thing, it's quite low volume. Is there any chance to increase that? Apologies, Marty.
Marty Cagan: No. No worries. Is that a little better?
Rory Madden: Yes. Yep. Yeah.
Marty Cagan: We've got a couple 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. 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 is 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 discoveries 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 its laws, legal compliance, privacy security, and we can also monetize it. We can make some money and we can actually afford it.
Rory Madden: 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?
Marty Cagan: Well, I mean 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, as long as it's there are some real challenges like machine learning which has got very hard usability, feasibility assignments but mostly it's value and then viability are the two hardest. 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, 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 covering anything. All you're doing is designing and implementing as just a practical rule of thumb. If you're not discarding it at least half the ideas you start trying, then you're not doing discovery.
Rory Madden: 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?
Marty Cagan: Well, it's a little more involved but it'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 a way in an empowered product team, rather than being even 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 it output but for 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 real outcome and as opposed to implement online tutorial videos to help our customers, that's a feature that may or may not do anything.
Rory Madden: [00:06:24] 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 and that it's learning is just a step along the way." So, can you elaborate on that and what you mean by that?
Marty Cagan: 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 learned. 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 we could do that might work. So, the point is it's all about that insights and solve the problem. 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. They think there's a phrase which is the, "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 him build it and look, if it works great when. 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. Using their engineers to see if it's to learn by the way, that 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 problems and helping us invent a great solution.
Rory Madden: Right. Now, it's a good point too. I've seen some, a lot of people that have kind of commented on the challenge that often it's kind of a hybrid of feature and product team, but you still have this concept where people are moving that the designers have to feed the developers. So, they're constantly just kind of trying to get something in front of dams to keep them busy.
Marty Cagan: 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 do, 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 moved to technical debt work anytime you start running out of things that are good. The engineer 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.
Rory Madden: Right. And how much should developers actually get involved in discovery?
Marty Cagan: Everyday but this is what's important. It only takes a few minutes a day. Normally, what we look for out of our developers every day. And I 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 on a little bit on your hiring for your engineers. But the reason what we're asking our engineers to do is really two things. We're asking them to well, to do one thing but look for too characteristics. The first, the only thing we're 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 is 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's sprint planning that is way too late and the second thing, the thing we want them to do, the second thing we want them to do is to see if they can't 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 used 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.
Rory Madden: Yep. That was great. Great. Kind of analogy approach. The one thing that you touched on there, it was kind of the lead only being part or potentially that's one option, if the lead only. We have Ryan Zinger 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 shaped the solution and you have the builders who build the solution?
Marty Cagan: 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 principal, 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 that this is because the people who are 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 but without having read the book yet, I can't say for sure.
Rory Madden: We'll, hear from Ryan tomorrow. So, he can clarify for himself. Back to I guess, the learning or the insights and that we talked about it with discovery. So, how do you track the effectiveness of a discovery and if we're not tracking learning or 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 measured that you're on track during discovery?
Marty Cagan: Well, one of the higher order principles is what matters is results not activity, not output. Right. 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 days. You don't need a big report or dashboard to monitor your progress in something that takes a few hours. We are weird testing out 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. 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 anymore 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.
Rory Madden: Great. So, it's kind of by trying to keep it small enough that you can iterate quickly.
Marty Cagan: Even you'd be surprised at how, in fact there is terrific book you may have heard of called Sprint: How to solve hard problems 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.
Rory Madden: So, I'll 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’re 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?
Marty Cagan: Well, just to be clear, discovery is not a phase, just any more than delivering the phase. Right. 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 couple of them, few of them. Jobs be done as 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 or these problems but whatever. Just like in delivery, there's different processes and different techniques whether the team is using Scrum or Kanban is to totally the different processes, both accomplishing the delivery work. 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 it 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 what the purpose of the book inspired was 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.
Rory Madden: 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?
Marty Cagan: 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 fall 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 officers under. Understand the constraints marketing has, sales has, product marketing has, finance has and once they understand those constraints, they are making sure that the solution. But the product team comes up with is going to be viable. It's going to work for the different parts of the business. Normally, they understand 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 up 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.
Rory Madden: Great. I'm just going to tag onto that thing. So, this is the responsibility of the product manager. And if we want to go with a product team, a small the kind of the two-pizza product team. So, 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?
Marty Cagan: Well, it's not all that different a question is 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 they'll 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. 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 that 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, 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. A product manager also has to go deep to learn the business like I described before, learn all those different stakeholders and what the concerns are and then the product manager has to learn the data on how their product is actually used. That's critical. You'd be the expert on the team, on the data and then they have to also learn the industry. A 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.
Rory Madden: Yeah. It's a lot to take on. I know you tried to avoid the Twitter Wars but there's one not too long ago, but 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.
Marty Cagan: Yeah. There is pretty much constant whining about the role of product managers and it just 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 but a product manager of a real product team which is what I'm talking about responsible for value viability is really nothing like the product manager on a feature team. A product manager and the feature team. These are the people they're talking about it sort of Jack of all trades, master of none, herding of cats. What they really are 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 a very much a project manager role 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 to it. It's just not the product manager job. 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. Those are 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.
Rory Madden: Great. I'm actually going to jump to another question from the audience. So, please, please do keep sending the main, and it was a great opportunity to ask Marty whatever been on your mind. I'm going to frame it slightly different. So, the question was, how do you split the time between your continuous discovery and delivery? But I'm going to frame that slightly different. 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 be still devoted to doing more discovery?
Marty Cagan: Yeah. I wrote about this just recently because it's a really common question. So, the real answer, one-word answer is judgment. There is no 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 bit 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. If you messed up, what's the consequence. So, whenever we talk about risk, we talk about consequence. What if you mess up if you mess up but you can fix it with an update push 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, 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." 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?" And do you think 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. I've done this a lot longer. What's my judgment on that?" And sometimes I'm telling you are 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 bet money your tech lead will say, this is way bigger than that.
Rory Madden: Yeah. So, it's a great kind of, you've mentioned judgments and then we've kind of talked about all the different bits that people need to do. How do you see the best way of kind of mentoring somebody? Is it that coaching approach or is it get your hands dirty and just get in there and get your experience?
Marty Cagan: 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 was 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 went out more into the left the bubble of HP labs, which was sort of like a Google is today and realize that a lot of people don't have this but without that coaching or even if the manager is willing to do the coaching, if they've never seen good before 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.
Rory Madden: 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 in your jo?
Marty Cagan: A little. I mean, I mostly advise and invest companies and I help them with their product vision and strategy and they're their leaders. But there are people absolutely called discovery coaches that coach product managers and designers on discovery work. They're great. I wish 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 it's only, I mean, 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 is actually, I actually had a chance to work at a good product company and seen it done well. I mean, I wouldn't hire the person.
Rory Madden: I'm sure there's lots of people don't take a one-day course.
Marty Cagan: I mean, if you join Google is a new product manager. It's about two years before a real coaching before you're going to be where you need to be.
Rory Madden: Excellent. That's good to know. One person's asking actually, are there any good people in product? Who would you recommend if you're trying to 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?
Marty Cagan: 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. Theresa Torres, you may have heard of her. Her writing is fabulous. Melissa Perry, Petra Willie, I list a bunch of other ones too but there are some really good people out there that you 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.
Rory Madden: Which we're seeing in lots of different ways at the moment. So, it 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 asks to me. Its 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?
Marty Cagan: 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, I mentioned before we have 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 and the other thing to keep in mind is you will typically have less customers because it's a business, so it'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 and in a bunch of books itself, but also in Inspired.
Rory Madden: Great. So, we're coming to the end of time but so inspired is kind of it's one of the top books that product managers should read. I actually believe that everybody in a product team 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?
Marty Cagan: Yeah. I mean, you're definitely right. Inspired was aimed at the product teams. I mean, 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 talked 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, but that what I realized with the 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.
Rory Madden: Great. I'm really looking forward to getting published. I hear it's at the printers at the moment.
Marty Cagan: December 3rd.
Rory Madden: 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 altogether and have enjoyed it as well. So, thank you once again, Marty. And then I'll hand it back to Snjezana now to close out for today.