Many product teams are busy, but not necessarily effective. Brian Milner talks with product consultant Jason Knight about why so many organizations struggle with prioritization, customer insight, and measuring success—and what it takes to build a product organization that actually delivers value.

Overview

What does it really mean to transform a product organization? Brian Milner sits down with product consultant and One Knight in Product host Jason Knight to explore the gap between how product management is described in books and how it actually works inside most companies.

They discuss the reality many teams face: massive backlogs full of competing priorities, pressure from stakeholders, and organizations that say they are customer-focused but rarely talk to customers. Jason shares practical perspectives on prioritization, strategy, and why good product teams must learn to say no—even to good ideas.

The conversation also dives into customer discovery, the barriers that keep teams from speaking directly with users, and how organizations should think about measuring success beyond simply “building the feature.” If your organization is trying to move beyond feature factories and build a stronger product practice, this episode offers a grounded look at where to start.

References and resources mentioned in the show:

Jason Knight
One Knight in Product Podcast
Blog: What Does a Product Owner Do, When, and Why?
Blog: How to Ensure You’re Working on the Most Important Items Each Iteration by Mike Cohn
#124: How to Avoid Common Product Team Pitfalls with David Pereira
#154: The Underpowered PO with Barnaby Golden
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Jason Knight is a product consultant, coach, and host of the One Knight in Product podcast who helps scaling B2B companies move beyond feature factories and build product teams that deliver real business impact. He works with organizations to connect strategy to execution through fractional product leadership, workshops, and coaching that bring clarity, alignment, and measurable results.

Auto-generated Transcript:

Brian Milner (00:00) Welcome in Agile Mentors. We're back. We're here for another episode of the Agile Mentors podcast. I'm here as always Brian Milner, but today I have a very special guest with us. have Mr. Jason Knight with us. Welcome in Jason.

Jason (00:13) Hi, thanks very much for having me. It's a pleasure to be here and looking forward to chat.

Brian Milner (00:16) 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 and London. And he basically, you know, focuses on the B2B products area and helps organizations to...

kind of revamp their product practices and refocus around how to get some discipline to their product area. So 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 podcasts are really all around this topic. And with the kind of renewed focus, I think, in the product area and this AI world, I thought it would be great to have Jason on to talk about this.

a post that we'll link to in our show notes that was really on how to transform the product organization. And I wanted to kind of dive in there a little bit with you, Jason. First of all, what does that mean to transform your product organization? What does that look like?

Jason (01:13) Thank you.

Well, that's a really good question, right? And if you think about some of the things that, example, all these books behind me, I just did a talk in Lisbon at a conference about product management, not being like the books, which is, you know, always a popular topic because, you know, so many people are out there looking at these books and blog posts and articles and podcasts and everything else that we're doing. And they're like, well, that all sounds great, but dot dot dot. And there's like something that's not like that in the context, like their business doesn't work like that. Their leadership team doesn't work like that.

They're allowed to do that sort of thing or they're kind of held back from doing certain things. And then there's this kind of almost wonderful idea of like, well, if we just, you know, if we just dot dot dot, like if we just did this, this, this, this, this, and this, then we'd be a quote unquote proper product company or to go back to Ben Horowitz would be proper or good product managers rather than bad product managers or working for a feature factory or whatever. Now,

I'm going to say, go on a limb here and say there are lots of companies, probably more companies that are not operating like that than are operating like that. There are lots of great examples of companies that do work like that. And obviously look at some of the books that, for example, Marty Kagan and transformed as the case studies are big and small companies. There's obviously 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 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 organization or products that the organization is building fulfill or address all of the different viability, usability, all of the risks, all the kind of the classic cliches that we start to trot out. Ultimately, I like to think about it I'm going to steal this thing.

this kind of almost this quote from Nick Metta, who until recently was the CEO of GameSight. When I interviewed him on my podcast, I was asking him the question, like, what is the point of what is the job of customer success? Surely we should all care about customer success. Because that's obviously his bag. And, 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 to the last thing at night, or at least whatever that is in the context of business. So like day to 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 well 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

But whether the marketing materials are good or whether the users are happy, you've got someone that cares about all of that in the context of that product and then 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. Now 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, but.

