“What will you do with that?” = :-(

Remember back when folks wrote blog posts that were blah-blah-blah “best practice”-type posts? I think this is going to be one of those – a bit of a throwback, perhaps. But, hopefully, mildly entertaining and, hell, maybe even useful!

Let’s Start with Three Facts

• Fact #1: Business users sometimes (often?) ask for data that they’re not actually going to be able to act on.
• Fact #2: Analysts’ time is valuable.
• Fact #3: Analysts need to prioritize their time pulling data, compiling reports, and conducting analyses with a bias towards results that will drive action.

None of the above are earth-shattering or particularly insightful observations.

And Yet…

…I am regularly dismayed by the application of these facts by analysts I watch or chat with. (Despite being an analytics curmudgeon, I don’t actually enjoy being dismayed.)

The following questions are all variations of the same thing, and they all make the hair on the back of my neck stand up when I hear an analyst ask them (or proudly tell me they ask them as part of their intake process ):

“What are you going to do with that information (or data or report) if I provide it?”

“What decision will you make based on that information?”

“What action will you take if I provide that information?”

I abhor these questions (and various variations of them).

Do you share my abhorrence?

Pause for a few seconds and ask yourself if you see these types of questions as counterproductive.

If you do see a problem with these questions, then read on and see if it’s for the same reason that I do.

If you do not  see a problem, then read on and see if I can change your mind.

If you’re not sure…well, then, get off the damn fence and form an opinion!

Some More Facts

We have to add to our fact base a bit to explain why these questions elevate my dander:

• Fact #4: Analysts must build and maintain a positive relationship with their stakeholders.
• Fact #5: Analysts hold the keys to the data (even if business users have some direct data access, they don’t have the expertise or depth of access that analysts do).

How Those Questions Can Be Heard

When an analyst says, “What decision will you make based on that information?” what they can (rightly!) be heard saying is any (or all) of the following:

“You (the business user) must convince me (the analyst) that it is worth my time to support you.”

“I don’t believe that information would be valuable to you, so you must convince me that it would be.”

“I would rather not add anything to my plate, so I’m going to make you jump through a few more hoops before I agree to assist you. (I’m kinda’ lazy.)”

Do you see the problem here? By asking a well-intended question, the analyst can easily come across as adversarial: as someone who holds the “power of the data” such that the business user must (metaphorically) grovel/justify/beg for assistance.

This is not a good way to build and grow strong relationships with the business! And, we established with Fact #4 that this was important.

But…What About Fact #3?

Do we have an intractable conflict here? Am I saying that we can’t say, “No” or, at least, “Why?” to a business user? There are only so many hours in the day!

I’m not actually saying that at all.

Let’s shift from facts to two assumptions that I (try to) live by:

• Assumption #1: No business user wants to waste their own or the analyst’s time.
• Assumption #2: Stakeholders have reasonably deep knowledge of their business areas, and they want to drive positive results.

“Aren’t assumptions dangerous?” you may ask. “Aren’t they the cousins of ‘opinions,’ which we’ve been properly conditioned to eschew?”

Yes… except not really in this case. These are useful assumptions to work from and to only discard if and only if they are thoroughly and conclusively invalidated in a specific situation.

Have You Figured Out Where I Am Heading?

As soon as a business user approaches me with any sort of request:

• I start with an assumption that the request is based on a meaningful and actionable need.
• I put the onus on myself to take the next step to articulate what that need is.

Is that a subtle pivot? Perhaps. But, with both of the above in mind, the questions I listed at the beginning of this post should start to appear as clearly inappropriate.

The Savvy Analyst’s Approach

I hope you’re not expecting anything particularly magic here, as it’s not. But, no matter the form of the question or request, I always try to work through the following basic process by myself:

1. Is the requestor trying to simply measure results or are they looking to validate a hypothesis? (There is no room for “they just want some numbers” – given my own knowledge of the business and any contextual clues I picked up in the request, I will put it into one bucket or the other.)
2. If I determine the stakeholder is trying to measure results, then I try to articulate (on the fly in conversation or in writing as a follow-up) what I think their objective is for the thing they’re trying to measure. And then I skip to step 4.
3. If I determine the stakeholder is trying to validate a hypothesis (or “wants some analysis”), then I try to articulate one or more of the most likely and actionable hypotheses that I can using the structure:
   • The requestor believes… <something>.
   • If that belief is right, then we will… <some action>.
4. I then play back what I’ve come up with to the stakeholder. I’ll couch it as though I’ve just completed a master class in active listening: “I want to make sure I’m getting you information that is as useful as possible. What I think you’re looking for is…(play back of what came out of step 2 or 3).”
5. Then — after a little (or a lot) of discussion — I’ll dive into actually doing the work.

If you’re more of a graphical thinker, then the above words can be represented as a flowchart:

This approach has several (hopefully obvious) benefits:

• It immediately makes the request a collaboration rather than a negotiation.
• It sneakily demonstrates that, as an analyst, I’m focused on business results and on providing useful information.
• It prevents me from spending time (hours or days) pulling and crunching data that is wildly off the mark for what the stakeholder actually wants.
• It provides me with a space to outline several different approaches that require various levels of effort (or, often, provides the opportunity to say, “Let’s just check this one thing very quickly before we head too far down this path.”).

Are You With Me?

What do you think? Have you been guilty of guiding a stakeholder to put up her dukes every time she comes to you with a request, or do you take a more collaborative approach right out of the chute?