Supercharge Data Product Adoption

A Quick Recap...

So far, we’ve covered a lot. Over the past 4 "how-to" guides, we’ve covered the following topics:

1. Delivering a data strategy has little to do with data and more to do with people and change (link to article)
2. Building out data communities and earning the trust of the business is a step most often skipped, but so desperately needed at all companies (link to article)
3. Defining use cases with clear business impact will establish meaningful executive sponsorship (link to article)
4. Performing data governance work activities without overwhelming your stakeholders will keep them active and engaged (link to article)

Most organizations go through these steps very informally or neglect them altogether and jump right into execution. Data products go unadopted when they do this, stakeholders get alienated, and data leaders lose their jobs.

This article intends to serve as a "how-to" guide for data leaders to ensure the strong adoption of their data products. A series of questions will follow sections to help you think about where you can tweak or pivot your data strategy to empower your data communities to drive tangible and measurable results with data.

So Now What?

By this time, if you've performed these steps appropriately, you have developed a very engaged audience that includes many members of your data community at various levels of seniority eager to adopt and use your data product that will solve their problem.

The best part, you KNOW that what you are building will 1) solve a problem that is universally agreed upon and 2) you have the requirements needed to ensure that what is built will meet the needs of this use case.

The problem is that people are likely so excited that they may be losing their patience.

But First, What is a Data Product?

Well, a data product is a product that is highly reliant on data to be successful. A data product serves a customer and drives some business outcomes.

Data products leverage many technologies such as flat files, APIs, dashboards, algorithms, enterprise software, alerts, AI & machine learning, etc. Too often is, the underlying technology confused with the product. For example, a business intelligence tool is a product, absent data with a discernable use case; it isn’t driving much value.

In many organizations, the most valuable data products are spreadsheets or clunky reporting solutions embedded into legacy tools, as they respectively advise executive and customer decision-making.

How Many People Should be Using Your Products?

The rule of thumb is that 10-20% of your organization should engage with you to build data products. The caveat is the industry you're in. So, if your organization has 1,000 employees, it’s likely that you will have 100 to 200 members of your data community. Depending on the use case being served, it should be adopted by those members of the data community.

Organizations such as technology-enabled services have even more data community members because reports are a proof point for customer value. Client facers and operations alike will begin assembling pieces on behalf of customers and executives, hampering organizational productivity. Whereas manufacturing companies will be closer to 10%, where few control the information and the flow of information is more formalized.

Ask Yourself…

1. How many employees does your company have?
2. What percent of your colleagues are part of the data community? 10%, 20%, or more?
3. Do you know all of the members of your data community?
4. Do you know what they want?
5. Do you know how they perceive the data team and data strategy?

Note: Many data leaders will spend a ton of time with data, but to get your products adopted, you need to meet with your stakeholders and get to know their wants and needs from a business lens. Breaking your organization down into a data community or many data communities will make it easier to meet their needs without alienating others.

Why Your Data Community Isn't Using Your Data Products

The data is "bad".

This is usually the first statement, but a data leader must unpack it. Does the data product solve their problem? Do they understand how the data is presented? Do they even know who you are? Do they trust you?

Data gets blamed for many other problems because it can't defend itself, and no one is genuinely responsible. Much easier to say that the data sucks, versus the data leader sucks.

The reality is that most companies by now have at least one business intelligence tool. However, talk to organizations using these tools and even business intelligence vendors. You'll find that adoption of these tools is modest at most companies (10-20 people), and only a few companies have hundreds of users.

Why?

It seems silly, but the feedback we hear is that “so and so selected XYZ technology, and it doesn’t solve our problem, so we won't use it.”

Another challenge we see is that data products are adopted by 2-5 people, who are very happy with the product. Generally, this is because the problem being solved is low-value. Data leaders get themselves into trouble solving complex, low-value problems. If people aren’t using your data products, it’s generally because they don’t solve a meaningful use case for a large enough community.

Ask Yourself…

1. Of the members of your data community, how many are adopting your products?
2. How many of the ones adopting your data products are using it daily, weekly, and monthly? Do you know what's driving their usage?
3. Of the members not using your data products, do you know what they want?

Pro Tip: Involve the data community members in your technology selection process. All too often, technologists or data leaders select the "best" technology without consulting the end user. This is a quick way to alienate yourself from your data community.

Crossing the Chasm

