#176: Why Most Product Organizations Struggle with Jason Knight

0:00Actually, one of the good things about well-functioning product organization is that it's okay to say no to good ideas. Maybe the reason that you're not doing it is because you've got an even better idea. And you should be able to stand behind that rather than kind of dragged into every single new idea. I'm Brian Milner, and this is the Agile Mentor's podcast. A show about both the personal and organizational journey towards agility. My friends and I will be sharing with you what we've collectively learned from seeing thousands of company's Agile implementations, the perils and pitfalls, as well as the secrets to success. We'll share our personal and the trenches experiences so that you can apply what we've learned in a practical way in your careers. We also hope to hear and learn from you as well. If you're like us and are always in search of better ways of working together, you're in the right place. Join us, mentor and be mentored. Let's get started.

1:06Welcome in Agile Mentors. We're back. We're here for another episode of the Agile Mentor's podcast. I'm here as always, Brian Milner, but today I have a very special guest with us. I'm Mr. Jason Knight with us. Welcome in Jason. Thanks so much for having me. It's a pleasure to be here and looking forward to chat. Yeah, absolutely. For those of you who haven't crossed paths with Jason, Jason is a product consultant and coach. He's a podcaster. He has a very popular podcast called One Night in Product. He's based out of the UK in London. He basically focuses on the B2B products area and helps organizations to revamp their product practices and refocus around how to get some discipline to their product area. We wanted to have Jason on to talk about that a little bit. He's got a fascinating blog post and the episodes from his podcast are really all around this topic. With the renewed focus in the product area in this AI world, I thought it would be great to have Jason on to talk about this.

2:07He had a post that we'll link to in our show notes. There was really on how to transform the product organization. I wanted to dive in there a little bit with you, Jason. First of all, what does that mean to transform the product organization? What does that look like? It's a really good question. If you think about some of the things that, for example, all these books behind me, I just did a talk in Lisbon, a conference about product management, not being like the books, which is always a popular topic because so many people are out there looking at these books and blog posts and articles and podcasts and everything else that we're doing. They're like, well, that all sounds great, but. There's something that's not like that in the context. Their business doesn't work like that. Their leadership team doesn't work like that. They're not allowed to do that sort of thing or they're kind of held back from doing certain things. There's this kind of almost wonderful idea of like, well, if we just, if we just did this, this, this, this and this, then we'd be a quote unquote, proper product company. That's a Ben Horowitz would be proper or good product managers rather than, you know, bad product managers or working for a feature factory or whatever.

3:14Now, I'm going to say you can go on a limb here and say there are lots of companies, probably more companies that are not operating like that, than I'm operating like that. There are lots of great examples of companies that do work like that. And obviously, some of the books that, for example, Marty Kagan and transformed as the case studies of big and small companies, all the Silicon Valley companies that, at least on the surface seem to work like that. But there's also lots that don't. That's fine. But, you know, to the point of the question is, well, what does it mean to, you know, to be that? Is that, well, in theory, what it means is you've got a product management team that is fully responsible for the direction of the product that is sort of sitting there at this kind of intersection between business and users and technology, making sure that the product, that the organizational products, that the organization is building, fulfill or address all of the different viability, usability, all of the risks, you know, all the kind of a classically shades that we start to chop out. I would certainly, I like to think about it. And I'm actually going to steal this thing, this quote from Nick Mehta, who, until recently, was the CEO of the game site. When I interviewed him on my podcast, I was asking him a question like, what is the job of customer success?

4:18Surely we should all care about customer success. Because that's obviously his bag. And he said to me, well, yeah, everyone should care about customer success. But one team wakes up thinking about that from the first thing in the morning to the last night, or at least whatever that is in the context of business. So like your day at work, you get to work, that's the thing that you care about. You don't care if it's a technical issue or a product issue or sales, you just care that your customers are successful. So I like to extrapolate that. So what's the point of a product team? What is a world functioning product organization? It's a company where you've got a function within the organization that cares deeply, not only about the technical implementation or whether it's being delivered properly, whether the processes are being followed or whether the market materials are good or whether the users are happy. You got someone that cares about all of that in the context of that product and a driving forward with that mentality. Putting the users first, putting the customers first, sometimes they can be in opposition, understanding the difference and just driving product forward as a practice within an organization. You could sit there and say, well, that sounds wonderful. Do we just need some cool product managers to come in and do that? Maybe.

