ChatGPT
Perplexity
.png)
.png)
Build your first embedded data product now. Talk to our product experts for a guided demo or get your hands dirty with a free 10-day trial.
.png)
We spent a day at ProductCon last week, talking to product leaders who are building analytics into their SaaS products.
What stood out wasn't any single conversation: it was how often the same questions came up, from very different companies, at very different stages.
Here's what product leaders kept asking, and what we think those questions actually reveal.
This was, by far, the most common question. Not in the abstract, either. Product leaders would describe a specific friction: engineering built the dashboards, Product manages the roadmap, but Customer Success gets the complaints. Nobody owns outcomes.
The question sounds organizational, but it's really about accountability. When analytics is treated as a shared responsibility, it often means nobody is responsible for whether the analytics layer actually works for customers.
What we've seen work: a single team (usually Product) owns the analytics experience end to end. Engineering builds it. CS feeds back on it. But one team decides what gets shipped, what gets measured, and what gets improved. That clarity changes everything downstream.
This one came up more than we expected. Teams have already invested months (sometimes over four months, according to our own research) in building dashboards. They shipped. They got a brief spike in engagement. Then adoption flattened.
The pattern is almost always the same: dashboards were designed around the data that's available, not the decisions users need to make. The result is a reporting tab that looks comprehensive but doesn't actually help anyone do their job faster.
The fix isn't adding more charts. It's going back to the user's workflow and asking: what question are they trying to answer right now? Start from that, and work backward to the data.
Monetization came up a lot, but the framing was usually wrong. Teams would ask about pricing tiers and packaging (which are important) but the real bottleneck was always earlier in the chain: adoption.
You can't charge for analytics that nobody uses. And you can't get adoption if the analytics don't solve a specific problem for a specific persona. The monetization conversation always has to start with: do your users find this valuable enough to come back tomorrow?
Once that's solved – once analytics is part of how customers operate, not just a tab they check occasionally – the pricing conversation becomes much simpler. Premium analytics tiers work when users already experience the value of the base tier.
The build-vs-buy question hasn't gone away. If anything, it's getting more nuanced. Product leaders aren't asking "build or buy?" in a general sense anymore. They're asking: "We built something. It's not scaling. How do we migrate without disrupting customers?"
That's a very different question, and it reflects a maturity shift. Teams that tried to build analytics in-house are running into the same wall: maintaining a custom analytics layer requires dedicated engineering resources that could be working on core product features instead.
The conversation has moved from "can we build this?" to "should we keep maintaining this?" For most teams, the answer is no; but the migration path matters as much as the decision itself.
This was the enterprise crowd's version of the ownership question, but with higher stakes. In larger organizations, Sales is promising analytics capabilities in demos. CS is managing expectations on the ground. Product is trying to ship improvements on a roadmap that doesn't always match what Sales promised.
The misalignment isn't intentional. It happens because each team interfaces with analytics differently; and often, they're looking at the analytics capability through a different lens. Sales sees it as a competitive differentiator. CS sees it as a support issue. Product sees it as a feature set.
The teams that have solved this (and we've seen a few) did it by creating a shared definition of what "good analytics" looks like at each maturity stage. Not a product spec. A shared language for what the analytics layer should do, who it's for, and how success is measured.
The simplest question. Also the hardest to answer in a hallway conversation.
But there's a pattern to what "good" looks like across the teams we've worked with. Good analytics is opinionated; it doesn't show everything, it shows what matters. It's interactive; users can filter, drill down, and explore without leaving the product. It's fast; both in terms of query performance and time-to-insight. And it's embedded; not a separate tab or tool, but part of the workflow.
That last part is what separates embedded analytics from BI tools. A BI tool is designed for analysts. Embedded analytics is designed for the person doing the work.
Every one of these questions points to the same underlying challenge: analytics is no longer a nice-to-have feature. It's becoming a core part of the product experience — and product teams aren't always equipped to treat it that way.
The gap isn't technical. Most teams can build a dashboard. The gap is strategic: knowing who to build it for, what decisions it should support, and how to turn that into something customers value enough to pay for.
That's the conversation we kept having. And it's the one we think will define how SaaS products compete over the next few years.
Luzmo is an embedded analytics platform built for SaaS teams. From drag-and-drop dashboards to AI-powered insights with Luzmo IQ, everything is designed to help your users make faster, better decisions — inside your product. Start your free trial →
All your questions answered.
Build your first embedded data product now. Talk to our product experts for a guided demo or get your hands dirty with a free 10-day trial.
