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.