TLDR: A framework for making data science useful.
Data is the new oil. AI is the new electricity. Great!
Unrefined, oil is just a messy goo which suffocates all living things which come close. Electricity, if not harnessed properly, can provide some shocking surprises. Neither is all that helpful in and of itself.
Useful data science can be defined narrowly as the application of statistical and computer science methods to data to provide actionable insights. Without the word “actionable,” data science can be a lot like an oil spill or an electric shock. Plenty of mess and noise, very little value.
In the 3 layer decision architecture, the action or decision, is represented on the right side. This is the change which is to be made based on the decision. It is the motivating purpose for the whole architecture, and should be the starting point for any project.
Simon Sinek has carved a place for himself next to Dale Carnegie and Peter Drucker with a simple, but far too often neglected concept called, “Start With Why.” The advice that Sinek first shared in his 2009 TED talk applies to individuals, organizations, and projects. Without the core motivating “why” it is easy to lose the cohesiveness of the corresponding outer layers. Once the “why” is well understood, the “how” and then the “what” come together.
Nothing else really matters if the Why is not aligned to the stakeholders of the decision process. Refining oil, fueling into a car, and starting the engine do nothing to help if you are lost without GPS or a map. Using your electricity to power a laptop for writing a blog post don’t do much if you don’t have anything to say. 🤘 Meta!
Solving for the “Why” of an analysis requires humility and patience. The role for Product Management in organizations has significantly matured over the past ten years to solve for “why” and then how and what in the development of technical products. Product managers have learned that progress is not about being the most brilliant technologist ushering in the next big thing from some skunkworks. Nor is it about taking dictation direct from the same consumers to build exactly what they ask for. The design process is a delicate balance between expertise and empathy.
“Some people say, “Give the customers what they want.” But that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!'”Steve Jobs – established Apple’s “Why”
It is useful to deploy the though model of “problem space” and “solution space” The Lean Product Playbook. This framework helps to align the “Why” for decision projects.
Problem space is the set of needs that stakeholders of the decision have, what kinds of impacts decisions can make, and what value the automation provides.
Solution space is all the ways that a decision process could make use of the available resources.
Not all possible solutions map to useful problems. Some problems can’t be solved by the project team implementing a new decision process. It is good to acknowledge these limitations up front to manage expectations and plan time for discovery. The more innovative the effort, the less well defined these spaces will be. Failure is to be expected and encouraged.
When learning about the solution and product space for the first time, projects should be a portfolio of small experiments. Each “sprint” is looking for possible connections in the alignment space. Many will fail. It is far better to fail fast, early, and in expensively.
Product managers understand this, and seek to continuously learn more about the problem space and guide the selections of product features in the solution space to align with useful problems. When this works, great value can be unlocked for all stakeholders. When it does not work it leads to results like the Ford Edsel, New Coke, and Google Wave.
The disciplines of actionable data science and product management are closely related. Innovating a new solution with data and technology depends on a thoughtful mapping of problem to solution. Choosing features, model architecture, or data structures all require domain expertise, and hyper-sensitivity to the “why” of the problem being solved.
Exercises such as asking 5 whys, considering the analytics hierarchy of needs, and treating projects like a Lean Startup can help. Start with “why” and go forth with decision architecture for the right reasons.