5:22But at the same time, it's not just about having a product manager function and just sort of ticking a box and saying we have it. There's also got to be this kind of cultural element of actually enabling the team to do that, giving them the authority to make decisions or at least influence decisions and making sure that someone's looking after the product and not just a part of what makes up the product. Yeah, no, that's great. I love that. It's kind of a struggle for a lot of these companies because it feels like there's so much for us to do that a lot of these organizations that I've talked to just have this enormous backlog of stuff that they just think, gosh, if I could just turn through all this stuff, then that's how I'd be successful, kind of swimming in a sea of opportunity kind of thing. So how does a product organization start to really winnow down into what's really going to make an impact? It's an incredibly, incredibly common and let me say provocatively naive kind of idea that somehow, like, there's something that new product people will see as they go into an organization.

6:23They'll see exactly what you've just described, like a 200, 300 long item, long backlog of different types of things, different size, and obviously you could use some of your organization's work and mics work around estimations and agile planning and some of those techniques to try and get through that. But the ultimate point or the problem that many of these companies face when trying to answer that question isn't so much, well, how can we go with this stuff done? It's which of this stuff or what from this list should we even be working on? So if you've got this laundry list of 300 things, they've probably been estimated in some way, fine, brilliant. Maybe they've gone through something horrible like Moscow must should could, and you sit there and say, okay, well, that's great, but someone said must for at least, each of those things, at least one person said must. So you've basically got a list of 250 musts and, you know, like a handful of goods down the bottom and maybe a couple of shirts or all which have way around. And you're just sitting there and you're kind of comparing, as I like to put it kind of apples with oranges, right? You're sitting there saying, well, this thing over here, which is like a new front envy right over such and such or a mobile apple.

7:28This is a bug fix. This is breaking into a new market. This is internationalization to support that. This is some regulatory thing. This is a nice to have visualization on a chart, and it's just so different to each other. It's not even possible to actually even, even if you do score them, it's not possible to trade one off against the other. You're sitting there saying, well, how can I balance that against that? Or what you end up being in a situation, if you're kind of driven down a path of having worked on too many things, you end up almost having to do, you can't say no to any of the things. You can't say no because there's no kind of decision guard rails or anything that you just sit there and say, okay, well, everything's important. We've got one big customer that wants this, one big customer that wants this. They're all too big to say no to. We've got to try and somehow squeeze it in at the same time as making progress on some strategy that you may or may not have. And you sit there and think, well, how do we decide? How do we make a decision about any of this? And I think that's really where you get to the point that how do you make that decision? Now, the book answer would be, well, you need a strategy and a vision and a strategy that have a three to five year vision, 10 year, 20 year vision.

8:30Let's have a strategy for the next one year or so based on the best evidence that we have now, let's make, we can make some decisions. We're going to say we're going to do this and we're not going to do this. You know, strategies should be consistent and they should be focused and they should be evidence based and they should be actually oriented, et cetera. So you sit as, okay, well, we're going to work on whatever we're going to work on going into the US with our app or whatever, because we've never been there before. There's a big opportunity. We've validated it by this. Let's go this, which means we're not going to do this. So automatically a bunch of stuff just falls off the backlog in theory. Or as some people might say, if you follow the right people on LinkedIn, just delete the backlog. There's a great idea. I've never seen it happen in an actual organization, but you know, you can get away with it. Then give it a go. But like, it's just this naive idea that somehow all of those things on the backlog are ever going to get done. Like some of them will, but not all of them. And it doesn't matter how many times you reprioritize it and resort it. They're not all getting done. It's just going to get longer. You look at a backlog. It's stuff on it five years old. None of it's getting done. It's just sitting there as baggage. Doesn't mean it's not a good idea.

