Building Better Bets on Big Data
or, Code is for Humans.
A Pair of Paradoxes (Paradoxi?)
When I worked on the Agency side, I frequently referred to “the PowerPoint Paradox.” This is the inerrant, often depressing reality that the most-often approved ideas aren’t necessarily the best, but the ones that look the best in a slide deck. It’s that the creative “value” of an idea isn’t measured in the free market of the Public, but a transaction between people working for the Brand (often former Agency types like me), and the Agency people they’ve hired. Rare was the client who would use experimentation and empirical evidence to evaluate an idea, and these were the relationships where you REALLY got to have fun.
The Codebase Paradox
Fast forward now to my work leading the roadmap and development of a technology platform, and I feel the same emotional tug — but this time with new players. We work in Big Data with all the appropriate capital letters, specifically, that from social media. And for what may very well be the first time in human history, the digital world is practically our oyster. Cloud computing, open source architectures, linguistic analysis and available data APIs have all matured at don’t-blink-or-you’ll-miss-it speeds, making practically any product or creation you can think of possible. So when you’re constantly bathed in this sea of possibility, its extremely easy to become enamored of the things that seem to push the limits of what can be done and find new frontiers.
Maybe label it the “and here’s how I did it!” factor — many of the offerings that seem to be the best products must involve an explanation of how it was done. It’s the data visualization or statistical correlation or semantic learning natural language sentiment entity detection processing nested algorithm that appears cool because it exists. I am NOT immune to this feeling, and I completely get it — when a developer has been working hours on end on a feature or product, you have to appreciate the effort, particularly when they tell you all the hoops they had to jump through to make it work.
But it’s here where the hard question must be asked: does more technical wizardry make a better product?
Reward the Decisions, not the Database.
Before sitting down to create ANY data product, teams that hope to have a shadow of success MUST agree to three truths:
- We can create anything. But that isn’t the goal.
- We win when users make better decisions by using our product.
- We can’t force users to look under the hood before they drive the car.
These statements make us automatically — and radically — readjust the lens of judgement we use to evaluate What We Shall Build. If my job is to help a user make a better decision, it’s often the most simple products that get them there. In fact, if there is any technological tour de force to be accomplished, it’s often completely hidden from the user behind the fog of “it just works.” This flips the reward system entirely: products aren’t lauded for their complexity, but for their effectiveness.
Don’t. Be. Afraid.
My best advice for anyone else working with data day-in and day-out? Don’t be afraid of the red pen. In my Agency days we would also have “tissue sessions”: all the creative was printed and posted on big boards around the room, and we started tearing down what didn’t work. You couldn’t fight for your own “baby,” because we had one goal: making brand narratives more compelling, and hopefully, doing it for a client that wasn't trapped by the PowerPoint Paradox.
Likewise, technology companies MUST make these decisions. They must look each other in the eye, swear a solemn pact to value the user, and be ready to build what they need — whether easy, hard, or somewhere in between.
