Lessons from Yet Another PM Building Dashboards

Six months ago, I joined groundcover and quickly took the reins on Dashboards and Data Exploration. Coming from the security world, I had no idea how challenging building a data visualization platform in a mature market could get. The only thing I knew for sure? Great visualizations are critical in complex platforms like ours.

Turns out, it’s really complex. But along the way, we learned a few key lessons.

Taking the Hard Road on Purpose

In a world full of raw logs, endless metrics, and complex traces, dashboards are a breath of fresh air. Visualizations aren’t just nice to have - they’re how most of us make sense of vast amounts of data. We knew from the start that this was an area where we couldn’t take shortcuts.

Recap: We built the best eBPF-based sensor in the industry, layered it on top of a one-of-a-kind infra architecture, and that alone got some dogs howling at the moon. But to stay ahead in this well-established market, we needed a first-class o11y platform, a seamless experience from APM to Infra Monitoring to Logs and beyond.

That meant that from the moment groundcover was deployed, our platform was full of rich, real-time data collected by our eBPF sensor—data that’s often impossible to get from self-hosted solutions or vendors that require instrumentation.

For dashboards and alerting, we started with Grafana, embedding it into our platform, managing it with inCloud, and connecting it to ClickHouse and Prometheus.

Grafana is great. But we wanted more.

There’s a reason Grafana has 25M+ users worldwide & 66K starts on GitHub - it’s packed with functionality, has an incredible OS community, and many of our customers felt right at home using it inside our platform.

But here’s the thing: People expect more than just dashboards. They want an integrated o11y experience. One that’s fully native, fully configurable, and fully optimized for how they work. We wanted a single, seamless UX across our native pages, monitors, and dashboards.

More than that, using Grafana required our users to be familiar with PromQL and SQL. Even those who were familiar with the tech aspect, weren’t familiar with our schemas and optimizations. Some of our customers who migrated from other tools weren’t familiar with PromQL, which can be overwhelming. And without full control over the experience, we couldn’t make it truly groundcover-fine.

So, we set out to build something amazing.

Building It the Right Way (& the Fast Way)

We didn’t have six months to disappear into a feature branch and emerge with a polished dashboarding platform. That wasn’t an option. We believe in delivering value fast, so we had to move quickly, optimizing every decision based on customer feedback.

So, we did it the groundcover way:

• Short dev cycles (one week at a time)
• No bloated feature branches - every change ships fast
• Gradual rollout - starting with the smallest component and scaling up
• Constant feedback loops with our customers

Instead of “building dashboards”, we built the foundation first:

1. Query Bar – The backbone of our Data Explorer, Monitors Creation Wizard, and Dashboards
2. Data Explorer Page – Replacing Grafana’s Explore
3. Saved Views – Letting customers keep their queries
4. Dashboards – Saved Views evolved, laid out on a grid

This wasn’t just about speed, it was about maximizing user value. Releasing in quick cycles meant we could learn fast and iterate in days, not months. From day one, we had highly engaged customers helping us shape the feature. And just weeks after launch, we already had users who completely stopped using Grafana’s Explore, relying solely on groundcover instead.

That was addictive. It helped us push 50% faster while staying laser-focused on who we were building for and why.

From Zero to Dashboards in 12 Weeks

In just three months, we went from zero to fully integrated dashboards, sharing a Query Bar across the platform, blending seamlessly with the rest of our observability stack, and finally being able to tell our users: "We have something better. And we're just getting started."

The Query Bar

From the start, we believed that if we built an awesome Query Bar, most users wouldn’t need Code Mode. That assumption turned out to be right.

The Query Bar was the hardest part. We started with a minimal version for generating PromQL queries. After much debate, we decided to keep the UX lean - allowing users to generate 80% of their PromQL metrics easily, while the rest could be handled via Code Mode.

We intentionally didn’t invest much in Code Mode. This was a deliberate signal: the Query Bar was going to get really good, and we were fully committed to delivering a seamless UX.

Here’s how it started:

