Heuristics: the power of folklore in decision-making

Long before I got into data, I had another love. One I've never been able to let go of. Like data, it satisfied my need to have things ordered and was focused on using that organization to uncover patterns and influence change. This was the field of Systems Engineering.

The similarities between Systems Engineering and the world of Data Analytics are never-ending. Recently, when doing a bit of light reading on SE, I stumbled upon a concept we don't talk nearly enough about in data: heuristics.

Heuristics are the rules-of-thumb, or 'words to the wise' that we all use every day to make rapid decisions.

Heuristics: Our antagonist

In data, we tend to come up against the power of heuristics in scenes like this one:

YOU

Hey Jim, the data is saying we should go left.

JIM

Hhhmm, yeah that's interesting.

YOU

Ok, so we're going to go left, right?

JIM

Well, I've always gone right and it's really nice over there so no, we're going to go right this time. Thanks for doing all that analysis though. Those charts look sick.

It doesn't always have to be data vs. heuristic. In fact, if we ever want to truly influence the decisions of the business, we will have no choice except to tackle these experiential beliefs at play. After all, these rules of thumb are far more widely used than any dashboard we create.

But alas, I will save that topic for a separate blog post 😉.

Heuristics for you and me

Our business partners aren't the only ones who use heuristics to guide how we work and make decisions. We use them to intuit when some numbers don't look right, or even when we use the famous 80/20 rule.

But have we ever considered what our guiding heuristics should be?

The Systems Engineering Body of Knowledge outlines 4 Heuristics for Systems Engineering projects that are directly applicable to Data projects:

4 Heuristics for every Data Project:

1. Don't assume the original statement of the problem is necessarily the best, or even the right one

2. In the early stages of a project, unknowns are a bigger issue than known problems

3. Model before build, wherever possible

4. Most of the serious mistakes are made early on

I find these four rules of thumb incredibly powerful. So little is documented or decidedly 'best practice' for how we begin a data project, which is undeniably a pivotal step of any analysis.

How do we act on them?

These are the types of activities we strive to make possible and effective with the canvas, including:

• mapping out a problem space with a stakeholder to get to the heart of a problem,
• getting feedback quickly to work through the second and third-level questions behind a request,
• prototyping a report before perfecting one to make sure you're building the right things

I'm personally convinced heuristics have a larger role to play in how data teams approach our work, and ultimately how we do our job of influencing better decisions in the business.