From Metrics to Meaning

On the surface, Voice Insights read as a dashboard problem. Users had operational and telephony metrics available to them and found the reporting hard to interpret, especially anyone who was not a voice or infrastructure specialist. Framed that way the brief writes itself: improve the dashboards.

The research said otherwise fairly quickly. Data was not the gap. The product was already exposing call success and failure rates, post-dial delay, SIP response codes, MOS, jitter, packet loss, latency, trunk signals, call detail records. What people were still doing entirely on their own was deciding whether what they were seeing was normal, what mattered most right now, where to look first, what was probably happening, what evidence backed that up, and whether the right move was to act, escalate, or keep watching.

So I stopped asking which metrics to show and started asking how the product could move someone from visibility to understanding to action, because a dashboard does not create value by exposing data. It creates value when it helps somebody decide faster with less ambiguity.

Personas were the wrong cut

Voice Insights served operations leaders watching day-to-day health, support and implementation users digging into specific issues, and telecom SMEs doing real root cause work. The obvious move is a persona-based approach, and it would have given us three segmented dashboard concepts and a lot of arguing about who the product was for. What the research showed was that the workflows were not actually siloed by role. Everyone was moving through the same progression, monitor then orient then diagnose. They differed in how deep they needed to go, not in what they were doing.

That let the team stop debating which persona owned the dashboard and start asking which decision stage a given surface supported and how much depth belonged at that stage, which is a far more useful question for design and engineering to work from.

The gap was in the middle

Monitoring was reasonably well covered. So was diagnosis, through call records, SIP codes, and quality metrics. The weak link was orientation, the step where you know something changed and still have to work out which trunk is implicated, whether it is inbound or outbound, whether the issue is isolated or widespread, whether it looks like signaling or media quality or capacity, and which piece of evidence deserves your attention next. That is the connective tissue between seeing and diagnosing, and without it people were left with raw signal on one side and detailed evidence on the other with nothing bridging them. The highest-leverage opportunity was never more metrics or nicer charts. It was helping people narrow the problem before they had to go deep.

Getting it into the plan

Generating signal was not the challenge on this project. The challenge was getting the signal into product decisions before roadmap and sprint plans hardened. Findings handed off as findings get reinterpreted downstream, and every layer of reinterpretation shaves something off: the problem gets simplified, the user need gets diluted, the reason behind the recommendation goes missing, and sprint planning moves faster than research integration.

So I wrote the research into shaped Jira epics and stories, each with the problem being solved, the user need, use cases, priority phasing, relevant metrics, and a release recommendation. Not to take prioritization away from product, but to shrink the translation cost so the trace from insight to requirement to roadmap stayed intact.

Where AI fits

Because this work sat next to broader Copilot ambitions, we had to be careful about what AI was for. The temptation is to assume AI can fix an interpretation problem after the fact. It cannot. AI can summarize, explain, and point, and none of that compensates for a sense-making experience that is not structured underneath. Without monitor, orient, and diagnose working as a connected workflow, an AI summary is just one more output the user has to evaluate. The framing that stuck was that AI should amplify clarity rather than substitute for it, which also meant it should not assign blame early, overstate root cause, or bury uncertainty.

The shift was from asking what data we can show to asking what decision this data needs to support.

That change is small to describe and it moves everything downstream. It changes how a team prioritizes, how they design, how they define success, and whether the person on the other end experiences the product as a pile of metrics or as something they can trust to tell them what is happening and what to do about it.