
Mike Lyons breaks down the difference between customers (who pay) and users (who use the product), with examples from consumer apps to enterprise software. Teams need to satisfy the actual customer while considering other stakeholders like IT and finance.
Chapters
Sometimes it can be confusing in understanding who the customer is and who the user is. So I want to spend a minute just talking about this briefly. The Agile Manifesto principle that I want to sort of anchor to here is that first one. So remember this principle. Our highest priority is to satisfy the customer through early and continuous delivery of valuable safe software. Now note the word customer. To be clear, the customer is that person who is buying your product, buying your service, buying that thing of value. The value is in the eye of the customer, the person who's willing to pay for it. Sometimes the user of the product is the paying customer. This happens all the time. Think about, think about. Even right now, you've probably got an app on your phone, your device, whatever you're using that you paid for, you paid a buck 99 for that photo app. You are the customer because you paid for it and the user because you use it every day. Maybe you use one of those online storage solutions, you know, any one of the myriad of online cloud based storage solutions. If you pay for it, you're the customer, and if you use it, you're the user. Pretty simple, right? Think about this. What if you work in an enterprise, you work in an organization, and the organization has purchased for your use that same cloud based storage. You, the employee, you didn't, you didn't actually pay for it, but you use it all the time. So your enterprise, your organization is the customer, they paid for it. The person that, like the group that paid for it, they may not even use it. Maybe it's a software development tool and maybe the purchasing decision came from the organization to buy a software development tool that the developers use. So the developers are the users, the, the organization, the buying unit is the customer. So when we build products, we do need to do a little bit of deeper thinking about who the customer is and who the user is. So why is it important to consider that? Well, because as you're building products, as you're releasing value, depending on who you're target, it may change the dynamics and some of the thinking around what you're building. So think about this way. For example, if you're building a sort of, you know, plastic toy truck or something like that, that's the product you're building. And your target user is say a child, maybe ages 2 to 5. So this is for smaller children. Typically children are not going to have money to purchase this product, but they'll be the user of the product. So for them it's got to be shiny, it's got to roll really well. Maybe it's got a little motor. When you pull it back, it take, you know, maybe it lights up and makes sounds and things like that. So for the, for the user, those things are important. So that's the user, but not necessarily the customer, because the child's not going to pay for the product. The customer is maybe the parent. So the child's parent is going to be looking for different things. Maybe they don't want the sound, like they don't want this loud, obnoxious toy in the house. So the customer, the parent who's going to purchase this might be looking at something different, might be looking for, you know, no sharp edges or no small parts that the child could choke on. Maybe they don't want the loud siren or loud noises as well. And then there's the cost factor. Maybe they're not willing to pay more than $12.99 for this particular unit. Whereas the child, you know, the child doesn't have an idea of whether or not it's $12.99 or $24.99. They. They don't know that. So you've got to consider your customer, the person who's paying for the product or service, and the user. Sometimes they're not going to be the same person. And it gets even more complicated because as a development team, our highest priority is to satisfy the customer. Absolutely. But there's a myriad of other people to satisfy as well. There are stakeholders, those people who have an interest in this product being successful. It could be anyone throughout the organization. There are sponsors, those who are sponsoring the idea. There are. There are internal service providers. It gets even more complicated with technology because now we've got to work together across the IT landscape. There's IT operations that have to maybe support and run and maintain the infrastructure needed for our product to be released on. There's service desk within IT that we need to deal with. Outside of it, there's finance and accounting. We've got to satisfy them as potential stakeholders. And the list goes on and on. And this is part. It can be confusing. The important thing to remember is the relentless focus on the customer who is going to pay for this product and how are they going to use this product? They may not be the same person. We call it a customer centric view. We're relentlessly pursuing that customer. We want to satisfy them early and often.










