Product Users

Since good product development is always focused on business value and therefore, end users, we follow the Product Vision with a clear breakdown of the different kinds of people who will use it.

The job of the Product Owner, and the likelihood of product success, relies heavily on the team and stakeholders having a clear vision of what they are building and why.  This is probably best encapsulated in describing who will be using the product.

The more iconic the users are, the more intrinsic the product’s functionalities and requirements will be to everyone, even without reading descriptions and requirements.

To start, systematically go through all your product’s functionalities.  Split them into …

• those that will be used by your customers, and
• those to be used by your own team, i.e., employees & contractors.

Front End Users (Customers)

Make a list of customer functionalities, and identify different kinds of users. 

• Content Creators
• Content Consumers
• Researchers

Back End Users

Identify different employees / team members you might have who would be accessing the backend for different purposes, based on their expertise and the jobs they are performing.  Also consider outside contractors.

Employees

Development Team

• find bugs
• fix bugs

Business analysts

• measure usage volume, frequency, etc.
• look for potential improvements

Third Party Personnel

Contractors or other professionals who are not your regular employees but who access the backend of the product to maintain or improve it.  Special consideration must be made to insure the security of your team and users while giving such personnel the ability to do their jobs.

• Consultants
• Technicians

Why establish user types?

A good product build is always focused on solving a problem for a specific group of real people, and every stage of a build prioritizes business value as much as possible. Epitomizing the users helps all team members maintain a clear understanding of who is to be served and the value they will derive from the product.

This avoids two tendencies:

Over-engineering: developers will naturally focus on building the best possible product from their own, technical perspective. And why wouldn’t they? A well-engineered product will be technically robust and easy to modify, update, or add onto. The problem is that making “the perfect product” will take too long, will cost too much, and may not match up with what potential clients would find (most) useful. The dev team’s enthusiasm for quality and excellence (from a technical perspective) must be constantly checked against the actual problem to be solved and by the end user’s standard.

Feature Creep: on the business side, some stakeholders (i.e., decision-makers) might tend to make “wish lists” based on their own idea of “the perfect product.” It is important to take into consideration what any user might find useful in a product, but ultimately, a successful product must focus primarily on the typical user. Trying to solve too many problems, or meet the demands of atypical, or fringe, users, can also detract from business value and lead to a product that is too expensive, or that is simply too complicated to market efficiently.

Go to …

Product Users in

MANDAROON

In the next section, we will turn these typical user types into more iconic examples, or personas.