(Customer) Life is a Collection of Experiences: Applied Existential Crises

This is part 3 of a 6 part series building a Growth mindset, for life and work

Is a data artifact nothing more than the result of a series of aggregate events that have happened to some blank slate? Or is there some dark matter holding it together — which provides nuance that would otherwise be lost? Could the act of experiencing life be dissected with the same questions?

When performing our nightly backups of production data on which to perform analysis and other arcane magics, we’ve run into complications that have caused us to consider the idea of partial updates. Our days-long deliberation boiled down to the simple questions stated above. In investing my heart into my craft, that also forced upon me the existential question of “are we defined by snapshots of life? Could I be constituted mostly of partial updates, and is there a changelog?”

A Painting is Brushstrokes

In both work and life, we become what we create, but we also impress ourselves on to what we make. This is especially apparent for the software products and services we craft — so much so, that this notion has been codified by Melvin Conway, into a law named in his honour. Is it possible then, that the design of our tools implies something about ourselves?

For example, a social platform might allow us to be more human by giving us the opportunity to feel real emotions — but it can be described solely by change logs, commits, and diffs, plus the design, thought and planning that never gets translated into the digital realm. However, what’s interesting, is that a customer’s experience while using that service can also be described by a series of actions, navigations and interactions — plus some nuance that never gets transmitted digitally.

Memories are Keyframes

In recent history, there has been a great interest in the neuroscience of how we capture memories, and we’ve come to understand that when we perceive time slowing down, what’s actually happening is that we record higher density memories. High density awareness is effectively a function of our brains filling in the past, using those dense memories as keyframes. As our brains have limited storage, naturally it would make sense that we’ve evolved to automatically prioritize a situation, and then record it to the appropriate density. Quite simply, we don’t need to record high density memories of the routine — that would be a colossal waste of resources. Instead, we naturally record higher density memories of the novel, ones that will frame all our future experiences.

I think this is why youth is so important. Having no routine yet, we are in a constant state of experiencing something new, and so build a corpus of high density memories — defining moments that we carry with us for the rest of our lives. As the saying goes, we don’t stop learning because we get old, we get old because we stop learning. Youth is a function of being immersed in novel experiences, breaking the routine, and building that collection of rich memories

Parallelism

We also see this reflected in the practice of software development. In the lifecycle of a well designed codebase, the nascent stages often start by building or referencing a foundation for subsequent code. The initial commits have more meaning, if such a thing can be quantified, because they represent material that future work will be built atop of. But as the codebase grows and ages, subsequent work will be less likely to add core foundational pieces which shape the character of the project. This is a function of technical debt, which can of course be mitigated by progressive refactoring. Unfortunately for the offline world however, we as people do not have that capability.

Much as how maintaining a healthy commit history is good practice for codebases, and much as how self-reflection is important for a healthy and well balanced life, the analogy can be extended to metric gathering. Instead of tracking the entire state of a customer’s behaviour within a system, we need to capture those “defining moments”, or “commits”. In fact, with the industry’s current focus on lightweight write-optimized collection services (ie, PubSub, Mixpanel, etc), this is anticipated! Instead of trying to understand the customer’s universe with one complete object, it is almost enough to rebuild the the universe from critical moments. The one missing ingredient here is nuance around the offline context in which those moments happen — a question with many answers in the field of customer research.

Minimal Viable Youth

Understanding that our analysis of events should occur asynchronously from the actual experiencing of events, we are now left with the question of what events to actually capture, and to what density. Fortunately, our analogy of humans and technology can be of service here. Ideally, we would want to capture everything, with immaculate recall — but we are constrained by processing power, storage capacity, and in the case of technology, time to implementation. Instead, we should focus on the “youth” of the customer lifecycle, as well as their defining moments with the product.

What this means, is that we should focus our measurement effort on the product flows where the customer is experiencing something for the first time. Not only will these events be present with high frequency towards the beginning of the critical path for any intent, but it will also occur naturally in the earlier stages of a customer conversion funnel. Instead of listing the gloriously endless number of actions a customer could perform, I will suggest a guiding question, that while different for every service, is useful. What can a customer do in their first 15 minutes on the platform, and what behaviours are indicative of their success?

Gathering quantitative information about someone’s first experiences is an excellent reference point from which to understand the mature stages of the customer’s lifecycle. However, as we know from life, nuance is lost when only looking at snapshots. So while we might be able to roughly infer customer intent from large datasets of well documented events, the only way to really understand the dark matter that ties those events together is to get out from behind the SQL, and talk to people.

We have always used stories to relate to others, and to relate to ourselves. For as long as we’ve been telling them, we know that stories told strictly as a series of events are not engaging, and stories told strictly with nuance are not useful. Captivating stories though, are comprised of a series of engaging events tied together with rich nuance. Such as it has always been in the offline world, and so too, it must be, in the online world.

Have any feedback? Want to discuss more? Are you building something out and looking for advice on how to get more traction? Hit me up at harrison@dahme.ca