We often talk about our “customer”, they’re at the center of everything we do. But we rarely talk about who our “customer” may actually be. Often, we just assume that our customer is the user of our product…but what if they’re not? It may seem strange to imagine a case where our customer and our user are not the same person, but it happens more often than you may think. But if our customers are not the users of our product then we need to think about who is…and how can we design a product that appeals to them, too.

For example, imagine that we create educational apps for kids. We write these apps to appeal to kids, and we want them to be fun.

Kids are our Users.

So, to appeal to our users we craft colorful environments filled with enticing audio cues and addictive rewards systems. And, as a result, kids love our apps.

But, kids aren’t paying for our apps…their parents are. So, we also need to appeal to the parents. In this scenario, the parents are our Choosers. This means that the app needs to provide more value beyond simply being “fun”. Perhaps it needs to provide educational value, or it simply needs to occupy the kids on a long car ride. Whatever the reason, it ultimately needs to serve the needs of the parents who will actually be the ones to spring for it.

But we can’t forget the kids, if they don’t enjoy the app then they’ll stop playing with it. And if they stop playing with it then they won’t be occupied on long car rides and their parents won’t buy apps from us again.

See what we did there? We’ve created a cycle. Whether it turns out to be virtuous or vicious is up to us.

Enough of This Consumer Nonsense

I know what you’re thinking. Sure, that example is all well and good for consumer apps…but I build business products. I build products for the enterprise…I don’t have to worry about this nonsense. But what if I told you that your Choosers versus Users dilemma is even more pronounced.

Imagine that you’re building a CRM app for the real estate industry. You’ll want the the product to appeal to real estate agents so you’ll want it to be easy to use, lightweight, and provide useful information such as contact info and recent conversations that agents can draw on when interacting with prospective buyers and sellers.
In fact, we could even customize it to their industry to allow agents to quickly access additional information such as each prospect’s desired home type and school district.

It should be everything they could ever want. After all, they are our Users.

However, there’s just one problem. The agents aren’t paying for the product, the brokers who own the brokerages they work for are. And as much as the broker would probably like to make their agents happy, they’re not likely to spring for the cost of a custom CRM system just to put a smile on their faces. So we also need to appeal to them….perhaps even more so. They are our Choosers.

To make the system worthwhile to our Choosers, we’ll need to provide features that meet their unique needs. Many of these will likely stem from their agents’ ability to bring in new business and close sales, but may also include things like understanding the types of properties their agents are transacting (and what types are likely to transact successfully), the number of times their agents are reaching out to prospects, and who the most productive agents are.

So our product needs to include features such as reporting on listing trends, providing insights into communication trends between agents and prospects, and ranking agent profitability.

And, we need to do all of this without sacrificing the agent’s usr experience.

Although our Choosers (brokers) are paying for the product, they’ll derive no value from it unless our Users (agents) find enough value in it for themselves to continue to using it. For example, brokers will find a lot of value in understanding the number of times that an agent reaches out to a prospect, and how that number correlates to the the likelihood of closing a listing. But, an agent won’t log those interactions into the system without getting some value out of that action themselves. This means that in addition to the broker facing feature of correlating interactions to listings, we also need to design an additional agent facing feature that incentivizes them to log their interactions in the first place, such as letting an agent know when it’s been more than two weeks since they reached out to a prospect. Otherwise, agents won’t log their interactions and brokers won’t have anything to report on. And if our Users don’t find enough value to keep using our product, then our Choosers won’t find enough value to continue to pay for it.

So What Do We Do About It?

So, what do we do about this? First need to understand who are Choosers and Users are, and whether or not they’re the same person. Next, we need to determine the incentives for each group to use our product. What do our Users hope to get from our product and what do our Choosers hope to get from it? And finally, we need to understand how the incentives for the Users will create value for the Choosers…or if gaps exist where they don’t. For example, what element of value do Choosers wish to derive that Users are not incentivized to provide? Once we understand where these gaps exist then we can design features and flows to help create the value expected by both.

By keeping this in mind, we can ensure that we create not only a product that our Users will love, but also a product that our Choosers will pay for. And then, everyone will be happy.

This post was originally published on the Front Row Agile blog.

You already know that roles are crucial to any User Story since they help us put context around who a given feature is for.  However, did you know that you can also put context around your roles?  Using a technique called Personas we can create rich backstories for our users to help us better understand not only their role, but also their goals for using the product.

Creating Personas

In my latest Pluralsight course, Creating Effective User Stories, I cover how to create these Personas using the excellent template created by Roman Pichler.  You can see an excerpt from the Personas portion of the course below as well as download Roman's template here.

Personas are an excellent way to better flesh out your team's image of the actual users who will be interacting with the product.  Not only do they help us better understand how a user will interact with the features of our product but, more importantly, they help us understand their motivations for doing so.

And, by better understanding both our users' motivations and backgrounds we can better build products that makes sense for them.

Want to learn even more ways to slice your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.