“He who controls Dune controls Spice. And he who controls the Spice controls the universe.”
It is not hard to see that Frank Herbert’s science fiction classic Dune is a thinly veiled critique of the world’s dependence on Oil. As some people like to quip these days - Data is the new oil. Just like Spice, Data lets you expand your mind and see into the future. But it is also a great addiction. If you are trying to grow your product, you will have to find ways to harvest this precious resource to fuel your empire. But there are some significant challenges on the road, and we have some tips to help you through them.
As product managers in this day and age, we are taught to live and breath data. Every decision, every feature, every pivot starts and ends with data. Hypothesis formulation, AB testing, user testing, experiments, Wizard of Oz. All of these begin with asking “what data do we need to validate this decision?” The next step is a design that takes data into account. And, hopefully, the final step includes the experimental results that confirm or disprove our hypothesis. After all, we serve at the pleasure of the mighty Emperor: the business side of the organization, sales, and marketing teams, who require data to generate growth and reduce churn.
We share this passion for data with our new allies - the data scientists. They can make the numbers jump and dance in beautiful graphs, turning an endless series of data points into an insight. Give a data scientist an interesting question to answer, access to huge sets of data, and a Chartio or Tableau license, and they’ll never leave your side (beer and cookies help as well). And if you ask a real data scientist, she will tell you that what she really needs is Excel. And yes, she will have another beer, thank you very much. Much like a Dune Mentat, data scientists are addicted to Data. When given a “hit” of the drug, they will provide you with incredible results. But Product Managers and Data scientists share a challenge within this addiction to data: we don’t control the source of the drug that sustains us.
In modern SaaS and Mobile products, developers control the source. They develop the features, the databases and the conversion funnels that we want to measure and monitor. And much like the Fremen of Dune - they sometimes feel like the cheap labor, harvesting the precious, world-addicting substance from the dangerous wastelands of code and cloud-native deployments.
You can’t force developers to give you the data you need, no matter how well you prioritize your backlog. Developing code for the sole purpose of providing business insight is a tedious, uninteresting task. And in some cases, what we're asking for is technologically impossible to fetch. Or, that’s what a bored engineer will tell us, and we’ll have to take their word for it. After all, we are but lowly, nontechnical product managers.
In some cases, we try and get around this by buying and installing expensive and sophisticated tools. Google Analytics, Pendo, Walkme, Heap and others measure the frontend -- what our users are trying to do. Other tools like Panoply, Chartio, and Tableau, connect directly to the source and a product manager or data scientist proficient in SQL can fetch data from the database. On top of these, there is a rich ecosystem for tools connecting these sources, aggregating the data, storing, presenting, and running queries on top of it.
There is one gaping blind spot, however. Between the user interaction in the frontend and the data stored in the database, there is a lot of transient information moving around in the backend. Information we can’t measure without writing additional code and building a BI system. The kind of data that DevOps engineers struggle to fetch by adding log lines and throwing them at tools like Logz.io, Kibana, and Elasticsearch.
DevOps engineers fetch this data to make sure production is stable and performing well. But if fetching similar data doesn’t seem to provide direct business value or, more likely, is not exciting and technically challenging enough for the dev team, product managers and data scientists are sometimes left starving. Some of them get around this by getting their hands dirty and writing the code on their own. Others struggle to prioritize the initial task of building a BI system and the ongoing tasks of fetching more data into it. And some choose to remain blind. Much like Paul Atreides at the end of the second, underrated book (50 years after its publication, it feels like ‘spoiling’ a classic Greek Tragedy).
Another recurring challenge is that in all three data segments (frontend, database, and backend), the task of fetching data usually means adding to, and changing the code. If your dev organization is mature enough, this is already built into your Definition Of Done. You plan for it when designing a feature; and as you roll out a feature, you track and measure its exposure, usage, and quality to make sure it behaves as expected. You take into account the fact that additional design and development time is required. You also know that as you roll out a feature, new questions will arise, and to answer these questions you will have to write more code to fetch more data. The time you spend planning, developing and rolling out a feature may double. But you do it nonetheless. Because you know it will provide the business insight your team needs to grow the product. The Spice must flow.
If your dev organization isn’t mature enough - well, may the goddess of data have mercy on your soul. You will release a feature or even a brand new product. You will spend weeks and months in the dark before you can get your developers to prioritize an overcomplicated system for collecting and storing data. Then, by the time you actually get to see the data - well, I’m sure you get the point. If this is a problem you’re facing, the best thing I can tell you is that you are not alone. Keep pushing until you get it. Some icebergs do eventually melt off as you keep pecking at them. We will terraform Arrakis eventually, and we will build a data-driven culture around us as we do it. Not sure which task is easier though.
So who are the DevOps engineers and the Product Managers in this Dune-themed blog post? If developers are the Fremen, then maybe DevOps engineers are the Atreides, fighting honorably and trying to cooperate with the developers while keeping business and customers happy. And perhaps product managers are the Bene Gesserit -- we abide our time, play the political and diplomatic game, and try and pull strings behind the scenes. We subtly try to help our organization become truly data-driven. And we will eventually introduce our developers and DevOps engineers to Kwisatz Haderach - the tool that can bring data from across time and space at an instant. Speaking of which...
Rookout lets developers fetch code-level data with zero code changes, no restarts, and delays. Just point at a line of code, choose a specific variable, and stream its value whenever needed to your favorite data aggregation tool. Do it to keep your devops engineers happy when they try to troubleshoot a failing deployment. To help your data scientists get the data they need so they keep smiling. Use it to keep that annoying product manager off your back. To spend more time writing beautiful code, and less time writing less-beautiful code that only measures how beautiful your code really is. Do it to save precious time for Spice coffee, or Spice beer, or pear cider. We don’t judge. Just make sure you don’t sit with your back to any door.