Product Management Scenario

A Simple Product Management Scenario

How a basic real-world scenario can be helpful in illustrating the key points of product management

For several years now, I have been trying to determine the best ways in which to describe and teach the core functions of product management to my peers and junior team members. Usually this involves some long-winded monologues, white boarding sessions, and cobbling together of book themes and my own personal experiences. Needless to say, this process was unorganized and inconsistent. However, I have recently realized that a very basic real-world scenario can be helpful in illustrating the key points of product management.

Enter my own personal scenario: the traffic intersection. From a product management perspective, an intersection represents all of the fundamental aspects of the job in a variety of ways. Everything from thinking about the target customer(s), devising relevant use cases, identifying possible solutions, and evaluating the cost-value trade-offs can be covered using this sort of example. We also undertook practice in creating mock-ups, writing user stories, and outlining a project plan as part of our exercise. And since this real-world scenario is familiar to a large portion of adults, it is easily accessible and understandable.

So how does the scenario work? I recently set this problem up for a junior product manager to help reinforce some of the product management skills I felt were most relevant to the job. I started by providing the problem: two roads intersect one another and there is currently no system managing the traffic. I then opened it up to questions about the situation. Here are some of the questions that were asked, along with the guidance I provided:

• How many lanes does each road have? Two lanes in each direction
• Are there any tolls for the roads? No tolls for the roads
• What is the speed limit of each road? 45mph for both

Again, since there is typically a familiarity with the scenario, it was easy to describe and define some basic parameters of the intersection. With this framework in place, we proceeded into a series of tasks that I devised in order to emphasize the product management process. Keep in mind that this scenario is meant to be a collaborative process between or among product managers.

Task: Defining the User(s)

The first step in this scenario was to define the users. I specifically asked my colleague to provide me with a list of possible users. We came up with several, from which I narrowed the scope:

• Motorists (the identified user)
• Pedestrians
• Cyclists

For your own application, you can allow the user(s) to be defined as broadly or narrowly as you would like. I found that in the interest of time, keeping the target users limited to just motorists made the problem easier to think about.

Task: Devising Use Cases

Once we established the target user type, I asked for a list of use cases for the intersection. Specifically, what do motorists need to be able to do in order to interact with and get value from the intersection. My colleague came up with a solid list, including some use cases I hadn’t even imagined, but we narrowed them to these three:

• As a motorist, I want to navigate quickly through the intersection
• As a motorist, I want to navigate safely through the intersection
• As a motorist, I want to be able to change directions in the intersection

There are certainly other use cases out there, but we chose to limit our evaluation to only these use cases as an initial step.

Task: Possible Solutions

The next action for my colleague was to identify possible solutions to the intersection problem. We undertook this effort by thinking about the target user and the aforementioned use cases that the user has. Given our knowledge of intersections, we came up with a list of possible intersection solutions:

• 2-way stop sign
• 4-way stop sign
• Traffic lights
• Traffic circle
• Flyover / clover

We also noted that there were other options for the intersection (such as a traffic cop), but opted not to evaluate those possible solutions as viable for this particular scenario.

Task: Evaluate Cost-Value Trade-Offs

With our use cases identified, we set out to evaluate the cost and value of each of the potential solutions. Given the lack of empirical evidence for this hypothetical scenario, we came up with a scoring (on a scale of 0 to 10) for the costs associated with each intersection. We then calculated the value (on a scale of 0 to 10) of each intersection against the use cases. The tables below depict what we came up with:

Based on our scoring of the perceived value and the assumed costs for each of the possible solutions against the use cases, we used simple math to determine the cost-value benefit added by each intersection, which yielded the following results (with the caveat that in a real-world scenario, we would need to validate our assumptions first):

Conclusions and Next Steps

Based on our scenario, we evaluated four use cases and five potential solutions based on our target user, a motorist. Given the parameters of the intersection, we came to the conclusion that although likely more expensive and a longer time to implement, a flyover/clover would be the best alternative for this particular example. Whether or not that was the desired result is irrelevant; in this case, the process was most important. Therefore, being able to justify this decision using our assumptions was the only requirement for making the hypothetical decision.

As a follow up to this, I had my colleague draw a mock-up of the intersection. I also used this illustration as an example to ask some questions about how he would design the project. We listed out some ideas around what information might be needed for implementing a flyover/clover into the intersection, which included surrounding real estate, construction costs, time to implement, and continuity of intersection navigation during construction.

In the future, a scenario such as this can be elaborated on, by adding new dimensions of traffic lanes, different user types, and construction, cost, or time constraints. However, the core scenario holds up against some of the basic product management principles. In order to reinforce these competencies, moving through this scenario can help a product manager remember to ask lots of questions, list their assumptions, and think through a problem with (quite literally) many moving pieces.

Let’s continue the conversation on Twitter or in the comments. For more on product management, follow Trust the Product on Medium.