In traditional enterprise reporting, the goal was to build durable, reusable dashboards as the strategic state. But we often hit a different reality: dashboard fatigue. Hundreds or even thousands of dashboards exist across teams, yet few people use them and even fewer understand them.

I wouldn’t simply call this as an execution failure. As leadership reshuffles and priorities evolve, variations in reporting are a reflection of business needs from different times, not always a bug.

Instead, I want to challenge the mindset of ‘strategic reporting’ in growth reporting. Growth reporting behaves differently, so different that it’s probably not meant to be durable in the first place. I would argue that growth reporting is FMCG like: high value, high urgency, highly contextual and low shelf life.

If I had to describe the current state of reporting in one phrase, I would call it almost useful. The dashboards are not useless but almost always fall short of being enough for any real action to be taken. No one described product discussions better than Andrew Chen:

Don’t get me wrong. The people who build dashboards are usually not incompetent. Some reporting is there to show where things are, without necessarily leading to an immediate action. That is still useful. No great investor makes an investment decision based purely on the news, but they still read the news.

Growth reporting, on the other hand, has a different job. It is there to validate whether an opportunity actually exists, or whether a growth assumption is true. And this is hard because growth is hard.

When the low-hanging fruit has already been taken, opportunities no longer sit in obvious places. They hide in small pockets across acquisition, activation, monetisation and retention. Anything that creates incremental value is usually new, specific, and contextual. Naturally, the thing we need to measure also becomes highly specific. This is why existing dashboards often fail, as they were built for a more stable version of the question. But growth questions mutate.

A simple example is lead quality. If we use a static quality metric, we may get a misleading result for leads that are time-sensitive. A lead may look low quality not because the customer was never interested, but because we did not act on it fast enough. In that case, lead quality is partly a function of time. The shorter the response time, the better the apparent quality. But if we apply the same logic blindly to a different type of early-stage leads, it may become counterproductive. Acting too quickly may feel pushy and turn people off. So even within something as simple as “lead quality”, the right metric depends on timing, channel, customer intent, journey stage, and follow-up action. Every meaningful tweak around channel, timing, targeting or onboarding requires its own reporting angle.

This is the almost-useful dashboard problem, where the data may exist, the dashboard may exist, the metric may even look sensible, but the exact context needed for the growth decision is missing. And in growth reporting, that missing context is not a minor detail; it is often the whole point.

This is why growth reporting is FMCG-like: high value, high urgency, highly contextual and low shelf life.

It may sound like I am arguing for even more reporting to be created, as if hundreds of dashboards are not enough. That is exactly what I am suggesting, but with one important tweak: reporting should be created quickly and killed quickly once it is no longer useful.

Around a decade ago, I was a big believer in self-service reporting and apps. I was excited by fast frameworks like R Shiny, Python Flask and Django. My team had some minor successes with this approach for a few years, until the momentum eventually stopped, both in my team and in the broader self-service reporting buzzword. The reason was simple. Compared with Tableau, the benefits in both time and value were still marginal. Yes, code-based apps were more flexible. But they also required very capable coders, and capable coders are always in high demand.

That was the first time I really understood what Peter Thiel meant by 10x.

R Shiny was better than traditional dashboards in some ways, but it was not 10x better as an operating model. It solved the flexibility problem, but not the cost problem. It still required too much technical skill, too much build time, and too much maintenance to serve the long tail of customised reporting needs. Recently, I experienced a case in first hand where extremely customised reporting connected to multiple data sources was created in one or two days by a junior analyst using Claude Code. That was my lightbulb moment.

This is exactly the use case where AI productivity gains can outpace the growing need for customised growth reporting. AI does not remove the need for good data foundations, clear metric definitions, or human judgement. But it changes the economics. It makes code-based custom reporting cheap enough and fast enough to be useful for reports that may only have a short shelf life. It is better reporting, created faster, and discarded with less guilt when it has served its purpose.

The 10x moment for growth reporting is here.

From here, the bottleneck is no longer whether we can produce enough customised reporting. The bottleneck becomes whether we are asking the right growth questions in the first place. And that is probably how it should be.