The purpose of a data team is to support the business in achieving its goals. To facilitate that collaboration, most data teams set up an intake process for requests at some point. So far, so harmless.
But over time, this often leads to data teams becoming “ticket takers.” Slowly, but surely, they get further and further removed from the business, and tickets become the main — and eventually the only — way they interact with stakeholders.
Instead of partnering with business teams to solve problems together, they are now fully reactive. With this, the goal shifts from driving business impact to reducing JIRA ticket backlog.
The good news is, this can be fixed. In this article, we’ll walk through how to transition to thought partner, including tips for:
Understanding the business context
When the data team works as ticket takers, it creates several issues:
Issue #1: The data team’s impact isn’t maximized:
🔍 First, the data team is unable to help biz stakeholders proactively identify opportunities they might not have thought of
🎯 Second, data leads are unable to prioritize and focus their resources on the highest-impact opportunities
Issue #2: The business gets lower-quality analytics solutions since the data team is tackling individual tickets instead of solving a problem end-to-end. Business stakeholders start viewing the data team as a service desk for data pulls and are less likely to involve it when it comes to solving more strategic problems
Issue #3: Data team members become demotivated. Handling a never-ending stream of tickets with no common strategic theme and unclear impact feels like Sisyphus pushing a boulder uphill
These issues all stem from the fact that in a ticket-taker model, business stakeholders assign tasks to the data team instead of asking them to solve problems.
In other words, the problem solving is done by the business teams in isolation, and they then approach the data team with what they think the solution should be.
This set-up is flawed: The biz team typically lacks technical understanding and the data team is missing business context, so neither is in a position to define the ideal solution to the problem.
To address these issues, a data team must evolve from a reactive ticket taker to a proactive thought partner.
But how do you get there?
Data team members need to have deep business context and empathy for the pain points of their stakeholders
There needs to be mutual trust and respect between data and business teams
The team needs to learn how to analyze and solve complex business problems
The data team needs to have a seat at the table
In this article, we will walk through how to succeed at each one of these points.
Requirement #1: Getting business context #
In order to be a thought partner to the business, you need to understand:
The company’s business model and strategic priorities, as well as
What your business stakeholders do — and care about — on a daily basis
Understanding the business model & company goals #
The company’s business model and goals provide important context for evaluating any opportunity that comes your way.
Example: Are more “supply hours” the solution?
For example, when I worked at Uber, there were teams in charge of growing the number of drivers on the platform, as well as the time they spend on the app (a metric called “supply hours”). Any analytics project that helps grow these “supply hours” might seem impactful at first glance. But once you consider how Uber’s marketplace works and what Uber is optimizing for as a company, things are a bit more nuanced.
As mentioned in our prior post on “How to make an impact in your first 90 days as a data leader”, a great way to understand the business model is to dig into the revenue equation and key drivers of the business. Let’s look at what that looks like in practice and how it can help you become a better thought partner.
At a high level, Uber’s goal is to make money, and it does that by 1) growing the number of trips on the platform and 2) increasing the fare per trip:
The number of trips is affected by demand (how many people are requesting a ride) and by how many of these requested rides Uber can fulfill. That’s where the supply comes into play: More drivers spending more time on the platform = higher likelihood any given request can be matched.
But here’s the catch: In order for a match to happen, the driver needs to be 1) online at the same time as the request, and 2) roughly in the same area (nobody wants a 20-minute pickup).
That puts things into perspective. The business doesn’t simply need more supply hours; what it really needs is more supply in times and places where there isn’t enough1.
There are a couple of things you can do with this new context:
When evaluating opportunities, you now know what metrics to look at
You can potentially help the team build reports and predictive analytics that help them balance supply and demand better across time and space
Without digging into the mechanics of the business, you wouldn’t have been able to do either.
Now, let’s look at the second part of the revenue equation. The higher the fare per ride, the more money Uber will make.
This sounds obvious, but it has some profound implications. For example, this means that when prioritizing initiatives, you should pay special attention to high-fare products like airport or premium rides (e.g. Uber Black) even when growing the high-volume “mass market” products might be easier.
Getting domain knowledge & day-to-day business context #
Even if you know what is impactful for the company, you can’t be a good thought partner to your stakeholders if you don’t understand what their teams do or the challenges they face.
Once you understand the status quo, you can:
Help improve it (make data more easily accessible, generate automated reports before important meetings, etc.)
Identify net new opportunities that can be unlocked through analytics and design custom solutions based on how the team operates
For example, you can only help the marketing team think through how an attribution model should work if you deeply understand the marketing funnel, the different types of campaigns, the tool stack, and the metrics the team is measured on.
You can get a good foundation by reviewing documentation. Internal wikis can give you an overview of how the team operates and what was done historically, while documents like roadmaps, RFCs (Request for Comment), PRDs (Product Requirements Documents) etc. are a great way to get up to speed on what the team is currently working on.
Once you have enough context, you can add additional questions and comments to these documents to start establishing yourself as a thought partner who is invested in learning more and providing proactive ideas.
However, if you want to be able to debate solutions as an equal, you need to integrate yourself and become an (informal) part of the team. That doesn’t mean that you have to officially report into that organization, but it means that you need to be in the flow of information and dedicate substantial time to learning the ins and outs.
Here are some concrete things you and your team can do:
Sit close to the team: Even just spending one or a few days a week in their area of the office will expose you to a lot of valuable information through ad-hoc conversations etc. It will also simply help build stronger relationships with your business partners
Ask to join select meetings: A lot of important discussions happen in meetings and never get documented. Joining weekly team meetings, standups, problem-solving sessions etc. can give you invaluable context you otherwise wouldn’t have access to.
Note: It’s hard to know in advance just how valuable a meeting will be; to avoid wasting time, pick the most promising one or two to start, join them for a few weeks, and then decide if you should 1) continue to attend, 2) try another meeting, or 3) claim your time back
Also, if your company uses an AI note taker, you can ask to get access to a summary instead of attending, which can save you a lot of time
Ask to be added to Slack channels & distribution lists: Most teams have Slack channels for group discussions and email distros for sharing updates and announcements. Make sure that you’re added to the ones of the teams you work most closely with so that you can stay in the loop
Encourage your team to do coffee chats with their stakeholders: Most business teams will be hesitant to have standing 1:1s with their data stakeholders because their calendars are already packed. But almost nobody will say no to a coffee chat or lunch. Besides strengthening relationships, they are a great opportunity to learn about what’s on people’s minds
Requirement #2: Building trust #
Becoming a thought partner to your business stakeholders is an evolution. In order for them to consider involving you in more strategic problem solving, you need to fulfill the basic level of your mandate first. For example, this means:
Being highly responsive and flexible in responding to the needs of the business
Doing a good job fielding their ad-hoc requests
Reliably maintaining dashboards & data pipelines
In other words, becoming a strategic thought partner doesn’t mean that you’ll stop working on ad-hoc requests or recurring tasks; it just means that you start engaging with your stakeholders earlier in the process so that you can together scope better analytics solutions (and eliminate some of the low-impact tickets).
Trust is best earned in small increments. So instead of directly asking to be involved in planning discussions and the scoping of all new projects, I’ve found it more effective to gradually evolve the partnership into a more strategic one.
Concretely, that means going from purely executing what you’re asked to recognizing patterns and proactively offering solutions.
For example, if you are getting repeated tickets about reconciling the number of leads between Marketing and Sales queries, you could propose a standardized leads metric to your stakeholders.
If your stakeholders are on board, you can then offer to create a source-of-truth dashboard based on this metric that both teams can reference. That way, you:
Proactively identified a recurring problem
Found a quick fix to address it, and
Provided a self-service solution so that the teams can dig deeper into metrics changes on their own.
If you do this consistently, it shows your stakeholders that you are taking ownership of the problems you’re exposed to. As a result, they’ll be more likely to think of you when new problems come up and pull you in sooner.
Requirement #3: Developing problem-solving skills #
For business teams, pulling the data team into planning and problem-solving sessions adds additional friction (since there are more cooks in the kitchen). So to justify that, your team needs to add value without slowing things down.
How do you do that? By analyzing problems and identifying pragmatic analytics solutions in a structured way.
To help you get started, we’ll walk through a framework that you can use to practice this with your team:
1️⃣ What is the true underlying problem? #
If your team members have been operating as ticket takers, they will have had little direct exposure to business problems. As mentioned above, the requests stakeholders put into tickets tend to be tasks with limited business context.
Acting as a thought partner means that instead of following detailed instructions, your team is analyzing problems and tracing them back to the root cause to identify suitable analytics solutions. This is a (new) skill set your team needs to master.
The easiest way to do this is to keep asking “Why?”
Let’s look at an example:
Let’s say your stakeholder asks you to build a customer health score…
If you ask them why they need it, they might explain to you that they are trying to figure out which customers Customer Success Managers should schedule monthly check-ins with
If you ask what the goal of these check-ins is, you might learn that the team is concerned about an increase in churn over the last few months and wants to take steps to address that trend
Armed with that understanding of the underlying business problem, you can now work with your stakeholders to define what analytics solution would be most impactful.
For example, before building any type of health score or predictive model, you could start with an investigation into the drivers of the recent churn increase to then come up with more targeted solutions based on what you find. A customer health score and early warning system for churn might still be the right thing to build in the long term, but your investigation could reveal more immediate things you can take action on (and potentially with less resource investment).
2️⃣ How often does this problem occur? #
When deciding on an analytics solution for a problem, there is usually a wide spectrum of things you could do.
By identifying how often the problem actually occurs, you can start to determine which solution may make the most sense. If you’re dealing with a one-off question from leadership, a simple ad-hoc data pull (and a slide summarizing the findings) might be sufficient.
If it’s an investigation the team is doing on a weekly basis, however, it makes sense to think about creating an automated and/or self-service solution so that you don’t have to repeat this task all the time.
The key is to not spend more time automating the task than you save from that automation. This xkcd cartoon is a good place to start when thinking about this:
3️⃣ How large is the expected business impact? #
In addition to finding better solutions for analytics problems, your team can also help prioritize which problems would be the most impactful to tackle.
This is where opportunity sizing comes in. With this kind of exercise there’s no need for perfect accuracy, so a rough back-of-the-envelope estimation is usually sufficient. You just need to know if one opportunity is bigger or smaller than others, not exactly how big it is.
Besides keeping it simple, the most important thing is that you size all of them in a common “currency” so that you can compare them (e.g. “$ revenue growth” and “$ cost savings”).
Granted, this doesn’t work for every project, but many other impact metrics (e.g. conversion rate improvements, time savings etc.) can be translated into $.
So, how do you actually size an opportunity?
There isn’t a single “correct” way to do it, but here’s an example to give you an idea of what it could look like:
Let’s say you work in a B2B SaaS company and are considering doing work on the data pipelines that power automated email campaigns. The goal is to increase the daily volume of emails you can send to prospective customers by 30% to book more meetings for the sales team.
You might not have experimental data for this particular change, but chances are that email volume fluctuated substantially in the past. To get a rough idea of how incremental volume might convert to meetings booked, you can plot these data points and see if there is a meaningful relationship. If it’s linear enough, you can keep things simple and assume it’s linear for the purpose of this directional exercise:
Based on this simple approximation, you can estimate how your conversion rate will change and how many incremental meetings you can expect to book. You then just need to apply a few assumptions (win rate, average contract size) to get a revenue estimate and compare it against other initiatives.
4️⃣ What are the minimum requirements and nice-to-haves? #
TL;DR: Done is often better than perfect.
A simple solution can often deliver 80% of the value to your stakeholders, and tackling the last 20% is not worth it due to diminishing returns. Your time is better spent bringing an additional project from 0 to 1.
What’s more, I have seen over and over again that stakeholders ask for a solution to a problem that’s pressing at the time, but when you deliver it, it gets very little usage because priorities have shifted.
One of the best ways to address this risk is to build a minimum viable product (MVP) to see if stakeholders will actually use it and find value in it, and then add more functionality or improve performance over time.
To do this, you need to understand what the non-negotiables are.
What functionality do your stakeholders need at a minimum?
Are there any thresholds in terms of accuracy/performance below which your solution won’t be useful for business teams?
5️⃣ How will this evolve as the company grows? #
In fast-growing companies, most of what you build will need to be overhauled regularly or it will become obsolete.
For example, attribution models will break if you don’t account for new marketing programs and channels that are being launched, or dashboards will show wrong data when metric definitions change.
Acting as a thought partner to the business means anticipating this and building your analytics solutions so that it’s easy to adjust them to changing business realities.
Note: This is not about anticipating every future requirement and building those features. Instead, it’s about building a “good enough” solution for the moment and making it easy to go back and iterate on it.
For example:
Using a data model instead of hard-coding metric definitions in dashboards allows you to define (and update) metrics once, so they populate consistently for everyone else
Assuming any set of entities (countries you’re active in, currencies, marketing channels, cost centers etc.) will grow by up to 10x over time, and structuring your code accordingly
Applying software development best practices like the use of Git / version control so it’s easy to evolve your data products over time and collaborate on them
6️⃣ Developing with your stakeholders #
Even if you analyze the problem thoroughly, there’s a good chance you’ll build the wrong thing.
For example, your stakeholders might have communicated their requirements poorly, or you might have misunderstood what they want.
The best way to avoid this: Involve your biz stakeholders from the beginning. Here are concrete steps you can take:
Start by shadowing your stakeholders’ workflows to understand the use case in detail. Ask them about their current pain points, data blind spots, and inefficiencies
For larger projects (e.g. building a model), write a spec and get feedback before you proceed
Mock up the user-facing components (e.g. a dashboard layout, or the output of a model that teams will receive) before you build the fully functional version. This way, you can test if it’s intuitive for non-technical users, and whether anything fundamental is missing or needs to be changed
Note: Current-generation GenAI models are good at mocking up UI components and can save you a ton of time – just make sure it’s actually possible to build what you mock up in the BI tool of your choice so you don’t overpromise to your stakeholders!
As mentioned above, build a minimum viable product (MVP) and see if it gets used before you make it fancy
Requirement #4: Getting a seat at the table #
Building mutual trust with your stakeholders and developing strong problem-solving skills is a requirement for being able to act as a thought partner, but it is not enough.
You also need to make tactical changes to how teams operate; in other words, you need to get a seat at the table for important work streams. If you’re not there, you can’t get context or provide input.
Let’s look at quarterly planning as an example, as that’s where a lot of analytics requests come up.
Most companies’ planning processes are dysfunctional. I have seen them at startups, growth-stage companies, and FAANG, and there is always a lot of friction. But even though it will never be perfect, you need to make sure you’re not setting yourself up to fail from the start.
Let’s say your company is a B2B SaaS business. Here’s what planning looks like for a “ticket-taker” vs. “thought-partner” team:
Planning as a ticket-taker team #
If your team is perceived as a “ticket-taker” team, here is how planning typically plays out:
Step 1: The business teams brainstorm analytics requests and assign them a priority
Step 2: They shoot that list over to you, the data team
Step 3: Based on the limited information you have, you do your best to estimate the effort for each request and indicate which ones you can resource
The result looks something like this:
In this example, you committed to resourcing the two projects with priority “P0” (both of them are estimated to be high effort). This means:
For the Customer Support team, you’ll build a model that predicts resolution time for incoming support tickets
For Sales, you’ll build a model that produces a running forecast of the number of leads and opportunities by the end of the current month
Based on your estimate, you didn’t have enough bandwidth to tackle any P1 projects.
The problem: You weren’t involved in coming up with the projects. You only reacted to the list and assessed whether you can resource the requests, not whether they are worth doing.
There is a high risk that the resulting analytics roadmap is not the ideal way to spend the team’s time (and isn’t maximizing business impact).
Now, let’s look at the same process with a data team acting as a thought partner.
Planning as a thought-partner team #
A team acting as a strategic thought partner needs to be pulled in earlier. If that doesn’t happen automatically, you need to push for a change in the process. The more you have already shown the value you can add, the easier this should be.
Armed with your deep understanding of the business, you should dig into the pain points the teams have before discussing any potential projects.
Sticking with the same examples from above, it would look like this:
Pain point #1: The Customer Support team wants to make better staffing and allocation decisions
The ticket backlog is growing and unevenly distributed across agents. That’s why they’re asking if you can build a model to predict ticket resolution times so that they can optimize routing and bandwidth management.
But when you do a simple analysis of the status quo, you realize that there are much more pressing issues. The Support team currently lacks a good understanding of what ticket volume to expect throughout the week, resulting in poor shift planning.
Judging from historical data, this should be fairly easy to predict, and a quick sizing exercise shows that it would be more impactful in reducing backlogs than a model that optimizes ticket routing.
➡️ By working with the Customer Support team to properly understand their pain point, you uncovered a higher-impact opportunity your team can solve.
Pain point #2: The Sales team wants to understand how many leads and opportunities they’ll end up with by the end of a given month
They are asking you whether you can train a ML model for this purpose.
You’re considering it, but when you take a quick look at past months’ data, you notice that a simple linear extrapolation would have landed, on average, at over 90% accuracy. If you apply seasonality for weekends etc., it would be even more accurate.
When you check with the team, you learn that this is sufficient for their use case. Great — you can deliver the simple linear extrapolation in a few days, before the quarter even begins.
➡️ The Sales team overestimated what was required to solve their problem. By scoping the solution together with them, you were able to find a simple fix and avoided spending weeks on a model that wasn’t needed.
So what changed by acting as a thought partner? Two things:
You avoided building the wrong thing for the Support team
The deliverable for the Sales team could be substantially reduced in scope
As a result, you can now resource an additional deliverable:
Checklist: Operating as a thought partner instead of a ticket taker #
Even after reading this post, “acting as a thought partner” can seem like a somewhat vague concept.
Are you maybe doing it already?
Where should you consider adjusting your approach?
For reference, here’s the checklist from beginning again:
It’s not a binary distinction. As discussed earlier, going from a “ticket taker” setup to being a thought partner to the business is a gradual evolution.
Hopefully, this guide provides you with some ideas on where to start.
Want more frameworks & news from our team? Subscribe to our newsletter to become omniscient 😉
1Now, you might wonder, “But what if the team is simply goaled on growing ‘supply hours’; isn’t it then our job to help them hit that goal?” I’d argue, no; a data team that acts as a true strategic thought partner would pose the question whether “supply hours” is the right goal metric, and work with leadership to develop one that more closely ties to business value.