Start with the user.

It is the #1 principle when it comes to building products.  

It is the reason why companies like Google, Meta, Apple, Amazon, etc. have succeeded.

But does this principle of putting the user first, work for internal data & analytics teams as well?  Can this help centralized data teams build better products?  Partner more closely with the business?  And ultimately create models that allow for better decision-making. 

Our guest today, Kathleen Maley, thinks so.

To help us better understand why and how internal data teams can benefit from putting their users first, I interviewed Kathleen Maley, VP of Analytics Products at Experian.

Kathleen Maley is currently the VP of Analytics Products at Experian, where she is responsible for delivering productized analytics at scale and being the catalyst for changing the way we do data & analytics.

She is an analytics thought leader focused on sharing knowledge and best practices to improve the collective discipline of professional analytics.  She is passionate about helping practitioners (at all levels – from analysts, to leaders, to business owners) succeed, build great analytics products, and achieve their full potential.  

What follows below is a condensed and lightly edited version of our interview

Kathleen, thank you for being a guest.  Let’s start with some context.  How do data analysts build their data products and services today?

Kathleen Maley:  Mustafa good to be here.

This is a great question to start with.  In my opinion, the way we build our products and services is very much output focused.

For example, the majority of requests that come in are for some type of report that the business is requesting.  And the way it currently works is that the data analyst tries their best to gather requirements, understand what data is required, pull the data from various databases, and then put it in a powerpoint and ship it out.  

If it is a recurring request, they may create a more interactive dashboard.  But in most cases, the output is usually a report in powerpoint or word.  

Oh boy…I can see a whole slew of issues with that.  Tell me why this way of working is a problem.

KM:  Yes (laughs) it is a big problem.  For multiple reasons.

First, the focus is not on solving the business problem.  It is just about getting the report out.  Most analysts never dig deeper into why is this data needed, who is going to use it, how is it going to be used, and what decisions will be made by consuming the data.  They are simply missing the context.  For them, it is just about getting the report out as fast as possible.

Second, it is very technically focused.  The analyst spends way too much time making sure that they can access the data, build the proper pipeline, make sure it is clean, etc.  Which, don’t get me wrong, is important.  But the technical aspects of the job are just one part of the job.  Right now understanding the user and the need is less than 10%.  And that is usually in the form of understanding requirements.  Some teams I have seen now don’t even bother talking to the user, they just have them fill out a form.

Third, and this really bothers me, is that not all requests are the same.  Some requests require them to be almost like a consultant or investigator.  And data SMEs need to know the difference.  

For example, I was asked by the GM of Consumer Banking to analyze online vs. branch account openings.  The intent was to figure out how we can drive more digital openings.  This was not just creating a report.  For this I had to go deep, not just understand why / how GM was going to use that data, but what was needed, and how we can predict the future.  That is very different from just creating a recurring powerpoint presentation.  

Kathleen, these seem like very common product issues as well.  Can I flip this around?  Is the business asking for data teams to be more business-oriented?  Become investigators?

KM:  Well you just highlighted the other challenge.

Yes, the business wants us to be more business-oriented, consultative, and investigators.  But they are also stuck in just creating a report for a report’s sake.

Let me go back to the Consumer Banking example.  After I was done with my investigation and analysis, I presented the information to the Head of Digital Acquisition.  After all, he was responsible for the acquisition and reported to the GM of Consumer Banking.  

And what I found was shocking. He treated the data as a reporting activity – a report his boss asked him to create, so he created it.

He never stepped back to see how the data in the report could help him do his job better or change his approach.  He was not able to consume that information and make business decisions.  To him, it was just another report, a check in the box of what his boss asked him to do. 

So sometimes, not all the time, data teams get hit from both sides.  Not just on how we build stuff but also on how it is being consumed.  

Wow…amazing.  The deck is stacked against you.  So tell me, how does having a user-first mindset actually help data teams be better?

KM:  For me, where the user-first mindset really comes into play when you need to understand the user or consumer of the data.  It’s what I previously mentioned as the first issue with how data teams build stuff.

