What does it mean to be data-driven?

Why being data-driven is a lazy term.

Like with most of my stories, I need to take you back to around 1370 BC. Where two semitic tribes, the Ephraimites and the Gileadites have a great battle. The Ephraimites lose and the Gileadites set up a blockade across the Jordan River. To catch anyone trying to cross the river who are not part of their tribe, the Gileadites ask each person to say the word shibboleth. The Ephraimites, who have no sh sound in their language, pronounce shibboleth without the h, which reveals them as the enemy and they are then slaughtered.

Other than finally being able to reference something I learnt from The West Wing, the word shibboleth is maybe the first recorded example of a type of Iinguistic password. We often want people to say specific things that let us know they’re one of us. To see if they invest in the same cognitive fluencies as us. If they don’t, they won’t be slaughtered, thankfully we’ve moved away from that sort of stuff. But they will be unmasked. Revealed as an outsider. Not one of us.

But that’s enough history for today, let’s talk about software development.

Being data-driven feels like the shibboleth into product management. The secret key. You’re one of us if you talk about data. Use the data. Trust only the data!

This phenomena is exacerbated in job interviews, where this weird, but socially accepted dynamic exists where an interviewee doesn’t know what the linguistic password is, so tries to say lots…