Last year, Emilie Schario and Taylor Murphy proposed this wonderful idea of “running your data team like a product team”. The key premise of the article was this: product teams have a lot of great practices that data teams would benefit from adopting. But somewhere along the way, we lost sight of this point and happily replaced it with strawmen: maintaining production-grade systems for our data assets, building more data products, or painstakingly defining what production means in service of hardening data contracts. All of these are certainly worth consideration, but they’re concerned more with the proper handling of data and data assets rather than the data teams that actually drive the impact.

The central idea here was never to quibble over the definition and boundaries of the “Data Product” or set SLAs for data producers, but rather to compel us to reconsider how data teams operate by using product teams as a model.

I’d like to spend some time discussing precisely how to run your data team like a product team.

Two core ideas: user-centricity and proactivity

There are two core principles that product teams embody — user-centricity and proactivity. Let's discuss each in turn.

User-centricity

The best product teams are user-centric. They speak with their customers regularly and let direct user feedback directly influence their roadmap. This flywheel is the lifeblood of any good product — it ensures that they are not just shipping features but solving problems.

Data teams need to operate the same way. We’ve been too enamored by how technically interesting our work can be, and we’ve forgotten that we are not standalone havens for scientific/engineering pursuits - we are a business unit hired to provide business value. And if we, like product teams, do not solve business problems with data, our metaphorical “data product” (all data work we do) is failing.

This does not mean responding reactively to ad hoc requests. Nor does this mean completely shunning scientific endeavors. It simply means staying attuned to what the business needs and pursuing opportunities to that end. While Taylor and Emilie suggest your coworkers are your customers, I don’t think this is quite enough — the business is your customer. You need to know it, understand it, and orient everything you do around it.

Proactivity

Secondly, the best product teams have proactive processes set up to support the product-building process. They provide themselves intentional space to set vision, to brainstorm, to pursue passion projects that lie outside the scope of directly fielding customer requests.

Analytics teams, on the other hand, seldom operate like this. At minimum, we should be spending some time exploring data outside of inbound requests. And at the team level, we should be on the lookout for patterns so we can intentionally craft our roadmap and do high-leverage work.

That said, reactive work certainly still has its place - analysts are the primary means through which the business can explore data, so we will often find ourselves necessarily in a supporting role. But the key is to constantly push to understand the context behind this work, and let it motivate strategic, high-leverage projects.

But how do you get started?

The original LO article has some great organization-level suggestions to make this all possible: have sufficient headcount so you have enough bandwidth to be strategic; gather a multidisciplinary team to draw inspiration from. To add onto this, here are a couple concrete process-level changes that you can immediately make:‍

1. Establish a process for knowledge consolidation.‍

Putting your team’s work in one place is a pre-requisite to being user-centric. For your work to be user-centric, you need a view of all the work you’re being asked to do. Organizing your work in a shared space can enable pattern-matching across your team’s work — equivalent to a product team reading UX research findings before a brainstorm.

This will be your biggest hurdle because non-compliance is a huge issue. People strive to stick with the status quo, and too often I’ve see documentation/knowledge-sharing initiatives fail.

While we’re certainly biased, Hyperquery is the only tool we’ve come across that lowers the friction enough that people will comply, and the benefits of knowledge sharing can be reaped across the entire org. Publishing work in a wiki workspace like Notion, Confluence, or Dropbox paper, however, can come close.

2. Understand the business needs intimately.

We’re not just technical workers. We are a bridge between data and the rest of the business. And if we just immerse ourselves in the data — which is just one side of this conversation — we won’t be nearly as effective as we should be.

We pride ourselves on our technical prowess, but we are only effective insofar as we know why we’re doing our work. Without keen business acumen, we’ll write up pointless analysis after analysis until we’re moved to Storage B, our interactions relegated to data pulls.

Conclusion

The nature of data analysis has drastically evolved in the last decade. We have access to more data, more compute power, and more tools than ever before. But we haven’t yet figured out we should operate within an organization with our newfound powers. It can be helpful here to carry successful practices over from other domains. From product teams, in particular, a focus on user-centricity and proactivity can mean the difference between a help desk analytics team and one that truly drives strategy. And user-centricity and proactivity come from acute awareness of business needs and better knowledge-sharing practices. To learn more about how Hyperquery can help, check out hyperquery.ai.