A popular book for product management folks is Crossing the Chasm by Geoffrey A. Moore?(link here). The book's punchline is that a user base is distributed into early adopters, detractors, and the early/late majority. Although it may feel differently at times, early adopters and detractors are a tiny population of your organization (let’s say 5% each). Getting early adopters (and detractors) is generally straightforward, but getting the early/late majority of people is extremely difficult.?

Getting Early Adopters is Easy

When you have a dashboard adopted by five people who love it and rejected by five people who hate it, you have likely not crossed the chasm. People are generally enthused about technology and probably like working with you. These are the easy wins. Lean on these early adopters to help you win over their peers or the late majority.

Getting the Late Majority is Difficult

Going back to my example from above. If you have 100 members of your data community and 5 of them use your data products, you have 5% adoption.

Not great.

How are you engaging the other 95 members? Are you speaking with them often? How can the data product evolve to serve their needs? Data leaders must spend enormous time here understanding their needs and wants. It’s a common miss across most data professionals who tend to spend more time with data than their colleagues.

Don't Worry About the Late Majority, and PLEASE Ignore the Detractors

The late majority will show up over time. It's mainly out of your control and the early majority will dictate your success. Also, it's worth noting that it's effortless to find detractors. Show them respect by listening to them at least once, but keep them from dissuading you if their feedback isn't actionable. I've found most detractors in my experience to have some personal agenda, a battle not worth fighting as it's on their time and their ruleset.

Ask Yourself…

1. Who are your early adopters?
2. Have you asked them to help you "cross the chasm" with their peers?

Note: No single person in a company can influence everyone, including your CEO. Even if the CEO is the founder, someone probably doesn't like them or would take pleasure in making their lives harder. You can build your network internally to increase your sphere of influence. By doing so, people will see value in what you do and how it impacts them.

What is the ROI of your products?

A data product should have revenue or, more likely, reduce costs. What’s the ROI of the XYZ dashboard at your organization? New insights? If a dashboard doesn’t have an ROI, how will a data leader know what’s important? If everything is important, nothing is important. To determine the ROI of a dashboard, one must look at all the use cases the data product solves versus the cost of the underlying solution architecture, including staffing.

For example, if the use case being solved generates a $1M cost savings annually, the software cost is $500k, and the team supporting it is another $500k, the ROI here is effectively zero. If the organization has $10M of use cases solved by the same data solutions architecture outlined above ($1M), the ROI is quite good (10x).

If you don’t know the ROI of your data products, it’s probably negative. In this case, it may make your role as a data leader indefensible; at the least, you may lose credibility.

A data leader should be able to raise their hand in the board meeting and say before we spend $100M to buy a company with a 20% return on investment, I can get the organization a 50% return on investment on a $5M project and here are the associated risks.

This exercise can expose where you have expensive solutions relative to others. Look at each data product you are managing. Calculate the number of ACTIVE users versus the licensing cost. If you're paying thousands of dollars per user, you may need a different solution for the use case you're solving for.

Ask Yourself…

1. What are the costs of your data products?
2. What are the benefits of the use cases your data products solve?
3. Do you know these numbers?
4. Are these numbers universally accepted?

Note: Everyone at the company is accountable for growing the bottom line. Data leaders have been exempt for years because data has been a source of innovation for most companies. You will go far if you can demonstrate measurable business impact with your data program.

In Closing

We've covered a lot. From communities to use cases to glossaries to dictionaries and, finally, to solutions, you can understand why people need clarification about data.

The amount of work to get a data product shipped is enormous. It requires intelligent people to do a hard and thankless job. Data products have high failure rates, and outcomes often need clarification.

As a data leader, simply bringing clarity and purpose to the work that needs to be done that benefits executive leadership, the business, technology, and ultimately yourself is an invaluable gift you can give your organization.

I also know how hard it is to do. The grit, persistence, and will to get it across the finish line can be complex and thankless. Remember, it feels this way for almost everyone involved, so take time to celebrate others' efforts.

One day, I was walking past some offices in my building and saw a product I helped roll out on nearly everyone's screen. It's something that I am still very proud of, and it's probably one of my most outstanding achievements of the time.

The road to massive product adoption is painful, but stick with it because it will elevate you and others to a whole new level - there's no greater value you can give back to your community.

Best of luck in your journey, and don't hesitate to reach out!