9:31And I think actually one of the good things about well functioning product organization is that it's okay to say no to good ideas. Maybe the reason that you're not doing it is because you've got an even better idea. And you should be able to stand behind that rather than kind of dragged into every single new idea. Everything being put onto a backlog. Everything having this expectation eventually at one point is going to get worked on. There needs to be something on top of that to say, this is our filter. We're working on things in this area. We're not working on things in this area. Yeah. Yeah, I agree. I mean, otherwise, like you said, there's no focus. And you just sort of scatter shot all over the place. This is kind of one of those points, I think, for product organizations where like we say sometimes where the rubber meets the road. It's sort of like you got all your stakeholders that all are vying for attention because they need something for their area or they need something to do what they need to do. But then somehow you've got to balance all that from a product standpoint to say, well, what's best overall? And I love the focus you started with about impact for the customer and what difference are you making for the customer as sort of being the thing that tips the scales.

10:40When you start to line all these different priorities up and different ideas that that should be the one that actually determines what goes first and what goes next because that's ultimately what we're trying to do is impact the lives of our customers. But as an interesting kind of wrinkle around this kind of concept of a customer, of course, we all care about our customers right. And again, customers and users be to be sometimes could be different. You could have like the compliance arm of a bank that actually buy you and it's the kind of the frontline workers that are actually using you. And maybe they don't even like each other that much within the organization. Sometimes it depends like sometimes some of these teams are frankly forced to use tools that they're every tower city hall people buying for them. And that's fine. Like, you know, ultimately, you still want to make it good for these people, but you kind of have two different camps to sort of satisfied. But there is this interesting thing around the kind of the concept of customers and actually sometimes what how I see it. I don't know how it is in the US, but certainly in the UK and actually in in certain parts of Europe. You know, Latin languages, for example, it's the same word, but I like to look if I look at a company that talks about working with clients versus a company that talks about working with customers.

11:45Because for me, a customer is someone who buys something that you have made, you know, whatever that is, you know, in our kind of case, it's like a SaaS tool or something, but it could just as well be a can of beans or some shampoo or something. We build a thing that we decide what it should have in it based on the knowledge of the whatever the competitive landscape, what the preferences of users are or customers. And we make a thing repeatedly that we can sell to all of those different people. A client is someone who comes to us with a piece of work and we say, right, okay, well, let's work out how we can do that for you. Now, that's not 100% across the board. Like, there are people that just default to one way of saying it or others are not the same. Say, for example, Spanish, it's the same word for both. So like, it doesn't work in all scenarios. But there is still this broad definition of what a customer is or what being customer focused is. So like, if I think about what being customer focused is and it's kind of what you touched on. How do we do something to meet the best needs or to meet the needs of all of our customers? Yeah, all of the people that could potentially, you know, currently and in the future by our staff. Not how can we satisfy that one individual customer over there?

12:48So like, when you say your customer focused, then you go to, for example, a customer success or particular someone that's working on a bunch of accounts. For them, being customer obsessed means working and solving problems for their customers. The ones that they're looking after doesn't necessarily mean that they care. You know, cares may be the wrong word, but they're not incentivized to care about all of the customers and the future market potential. They're incentivized to care about the accounts that they're, you know, called to look after. In which case, being customer focused starts to feel a bit woolly because like, what does it really mean? Anyone can say they're customer focused because just doing things for one customer can sound customer focused. Our job as product people is to sit there and say, well, actually, we have lots of customers who hopefully we do anyway. How can we solve and how can we fix things for as many of those as possible and kind of capture the or solves the needs of a market and capture a market versus individual customers one at a time. That's a very big mindset shift. Yeah, and the whole now we're back to prioritization, right?

13:49I mean, we look at prioritization for products, but then you have to prioritize your customers as well and your clients and say which one is most important right now, which one's important in this thing I'm working on. I'll just step away from this fascinating interview with Jason for just a moment to make sure that you guys are aware of a new offer that we have here at Mountain Good Software. We've only had that for a little bit now, but we've actually packaged up all of our video courses that we've offered in the past. There's eight of them that you can now get as part of our Agile Skills video library. It's an on-demand video library with some really extensive courses from both Mike and myself that are on there. All eight of those are now available to you. These are our courses that we've had for a long time like better user stories. Mike's really popular course on user stories at Agile Estimating and Planning. You can go really deep into that, estimating with story points and really understanding what story points are like. The courses I developed last year, better retrospectives and retrospectives repair guide, both of those are included.

