Can you build a report for me...?

How many times have we, as system builders, developers and product owners seen this requirement in one of its many subtle guises? Me? I get these kinds of requests once or twice a week.

Here's the problem though, reports masquerading as requirements are actually a few steps removed from a potential real problem we could be solving.

The 5 why's and root causes

When our customers ask for reports, they are almost never asking for us to solve their root problem. We can help them along the path to figuring this out by employing the simple "5 Why's technique" first pioneered by Toyota. Here's an example apropos the theme:

Hey, can you build me a report that show's this data? Sure! I'll get right on that. (Just kidding, but this is where some people will stop asking questions and get down to coding. Let's dig a little deeper instead.)
1. Why do you need a report? Because I've noticed we aren't collecting full data for metric X.
2. Why do you need complete data for metric X? Because then we can know who's on our platform.
3. Why do you need to know who's on your platform? So that we can tell if we're missing clients who should be.
4. Why do you need to know if there are clients missing? Because we are leaking revenue, and suspect it's due to missing clients, and need a report to cross-reference our theory.

AHA! So thaaaaaat's why you want a report? Now, how about we partner up and find a way to proactively stop revenue leakage at the source instead?

...reports masquerading as requirements are actually a few steps removed from a potential real problem we could be solving.

OK, that was only 4 why's, but you get the picture. Obviously, a conversation like this with your stakeholders would necessitate a little more finesse to avoid you sounding like a broken record. The take-home message here is that stakeholders cannot always articulate a requirement in its most complete sense. Possibly due to their (completely understandable) lack of what is possible, their tacit knowledge of the problem domain, or simply their bias towards past success in solving problems.

When our customers ask for reports, they are almost never asking for us to solve their root problem.

It's our job as solution makers to get to the root cause and solve their problem decisively in ways that delight and surprise them.

Just what, exactly, are TPS Reports for?