How do tools evolve? Often, change happens with the observation that existing tools are no longer right for the job-to-be-done. The tools are “stressed”, and to the user, the process is constrained and tedious. Sometimes the user believes this to be normal pain - that is, “this is how things are done”. But, as this feature gap persists, chronic pain converts to acute pain, and often those who experience this deeply drive the change in the toolklit to serve the new need to unlock a lower friction, superior behavior.
Take the evolution of version control systems as an example. Versioning has been with us since we started writing. In software engineering, as both code bases and engineering teams grew in size, the tooling evolved from simple linear revision history to file-locking mechanisms to centralized check-in/check-out workflows to finally distributed systems with sophisticated branching and merging workflows.
Git is now the gold standard for code version control, and in other domains like docs and design, there are even newer ideas that facilitate multi-user collaboration. Use cases grow and mutate to stress existing tools, and the emerging pain points drive fundamental changes to the underlying tools. And this cycle of product innovation repeats.
In the data domain, one such legacy construct is the ubiquitous “report” or “dashboard” powered by reporting tools. In a prior world where data collection was scarce, and only a few metrics were even trackable or considered important, creating a hand-crafted report that represented these select metrics was sufficient.
But, as we rapidly digitize and track the entire connected system of business operations from sales to marketing to product to finance and more, and increasingly want to operate on all this data, we start to feel the pain of using reports and associated reporting tools. We end up with hundreds of reports and datasets tracking various metrics across the org built at various points in time. Each metric has several dimensional cuts which are split across multiple reports with varying levels of aggregation, and metrics that represent a complete business process like a scheduling workflow or a user lifecycle are scattered across the reporting universe.
This puts the onus on the end user to manually hop across the collection of reports every single day to make sense of the connected system. While you have a pulse on the key metrics i.e., the “what”, - if you want to understand metric changes or connections, or pose a hypothesis you want answered, say the “why” or the “how”, the process is incredibly tedious, if it exists at all.
Measurement and visibility is now table stakes. Organizations want to set metric goals thoughtfully, understanding the metrics dependencies across the org; they also want to monitor, root cause metric changes, and run and measure experiments to impact metrics. These workflows are woefully underserved by reporting tools which are stuck in a legacy lower level of abstraction (the “report”) meant for a different world.
Many data and business teams have come to accept this reality as normal - that these operations will be manual (”ask the data person to run this”) or takes time (”I can get to this next sprint”), will be inconsistent or error-prone (”this isn’t what the analyst shared last time”), and even accept that many such requests will never be completed. But, as we know from history, tools can change to unlock superior behavior.
Every technological revolution builds on the previous by pushing the frontier of standardization, abstraction and composability. In the data world, there is enough history now to standardize the business concepts - the base concepts of entities, metrics, attributes to newer concepts like a business process (e.g: a funnel or a graph) or the notions of segments, experiments, and scenarios.
And if these can be abstracted by data teams who can model the inner details, the wider data and business teams can now compose on top, and execute high value generating analysis with significantly lower friction.
A new wave is coming. Old tools can only be stressed so much. Frustration is building. Data and business teams want to operate with more consistency, higher velocity, and with a deep desire to understand and drive metrics across the complex connected enterprise. A powerful “metrics stack” is inevitable.