14:54Scrum repair guide, let go of knowing, scrum foundations. These are all courses that are available to you as part of this package. We have an AI tutor that goes along with you alongside as you go through these courses that lets you ask questions about the module that's here on. Find out deeper information about it. All of these are bundled together for just $99 now. That's lifetime access to all that material. Take advantage of it. You can find it on our website and find out more information about this. Let's get back over to Jason. That brings to mind kind of an important area as well. That's actually connecting to our customers and how we actually listen to them and hear from them because I know there's lots of product discipline around there around sort of trying to envision what our customers needs are. But I'd like to talk a little bit more about how we actually connect and actually talk to real customers. Well, the obvious answer to that is just go and talk to them.

15:56But that is something that's not always as straightforward as it sounds. Now in some organizations, there will be specific barriers between product teams and customers. Be they sort of a sales team or the customer support and the customer success teams. People are maybe executives if they're really large customers and they'll be like, well, you can't go and speak to those people. I actually had this said to me before, you can't speak to these people product team because you're not as an expert. You're not an expert in this industry. You're product people. You're not financial people or consumer goods people or whatever industry they're in. And therefore we need other people to go and talk to those people. There's kind of idea that somehow the job of the person talking to them is to go and sort of share stories about how cool they are in that industry versus what we all know that these people should be doing, out and finding out why these people's problems, what's going on in their lives. How are we serving them at the moment? How could we serve them better? Are there any new and unmet needs that we have or any potential? Yes, threats or whatever. So, you know, as product people and I include designers, obviously within the product area as well as engineers,

17:03we should all be interested and care and empathize with our customers' problems and our users' problems. Maybe again, maybe they're different depending on that balance. So, we should go and speak to these people and if we're not able to, we need to address that. So, how can we address that? Well, maybe we can start to go on right along with the sales team. It's not quite as good as doing it yourself in a proper sort of kind of unguarded setting with people that don't think you're trying to sell to them, but it's better than not doing it at all. How can we find any ways to give here? Can we do customer panels? Can we do quarterly things where they come in and we kind of present some stuff and get to ask some questions and bond with them? What kind of secondary data can we use? You know, can we, whilst we're all aware that, for example, sales teams are going to be asking these sales-focused questions, can we get access to those recordings and kind of mind those for information? Can we mind the quarterly business reviews that the customer's success teams do to try and find more sources of input? Can we just look at social media and see what people are saying about the space here? Can we look at market research industry reports?

18:05Now, none of those are as good for most common use cases around like, well, going out and actually doing a customer interview with some actual customers or potential customers, but there's still additional sources of information that can be brought in. There's also now the tantalizing idea of synthetic users. You know, let's just use AI to generate synthetic customers and see what they would think. Time will tell on that one, it's not a bad idea to see what it says and maybe give you some ideas, but I'm not sure it can kind of replace everything yet. But I don't even think the people that are creating these tools think that it's going to replace everything yet. But it's just a good, an additional source of input. So what can we do to get as many sources of input as possible? What can we do to build credibility with customer-facing teams? For example, sales or, again, account management, etc. So make them understand that we're on the same side as them that we're not going to talk to customers because we think these people are stupid or because we don't think that they can talk to customers properly, but that we just want to go and find out not what they want now,

19:05but what they're going to want, what the future is going to hold, how we could potentially get ahead of their requirements, demands, jobs to be done, etc. What can we do to make sure that the sales team, the account management teams, are easier in six months to 12 months' time versus just solving the problems that we are. Where we get dragged into a customer conversation at the last minute because of an escalation. But that is, again, it's a mindset shift. And there is a credibility problem in a number of B2B organizations where, for example, again, you get that same mindset, the product team aren't capable of going to talk to customers. Or we don't need them to do that because we've already had someone else go and talk to them. There's about trying to almost win permission for that by getting some sort of small customer interactions to start to try and build credibility with your kind of customer-facing teams. Start to maybe show us some examples of some early wins. The product team went along and they did some things, they showed a thing or they found out something, they turned that into whatever they turned it into.

