Data scientists are detail-oriented by nature. You’ve probably noticed that by now. And can you blame us? We spend our time pouring over granular datasets, finding mistakes, cleaning them, building predictive models, producing visualizations, deriving insights, and communicating those insights to stakeholders in the hope of driving impact.

All of these things require lots of attention to detail, so it’s good that we know how to focus in on the small stuff. But there are two sides to every story.

The Problem

When given a request or business problem to tackle, we have a tendency to latch onto details and overlook the bigger picture. Let me elaborate a bit with an example from Greg Reda and his great essay on life as a freelance data scientist:

You receive the following request: “What’s the optimal number of leads that a rep should get? We want to get directionally better.”
As data scientists, we hear “optimal number” and we start thinking about doing complex math and building models. We end up ignoring the most important part: “We want to get directionally better” — our stakeholder is telling us “we don’t know much about this right now — help!”

If we stop after hearing “optimal number” and go down that route, chances are that we’ll end up spending hours on a complex problem. It’s only after completion that we realize the stakeholder needed something much simpler. This problem plagues data scientists for a couple of reasons.

First things first, data science problems are often open-ended. There’s always another hunch to follow, another model to iterate on, or another visualization to produce. The possibilities are truly endless. When we aren’t careful, we go down these rabbit holes looking for better and better solutions to our problem. While this is happening, hours melt off the clock at an alarming rate. This time could be better spent elsewhere.

Second, communication is just flat-out hard. Stakeholders will often say one thing and mean another thing. As data scientists, we often interpret things one way when it’s actually a completely different story. We fall into an illusion of agreement where both parties think that the other one understands each other. In order to fix this, we end up going back-and-forth with our stakeholder until we finally have things down. Once again, not only is this frustrating, but it’s also a waste of our most precious resource: time.

Image Source
Image Source

Enter Minimum Viable Analysis

So we know that this is a problem, but how do we address it? In short, just start simple and iterate from there. Produce something and get feedback as quickly as possible. If this sounds familiar, it’s because it is. Product people know this as a minimum viable product or MVP, a term popularized in the early 2000s by Steve Blank and Eric Ries.

Data Scientists can leverage a very similar approach. Not only will this help us solve the problems outlined earlier in this post, but it will also generate more insightful and frequent results. We’ll call it minimum viable analysis or MVA.

The idea here is that we prefer incremental progress and don’t assume that our stakeholder needs the most complex solution available. The process of producing a minimum viable analysis is pretty straightforward. I’ll lay out a concise version of the steps below and then go into more detail later on.

Steps to produce a minimum viable analysis:

  • Make sure you completely understand the problem at hand
  • Produce fast, surface-level insights that address the problem
  • Communicate the results back to your stakeholder and get their thoughts
  • Either wrap up the analysis or dive deeper

Before anything else, you want to take as much time as you need to wrap your head around the problem. That might mean an extra 1-on-1 with your stakeholder to clear things up. It might mean taking some time to review past work on the project or reaching out to other teammates with useful information. Whatever you need to do, it will be well worth your time to get your footing before you dive into the analysis and produce your minimum viable analysis.

Start simple with some basic exploratory work or plots. From there, move into addressing the problem in the simplest way you can in order to generate your surface-level insights. Once that’s done, it’s time to communicate your results. Make sure they are easy to digest so that you and your stakeholder are on the page.

Typically, they’ll offer you one of two types of feedback. Either you’ll get a “cool, this is all I needed” or “this is good, but keep going.” Depending on their answer, either wrap up the analysis or dive deeper into the problem. Simple enough, right?

Wrapping Up

You would actually be shocked how often stakeholders are satisfied with your minimum viable analysis. By not assuming they need the most complex or optimal solution, you save yourself and the company countless hours that could be spent on other projects. So enjoy these other projects and remember: Just because you can, doesn’t necessarily mean that you should.

Thanks for reading! If you enjoyed this post and you’re feeling generous, perhaps follow me on Twitter. You can also subscribe in the form below to get future posts like this one straight to your inbox. 🔥