User Classes and Product Champions

Key ideas#

From stakeholders to user classes#

Stakeholders include customers, customers include users, and users fall into user classes. One person can belong to several classes; an administrator also works as an ordinary user.

How to tell classes apart#

Wiegers and Beatty suggest eight dimensions: access privileges or security level, the business tasks people perform, the features they use, how often they use the product, their domain and computer experience, the platform they use, their native language, and whether they use the system directly or only receive its outputs.

Do not classify by industry or geography (“large banks”, “small banks”). That gives market segments. Classify by the work people do (teller, loan officer).

Favored, disfavored and other classes#

• Favored classes matter most to the business objectives. Their needs win conflicts, whoever pays or has political weight.
• Disfavored classes should not be able to use the system, for legal or security reasons. Requirements for them say “prevent”, not “satisfy”: lock an account after repeated failed logins, block automated scrapers.
• Other classes are served where possible.

Classes do not have to be people. Software agents, such as integrations or bots, form classes too, sometimes disfavored ones.

Expand, then contract#

Wiegers and Beatty recommend a technique from Ellen Gottesdiener: brainstorm as many candidate classes as possible, then merge similar ones. They suggest ending with no more than about 15 classes. Good places to look are the external entities on a context diagram and the organization chart: departments that take part in the process, are affected by it, or deal with outsiders. In the book’s example, a pharmaceutical company’s chart points not only to chemists but also to a health and safety department nobody had listed.

Personas#

A persona is a fictional but realistic description of a typical member of a class, built from real research. When you cannot reach real users, asking “What does Fred need most?” works better than asking about a faceless group.

The product champion, in Wiegers and Beatty’s sense#

A product champion is the most engaged representative of one user class who acts as the main link between that class and the business analyst. Ideally a real user, not a surrogate such as a manager or marketer imagining the user’s view. Look for a clear vision and enthusiasm, good communication, credibility in the organization, and domain knowledge. The champion needs authority to decide for the class; if managers routinely overrule them, the role loses its value.

Champions’ possible duties fall into five areas; agree which apply to each person:

• Planning: clarify scope and interfaces, assess impact on business operations, help plan the transition.
• Requirements: collect input from colleagues, write scenarios or stories, resolve conflicts within the class, prioritize, set quality targets, evaluate prototypes.
• Validation and verification: review requirements, define acceptance criteria, write or run acceptance tests, take part in beta testing.
• User aids: contribute to documentation and training, demonstrate the product to colleagues.
• Change management: evaluate change requests and help adjust future releases.

For a large or mixed class, one champion can gather a small backup team from different sub-groups. In the book’s example, the champion for roughly a thousand chemists worked with five chemists from different departments.

For commercial products without direct user access, the authors describe four options: invite representatives of major customers, hire a domain expert full time, hire former employees of customers, or send analysts to work at customer sites. In each case, check that the person’s view is current and typical.

They also cite Keil and Carmel: projects with more direct links between users and developers tend to do better, because every intermediary distorts the message. A skilled business analyst is the sensible exception.

Not the same as Leffingwell and Widrig’s product champion#

See The Product Champion Role for the second meaning.