You know, at the same time, it's not just about having a product management function and just sort of a box and saying that 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's part of what makes up product.

Brian Milner (04:42) Yeah. Yeah. No, that's great. I love that. you know, it's kind of a struggle, right, for a lot of these companies because the, I mean, it feels like there's so much for us to do that a lot of these organizations I've talked to just have this enormous backlog of stuff that they just think,

Jason (04:52) I'm go

Brian Milner (05:05) 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 gonna make an impact?

Jason (05:08) You

It's an incredibly, incredibly common and let me say provocatively naive kind of idea that somehow like, it's something that new product people will see as they go into an organization. They'll see exactly what you've just described, a 200, 300 long item, long backlog of different types of thing of different size. And obviously you could use some of your organization's work and Mike's work around, you know, sort of estimations and agile.

kind of 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 get all 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. Now you sit there and say, okay, well, that's great. But someone said must for at least

Yeah, each of those things someone has said must so one of these 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 sheds or which have way around and you're just sitting there and you're 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 with you know, a new front-end rewrite over such-and-such or mobile app or something like this. This 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 is so different to each other that it's not even possible to actually even if you do score them, it's not possible to almost trade one off against the other. You're sitting there saying, well, how can I, how can I balance that against that? Or what you end up being in a situation. If you're all kind of driven down a path of having worked on too many things, you end up almost having to do like, you can't say no to any other things. You can't say no because there's no

kind of decision guardrails or anything, 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, 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 we 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. Like, how do you make that decision? Now the book answer would be, well, you need a strategy and a vision and a strategy. I have a three to five year vision.

10 year, 20 year vision. Let's have a strategy for the next one year or so based on the best evidence that we have now. Let's make, we're to make some decisions. We're going to say, we're going to do this and we're not going to do this. know, strategies should be consistent and they should be focused and they should be evidence-based and they should be action oriented, et cetera. So you sit and say, okay, well, we're going to work on whatever. We're going to work on going into the U S with our app or whatever. Cause 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. It was a great idea. I've never seen it happen in an actual organization, but you can get away with it and then give it a go. like, this this naive idea that somehow all of those things on the backlog are ever going to get done. Some of them will, but not all of them. And it doesn't matter how many times you re-prioritize it and re-sort it. They're not all getting done. It's just going get longer. You look at a backlog, it's got stuff on it five years old.

Brian Milner (08:40) Right.

Jason (08:40) None of it's

getting done. It's just sitting there as baggage. Doesn't mean it's not a good idea. And I think actually one of the good things about product or kind of a well functioning product organization is that it's okay to say no to good ideas. The, yeah, 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 just getting kind of dragged into every single new idea. Everything being put onto a backlog, everything having this expectation eventually at one point, it's 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.

Brian Milner (09:13) Yeah, yeah, I agree. mean, otherwise, like you said, there's no focus and you just sort of scatter shot all over the place. But this is kind of one of those points, I think, for product organizations where, like we say, sometimes where the rubber meets the road, right? It's sort of like, you got all your stakeholders that all are vying for attention.

Jason (09:28) Hehehehe

Brian Milner (09:36) 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, know, impact for the customer and what difference are you making for the customer as sort of being the thing that tips the scales. You know, when you start to align 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.

Jason (10:12) 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, B2B 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, you know, some of these teams are frankly forced to use tools that the, you know, ivory tower, city hall people, you know, buy in 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 satisfy. 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 certain parts of Europe, Latin languages, for example, it's the same word. 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, because for me, a customer is someone who buys something that you have made.

whatever that is in our kind of case, it's like a SAS 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 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 a hundred percent across the board. Like there are people that just default to one way of saying it or others. And like I say, 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 kind of 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 for the better, for the, you to meet the best needs or to meet the needs of all of our customers.

all of the people that could potentially currently and in the future by our stuff, not how can we satisfy that one individual customer over there? So like when you say your customer focused, then you go out to, for example, a customer success operative, 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. It doesn't necessarily mean that they care. know, care is maybe 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 told to look after. In which case, being customer focused starts to feel a bit woolly because 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 or 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 solve the needs of a market and capture a market versus individual customers one at a time. That's a very big mindset shift.

