Recently I spoke at CrunchConf in Budapest. It was a great experience. The conference is fantastic for people interested in data (e.g. data analysts, scientists, product managers, etc.) Having said that, I’m not a data scientist. I don’t spend the bulk of my time storing, organizing and sifting through data. I’m not smart enough for that!
I also like simple things, or better said, I like to simplify things as much as I can. The more I think about Lean Analytics, which Alistair and I wrote 3 years ago, the more I realize that the key message of the book is this: data is about simplification and communication. I don’t know if we got that across strongly enough in the book, but that’s why we blog, to adapt and evolve our ideas on various subjects.
So in preparing for my presentation at CrunchConf, I asked myself, “How do I take what I know about product management and data, and communicate that effectively and simply to an audience of data experts, without looking like a bozo?”
And this is what I came up with. (You can be the judge.) There’s no soundtrack here, and very few words on the slides, but hopefully the presentation itself is helpful.
Here are the key messages I was aiming to get across:
The answer isn’t more data, it’s more process. I know “process” is a scary word, but I genuinely believe the answer to building better products is in process…it’s just a question of what process and how we implement it. A painfully long, thousand-step process to do something is clearly not the answer. Fundamentally, this is why I believe Lean Startup has become so popular, it promises a simpler, faster process for getting stuff done.
But Lean Startup isn’t as easy as we’d like it to be. What a shock, there’s no silver bullet. No easy answer. Shit’s hard and it takes a lot of work. If you’ve tried to implement Lean Startup in your organization, you’ll know what I’m talking about. Build->Measure->Learn looks so simple and elegant (and it is, in some ways), but it’s hard to implement. My goal with this presentation was to break up some of the parts of the cycle (specifically around idea generation and triage) to hopefully make the process clearer.
You can’t ignore qualitative data. Qualitative data is the unsung hero of most product decisions. If you lean too far to using your gut, without real data, you run the risk of being blindsided by your own biases; but if you ignore your gut completely, you’ll suck the magic out of the product building process.
Customer input is incredibly important. Customers can’t tell you what to build (because they don’t really know), but they have pain. Customers/users have problems. You need to listen to that pain, and deeply appreciate/understand it, so you can translate that pain into solutions for them. You’ll see in Slide 29 that I put “Customer Input” as a cycle around Build->Measure->Learn. It’s more than a single input at a single point in time, you should be collecting customer input constantly. But do it right.
Corporate goals are both good and bad. You can’t ignore corporate goals. The good ones align everyone around a common mission and purpose. The bad ones are misaligned and don’t work towards create genuine value for customers. If you’ve ever worked anywhere in your life this should resonate with you, because almost every company has good and bad corporate goals. They’re a necessary input into the equation, but a tough one to manage.
Data is a key input and filter into the product development process. See slides 39–41. Data is a key input that gives us ideas on what to build. If you’re using data at all, you’ll know how this works. But data is also a filter to balance against the other inputs into the process, most of which are qualitative in nature. So data is both an input and a filter. You’ll see in Slide 40, I’ve put “data” as a circle around Build->Measure->Learn. I’m not a visualization wizard, but the point I was trying to get across is that it’s ever-present and necessary for helping to make good decisions.
Data is also a communication tool. I mentioned this earlier, but I think it’s critical. I think this is a key lesson for data scientists and analysts who may find themselves lost in the data. If you can’t communicate the data effectively, no one will give a shit. Worse, they’ll do everything in their power to ignore the data (see Slide 47). If we want data to be used effectively as an input and filter into the product management/development process, then it’s on us to make the data simple for people to understand.
The title slide of the presentation has the words “Data + Guts” on it, because I genuinely believe you need a mix of both to build great products. You can’t win with one of them alone. And the key, since most people/companies rely too heavily on their guts today (or the voice of the HiPPO / Highest Paid Person’s Opinion!), is to make data approachable and usable by everyone. Make data meaningful to every department, so that they want to use it in their every day decision-making process.
Data is complex, but how we communicate it doesn’t have to be.