The question to ask before you build what someone asked for

“Can I get a dashboard with weekly signups by channel, split by plan tier, with filters for region and campaign?”

That is a request for a solution. Somebody arrived at it by reasoning backward from a decision they need to make, and somewhere between the decision and my inbox the decision fell off. What reaches me is the shape of an answer with no question attached.

So before I build, I try to ask some version of this: what would you do differently depending on what it shows?

Sometimes the answer is “nothing in particular, I just want to keep an eye on it.” That’s a real answer, and a useful one, because something you glance at weekly can be an email, and an email is far cheaper to keep correct than a dashboard with five filters that has to stay correct forever.

Sometimes the answer is an actual decision, and the decision is smaller than the request.

The dashboard with fourteen filters. Early on I got a request that arrived with a list of dimensions attached, and I did the obedient thing and put every one of them in. Fourteen controls across the top. All working. Genuinely correct. It was opened twice. When I finally asked what the person had been trying to do, the answer was that they wanted to know which accounts to contact that week. Which is a table. Four columns, sorted, no filters. I had spent a week and a half building the wrong shape of a right answer, because I never asked what happened after somebody looked at it.

Two requests, one number. At my last job, Product and Growth came to me within a couple of weeks of each other. Product wanted weekly actives by feature area. Growth wanted a funnel with an activation step in it. On the intake list they looked like two projects. They were the same number wearing different clothes, and the interesting part was that the two teams did not agree on what counted as active and had never noticed, because nothing had ever forced them to write it down in the same place.

That is most of the argument for standardizing KPI definitions in dbt models instead of inside each report. Not tidiness. The definitions are going to collide eventually, and it’s better for them to collide in a pull request than in a leadership meeting where two people are both holding a slide. (The platform that came out of that work is the case study on my home page.)

“Can you pull this for me” is often a different sentence. At a capital firm I spent a stretch documenting the warehouse and running short sessions on how to query it, and self-service adoption went up something like 60% within six months. What I noticed while doing it was how many one-off requests weren’t really requests for data. They were requests for confidence. The person didn’t know whether the table they’d found was the right table, or whether they’d embarrass themselves in a meeting defending a number they’d computed alone. If you only answer the literal ask, you stay the permanent middleman for a question that was never about you in the first place.

The catch is that asking badly sounds like refusing. “Why do you need this” lands as a challenge, particularly coming from the data person, particularly to someone more senior. Two phrasings that have worked better for me: “who’s going to look at this, and what happens after they do?” and the one I lean on most, “if this number comes back bad on Monday, what’s the first thing you’d do?” That second one makes people describe an action, and actions are much more specific than topics. People can talk in vague nouns indefinitely. Almost nobody can describe a next step vaguely.

There’s also a point where all of this turns obnoxious. Plenty of requests show up fully thought through, from someone who has already done this exact reasoning on their own time, and the correct response is to build it quickly and stop talking. Digging for a deeper motivation past that point is theater. Do it often enough and people stop bringing you problems and start bringing you finished specifications, or they skip you entirely and rebuild it in a spreadsheet, which is worse for everyone and much harder to find out about.

So the test I use is deliberately shallow. Ask once. Listen to the answer. If the answer contains a decision, build for the decision. If it contains a description of a report, build the report and get on with it. I’m not trying to catch stakeholders being wrong about what they want. Mostly I’m trying to catch myself being incurious about why they want it, which is a more common failure and a much cheaper one to fix.

The dashboard with fourteen filters is, as far as I know, still out there. Technically correct. Fully filterable. Waiting.