^{READ TIME: 5 MINUTES}

I went camping this past weekend on the Belgium/German border with my brother and some of his friends for his Stag/Bucks/Bachelor party.

Generally speaking, we were super disorganised for the whole thing, which wasn’t helped by the fact that the camping grounds were ultra primitive and basic — which I actually enjoy in a weird way.

One thing in particular we’d not brought with us was a power lead of any kind to help inflate our mattresses. We had the electric pump, but with little more than a one-metre long cord and no power solution in our designated camping area, we were in desperate need of an extension lead that could reach the single distant powerpoint.

We were staring down the barrel of a very uncomfortable weekend sleeping on the cold hard Belgium ground. We had a problem to solve.

Myself and one other member of the stag crew went hunting for a solution. We asked in at every single other campsite, “do you have an extension lead we can borrow?”

Every single one said no. They either didn’t have one, or weren’t willing to lend it to us.

We returned to our campsite feeling ‘deflated’.

The lady opposite us who had a killer camper van with every mod con — who had been the first person we asked and the first person to say no — noticed our enduring dilemma.

She came over to ask us, “what do you need the power cable for?”

“To inflate our mattresses” we replied.

“Ah! Why didn’t you say so?! Of course you can borrow mine for that! I thought you wanted it for the whole weekend!”

It hit me like a bolt of lightening. While asking every single person in this enormous campsite, we’d never communicated why we needed a power lead.

They couldn’t help us find the right solution because we hadn’t told them what the job to be done was!

👉🏼 Check out this famous story on “Jobs to be done” all about milkshakes.

This happens constantly in the data and analytics space. Stakeholders come to the data team with a fully formed request. "Can you build me a dashboard that shows X?" or "I need a report with these columns by Friday." They arrive with a solution already in mind rather than a problem to solve.

Data people are equally guilty. They take the request at face value, build exactly what was asked for, and ship it, thinking the job is done. Except it often isn't. The stakeholder may have gotten what they asked for, but it doesn’t help solve the problem they have.

Both sides here are failing each other. The stakeholder hasn't communicated what they're actually trying to accomplish. The data person hasn't asked. And so the real job to be done sits undiscovered somewhere in the middle and everyone wonders why the data team never adds any real value.

The result is a data team that stays permanently busy, but rarely feels like it's delivering anything genuinely useful. Sound familiar?

When you only tell someone what you want them to do, you are making two assumptions that are almost certainly wrong.

1️⃣ That you've correctly identified the best solution to your problem.

2️⃣ That the person you're asking has nothing better to offer.

The lady with the camper van could have helped us immediately if we'd been clearer. Instead, we burned an hour trudging around a campsite asking the wrong question. She had exactly what we needed. She just didn't know what we needed it for.

Your stakeholders are doing the same thing to your team every single week. And your team is letting them.

1. Make "what are you trying to accomplish?" the first question

Before any work begins, the data person's first job is to understand the outcome the stakeholder is working towards. Not the output they've requested. The outcome. What decision will this inform? What action will follow? What changes if they have this information versus not having it? These questions reframe the conversation from solution delivery to problem solving, which is where data people do their best work.

2. Train your stakeholders to lead with the problem

When requests come in framed as prescriptive solutions, push back gently and consistently. "That's helpful context. Help me understand what you're trying to solve for first." Over time, stakeholders learn that the data team gets them to better answers faster when the brief starts with the problem rather than the solution. That reputation is worth building deliberately and intentionally.

3. Never assume the requested solution is the right one

When a stakeholder asks for a dashboard, they think that's what they need. Often it isn't. Sometimes a weekly email summary does the job better. Sometimes a one-off analysis via excel is enough. Sometimes the question they're asking is the wrong question entirely. You can only see this if you understand what the actual job to be done is. Take the request seriously, but hold the proposed solution loosely until you've done your discovery.

4. Apply this inward too

This dynamic runs in both directions. When data leaders request support from other teams, from engineering, from finance, from the business, they need to communicate the job to be done, not just the task. "Can you give me access to this data set?" is a much weaker ask than "We're trying to understand why retention dropped in Q3 and we think this data set holds part of the answer." The second version invites collaboration and encourages thought partnership.

The principle is simple: lead with the job, not the task. Whether you're receiving requests or making them, the quality of the solution you get back is almost entirely determined by how clearly the real problem was communicated upfront.

We had an electric pump, a one-metre cord, and a willing neighbour the whole time. We just asked the wrong damn question.

Free resources:
Data Leadership Playbook · Data Career Compass · Data Leader Assessment

Tristan Burns
Find me on LinkedIn