Later, we expanded the Query Bar to support Logs and Traces. But the real game-changer? Infra Metrics - a mode we’re especially proud of.

Infra Metrics is a curated set of key infrastructure metrics, hand-picked and pre-configured by us, so users don’t have to memorize every metric, its structure, or the best way to calculate, say, Container CPU Saturation Level. This feature highlights one of our biggest advantages over competitors: great Infra Monitoring out of the box.

Single Investment

From day one, the Query Bar was deeply integrated with the Monitors Creation Wizard, which meant we weren’t just investing in one feature, we were pushing on two fronts simultaneously. This allowed us to justify our efforts, even when things took longer than expected.

Once the Query Bar was in a solid place, we shifted gears and tackled multiple areas in parallel:

• Metric Summary Page (originally called Cardinality Explorer) - giving teams insights into their metric cardinality
• More visualization types to enrich the data experience
• Continuous improvements to the Query Bar based on user feedback

Adoption picked up, and the feedback was great. But what really mattered? Feature requests. They told us exactly where to focus our efforts, helping us maximize impact.

"Views" to Dashboards

We knew dashboards were the next step, but we started small. Instead of launching full-fledged dashboards right away, we introduced “Views” - a way for users to save their Explore page presets. But let’s be real: Views were dashboards from the very beginning. Adding a grid layout and allowing users to name them was all it took to make them feel like proper dashboards.

Then came the most exciting moment: we replaced the sidebar link to Grafana dashboards with a link to our Views page. And finally, we dropped the name Views and called them what they were: Dashboards.

New customers never knew there was a transition. They started using dashboards naturally during onboarding. Meanwhile, existing users picked them up fast, and adoption grew.

Not that simple, ha?

At first, we thought of dashboards as a “basic” feature set. But as adoption grew, we learned we needed to simplify them even more.

Most of our users are highly technical, but as we started reaching large enterprises, we met more people with less technical background in observability. We realized we couldn’t just rely on great docs or an amazing Customer Success team.

So now, one of our biggest priorities is making dashboards 100% self-explanatory, even for users who don’t know what metrics are or the difference between a Gauge and a Counter.

Future Plans

Now, we're in Phase 2: driving adoption and closing feature gaps while diving into the deeper layers of observability.

In Phase 1, we relied on ECharts for graphing. It worked. But now? We've hit a point where we want full control over our visualizations - so we're building our own graphing library, tailor-made for the way we think observability should work.

This isn't just about customization for customization's sake. High-level libraries served us well in Phase 1, but we knew they couldn't support the complex visualizations we're envisioning. Our obsession with details meant we needed control over every pixel - from custom legends and precise Y-axis padding to performance-optimized tooltips. Without this level of control, we simply couldn't deliver on our vision of deeply integrated, embeddable charts that scale seamlessly across the platform.

At the same time, we're focusing on features that drive adoption: Dashboard Catalog, LLM-based Migration Tools, and addressing specific User Requests. These aren't just checkbox features - they're strategic investments in making our platform indispensable.

The future of observability isn't just about building better dashboards - it's about reimagining what dashboards can be. Our vision has always been ambitious: dashboards aren't just visualization tools, they're the foundation for understanding vast amounts of complex data. Now that we've built solid fundamentals, we're shifting from catching up to leading innovation.We believe you shouldn't have to reinvent the wheel with every deployment while still maintaining complete control. That means enhanced sharing capabilities across dashboards, coupled with intelligent automation that helps you build visualizations. Because ultimately, this was never about just building dashboards - it's about creating an observability experience that helps you understand your data, spot anomalies, and find the needle in the haystack faster than you ever thought possible.

About the Author

Amir Sheffer is a Product Manager at groundcover, with technical roots in Linux kernel research and building startups. Before joining groundcover, he was part of Avalor Security, which was later acquired by Zscaler.

When he’s not obsessing over dashboards and observability, you’ll find him enjoying life’s simple pleasures: drinking wine with friends and taking long train rides while deep-diving into podcasts.