~/rewind/chronosphere

Chronosphere (opens in a new tab)Case study · 2022 – 2023 · 7 min read

The best call we made was not to build it.

The feature we didn't build

A bold vision, GitOps for observability, met real users. My research showed who would use it and who wouldn't. The best call was to keep the useful patterns and skip the platform.

★ The futureEvery dashboard, monitor and rule changed through a Git workflow, inside Chronosphere
⏪ Rewound toWho is actually ready for that? A Git Maturity scale of our users
▶ Built forwardNot the platform, but its best patterns: history, diffs and code views
My role
Product designer, the only designer on the GitOps team
When
Sep 2022 – Apr 2023
Team
A product manager, an engineering manager, back-end engineers, a front-end engineer, and me
My part
Research strategy, interviews and usability tests, personas and journey maps, concepts and prototypes
What changed
We skipped the platform, and its patterns shipped: Version History and Code Config, announced Sep 2023 ↗
3personas, one overlooked
1scale that changed the plan
7stages, from clicking around to in-house platforms

01Meet Chronosphere

Observability at billions of data points a second

Chronosphere is a cloud-native observability platform built on the open-source M3, for engineering teams that need to find and fix problems fast.

Who uses it

Companies at every stage of their cloud-native journey, from startups to mature orgs with a dedicated Central Observability Team.

Why they love it

Granular control over what data is ingested, which helps manage the observability budget team by team.

02A bold bet, rewound

The north star: GitOps for observability

Our co-founders wrote a vision: give users a well-structured Git process inside Chronosphere, and it could solve real pain and become a competitive advantage. The GitOps team was formed to dig in.

  • Different entities, different formats. Dashboards were made in the UI, but critical aggregation rules lived in the backend.
  • View in the UI, edit in the backend. App developers could see changes, but saving them needed Terraform skills or the central team, with no Git review process.
  • Clutter. Abandoned experiments piled up in shared spaces.
  • Different needs. Central teams wanted visual feedback; app developers wanted the code.
A hand-drawn flow: find a dashboard, create a copy, make changes, preview, sync to Git, create a PR, review, deploy, and delete the draft.
Sketching the vision's flow: copy, change, preview, sync to Git, review, deploy.

03Who it's for

Three personas, including the one everyone forgot

Central observability team

Writes and manages observability code and rules. Needs scalable, replicable systems, visual feedback before code ships, and a clear record of what changed, why, when and by whom.

Site reliability engineer

Responds to alerts and tweaks monitors mid-incident. Wants more control with a small blast radius, and a safe sandbox to experiment, then save or discard.

Customer success overlooked

Usually forgotten, but critical to every launch. Wants to demo and customize on the fly, without wrestling with source code.

A customer success insightThey didn't believe Chronosphere should be known for its "Git" features, but saw that a smooth way to collaborate on changes could become a real marketing advantage.

See the persona cards
Persona card: observability owner on a central team, with background, responsibilities, frustrations, goals and a quote.
Persona card: site reliability engineer, with background, responsibilities, frustrations, goals and a quote about tradeoffs.
Persona card: observability owner who is a distributed engineer, with background, responsibilities, frustrations and goals.
Persona card: DevOps, with background, responsibilities, frustrations, goals and a quote.

04Research

One size does not fit all

I split the research three ways, to test the vision before we built it.

  • InternalThe vision doc, our assumptions, technical limits, and each entity's roadmap
  • With clientsPre-interview journeys, their observability setup, pain points, and how mature their engineering practices were
  • ExternalIndustry standards, and what teams did without a Git process
The harsh reality

Every company has a different setup. Every entity has different requirements. Every persona has different needs. One workflow couldn't serve them all.

05The turning point

I put our users on a Git Maturity scale

From click-ops to in-house platforms, every client sat somewhere on this line. Slide along it and see who would want GitOps inside Chronosphere.

How they work today

GitOps inside Chronosphere?

What would actually help

Rebuilt from my research board, without company names.

06The call

Keep the patterns, skip the platform

Git-mature teams

Already had Git, pull request reviews and pipelines. They didn't want a third party, even Chronosphere, owning their version control.

Teams new to Git

Didn't want to touch complex Terraform, and weren't ready for yet another layer of version control.

My recommendation

Don't build the full GitOps platform. Take what users did want, like seeing what changed, comparing versions and reading an entity as code, and turn it into patterns the rest of the product could use. The research I led shaped that decision, and it saved the company engineering time on a platform users wouldn't have adopted.

A diagram of GitOps: a code repository as one system of record, an automation pipeline, and Chronosphere's UI, API, Chronoctl and Terraform provider, next to other vendors.
What GitOps meant for us: one system of record, many ways in.

07Built forward

The patterns that lived on

I started designs for version history and code views before I moved on. In 2023, Chronosphere shipped them in public.

A concept for a monitor's Version History tab: a list of saved versions on the left, and a side-by-side, Terraform-format diff of two versions.
Patterns from the GitOps research, and where they appear in Chronosphere today
Pattern from our researchIn Chronosphere today, in public
What changed, why, when and by whomVersion History, Sep 2023: "users can now view and understand how monitors have evolved over time directly in the product." Chronosphere blog ↗
Compare versions like codeA Git-style diff between revisions, showing who made the change and how. Docs ↗
View in the UI, see it as codeCode config shows an entity as Terraform, Chronoctl or API, with a diff for unsaved edits. Docs ↗

The team built and shipped these after I moved on, so I can't claim every pixel. The research and early designs were where they began.

✦The future, rewound

What this story says about how I work

The receipts this story, in public

  1. Sep 2023Version History and Code Config are announced, the patterns we kept Chronosphere blog ↗
  2. TodayGit-style diffs and code views in the GitOps workflow docs Product docs ↗
  3. TodayVersion history, code config and code diffs on dashboards Product docs ↗

Research can say no

Testing a vision before building it is part of the design.

Find the forgotten persona

Customer success saw what the market would value.

Patterns over platforms

Keep what users want, and let it travel across the product.

Save the build

Not building the wrong thing is a result, too.

whoami // here I am

Senior title, staff-scope work. Looking for staff product design roles.

Complex, technical products are my favorite kind. The gnarlier, the better.

say --hi // let's talk

Liked this story? Ready to hustle together? Reach out to me. I'd love to hear what you're building.

Email me ✉