Relationships over Requirements

I’d love to be able to take credit for the mantra “build relationships, not requirements”. I’m fairly certain I came across the phrase in an article written by data thought leadership stalwart Wayne Eckerson. Alas, my Google fu has failed me and I’ve struggled to find the original article. But the idea has always resonated with me.

I find folks that work in data can be an odd bunch. The majority of data teams I’ve worked in have been regarded as a technical resource, and have often sat within IT functions. Yet my personal experience is that a lot of data professionals don’t necessarily come from a technical background. I myself studied politics and philosophy at university (though I dropped out before earning my degree to work as a barman). The guy who mentored me had a degree in music. Other folks I know come from diverse educational backgrounds such as history, astrophysics and the arts.

For many, data becomes an accidental career. People who are natural problem solvers find themselves working with data as part of administrative roles, and the quest to do things better starts to lead them down more and more advanced solutions. Certainly Excel was my gateway drug, but before I knew it I was learning SQL and dimensional modelling practices; a familiar story, I’m sure.

Given these origins, this particular breed of data professional should be perfectly placed to understand the challenges of their end users. They should be able to empathise and sympathise with the day to day struggles of those at the coal face of the business, and see where data initiatives can aid and assist with providing additional value the most.

However, all too often an “us versus them” type attitude seems to emerge. We end up with a disconnect between the needs of “the business” and the actions of the data team. Data teams find them selves bemoaning the fact that “the business” need to be more data literate. At the same time they begrudge the fact that they end up being treated as order takers, expected to deal with a seemingly endless backlog of minor changes (“can you please add an extra column to this data extract”) or worse still, responsible for building countless new dashboards that are often forgotten about before they’ve even been delivered.

Yet in parallel to this, you find teams putting up barriers to doing any truly collaborative work. If a stakeholder needs an amendment? “Raise a ticket”. New dashboard request? “Fill out the specification form”.

When stakeholders discover that the end product is underwhelming and doesn’t actually meet their needs, the blame gets laid at the door of the party who made the request in the first place for not communicating their requirement effectively.

It’s time for some self-reflection from data teams. There is no “the business”; You’re all the business. Everyone should be working for positive outcomes together. The success of the businesses you work for should be the shared goal. Another great soundbite that I came across on my LinkedIn feed recently (I forget who exactly said it) was the idea that instead of complaining about a lack of data literacy, data professionals should make more effort to become more business literate.

And I loved Dylan Anderson’s recent take on how data folks need to get better with dealing with ambiguity and should embrace the opportunity to tease out a better understanding of their users’ wants.

Which leads me nicely on to one of the reasons why I advocate for applying product thinking to your data initiatives. I fear that we’ve hit peak buzzwashing with the term Data Product. It feels that practitioners really are struggling to come to a consensus of what the term really means. But I still see so much value in the underpinning ideas of product thinking. Echoing the thoughts of Marty Cagan, make sure your data initiatives are valuable and usable – users want to use them because they feel the benefit.

The way to do this is through collaboration. Be open to users thoughts and feelings. See their pain points. Understand their needs. Move towards becoming a trusted partner, as opposed to a service provider. And realise that ultimately, you all share common goals and all parties want each other to succeed. The key to this; build relationships, not requirements.