Prioritizing phenomena for discovery
Avoiding myopic prioritization
At this point, we're making the assumption that you have started to tend to a repository of observed phenomena inside of your organization. As a vital next step, you'll need to decide how you will go about prioritizing which phenomenon that you will decide to learn about. It's important that you think about this process differently than you would think about prioritizing a product initiative or feature. When prioritizing phenomena, it's important to remember that you without intentional bias, there's quite a bit of unknown outcomes. You don't really know what discovering the causation of a phenomenon will have on your business— where with a backlog of features you most likely have already done the work of demonstrating or measuring the impact they will have. In this circumstance, you're determining what _might_ have the largest impact for something that _could_ be learned. I would encourage you to not look myopically at each phenomenon, but change your perspective to think about the enabling and downstream capabilities of learning about a specific phenomenon.
If we compare the two contexts: when prioritizing features you're primarily focused on the isolated value that a particular feature has in comparison to the other features you want to build, where when prioritizing phenomena you're thinking about correlative network-like effects that your learnings could have on other initiatives, phenomena, and features.
As you're thinking about these enabling and downstream effects, it helps to have some guiding variables to think through. Here's what we suggest:
Consider what implicated costs or lost value is occurring in the business because of what has been observed. Are there elements of what has been observed that is noticeably reducing the company's ability to retain customers? Are there inefficiencies occurring that could reduce operational costs? Is there something that is preventing the intended value from being created?
What are the efforts currently impeded by your lack of understanding of this phenomenon more deeply? Is there a sequence of impactful efforts that would be opened up for discovery or implementation if you understood more about this?
How many other features, initiatives, and phenomena would your learnings touch? How many customers could this effect?
How quickly could you respond to what you learn? How quickly can you dedicate resources to really understand the causation of this phenomenon? How quickly could you experiment and implement solutions?
Narrowing down your options
It's important to remember what the purpose is behind evaluating these variables. These factors are designed to subvert natural tendencies to approach phenomena like features and to help narrow down which phenomenon your organization should investigate. You'll notice that each variable doesn't naturally build up to one clear conclusion. Oftentimes, one or more of these variables will contradict each other. This isn't anything to be concerned about. These contradictions should spur dialogue around what's most important for your team and organization as a whole.
Once you've established the phenomenon you'll investigate next, you'll need to properly scope and frame your plan for discovery. We'll be diving into how to think work through this in our next fieldguide. Until next time, let us know your experiences with phenomena so far.