Brian Milner (13:06) Yeah, and the whole, now we're back to prioritization, right? I 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. And so that brings to mind a kind of an important area as well. And 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 out there around sort of

Jason (13:10) You

Brian Milner (13:34) trying to envision what our customers' are. But I'd like to talk a little bit more about how we actually connect and actually talk to real customers.

Jason (13:44) Well, the obvious answer to that is just go and talk to them. But that is something that's not always as straightforward as it sounds. Now in some organizations, there will be specific barriers put between product teams and customers, know, be though, be they the sort of the sales team or the customer support and the customer success teams, people, maybe executives, if they're really large customers, and they'll be like, well, you can't go and speak to those people. And you know, I've actually had this said to me before, you can't speak to these people product team.

because you're not 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. This 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, which is actually going out and finding out what are 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 unmet needs that we are or any potential threats or whatever? So, you know, as product people, and I include designers, obviously within the area, as well as engineers, we should all be interested in 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.

ride-alongs with the sales team. It's not quite as good as doing it yourself in a proper sort of, you know, kind of unguarded setting with people that don't think that you're trying to sell to them, but it's better than not doing it at all. How can we, how can we find any ways to get in here? Can we do customer panels? Can we do like quarterly things where they come in and we kind of present some stuff and get to ask them some questions and bond with them? What kind of secondary data can we use? know, can we, whilst we're all aware that, for example, sales teams are going to be asking very sales focused questions.

Can we get access to those recordings and kind of mine those for information? Can we mind the quarterly business reviews that the customer 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 this space? Can we look at market research, industry reports? Now, none of those are as good for most kind of 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. know, let's just use AI to generate sort of 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's going to 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 an additional source of input. So what can we do to get as many sources of input as possible? What can we do?

Brian Milner (16:13) Yeah.

Jason (16:32) to build credibility with customer facing teams, for example, sales or again, account management, et cetera, to 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, but what they're going to want. Yeah. What the future's going to hold, how we could potentially get ahead of their requirements, demands, know, jobs to be done, et cetera.

What can we do to make sure that the sales team, the account management team's lives 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. So it's about trying to almost win permission for that by going and getting some sort of small customer interactions to start with. Try and build credibility with your kind of customer facing teams. Start to maybe show some examples of some early wins. Yeah. But that team went along and they did some things. They showed a thing or they found out something. They came back. They turned that into whatever they turned it into. And now that customer's happier or that

type of customer ideally is happier and then start to demonstrate those kind of incremental gains. And ideally then get to a point where you can start doing a kind of Teresa 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.

Brian Milner (18:16) Yeah, it's fascinating to me. It seems like we throw up a number of barriers to actually talking to real people. You mentioned the AI simulation of a customer and I'm with you on that. think that the verdict's out, at best, I think you can look at it like a mock-up. It's a mock-up of that conversation. It's not the real conversation.

And I'm surprised at the number of times I've worked with different product people. And when I asked just the basic question, have you, have you done a customer interview? Have you actually, you know, talked to a real person and ask them questions about it? Well, no, we haven't done that. We've mocked it up. We've, created personas we've, but, but no, we haven't actually in any way touched base with a real actual live human being. And to me, it seems like that's gotta be a foundational.

Jason (18:46) You

Brian Milner (19:03) aspect of it is that we, you cause people are complex, you know, 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, you know?

Jason (19:21) 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, where is that information coming from? So yeah, we, 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. Like, like that's part of the loop. And that's something that I profoundly believe in. And even, you know, 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 like there are, there is this kind of cliche where engineers don't want to go and do that kind of thing. They just want to go and code stuff and some do, but not all do. And even the most sort flint hearted from the outside sort of engineer that I've seen that's kind of, even if they've not gotten 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 where it's really easy for people to lose sight and track of the real lives of the people that 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 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 all those abstractions and top level metrics and dashboards, which are important, but they don't tell the whole story. I think building that empathy from everyone, obviously from the product team, absolutely, but all the way down to the backend list of the backend list engineer, they should all care about the people that are ultimately consuming the thing and they should have a chance to find out.

