In addition to encouraging our team to think of support as field research, we also encourage everyone to extract patterns from every support thread they handle. At the time of the Device Metrics update, the process wasn’t as formalized as it is now, but, nevertheless, the team had an internal discussion around the underlying causes of the user’s issue, and provided a product update that would help prevent similar problems in the future. These days, we’re working towards making sure that all support threads have patterns extracted and attached in Jellyfish.

Our insistence on pattern creation helps us get the most out of every support thread and ensures that we organize incoming signal in a coherent and scalable way. Our ProductOS spec, an internal document outlining our goals for the ProductOS Loop, summarizes our thinking: “For instance, if there is an incident that users experience as a particular error message, (recent example: unable to create a new application) we may hear about it from support, DevOps, customer success and more. It is important for a pattern to be created so that all channels can discover it, share context, and have a coherent response, rather than each agent doing their own investigation and responding with a different answer to each occurrence.”

Becoming proficient at identifying patterns can take some practice. At a high level, a pattern can be simply described as a pattern of behavior. We may have lots and lots of bits of feedback scattered across many channels that all correspond to a single pattern based on their similarities. We often say that patterns are the first attempt at sense-making; the first time we step back and ask ourselves “Ok, what is going on here?”. It’s important to note that patterns are not an attempt to come up with a solution, they’re just an attempt to accurately identify the problem. We often frame patterns as “problem statements”, whereas the more concrete ideas and improvements that come in farther along the loop are “solution statements”.