20:09And now that customer's happier or that type of customer ideally is happier. Start to demonstrate those kind of incremental gains and ideally then get to a point where you can start doing the kind of Theresa Torres continuous discovery once a week type thing which is kind of the gold standard. But yeah, I completely appreciate that many companies aren't anywhere near that. Yeah. It's fascinating to me. It seems like we throw up a number of barriers to actually talking to real people. You mentioned kind of the AI simulation of a customer. And I'm kind of with you on that. I think that's the vertex alpha that best I think you can look at it sort of like a mockup. You know, it's a mockup of that conversation. It's not the real conversation. And I'm surprised that a number of times I've worked with different product people. And when I ask just the basic question, have you done a customer interview? Have you actually talked to a real person and asked them questions about it? Well, no, we haven't done that. We've mocked it up. We've created personas. But no, we haven't actually in any way touched base with a real actual live human being.

21:13And to me, it seems like that's got to be a foundational aspect of it is that we, you know, because people are complex. They're not something you can sum up in a persona and get all the aspects of them. You have to actually ask questions and reshape your thinking about what it is that they need. Yeah, I agree. And I think it's really important for people, obviously, to do that, but also to acknowledge if they're not doing that and try to work out, well, where is their information coming from? So, yeah, we sit here and obviously part of the Agile Manifesto is around, you know, engineers and product people going out and speaking to customers all the time, right? Like that's part of the loop. And that's something I profoundly believe in. And even in my past, when I've worked with the most kind of cliched, inwardly facing, kind of headphones on all times, engineers. And, you know, I used to be one of those, by the way, earlier in my career. So, I speak with all the love in the world, but there is this kind of cliché, well, engineers don't want to go and do that kind of thing. They just want to go and, you know, code stuff.

22:13And some do, but not all do. And even the most sort of flinthearted from the outside sort of engineer that I've seen that's kind of, you know, even if they've not done themselves, they've maybe watched the recording of a customer interview of someone that's excited about a thing that's been released in the product so that they can now save hours a week and whatever. Get home to their parents, not their parents, but they are parents. They get home to their kids and, you know, like, because they've saved that time, it's really easy for people to lose sight and track of the real lives of the people that are using their software. That doesn't mean every single person in the organization has to go and talk to everyone about everything. But I do think that more people within the organization should, you know, kind of do that kind of walk a mile in someone's shoes just to see, like the actual difference that's being made to someone's life, versus just treating it all as abstractions and top level metrics and dashboards, which are important, but they don't tell the whole story. And I think building out empathy from everyone, obviously from the product team, absolutely. But all the way down to the back end list of the back end list engineer,

23:13they should all care about the people that are ultimately consuming the thing and they should have a chance to find out. Yeah, absolutely great. So I think this is one of the major ways we think about whether what we did worked or not is, you know, the impact it actually makes on someone. But that brings to mind the idea of how success is measured in general for our products. And I know a lot of the organizations I've worked with all ask a basic question, what did you think success was going to look like before you did this? What were you hoping to do as a result of this? And a lot of times get blank stairs, right? Get people who kind of look back so, well, build it, right? That was what it was. The success was that we actually were able to do it. I wonder if you could talk a little bit about that, just kind of the misunderstanding, the disconnect that sometimes product organizations have around what we do and what we hope that actually drives as a result of success. Well, again, a lot of my experience, the vast majority of my experience is B2B

24:13and some B2B2C. So I can't speak for day-to-day life as a B2C product person that's sitting out there and every single decision and knob that you twist on the screen, somehow impacts directly the revenue that comes in or the acquisition numbers or whatever because most of the teams that I work with, almost all of the teams that I work with, have been for one of a better expression, kind of stuck behind sales teams and CS teams, account management teams, the more kind of commercial organizations they might be seen in those organizations because that's just the type of businesses that they are. They're selling to big companies, they're selling to enterprises, they're selling to banks, they're selling to insurance companies, they're selling to whoever they're selling to. So it is automatically in that situation that kind of a disconnect between what you're delivering and I don't know, like a six, nine-month sales cycle. Well, I was working with one company, it took like 12 months to sell the software or something. So whatever the product team delivered tomorrow, another sending revenue from that for 12 months, unless they're lucky enough to get maybe bunded it into a renewal or something like that

