It’s Tuesday morning. You spent two hours yesterday pulling data from three different systems, pasting screenshots into a slide deck, and writing commentary you’re not sure anyone will read. You hit send on the "Weekly Product Update" email, a ritual as old as the project itself. A few "thanks!" trickle in. Then, silence. By Wednesday, you’re in a meeting and a VP asks a question that was answered on slide four.
Nobody read it.
We obsess over user needs for the software we build. We do discovery, we write user stories, we prototype, we iterate. Then we turn around and communicate our progress with the equivalent of a waterfall-era requirements doc: a dense, one-size-fits-all data dump that we push out on a schedule.
It’s time to stop treating communication as an administrative tax. Your reports, your updates, and your presentations are products in their own right. They have users, and they have a job to be done. If they aren't doing their job, you need to fire them.
Your Stakeholders are Your Users
Think of your key stakeholders not as an audience, but as users. Your Head of Sales, your lead engineer, the CEO. Each is a distinct user persona with a specific need.
The CEO doesn’t need a burndown chart. She needs to know if this project is still the best use of company capital. The lead engineer doesn’t need to see the MQL-to-SQL conversion rate. He needs to know if the API performance degradation is a priority for next sprint.
If you send the same report to both, it fails both.
Find the Job To Be Done
Before you build another dashboard, ask yourself the most important question: what decision does this report enable? What action does it drive?
If the answer is "to keep people informed," that's a red flag. "Informed" is passive. It’s a vanity metric for communication. You aren't trying to get your report read; you're trying to get it used.
Frame it like a user story:
- Bad: "As a stakeholder, I want to be updated on project progress."
- Good: "As the Head of Marketing, I want to see the daily sign-up rate from the new landing page, so I can decide whether to double down on the ad campaign."
The second one gives you a clear, testable hypothesis for your report. It defines the necessary data, the cadence, and the user. It tells you exactly what a "successful" report looks like: the user made a better decision.
Build a Minimum Viable Report (MVR)
You wouldn’t spend six months building a feature without user feedback. Why do you spend hours building a complex dashboard that might be useless?
Apply the MVP mindset.
- Start with a sketch. Literally draw the chart or table on a whiteboard. Or type three bullet points into an email. Send a screenshot to your primary "user" and ask: "If you had this every Monday morning, what would you do with it?"
- Ship a manual version. Forget automation. Send a daily Slack message with a single, crucial number. Does it spark conversation? Does it change behavior? If people start asking for it when you forget, you have product-market fit.
- Iterate based on pull, not push. Don't add a metric because you think it’s interesting. Add it because a stakeholder explicitly asks for it to make a specific trade-off. Let your users' needs pull the features into your reporting product.
Conduct "User Interviews" and Sunset Failures
Go to the people who receive your reports and ask them directly. Not, "Did you find the report helpful?" That’s a leading question.
Ask better questions:
- "When you got the update last week, what did you look at first?"
- "Did anything in it cause you to talk to someone or change a plan?"
- "What's a recent decision you struggled to make because you were missing information?"
The answers will be brutally honest. You'll discover that your beautiful Gantt chart is ignored and that everyone just wants a simple list of what’s blocked.
And for the reports that nobody uses