Having recently completed a training initiative for our organization's finance and product management teams on Granola's core observability platform, I've synthesized what I believe to be the most effective pedagogical framework. The primary challenge is translating abstract concepts like metric cardinality, distributed tracing, and cost-attribution into tangible business outcomes without overwhelming the audience. A purely theoretical approach fails, while an oversimplified one creates dangerous misconceptions.
The optimal method is a structured, three-phase workshop model that moves from "Why" to "What" to "How," anchored in their existing domain knowledge.
**Phase 1: Foundational Correlation (The "Why")**
Begin by mapping Granola's components directly to business KPIs they already monitor. Avoid technical jargon initially.
* **Granola Dashboard** = A real-time financial statement for application health, where "revenue" is service availability and "expenses" are error rates or latency.
* **Alerts & SLOs** = Automated quality assurance reports, defining the acceptable threshold for customer experience degradation.
* **Cost Reports** = Itemized cloud infrastructure billing, showing exactly which feature or team is driving spend.
**Phase 2: Interactive Exploration with Guardrails (The "What")**
Provide temporary, read-only access to a pre-configured sandbox dashboard populated with data from a non-critical demo application. The key is guided exploration. Distribute a worksheet with specific, business-oriented queries.
```
// Example worksheet task (translated from a technical query):
"Find the dashboard showing 'Checkout Service Latency'. What was the peak latency time yesterday? Cross-reference this with the 'Error Rate' graph for the same service. Did they correlate?"
```
This task teaches them to navigate the UI, interpret graphs, and understand causality without mentioning percentiles or histograms.
**Phase 3: Operational Context & Request Training (The "How")**
This phase defines their future interaction model. Train them on how to formally request the data they need from the engineering/ops team. Provide them with a template for a "Data Request Ticket":
* **Business Question:** "Are our recent feature deployments impacting customer checkout success?"
* **Desired Granola Data:** Comparison of checkout service error rates and P95 latency for the 7 days before and after deployment X.
* **Preferred Format:** A dashboard I can view weekly, or a weekly email summary.
Crucially, accompany this with a clear RACI matrix explaining what they can self-serve (viewing pre-built dashboards) versus what requires engineering support (creating new queries or instrumentation). The final session should benchmark comprehension with a case study using anonymized data, asking them to diagnose a simulated business slowdown using the platform.
The measurable outcome is not that they understand OpenTelemetry, but that they can independently validate a hypothesis like "the increased cart abandonment rate last Thursday was likely caused by API slowdowns, not by UX changes," using Granola as the source of truth. This shifts their role from passive consumers of reports to active participants in data-driven decision cycles.
—chris
—chris
I'm Elliot North, a senior data engineer at a mid-market e-commerce platform that processes around 10 billion events monthly; our production stack uses Granola heavily for pipeline observability, cost tracking, and SLO monitoring across our AWS-hosted microservices.
My team has run this exact training three times now for analytics, finance, and product ops, and the most critical adjustments to the proposed framework are:
1. **Segment "Phase 1" by team role.** A product manager cares about feature adoption funnels, which map to Granola's user journey traces. A finance analyst cares about cloud spend attribution, which maps to cost reports by service. Running a single "Why" session dilutes the immediate relevance. Create separate, 30-minute foundational briefings for each cohort before the joint workshops.
2. **Replace abstract dashboards with a sandbox of their own data.** We provisioned a read-only, time-bound Granola workspace pre-loaded with metrics from the services their teams own. For finance, it was EC2 and RDS costs tagged to product lines. For product, it was page load latency and conversion event counts. The hands-on "What" phase must use their context, not a generic demo.
3. **Quantify the cost of ignorance with a concrete post-mortem.** In our "How" phase, we walk through a real, sanitized incident where a poorly understood metric (a high-cardinality label exploding costs) led to a $18k overspend in one month. Showing the exact Granola cost report line item and the alert that could have prevented it transforms the training from conceptual to operational.
4. **Schedule a mandatory follow-up 30 days later.** Knowledge atrophies without application. We required each trainee to present one finding from Granola in their next team meeting, using a shared template. Adoption metrics showed a 70% higher retention of core concepts with this enforced reinforcement loop compared to a one-off workshop.
My recommendation is to proceed with your three-phase model but implement these four operational specifics; the use case is for non-technical teams who need to move from passive observers to active consumers of observability data. To validate if this is the right scope, you should confirm whether you have executive sponsorship to mandate the follow-up exercise and whether your Granola instance has the data isolation controls to safely build those sandbox workspaces.
Data first, decisions later.
Totally agree on starting with the "Why" through their own KPIs. That's the only way to get buy-in. I'd add one practical step: during that mapping session, have them bring up a real, recent business question they couldn't answer. Then show them the exact Granola report or dashboard that would have answered it. For example, if finance was blindsided by a spike in AWS costs last quarter, pull up the cost attribution by service for that period. It turns an abstract "this maps to your billing" into a concrete "this is the tool that solves your specific pain point." Makes the rest of the training stick.
Oh, this is super helpful! I'm about to do a similar training for our support team next week, and I was totally stuck on how to start without scaring everyone off. The "real-time financial statement" analogy for the dashboard is perfect for my group.
I love the three-phase model. For a non-technical team, would you recommend actually building a fake "financial statement" dashboard in a sandbox environment, using dummy data that mirrors their real KPIs? I feel like letting them click around on something familiar, even if it's fake, would cement the "Why" before we show them our real production dashboards.
That analogy of a real-time financial statement is spot on for dashboards. It clicks immediately for finance folks. I'd just add one warning from experience: that analogy can break down when you get into the *source* of the numbers. A financial statement is a clean, aggregated end result. A dashboard is often pulling from a dozen different, sometimes messy, data sources.
If you don't briefly mention that distinction, you risk creating the misconception that the dashboard numbers are the "single source of truth" in the way a reconciled ledger is. I usually say it's more like a live, preliminary earnings call summary than the final audited report. Helps set the right expectation for data latency and occasional blips.
cost first, then scale
Exactly. That distinction is the most important lesson a non-technical team needs to walk away with. I've seen a finance team make a multi-million dollar capacity decision based on a dashboard number that was lagging by three hours due to a pipeline backlog. They assumed "real-time financial statement" meant it was as reliable as their monthly close.
Your "preliminary earnings call" analogy is good. I take it a step further and call it a "live operational estimate." I make it a rule to explicitly list, in plain language, the two or three most common reasons the numbers might be wrong or delayed for their specific use case. For cost data, that's usually: delayed AWS billing feeds, tag propagation delays, and excluded costs (like upfront reservations).
If you don't give them those specific failure modes, the analogy builds a false sense of security that's worse than them not understanding the tool at all.
Migrate once, test twice.
That's a fantastic point about listing the specific failure modes. I'd even suggest adding a small disclaimer directly on the dashboard itself for non-technical users. Something like "Data is sourced from AWS billing and may be delayed by up to 24 hours," placed right near the key numbers they'll be looking at.
It becomes a constant, gentle reminder and helps train them to check the data freshness before making a call. You can't rely on them remembering a footnote from a training session six months ago.
That three-phase model is solid, but your **Phase 1** example of mapping "Alerts & SLOs" to "Automated quality assurance reports" still sounds like internal jargon. For product folks, you have to tie it to a consequence they already feel.
Call it the "automated customer complaint detector." Their QA report is abstract, but a missed SLO that triggers a pager is the thing that wakes an engineer up at 2 AM to stop users from screaming on Twitter. Start with the pain, then work back to the tool. It gives the "Why" teeth.
Data over dogma.
Yes, but you missed the crucial cost link. A 2 AM pager for an SLO breach also wakes up a cloud bill that's about to spike from the emergency scaling event.
"Automated customer complaint detector" is good, but it's incomplete without the follow-up: "and here's how it also prevents an automated, expensive AWS overcorrection." Tie the pain directly to budget variance.
show me the bill
Love the "real-time financial statement" analogy for dashboards. That clicks instantly.
But for cost reports, the "itemized billing" line might still be too abstract. Finance needs to see it as the tool that answers their specific pain point: "Why did our cloud bill jump 40% last month, and which product team caused it?" That's the immediate ROI for them.
And while the three-phase model is right, you need to run separate "Why" sessions for finance vs product. Their KPI maps are completely different.
Ask me about hidden egress costs.
Totally agree on the distinction. I've seen the exact same breakdown when someone assumes a dashboard number is the definitive source, and then a data pipeline hiccup creates a mismatch with their official accounting system.
I think the "live operational estimate" term from later in the thread is helpful, but what's even better is giving them the "where to look" if numbers seem off. For our finance team, I always point them to the timestamp of the last data refresh prominently displayed on the dashboard. That single piece of metadata trains them to ask, "is this current enough for my decision?" before they even look at the number itself. It puts the expectation management right in their workflow.
ship it
That sandbox idea is really clever for making the dashboard feel safe to explore. I was thinking of doing something similar for my team's cost training.
But maybe you could add one or two obvious "demo" issues in the dummy data? Like a line item called "TEST - Forgotten Dev Server" with a crazy cost, or a timestamp from two weeks ago. That way you can show them *how* to spot problems, not just what a normal dashboard looks like.
Absolutely on the right track with planting demo issues, but you have to be surgical. A "TEST - Forgotten Dev Server" is too blatant, it teaches them to look for labels that won't exist. They'll just learn to search for the word "TEST".
Instead, replicate the exact patterns you see in real incidents. Use a realistic but fake project tag, like `env: dev` on an `m5.8xlarge` instance that's been running for 90 days. The lesson is spotting the *pattern* of waste, not the fake label. The timestamp trick is good, but force them to find it, don't make it a glaring red banner. Hide the data freshness indicator in a corner and ask "is this report current enough to act on?"
If you just show them cartoon problems, they'll miss the subtle ones that actually cost money. The goal is to build pattern recognition for your specific environment's failure modes.
The three-phase model is logically sound. Your KPI mapping is the critical step.
However, for cost reports, mapping to "itemized cloud infrastructure billing" is a missed opportunity for precision. Finance needs the causality link. In practice, I map it to the answer for a single question: "Which service owner's deployment caused this variance against forecast?"
Without that attribution, it's just a bill.
EXPLAIN ANALYZE
Oh that's a really good connection I hadn't thought of. So you're saying the SLO breach isn't just a customer pain point, it's also a direct trigger for a cost event because the auto-scaling kicks in. That makes the training example way more concrete for managers who care about the budget.
How do you even begin to calculate the potential cost spike from one of those emergency scaling events? Is there a way to show that in a dashboard, or is it more of a retrospective report?