25:14which may or may not be the case. So that's a problem, right? Because you sit there and say, well, what's our metric on that? By the time we get to the point where maybe the deals got closed, we've moved on and we built some other stuff. So I can certainly see where that comes from. I don't think it's a good thing, but I can certainly understand where it comes from. I think it's also somewhat disappointing how many product teams don't really have any kind of understanding of how the product is priced or packaged or why people even buy it to some extent. Again, this is sometimes by design because the product teams are kind of kept back and they're not empowered and they're not kind of actually for what they're a better phrase in charge of their product. They're kind of just working as delivery people for the sales and commercial focused organizations. So they don't know what happens. I was a member chatting to someone recently. I was doing some training on, basically, on pricing and packaging and so acquisition and such. So more sort of the product marketing lens on product management and one of the people, one of the participants said to me, well, this is brilliant, but we've got an entire team that does that.

26:15We don't get anywhere near that. So, okay, fine. Well, that's again by design. Maybe you don't get to drive that all yourself, but at the very least you should have an understanding. You should be in the discussion. You should understand what they're doing, what inputs they need, how maybe you can make their lives easier. It's the same with the sales team as well and the marketing teams, like, yeah, sure. Maybe there are other teams that are kind of closer to the metal from the kind of the sales conversation, the revenue generating part of the company. But they can't generate revenue without you or if they can, then what are you building? So if you're in that sort of situation, well, how can you get close to them, understand the levers that they can pull, what you can do to maybe make those levers more vulnerable? Or as, you know, sometimes I say to people, look, if there's a six, nine month sales cycle, is there anything that you can do within the product to maybe help some bits of that sales cycle get shorter? You know, maybe there's a bit of the product that's really hard to demo, like maybe we could work a bit on that, kind of grease the wheels a bit, get stuff moving quicker. That helps them to then get involved in those discussions and start to have good discussions around the actual impact that they're having,

27:19which obviously in most companies, the ultimate impact they're once looking for is revenue, as much as we would like to talk about referral rates and MPS and all these other things. Yeah, they're brilliant and we should aim for those in the appropriate sort of situations, but ultimately everyone wants revenue. You can't get revenue, you might as well not build the thing. I think also in many cases, you'll find that the product teams, you know, or rather the product of building, the product team are building something which is just bundled into a generic package of stuff that gets sold to people. So they can't sit there and say, well, we put this new widget in and that's been directly, you know, that's directly contributed to X amount of millions or thousands of dollars because it's just part of the bundle. And again, that then just sort of speaks to this idea that they're so far away from the pricing packaging and commercial decisions. Maybe they don't know why people buy the product, maybe they don't know why people don't buy the product. They need to get toasted to the commercial teams to be involved in those discussions. Then they can start to extrapolate maybe more product focus metrics around usage or take up or you know,

28:21refer on and all of the things that we talk about more from a BTC lens. They can start to extrapolate those to what really happens and really matters to the company, which is that commercial revenue based outcome. Yeah, I agree. And the work I've done with product teams, I've seen this as being one of those most fundamental early shifts is that shift in understanding about what is value and what's not value and what really matters to the company. And you're right, there's a bottom line at, I mean, unless we're a nonprofit, right? I mean, if we're a nonprofit, then obviously we have a different baseline than profit. It's our mission and how much is advancing our mission. Yeah, you still need to pay the bills though, right? For the most part, you still need to pay the bills. Right, right. Yeah, I mean, it's not to say there's not a financial aspect of it, but our bottom line is a little different in that area. But still, I think you're right, it's sort of this starting point, right? Of saying, what is it we're trying to drive with this and really even just recognizing what that is. You know, if it is, like you said, net promoter score, we're trying to increase customer satisfaction.

