A product manager pulls up a dashboard mid-meeting and the debate ends.
We had been talking for twenty minutes about whether a new feature should be prioritized. Opinions on both sides. The PM clicks, runs a query, flips the panel to a view they saved last month. The graph shows the answer. We move on.
This is not an unusual meeting. By 2021, it is every meeting.
What engineers always had
The component-level observability has been in place for years. SLOs per service. Latency histograms. Request traces that let you follow a single call across twelve systems. Error rate charts with thresholds. Per-service dashboards bookmarked by the team that owns each service.
All of this was built by engineers, for engineers. It reads like engineering. A latency P99 chart is useful if you know what P99 means. A trace flame graph is a debugging tool. These views answered operational questions – is my service healthy, did my change regress the error rate, where is the slow call in this request. The team who built the service read it and used it. Other teams did not.
The journey layer
What has matured is a different kind of dashboard. Not faster or prettier – different in what it is for. A dashboard organized around a user journey instead of a service: search, browse, cart, checkout, payment, confirmation. Each stage is fed by multiple services, but the panel does not show you the services. It shows you the stage.
The journey dashboard is not new; the idea has been around since the mission dashboard took shape a few years earlier. What is new is that there are enough of them, built well enough, covering enough of the business, that non-engineers read them.
The PM who wrote queries
A PM on my team taught themselves the query syntax. They found the exploration interface in the observability tool. They googled the functions, built their own views, saved them, shared them in chat. The first one was a panel showing how often a specific feature fired across regions, broken down by device. It was not a pretty dashboard. It answered their question.
After that, the same PM stopped asking me to pull numbers. They pulled their own. They filed tickets that cited graphs. They pushed back on engineering proposals with usage data. This is the kind of shift that is easy to miss – the PM did not announce it, they started doing it.
Other PMs followed. Business analysts followed. A finance person built a dashboard showing unit economics by request path. Our team has three distinct audiences reading graphs: engineers for operational checks, PMs to shape priorities, business to check the numbers that matter to them. The same system answering three questions.
What it changes
Arguments get shorter. A debate that used to be opinion against opinion becomes a question of “what does the graph show.” Sometimes the answer is “nothing yet, we are not measuring that,” which is its own useful answer. It forces us to name what we would measure if we wanted to settle it.
Roadmaps get leaner. Features that do not pull usage get cut sooner. Capacity asks get funded faster because the latency graph makes the case. The cost of a bad decision drops because the evidence arrives earlier.
Nothing about this is magic. The measurement costs to build and maintain. The tooling costs money. Teaching a PM to write queries takes time the first time. But the marginal cost of settling the next debate is low, and the marginal costs stack.
Remote work has helped. In an all-remote setup, the hallway is not there. A dashboard link with a timestamp is. The tool matured into something that works across time zones without a meeting attached.
We did not notice when observability stopped being a project and became how we talked to each other. It happened in pieces. A new journey dashboard, then a PM who learned query syntax, then a finance person with a bookmarked view, then a conversation that ended because the graph showed the answer. One day the graphs were a team resource. Another day, not announced, they were the shared language.
The ability to measure has mattered more than the engineering that enabled it. The engineering was hard. The language was harder to build. The second one is what I would invest in again.