Insights & updates from our experts
Product Metrics Decoded: Revealing Insights for Discovery

Most companies today compile a set of metrics for their product teams to regularly report on to the company management. This includes a variety of product performance metrics(usage frequency, churn rate, NPS, etc.). But a lot of them struggle a bit with product discovery activities. So how do you track discovery?
Here are a few ideas that you can try out:
- Tracking number of validated hypotheses
- Tracking number of invalidated hypotheses
- Problem-Solution Fit
- Product-Market Fit
- Iterations tested with users (a better spin on releases/deployments/shipped commits, etc), the thinking being that it takes multiple releases to validate or invalidate some hypotheses.
- Customer exposure hours
- Forgo NPS. Replace it with things customers actually have done, not something they might do in the future.
Do also remember that metrics are intended to indicate if things are going well or not. When you start giving numbers, people will try to associate that with some sort of outcome. So if number is high/low is that good or bad? My issue with some of these numbers is it isn’t clear to people outside of the organization as to what they mean. For example: If number of invalidated hypotheses is higher this time vs last time, does that mean you’re doing worse? I don’t think so, but it could be interpreted that way.
Metrics like customer experience hours, or interviews completed, or onsite visits become an easy thing to inherit as team or individual OKRs and an easy way to drive positive behavior. There are very few downsides and pretty high likelihood of positive cultural change when you increase customer touchpoints.
Looking for an end-to-end incident alerting, on-call scheduling and response orchestration platform?
Sign up for a 14-day free trial of Xurrent IMR. No CC required. Implement modern incident response and SRE best practices within your production operations and provide industry-leading SLAs to your customers

A Note From the Road: What SPARK Taught Me About Time
During the second SPARK event in Antwerp, I stood at the back of a training room and watched a customer build a custom integration with our new iPaaS, wiring Xurrent to another system in her stack that had never talked to it before. No services rep doing it for her. No statement of work, no project plan with a kickoff and a go-live date. Just a person with live beta access in her hands, connecting two systems by hand, and finishing it before her coffee went cold. A year ago that would have been a multi-week project with a budget attached. She looked up, a little surprised it had actually worked, and said something I have not stopped thinking about since. She said it just gave her her week back.

How Long Should ITSM Implementation Really Take in 2026?
Most vendors will tell you ITSM implementation takes six months to a year — but modern, configuration-first platforms have rewritten the math entirely. See what real implementations look like in 2026, and why a long rollout is now a choice, not a given.






.webp)





.webp)
.webp)














