Use Cases in Product Management
Question: "I keep running into confusion about the 'use case' within the MRD. The problem is that my colleagues have an entirely different idea of a 'use case.' They use it as what I would describe as a design tool. They get into the details of step-by-step action-result, which looks to me like a workflow analysis developed by UI designers.For them, the term ‘use case' is deeply embedded in the design and in the solution space, not in product management and in the problem space. They cannot seem to break away from the thinking that a 'use case' defines how the system will respond to user actions.
Please provide clarifications that would distinguish the (true) product management perspective of a ‘use case' from the (pervasive) designer's understanding of a ‘use case'."
There is much confusion and misunderstanding about use cases because the "use case" concept is employed in both the solution and problem spaces in a variety of ways. The "use case" term is used in the product management, development and testing domains; and interpreted somewhat differently in various development tools and methodologies such as Unified Modeling Language (UML) and Agile. Complicating matters even further are entrenched and inconsistent variations to the "use case" title which result in a myriad of related expressions.
In principal, the concept of a "use case" has similar meaning to both product managers and product developers. The user-focused use case that is created by product management (problem space) is presented to development (solution space) where the developers use it as a basis and add the technical and design details to create a suite of use cases that will provide the development team with sufficient information to begin the design, development, and testing of the product and its features.
However, the methodologies and languages that are used by product management (problem space) to document user-focused use cases are commonly very different than the methodologies and languages that are used by development (solution space) to document product-focused use cases.
Consequently, there are many instances where the developers reformat the user-focused uses cases provided to them by product managers to the language used by development (such as UML) in order to create product-focused uses cases. Only then do the developers begin to add to the use case the technical and design specifics that are imperative to their work.
In Blackblot's Product Manager's Toolkit® (PMTK) methodology the matter of use cases in product management is handled very definitively as part of Blackblot's Procedural Requirements Management™ Model (PRM Model) methodology for creating high-quality, usable market requirements.
Use cases define events (specific instances of usage) and describe who (persona) does what (interaction) with the product and for what purpose (goal). The purpose of use cases is to describe how different personas put a solution to use and for which events. Use cases are useful to construe functional requirements and perform system structuring. Therefore, use cases influence the design of a feature or product but they are not design or technical specifications of that feature.
Here are key definitions and clarifications in PMTK that relate to use cases:
- Use Case – A specific way of using the system by performing some part of the functionality.
- The collected use cases specify all the existing ways of using the system.
- Each use case constitutes a complete course of action initiated by an actor, and it specifies the interaction that takes place between an actor and the system.
- Uses cases focus on single instances of use. Combining several use cases forms a "Scenario". A scenario is a succession of uses cases and is sometimes presented using a "Storyboard" (visual representation of the sequence of events).
- In several published books covering the topic of use cases; the "Persona" may be referred to as the "Actor", and the "Product" may be referred to as the "System". These terms are and can be used alternately.
The second PMTK foundation rule states that ‘Product management resides solely in the problem space'. Does this mean that use cases, which deal with the solution, are part of the solution space and therefore not the responsibility of product management? The answer is a conditional "no".
Use cases are meant to help the developers design and build features via better understanding of product/user interaction. Corroborating this thought is the notion in UML that "a use case represents a functional requirement, showing what happens, but not how it is achieved by the system.". This means that use cases are truly about the user's interaction with the product and the user's goals from using the product; and therefore they are predominantly a part of the problem space.
According to PMTK there are three scenarios for writing use cases:
- The Market Requirements Document (MRD) exists but there is no product concept and no Product Requirements Document (PRD). In this scenario no use cases are written by anyone.
- The Market Requirements Document (MRD) exists and there is a general product concept, but no Product Requirements Document (PRD) exists so actual features are not documented. In this scenario the owner/writer of the Use Cases document is the product planner who may prepare (with the product architect as a contributor) high-level and descriptive use cases which describe how possible future features in the product would be possibly employed by different personas. These descriptive uses cases are included with the Market Requirements Document (MRD) document.
- The Market Requirements Document (MRD) and the Product Requirements Document (PRD) exist, and consequently there is a definitive product concept and documented actual features. In this scenario the owner/writer of the Use Cases document is the product architect who prepares (with the product planner as a contributor) detailed use cases which describe how actual features in the product would be employed by different personas. These detailed use cases are included with the Product Requirements Document (PRD) document.
The structure and nuances of writing use cases in product management (not development) are described in the "PMTK Use Cases" template that is part of the Blackblot Product Manager's Toolkit® (PMTK). In addition, the topic of uses cases in product management is explained in length in the Blackblot "Crafting Market Requirements" chapter in the Blackblot PMTK Book.