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 with intentional space to set the 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 a minimum, we should spend 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 constantly pushing to understand the context behind this work, and letting this context 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 of 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 prerequisite 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 studying UX research findings before brainstorming.

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 seen documentation/knowledge-sharing initiatives fail. Publishing work in a wiki workspace like Notion, Confluence, or Dropbox paper (and for an analytics-specific solution, hyperquery) can break down this barrier.

The key components here to ensure widespread adoption:

• Lower the friction to usage. As tempting as it might be to use git and a set up a peer review process, layers of process won’t ensure rigor — they’ll reduce adoption. Do something easy, light, and focus on ensuring your team will put their work in the tool.
• Set up organizational scaffolding. Again, use a tool like hyperquery, Notion, or Confluence, with a wiki structure that’ll enable your team to establish practices around not only centralization, but organization. Agree on reasonable, functional categories, and create a central “Start here” doc that onboards new analysts onto your practices.

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.

What this looks like, practically speaking:

• Always ask why. Before you dumpster dive into SQL, make sure you’re aligned with your stakeholders on business objectives. Write this down, agree on an approach, and only then, do the work. This sets a precedent that your involvement in the decision-making process is not limited to the technical work — at minimum, you’ll be at least seen as a translator, and at best, a thought partner.
• Care about the business. It sounds obvious, but too often I’ve seen analysts and data scientists put blinders on to the business and immerse themselves in the technical aspects of their work. This behavior is a harbinger of a truly dysfunctional, low-impact analytics org. Higher impact does not generally come from better analyses, but from data-driven impact at higher levels of strategic execution.

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 an acute awareness of business needs and better knowledge-sharing practices.

Original blog post published on hyperquery.