[Initiative]: Cloud Native Observability Personas

### Name

Cloud Native Observability Personas

### Short description

Develop a set of user personas pertaining to the Observability domain.

### Responsible group

TAG Operational Resilience

### Does the initiative belong to a subproject?

No

### Subproject name

_No response_

### Primary contact

Matt Young

### Additional contacts

_No response_

### Initiative description

Develop a comprehensive set of user personas specific to the Cloud Native Observability domain. By defining these roles—ranging from application developers debugging code to platform engineers managing fleet-wide capacity—we aim to provide a shared vocabulary for the CNCF ecosystem. This will enable project maintainers to better target their documentation and tooling, and help end-users understand which observability signals (metrics, logs, traces, profiles, …) are most relevant to their specific role and objectives.

Problem Statement As highlighted in the [CNCF Observability Whitepaper](https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md), the audience for observability is multidisciplinary: Site Reliability Engineers, DevOps Engineers, Sysadmins, Software Engineers, Infrastructure Engineers, and various stakeholders all consume observability data.

However, a "one size fits all" approach to observability fails at scale. An application developer needs high-cardinality traces and profiling data to debug a specific crash, while a cluster operator needs aggregated metrics to understand capacity. Currently, the ecosystem lacks a standardized definition of these roles. This can lead to mismatched tooling, cognitive overload, and communication gaps.

**In Scope**

* Conduct research and interviews with the CNCF End User Community to validate real-world roles.
* Define a core set of standard personas (e.g., App Developer, SRE, Platform Engineer, IT/Compliance) relevant to cloud-native observability.
* Map specific [Observability Signals](https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md#observability-signals) (Metrics, Logs, Traces, Profiles, Dumps) to the primary needs of each persona.
* Create a "Persona Matrix" identifying the primary "Jobs to be Done" for each role within the observability lifecycle (e.g., Triage, Root Cause Analysis, Capacity Planning).
* Publish the findings.

## Goals

* Establish a shared vocabulary for "Who is observing the system?" across CNCF projects.
* Provide a reference for CNCF projects to self-assess which personas their tools primarily serve.
* Help End Users identify gaps in their current observability strategy by mapping their team structures to standard personas.
* Reduce "alert fatigue" and "data overload" by curating and encouraging persona-centric dashboard and alert design patterns.

## Implementation Plan

**Phase 1: Research & Discovery**

* Leverage the existing work started in [TAG Observability Issue \#42](https://github.com/cncf/tag-observability/issues/42).
* Conduct structured interviews with End Users to identify challenges and wins in their current organizational structures.
* Specific questions to answer: "Who owns the alert?", "Who looks at the trace?", "Who pays the bill?"

**Phase 2: Definition & Mapping**

* Draft the Persona Definitions.
* **The Persona/Signal Matrix:** Create a mapping of signals (Metrics, Logs, Traces, Profiles) to Personas.
* Review with TAG Operational Resilience and TAG App Delivery for feedback.

**Phase 3: Publication & Dissemination**

* Publish the "Observability Personas" document in the TAG Observability repository.
* Present findings to the TOC and wider community (KubeCon maintainer track or similar).
* Work with CNCF projects (e.g., Prometheus, OpenTelemetry, Jaeger) to encourage adopting these persona tags in their documentation (e.g., "This guide is for \[App Developers\]").

## Resource Requirements

* Participation from TAG Operational Resilience members for reviews.
* Access to CNCF End User community for interviews/surveys.
* Collaboration with TAG Contributor Strategy for consistent persona formatting (if applicable).
* Technical writing support (community contributions) for the final deliverable.

## Timeline (draft, dependent on resourcing and level of community contribution)

* **Month 1:** Finalize survey/interview questions and reach out to End Users.
* **Month 2-3:** Conduct interviews and aggregate data.
* **Month 4:** Draft initial Persona definitions and Signal Matrix.
* **Month 5:** Community Review period.
* **Month 6:** Final Publication and integration into the Observability Whitepaper v1.1+.

## Additional References

* [CNCF Observability Whitepaper v1.0](https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md)
* [TAG Observability Issue \#42 \- Initial Persona Discussion](https://github.com/cncf/tag-observability/issues/42)

### Deliverable(s) or exit criteria

* Publication of the "Cloud Native Observability Personas" reference document.
* A matrix mapping Observability Signals to Personas.

### Tracking document for meeting and progress

https://notes.cncf.io/jo7UB6StQqGM98EOwTlJbQ

Start by reading the CNCF Observability Whitepaper and TAG Observability issue #42, then review the tracking document for current progress. Define the research questions and persona scope, map observability signals to each persona, and publish the reference document with the Persona/Signal Matrix as the completion criteria.

Written by the indexing model from the issue text.