But I’m Not Measured on Business Value
If most executive leaders recognize the importance of data for making strategic decisions and running organizations profitably. Why is it so hard for data leaders to demonstrate business outcomes?
What is the metric for success for a data leader? Better data? What's that mean? In any situation, confusing expectations lead to unrealistic goals, leading to poor outcomes, leaving a data leader directly in the cross hairs for a problem that has existed for years before their tenure.
Data leaders should measure themselves on business value captured as a direct outcome of the data strategy. Because:
- You can only generate business value if solutions are adopted.
- People won't adopt your solutions if they don't feel a sense of ownership in the requirements gathering where there is a clear outcome and;
- People will only give you requirements if you solve a problem that's important to them.
The purpose of this article will help data leaders push past their conventional roles of building, maintaining, and deploying analytics solutions to value creators, business champions, and stewards of operational excellence!
The Role of the Data Leader
Stop making dashboards for executive leadership. Firstly, finance, specifically the FP&A team, primarily meets executive leadership's data needs. Generally, this is a data-savvy, intelligent, hard-working group of people who know how to link data to operational performance. They can cut it six ways from Sunday to tell a story to any audience and generally work weekends. Not to mention has the backing of the CFO, who is arguably the most credible executive at the company regarding data certification because they have a fiduciary and sometimes legal responsibility to publish accurate numbers. What executive leadership wants you to do is get data into the hands of the business.
Secondly, with the advent of SaaS technology, the business has now found a way to work around data teams to get enterprise software in the door to meet their departmental needs. The sales team doesn't need the data team to report on quota, the marketing team doesn't need the data team to report on pipeline, and the finance team can report financials by themselves. They can define their metrics and measure them without much support.
What is left for the data leader to solve? A lot. A former manager of mine always said, "Taylor, the best insights are found between functions." In fact, by bringing cross-functional teams to work together to solve everyday challenges, the data leader will find enormous opportunities to benefit their organization, as departmental hierarchies limit a team’s ability to collaborate effectively. I spoke to this in my last article on Empowering Data Communities.
The data team needs to be positioned as a value generator. However, in most organizations, the data team usually resides in technology and has many requests with undue urgency and ambiguous requirements. The problem with this model is that the perception of the data team is often poor, and the level of work performed could be more robust. Talented data leaders run from this model simply for the lack of appreciation.
In other organizations, the data team is a net new function. So there is much whitespace for the data team to work in, which is excellent but also makes their path to proving value much harder.
So how do you prove value?
Forget About Solutions and Focus on Problems
Have you ever been on a "one-version-of-a-something-or-other-truth project"?
How'd that go? Exactly.
Let's take the scenario from above where a technical team is getting inundated with data requests. The data team recognizes that they are meeting business expectations on report generation, and the problem identified is the amount of time it takes to write queries. Naturally, it would make sense to invest in a business intelligence solution to speed up this process. So the data team invests in business intelligence technology, and the problem worsens. Requirements for reports have become more complicated, and requests come in faster. The problem is now (n) times more complex and more expensive, of course.
Let's take the scenario from above where there is a newly minted data team. To establish credibility, the data team usually will pitch a 3 to a 5-year roadmap that will culminate with data transforming the business model. This roadmap will lead to a substantial one-time investment. It is unlikely that this team will produce an ROI and makes it to year five as the high sunk cost becomes indefensible each minute data isn't transforming their business model.
In both situations, the data leader is pitching a solution versus identifying a business problem that is solvable with data that produces ROI. It is paramount that the data leader can identify and align others to a problem that helps them grow the bottom line - which is unfamiliar territory for most data professionals, and that's OK!
How Organizations Measure Value
In my experience, there's more data thought-leadership on how things should be versus how things are and how to do them better. Two well-intentioned buzz statements that don't always do data leaders service are "data monetization" or "managing data as a strategic asset."
- "Data monetization" is generally associated with generating new revenues directly from data, which is a noble goal. However, this can become a distraction as most companies will not generate direct revenues from data. Data can make customer relationships stickier, but don’t expect it to transform your brick-and-mortar business. Outside of companies like Equifax, which sells data, or Facebook, which uses your data to sell advertising, most business models are unable to build compelling investment theses around selling data.
- "Managing data as a strategic asset." I hear this all the time. A pencil is a strategic asset, but I don't need a pencil strategy. Data is important. OK, let's move on. Guys, data isn't an asset. The GASB (General Accounting Standards Board) does not recognize data as an asset. Where data is assigned a monetary value on the balance sheet is usually during an acquisition when a customer list is classified as an intangible asset, it is worth noting that these intangibles are generally impaired an written off over time.
This matters because when a data leader communicates to an executive audience that they will "manage data as a strategic asset" or "monetize data," it's compelling but it’s hard to show why this matters. Say, "I have a data strategy focused on generating business value," and have that statement serve as a guiding principle and leave the buzzwords at home.
A common way organizations measure financial value is through a concept called enterprise value. A data leader can calculate enterprise value in numerous ways. Whether it's a multiple of revenue or EBITDA, discounted cashflows based on forecasted growth, or what is on a company's balance sheet - all organizations can be measured in the eyes of the market. I'll spare you the tutorial, but you can read more about it at Investopedia.
A data leader's goal should be to maximize the overall enterprise value of the organization. If this is too abstract, a data leader's goal should be to maximize the impact of the data strategy to profit. Cost cutting, revenue growth, quantified risk reduction, working capital improvements, and productivity improvements are all ways to improve profit. The challenge is that other than canceling technology contracts where they own the relationships and cutting their already overworked team, there are few ways for a data leader to make the organization more profitable.
So a data leader will need to source use cases outside of their function. To do this, you will need data communities to want to engage, which you can read more about in my previous article on Empowering Data Communities, especially on bringing clarity to a business problem.
So what is a use case?
Defining a Use Case
One of the most widely misunderstood words in the data space is "use case." To a software vendor, it's where their product can solve a problem. To a data leader, it's where a data product can solve a problem. To most everybody else, it’s meaningless.
A use case is a clearly defined business problem that data can solve. A use case must have business ownership and demonstrate measurable business impact, and a use case owner is therefore accountable for capturing business value for the use case.
Two things I'd like to point out are that the data leader under no circumstances can define a use case. If you find yourself telling the business what the problem is versus listening to what they want, you're in for a world of hurt. Remember, and this may sting a little, that the business has to work with you because they don't have other options, not because they necessarily want to. Secondly, the business benefit must be something the use case owner can deliver.
It's essential to have an owner here that's in the business because they are the ones who are going to give you resources for requirements gathering. They alone can have their teams put competing goals to the side to prioritize the data strategy. A use case owner is invaluable. It's a leader who dares to stick their neck out for you because they see the benefits that you bring their team. Reward them with clarity and impact.
When you and the use case owner present to executive leadership that you want to solve a business problem with data and you have the backing of the business, you will generally get a yes with a resource allocation. If executive leadership says no without a good reason, they are saying that data is unimportant to them and at least relative to other priorities.
Once you're able to open up the business's budget, other company leaders will want to kick the tires on your approach to see where you can help. Data leaders get into trouble by saying yes to everything, so how do you keep people lined up outside your door without alienating yourself from them?
Ask Yourself
- What are the current priorities of my team? Are they linked to making my organization more profitable?
- Am I working on problems the business cares about, or are they enjoying the free support?
- Is your business champion going to go to bat for you? If not, why? Take them out for virtual coffee.
Note: It's essential to take a possible use case at face value. A data leader cannot say if one is bad or good. Beauty is in the eyes of the business, and you need to help them advocate for what they already know.
Managing a Portfolio of Use Cases
Firstly, once you have one engaged business stakeholder, they're likely to come to you with dozens of problems packaged as one. It's up to the data leader to break "data" into smaller chunks of issues that the team can solve independently with a single architecture. For example, a team may want ten years of historical data for a client review while also having real-time data for what's in the process there are two problems here - each with its benefits. By breaking this data issue into two more minor use cases, you can generally identify a more significant benefit and simplify execution for your technical counterparts.
Secondly, now that you have the trust of one business leader, you will likely get others. You must break their community's challenges into more digestible chunks and attach business value. The challenge you will face here is that you want to avoid getting in between two business leaders to argue about priority. Align them as much as possible but anchor them to the value being produced. Whichever use case has the more compelling return, stand behind that in principle. Present the facts and let the executive team decide; otherwise, you may alienate yourself from both.
Ask Yourself…
- What communities are you serving? Do you have a champion actively bringing you new use cases? What other communities could you be serving?
- Is there an overlap in your portfolio of use cases? Where can you align communities to a joint problem statement?
- Does the finance team agree with the assumptions in the use case? Are these assumptions committed to the budget?
Note: Managing a portfolio of use cases is a great way to determine the priority of data needs while linking your efforts to business value. This process also gives your technical counterparts some breathing room because it will force the business to think about data differently.
Aligning Your Data Strategy to the Business Strategy is Always a Good Strategy
Is your data function a profit center? Probably not. I mean, it is, but it is likely in the not in the way you want it to be. Not being aligned to generating business value makes it hard to ask for staffing or solutions outside of one-off requests, which is frustrating and arbitrary. Take control now by spending more time with your colleagues - understanding their problems and advocating for them. Remember to write down (because people will forget) what's important to them and what you discussed so you keep traction.
What's powerful in this process is that executive leadership will see you bringing clarity to a problem that few understand and can execute. Additionally, executives will see you bringing teams and people together in new and existing ways. You're helping them achieve their goals. You will be rewarded with the resources you need so you can do more interesting things. Also, if you can influence your peers to work together without any formal authority, it's a tremendous soft skill that few possess. As a data leader, where failure is the norm, what a great place to practice. :)
Now that we have 1) built up our data communities with executive sponsorship and 2) identified use cases that the business wants to own, my next article will go into operating a model where you can deliver on these promises and maintain your relationships.
I wish you the best of luck in your journey.