Brian Milner (21:07) Absolutely agree. One of the other things that, so I think this is one of the major ways we think about whether what we did worked or not is the impact it actually makes on someone. But that brings to mind kind of the idea of how success is measured in general for our products. And I know a lot of the organizations I've worked with, I'll 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 I often, a lot of times get blank stares, right? Get people who kind of look back and say, well, build it, right? That was what it was. The success was that we actually were able to do it. And 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.

Jason (22:04) Well, again, lot of my experience, the vast majority of my experience is B2B and 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 I work with have been, for want of a better expression, kind of stuck behind sales teams and CS teams, account management teams.

the more kind of commercial organization as they might be seen in those organizations, because that's just the type of businesses that they are. selling to big companies, they're selling to enterprises, they're selling to banks, they're selling to insurance companies, they're selling to whomever they're selling to. So there is automatically in that situation, it's kind of a disconnect between what you're delivering and I don't know, like a six, nine month sales cycle. Like I was working with one company, it took like 12 months to sell the software or something. So whatever the product team delivered tomorrow,

They're not going see any revenue from that for 12 months, unless they're lucky enough to get, maybe bundled it into a renewal or something like that, which 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 deal's got closed, we've moved on and we've got 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 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. Like, 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 want of 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 remember chatting to someone recently, I was doing some

training on basically on pricing and packaging and acquisition and such. Some more 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. We 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 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 team's 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. So if, 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 pullable? Or as you sometimes I'll say to people, look.

If there's a six, nine months 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 to 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, which obviously in most companies, the ultimate impact that everyone's looking for is revenue. As much as we all like to talk about referral rates and

NPS and all these other things that yeah, they're brilliant and we wish we should aim for those in the appropriate sort of situations. But ultimately everyone wants revenue. We can't get revenue. We 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 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 of 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 closer 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, referral and all of the things that we talk about more from a B to C lens.

can start to extrapolate those to what really happens and really matters to the company, which is that commercial revenue based outcome.

Brian Milner (26:26) Yeah, yeah, I agree. And I think I've, you know, in the work I've done with product teams, I've seen this as being one of those most fundamental early shifts is kind of that, that, that shift in understanding about what is value and what's not value and, 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 about our mission and how much is it advancing our mission. Right. Right. Right. I mean, it's not to say there's not a financial aspect of it, our bottom line is a little different in that area. But still, I think you're right. It's sort of this starting point of saying, what is it we're trying to drive with this and

Jason (26:55) You still need to pay the bills though, right? For the most part. You still need to be to pay the bills.

Brian Milner (27:13) And really even just recognizing what that is. If it is, like you said, net promoter score, we're trying to increase customer satisfaction. Great. 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, I'd argue it's not a success. That's a failure because we still need something then to raise net promoter score.

Jason (27:41) 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, two or something like that, that somehow that will translate to over time, an X percent increase in retention rate, for example. If you can say that based on, you can't say that

Brian Milner (27:56) Yeah.

Jason (28:06) 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 if 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, if we move up a metric that we can influence sooner, then that will potentially, in due 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 downswings from

going even further down, maybe kind of help to kind of hold the line, even if there's other kind of market stuff going on or other problems with the product or whatever. can we do? Well, 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...

client, but 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, well, first of all, you go and talk to them at that point, or, we've noticed a 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. So let's try and figure out, there's other stuff we could work on too, but if we want to kind of, you

plug up the holes in a 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. But you know, 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 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.

Brian Milner (30:04) Yeah. Yeah. This is all such great stuff. and, I'm, I'm like on the, on the tipping point here of like, could go another hour, just, just talking about this kind of stuff. but I, I, I think we'll re be respectful of people's time and kind of cut it short here. ⁓ right, right.

Jason (30:19) There's too many long podcasts out there.

Brian Milner (30:23) 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 K and I, G H T. It's like, you know, in a suit of armor ⁓ Knight. But yeah, so 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.

Jason (30:35) Yeah

Brian Milner (30:48) Can't thank you enough. Thanks for making the time and coming on. I really appreciate you sharing your wealth of knowledge with us.

Jason (30:54) Thanks for having me, it's been pleasure.