29:21Great, is this thing going to increase customer satisfaction? If it does other things, great, but if we prioritize this in order to get a higher customer satisfaction score and it doesn't do that, you know, I'd argue it's not a success. You know, that's a failure because we still need something then to raise net promoter score, right? Yeah, I mean, and again, it's more about like, what does, for example, raising the NPS for your product do? Does it actually predict anything? You sit there and say, well, actually we believe, based on past performance, that raising NPS by whatever to or something like that, that somehow that will translate to overtime and X percent increase in retention rate, for example. Like if you can say that based on, you know, you can't say that, you can't predict the future, but you can sit there and say, well, based on past performance, we know that if this goes up, this goes up by this X amount of time later, or this goes down, this goes down X amount of time later. So you can start to at least have a basic understanding of the fact that, well, if we move up a metric that we can influence sooner,

30:25then that will potentially induce course providing nothing else changes, which of course it always good, that that will then have an impact on that, or at least will prevent any other downswing from going further down here, and maybe kind of helps to kind of hold the line, even if there's other market stuff going on, or other problems of the products, whatever. Again, we can't predict the future, but what can we extrapolate based on the past, based on the data that we hold, and of course not enough people will look at that data in the first place, but can we predict churn? Can we predict churn based on product markets? I worked at one place where we looked at it, and we could tell. We could tell when a client was about to churn. We could tell because their usage would go a certain direction, and it was very consistent. So you could start to try to impact why that usage will, first of all, you go and talk to them at that point, or, hey, we've noticed your usage, et cetera, et cetera, et cetera. But you can also look at the results of that, and say, well, actually, we need to improve this area, because actually people aren't getting, or they aren't seeing enough value, this then is actually predictive of churn.

31:26So let's try and think here. There's other stuff we could work on too, but if we want to kind of plug out the holes in the leaky bucket, this is something that we need to work on to do that. We either need to do that, or come up with some new blockbuster way to gain so many more customers that the churn doesn't matter anymore. And then we all know that it's easier to, or cheaper to keep a customer than it is to get a new one. So most people want to do that. So what can we predict in the future based on past happenings and extrapolations and correlations in the past, and then we can use some of that to try and work out what success looks like earlier than maybe it turns into revenue. Yeah. This is all such great stuff, and I'm on the tipping point here of like, we could go another hour just talking about this kind of stuff. But I think we'll be respectful of people's time and kind of short here. There's too many long podcasts out there. Right, right. But if people want to hear more about this topic, I'll just point it back to your podcast. By the way, I don't think I said this earlier, but Jason Knight, it's KNIGHT. It's like, you know, in a suit of armor.

32:28Yeah. His podcast again, One Night in Product, and we'll put a link in our show notes back to this so that everyone can find it. And find out more from you, Jason, and a little bit more about your work and what you do as well. So, can't thank you enough. Thanks for making the time and coming on. I really appreciate you sharing your wealth of knowledge with us. Thanks for having me. It's been a pleasure. Well, my heartfelt thanks to Jason for coming on. He's just a fascinating individual and has so much knowledge to share with us in the product area. Again, point you to his podcast called One Night in Product, that I think you'll enjoy if you're in the product area. He also has a very nice vlog that he will post to from time to time that has some really great articles. You can dig back through that. And again, we'll link to that in our show notes so you can find out more information about that. If you like this podcast and want to help us out at all, what we'd ask humbly is that you just tell a friend. Tell someone you know about it and point them in our direction. We love when you do that. Also, like and subscribe and whatever your podcasting platform of choice is

33:28in this new year as we start to buckle down and get things situated. How about doing that for the podcast here? Make sure that this is in your inbox and you'll never miss an episode. If you want to have any feedback with us and tell us what you think about this episode, or maybe you have a suggestion for a topic or a person, please email that to podcastedmountaingoatsoftware.com. I've gotten some people who are sending to the wrong address. I don't know why, but podcastedmountaingoatsoftware.com. That's where you send things to. If you're going to suggest a guest, one thing that I really appreciate is when you send that. If you happen to have any links and any clips of that person, that's really useful to be able to judge whether this person would be a good person for our podcast and whether that would be useful to people who listen to our show. But yeah, please send that on to us podcastedmountaingoatsoftware.com. We really covet your suggestions, your feedback of any kind for the show. And we'll end it there. We'll wrap it up. Hope everyone's having a great week and a great start to the year.

34:28We'll talk to you next time on another episode up. The Agile Mentor's Podcast.