User roles and the three Cs

- The product owner is the team's North Star. They're the light that represents the customer value. They may know a little bit about what it takes to deliver the project, but they won't create the kind of detailed technical specifications you need for a traditional project. Instead, the product owner will always speak the customer's language. The customer's language is much different from what you'd see in a traditional project. It focuses on the user's experience, and not what goes into creating that experience. The product owner will prioritize the work based on their view of the product. They don't view it as a technical achievement, the product owner will view it as a means to an end. The easiest way for a product owner to do this is to create user roles. A user role is not a person. Instead, think of it as a bundle of user experiences. For a website, there could be many user roles. There could be a user role called visitor. This is someone who lands on the site but isn't logged in. For a user who logs in, you could create another role called customer. You could then divide this into other roles, maybe creating roles called customer premium or customer standard. If you come from traditional project management, you might be tempted to confuse user roles with stakeholders. For stakeholders, you should think of them as a person. Maybe they're a customer stakeholder. Another stakeholder could be the sponsor for the site. Someone might enter the website as a visitor, then they'll register on the site and become a standard customer. Once they're a customer, they might decide to be a premium customer. So, in this case, you have one person who actually went through three distinct user roles. They had three different bundles of experiences based on what they were doing on the site. Usually, the product owner will create all the user roles for the project. It'll be a real challenge for the product owner to come up with these bundles. They have to really think through how someone will interact with the final product. They'll have to decide, what makes a visitor different from a customer? Do we want to divide up user roles by those who are premium from those who are standard customers? These are tough questions a product owner will have to sort out early. When creating these roles, it's sometimes easier to think about their context, character, and criteria. The context is the bundled experiences the person will have based on where they are in your product. In the website, the product owner will probably have separate premium customers from standard customers. The premium customer will have a different context, but probably expects some extra content. They probably won't expect the first page of the website to be a login and a password box. The character is a little bit of insight into the experience a role might expect when interacting with your product. A visitor might be more curious about who runs a website. A standard customer might be more curious about how to upgrade their account. Finally, the product owner might create new user roles based on the person's criteria. They can create a role based on someone's expected outcome. That premium customer might be more interested in the available services. For them, the criteria is getting something that a visitor wouldn't get. If you're starting up creating user roles, it's easier to start broadly and create subgroups of experiences within those larger roles. With the website, the product owner could start with the customers and then break down the roles into different subroles. Try to use the context, character, and criteria of the role to break down the bundle further.