Data analysts, think about your work from the business stakeholders perspective

As data analysts, we often do lots of work — writing SQL, modeling data, drawing charts, and building data presentations. We spent hours optimizing our SQL queries for performance, looking for the right charts to present, or toying with different data catalog tools.

But have we ever stopped and asked ourselves:

• At the end of the day, how does my work translate to actual business outcomes?
• What are the different values my actual end users (business stakeholders) get from my work?

You might think "Duh, these questions are trivial, who wouldn't think about it this way?" But often times data analysts are too focused on the details/technical work that they forget to zoom out to see the big picture: What’s the actual impact of my data work from business users’ perspective?

I’ve seen many data analysts make this mistake (myself included). Not keeping the business users' perspectives in mind would lead to:

• The data analysts don’t prioritize their data work that’s aligned with the business outcomes. They keep nerding out optimizing their SQL queries and neglecting to attend to the business users’ requests because those are boring technical work.
• They don’t know how to communicate their work in a way that’s relevant to the business functions.
• They treat data as a purely technical function, instead of a more business one. After all, a lot of data people went to the professions because they enjoy writing SQL, Python, or running ML models.

Over time, the business stakeholders get frustrated and start thinking about the data team as another ‘IT support department’.

​

First, what values do the business users get from my data work?

If we think from the business outcome perspective, then what you (the data analyst) do can be boiled down to 04 types of work:

Type 01: Serving reporting requests

Stakeholders need certain numbers or metrics, and the DA does the necessary work (and infrastructure preparation) to support this.

Sometimes you run a SQL query, pull that into an Excel file, chart it up and email it over to the business folks. Other times if the company has some self-serve analytics infrastructure (wink wink), you prepare some core datasets, give some training to the business user and they can just use the tool to get the data they need.

Either way, what the business needs are the same: they have a fixed metric/report in mind, and they need your help getting those numbers.

Type 02: Figure out how a business process should be modeled and measured (process modeling)

Business stakeholders need to find the right ways to think about/measure the effectiveness of things. And sometimes this is not an easy task.

“How should we measure the effectiveness of this workflow? What metrics should we pick? And how should we think about them?”

You’d see this so often everywhere. Funnels. AARRR. Growth loops. Cohorts. RFM Segmentation. These are well-known invented frameworks that you can just pluck into your business. But more often than not, your business process (or product functionality) is unique that would require proper thinking from the ground up.

In these cases, you would have to come in, work closely with the business counterparts to develop the right mental model (framework) that best represents the business process, and follow through with the end-to-end data implementation.

Type 03: Analyze why certain things happened (Diagnosis)

This is the type of work that most business users think data analysts do. Bad things happen - and people want to know why. “A lot of tickets are complaining about the performance, can you investigate?”

The sequence of steps is similar to types 1 and 2. But here, you are required to understand the context of the event and make hypothesis loops: Form - Test - Reform, until a possible answer and a recommendable course of action is found.

Type 04: Forecasting things (Prediction)

If type 03 is about understanding the past, then this is about guessing the future. Here you act as a soothsayer - forecast business performance, predict different decisions, and test them for success.

​

Lessons for the data analysts

The above classifications might be wrong or not optimal, and that’s fine. The more important message here is this — Data is as much a business function as it is technical, so always think about your work from a business outcome perspective.

When you regularly think about your work from a business value perspective, you get a subtle yet powerful shift in how you work:

1/ You know how to prioritize your work better for maximal business impact.
2/ You know how to communicate your work better to business counterparts.

​

Prioritizing data work for business impacts

Data people are usually technical people. And technical people tend to:

1. Prefer working on technically challenging work
2. Like to optimize things (efficiency mindset)

Naturally if given a choice, I argue data analysts would consciously (and subconsciously) use those two as criteria to design how their work roadmap looks like. While those still lead to productive work being done, they might not be best aligned with the company’s business outcomes.

Having a "think about how your work translate to the actual value for business users" mantra serves as a constant reminder to balance between your innate technical preference and the company’s business goals.

• You might relish the challenging nature of building tough-to-crack data models or refactoring a complex SQL query, but you are mindful not to get too carried away.
• You know you need to do manual data extraction for a business unit. It’s technically boring as hell, but visualizing the end business outcome in mind gives you a little motivation to plow through.
• And in an era where there’s a new data tool around the corner every month, the mantra will help you stay focused. Granted you’ll take a look, but you can decide when would be the right time to play around with them.

​

Communicating data’s work better to business counterparts

Imagine you (the data analyst) are tasked to build a dashboard to analyze the performance of the company’s customer support system. You present your work in a cross-functional meeting.

The old (technically inclined) you would have talked about it as such: “Here’s the dashboard to monitor how many tickets we receive over time and how fast we resolve them. There are these filters you can use. Took me a long time to get this done because I needed to write scripts to pull the numbers in, and modify the data pipeline to account for XYZ…”.

To the business teams in the back, you sound like a data service provider.

Reporting on your latest data cleaning project or how you revamp your analytics stack might sound fun - but mostly to you. To strike a chord with your business teams, you need to talk the business talk — It’s the language they’re comfortable speaking.

Now, the new you put on the business users’ goggles, thinking from the business users’ perspective. And things start to make sense to you:

• For the support managers who are constantly on monitoring duty, they’d need all 04 types of data work: reporting as requested, quantifying performance, diagnosis and prediction.
• To your management team, having a dashboard to monitor is a no-brainer. They want to know how effective or efficient things are, what the numbers mean, and where to go next - data work type 01 (reporting) is no longer enough. Types 02, 03, and 04 are where you get stakeholders’ attention. You need to explain how you model the process. You need to diagnose and share your insights. You need to predict.

​

---

Are you starting to see the power of this?

When you prioritize and balance the impact work vs technical work well, soon you no longer be seen as the technical guy _ doing _ technical stuff. People will start to appreciate your work’s timeliness and realize the actual business value you’re bringing to them.

When you see your work from a business value perspective, you are no longer the technical guy _ talking _ technical stuff (while business users yawn left and right in the background).

When you think and talk like a business user, you no longer sound like a data service provider — you actively participate in the business conversation and converse like one. You became an equal business partner.

And if you operate at this level long enough, people start to see you as a decision scientist, a thought partner, or an internal data-driven “management consultant” — one that helps them improve decision quality, and they’ll seek you out where the numbers speak.

And I think that’s where every good data analyst should strive to become.