The path to being the best data analyst: Help, Build, then Do.

The path to being the best data analyst: Help, Build, then Do.

The core competency of a data analyst is “Speed to Insight”.

A data team often consists of many people, with many skills, using potentially overlapping techniques. This focus on speed distinguishes this role from data scientists or statisticians. Today I’m focused on answering questions about the business or about how users behave. I’ll refer to these types of questions as mostly in the realm of data analysts, though some orgs call these folks data scientists, too. A good data analyst should be able to interface directly with folks in the business unit that they’re working with. They need to have a solid understanding of business fundamentals in addition to data chops. A junior analyst may rely on business people asking smart questions, and answering the questions that they’re asked, quickly. While this is clearly helpful, it’s not the highest-leverage opportunity for an analyst. The best analysts don’t only answer the questions that they’re asked. Actually doing analysis is often the easy part. It’s other skills that separate an average analyst from the best.

Help teammates rephrase their question.

Ask the “next 3 questions” that they should know

When you’re asked a particular question, it can be tempting to think “sure, I can answer that”. While that might be the first step, it’s important to get at the root reason for the question. If someone asks for the signup conversion rate across a section of your website, it’s the analyst’s job to dig in. Why are you wondering about signup conversion? Would we rather measure conversion to active users? Are you interested in a particular segment? Does the signup rate vary across paid, direct, organic, and social traffic? It’s unusual that a PM wants a metric for the sake of a metric. They’re really trying to learn something about the nature of your product or your audience. It’s your job to know enough about your data sources and about the business itself to answer the next three questions that they didn’t ask. Short circuiting the back and forth will help your team move faster.

Answer faster by proposing a reframed question that’s close enough

Stakeholders may have a rudimentary understanding of what data is available, but they may not understand that a simple alteration of a question might reduce the time to answer from a day to an hour. No data team ever has all of the data that they want, modeled to answer every question. When someone asks a question that would require a new data model or custom work, see if you can reframe their question into one that you can answer quickly with existing data models. This most often to happen when they ask something extremely specific. They might even be asking a better question, but they may not care that much about the specifics.

Which of these 10 customer segments has the highest Lifetime Value (LTV)?

This is an astute question, and likely means that you’re dealing with a data savvy stakeholder. Say that “everyone knows” at your company that these are your top customer personas. But let’s say that you’re a young company and haven’t done segmented LTV calculations yet and have no easy path to getting this answer. You probably have “total dollars collected” easily accessible, though! In that case I would propose this counter, “What about if I give you Total Dollars Collected per user in segment?” Assuming that none of these user groups are systematically newer or older than others, that’s probably close enough! If the stakeholder is looking to prioritize marketing campaigns over the next couple of weeks, they’re not going to want to wait for a new LTV calculation. By reframing the question to one that was close-enough, you unblocked them a week early! That’s leverage.

Reframe to question that they should have been asking

For quite some time at Zapier, we had better data modeling around the number of Zaps that were “turned on” versus the number of Zaps that “had activity”. This lead to a tendency to rank various important KPIs and concepts using zaps-turned-on instead of actual activity. In most cases, this was fine (see reframing to be close enough, above), but once we got large enough to start noticing differences between turn on and activity, the data team made a concerted effort to help folks reframe their questions (and KPIs, and dashboards) in terms of activity! This is a better measurement in most cases, and when folks would ask for a turn-on count, we would ask them if that was really what they wanted.

Build Self-Service Tools (I consider Business Intelligence to live under the Analyst Umbrella at most organizations )

Building V1 is the quickest way to build stakeholder investment in data

The introduction to data driven decision making at many companies will come via an analyst working with the team to turn their goals into measurable outcomes. In the first iteration this often means building a dashboard or similar interface for folks to have access to answer those same first questions without you. Next, you have to build out data structures that are intuitive enough and well documented enough that you can advance to letting people explore the data on their own. Tableau, Looker, and similar tools are designed with the idea of letting savvy business users discover the answers to their own questions. Analysts who empower that will excel. How do we ensure that an analyst isn’t the only person diving into data? Well…

Teaching your team to answer their own questions makes everything go faster

In general, folks aren’t going to be comfortable mucking around in your data without some training. There are definitely good intros to [Looker|Tableau|Etc] out there, but they won’t explain your data sets. Good data teams will create intro material using real data, and actual questions that folks might ask in order to get them more comfortable. Success here doesn’t mean that everyone becomes a power user. Ideally, most people have enough familiarity to look around and feel good. Then, the few folks in various places around the organization that get really good are a massive force multiplier for the data team. At Zapier it’s our head of platform, a senior PM, a person in partner ops, and a writer. As good as an analyst might be at “understanding the business needs”, you’ll never be in it as deep as they are, and for the 80% of questions that are self-serveable, everyone wins here.

Do

Sometimes, your stakeholders are never going to DIY with BI tools. Sometimes, they ask questions that are too difficult to self serve, or require too much nuance. These are the best use of your analytical time. In those cases, you should still be willing and able to help build-it-for-them. The PM and head of platform that I mentioned earlier? They always have the most up-to-date and fastest time-to-insight of any teams in the org because they get so much of the way there themselves. In the best cases, you end up with a new data model that will let those types of questions be easier the next time. Analysts who follow these steps are likely to become the go-to folks on the data team. That’s good for the business, since you’re empowering people around the org. Plus it’s great for your career.

Anything else that you see good analysts do regularly? Hit me up on twitter @smlevin11.

These opinions are mine, and don’t represent Zapier’s official stance on associate, staff, and senior positions.

Published byStephen

I love helping people at all levels of a company use data to inform their decision making.