It’s about understanding why is the data being requested, who is requesting it, who will consume it, how will it be consumed, how will it be used, what decisions will be made off that data, etc.  

Data teams sorely lack that skill set.  Right now it’s just about filling out this form, give me these requirements and we will build it.

We are not good at solving business problems, we are good at solving our problems.

You know where I am going.  How do you build this user-first mindset with the data team?

KM:  Well there are several ways.

First and foremost is the redefinition of the job.  It is not about delivering data to the client (internal business partner) who has asked.  But rather it is to help the client solve the problem they’re struggling with.

Second, is training.  Data teams need to think from a product/user perspective first.  And this does not come naturally to them.  For them to just think outside of themselves, put themselves in the user’s shoes, and walk in their life a little bit would be very helpful.

Third is, and this ties into both the first and second, it is more of an interviewing technique or better people skills.  There are some analysts that do ask the right questions.  But the way they ask the question can feel like it is an interrogation.  And no one wants to be interrogated.  So we need to be more empathetic and build our people skills.  This is what happens when you deal with data all day.  You lose some of that soft touch.  

The last one is overlooked by almost everyone.  Is around driving adoption.  We analysts were taught for a long, long time that if you demonstrate the value of your solution, the business is going to adopt it. That in fact is nonsense. Because it isn’t as easy as saying here’s your model, it’s going to produce this much benefit…and that is it. The business has to figure out how to adopt it.

And this has to happen in partnership. Adopting a model, for example, usually means rebuilding an existing business process. The analyst can help make sure the algorithm is coded properly in production, but only the business leader can rebuild the business process in which the model will operate. So even if it’s a great model with a ton of potential lift, does the business leader have the additional resources required to rebuild the business process? If not, even the most valuable model will just sit on the shelf

The adoption is a good one.  Most product people don’t think about that one either.  And it is so absolutely critical.

Let me switch gears for a minute….why?  Why go through the hassle of changing data analysts to be more user-focused?  What is the benefit?

KM:  Well the obvious answer is that the business is asking us to. Even when they don’t really know what that means.

But, for me, it really comes down to one thing….money.  By being user-centric, you can build better reports, dashboards, insights, models, etc. that lead to better business decisions and eventually lead to more money. Or any other outcome of interest! It could be better health outcomes, reduced relapse, higher school attendance – literally any outcomes the end-user is working to influence.

Isn’t that why we are all here (laughing)?

Makes sense.  One last question, where are you and your team in this journey from being order takes to being user-centric?

KM:  Are you asking about my team or most companies?

Both, actually?

KM:  Well, most companies are still very much stuck in the order-taking mindset.  It is slowly changing but not fast enough.  And the people who do want to change, don’t usually have a roadmap or a plan on how to change.

This stuff, as we talked about is hard.  It’s not natural or at least it feels unnatural.  It’s new to the team it’s new to the business.  It’s just new.  So most teams and individual analysts are very early in our journey.

As for my team, we are much further ahead in the journey.  And the reason for that is two-fold.  First I seek out data analysts who are predisposed… and second I developed my own training to teach them how to operate in a more consultative way and marry their technical skill with business mindedness

But I will add that not everyone in my team or even the larger company needs to get there.  I’m a big believer in leaning into people’s strengths. So some analysts are really great data engineers and really great programmers. I lean into that. Some analysts are more about the investigative process, and they have the consulting skills that we are really after.

So I structure my team accordingly.  The consultants are out in the front talking to the business and have client-facing responsibilities.  And the rest of the team, the data scientist, and the predictive modelers are the ones that build the solution.

And this bifurcation, of designing what to build and then building it is really important.  For example, I am great at designing, and doing consultative work.  But ask me to program and it would take me weeks.  Ask my best programmer to do the same, and they will have it done in days.

The same segmentation exists in building products too.  There is product discovery (i.e. what we should build) and then there is product delivery (i.e building it).

Anyway, Kathleen, it has been an absolute pleasure.  Thanks for being our guest.  

KM:  Mustafa, this was a lot of fun.  Thanks for inviting me.  Much appreciate it.