Run a Better Observability Platform Conversation

An observability discussion often begins with dashboards, alerts, or a product tour. Those requests deserve attention, yet they rarely explain why an engineering group is looking now. A recent incident offers a stronger starting point. One operational story shows where signals appeared, where context was absent, who owned a next move, and which decision waited too long. Learn how a buyer works before anyone opens a dashboard.

Begin with a direct question: “During your last difficult incident, what took longest to understand or coordinate?” Give the SRE leader time to choose an example. Do not ask for every historical problem. One incident provides enough detail for an early conversation. Ask when the issue started, who first noticed a symptom, and which action followed. Listen for a sequence instead of a complaint. “Our tools are fragmented” has little detail. A story about an alert, a handoff, and a delayed rollback gives your team a specific moment to examine.

Follow the incident in order. Ask which signal arrived first. Ask where an engineer looked next. Ask which information was unavailable or hard to connect. Ask who needed an answer before a response action. These questions reveal more than a list of tools. They show a point where a person had enough evidence to act, or lacked enough evidence and waited. A platform review should center on one such decision point.

Consider a fictional practice situation. At Northwind Harbor, a fictional online retailer, a checkout slowdown begins at 10:08 on a Tuesday. An alert reaches an on call engineer at 10:10. The engineer checks application logs, sees increased failures, and asks a database team for help at 10:18. A database engineer joins at 10:31. At 10:42, both people notice a recent configuration change, yet neither knows whether a rollback would affect another service. An incident commander approves a rollback at 11:03. Service response improves at 11:12.

The useful issue in this fictional story is not a missing dashboard. The delayed decision sits between 10:42 and 11:03. Ask an incident commander which evidence would have supported a rollback sooner. Ask a database engineer which context was absent when handoff began. Ask an on call engineer which signal felt trustworthy and which signal needed confirmation from a second system. Answers create an evaluation question with clear limits. For example, a team might want to review whether one investigation view places service changes, database activity, and ownership context near a practice incident.

Avoid turning a story into an interrogation. Explain why a question matters. Say, “I want to understand where response momentum dropped, so we choose a review scenario tied to your process.” When a leader feels heard, useful details often follow. If an engineer says, “We spent time asking who owned a dependency,” ask how ownership is recorded and who updates records. An answer might point to a process gap, a data gap, or both. Do not assume software resolves either gap.

Invite people who hold different parts of an incident story. An SRE leader brings reliability goals. An incident commander recalls coordination choices. An engineer who received a late handoff describes missing context. A service owner explains consequences of a response action. You do not need every person in one meeting. Start with people connected to your chosen decision. Agree who needs to review a test outcome before technical work is scheduled.

Define success as an observable action, not a broad impression. “Show us a better platform” leaves room for a vague demonstration. “During a practice checkout failure, identify a service owner, view a related configuration change, and choose whether to escalate within fifteen minutes” creates a reviewable scenario. The buyer selects action and time target. Your team explains which data or access a test needs. If required evidence is unavailable, say so early and adjust a scenario together.

Keep a boundary between learning about a current process and promising an outcome. An account team should not promise a new platform will prevent future incidents or remove every handoff. Incidents involve people, systems, and decisions. A review tests whether a selected workflow becomes easier to investigate. The buyer judges fit with operational leaders. Precise language earns more trust than a broad claim.

Use incident details to plan a technical review. Write a trigger, first signal, missing context, delayed decision, people reviewing results, and next buying decision. In the fictional Northwind Harbor situation, a trigger is checkout failure. Missing context concerns a configuration change and a service owner. The delayed decision involves a rollback. Reviewers are an SRE leader, incident commander, and database engineer. After a practice review, they will decide whether a wider evaluation deserves planning.

Send this plan before a demonstration. Ask participants to correct facts instead of treating notes as final. An SRE leader might explain a handoff was slow because an incident channel omitted a service owner. This correction changes a review scenario. A scenario should reflect an actual point of friction, not an assumption from a sales call. A corrected plan also helps a new participant understand why an invitation arrived.

When a buyer requests a dashboard demonstration before sharing an incident, acknowledge their request and return to context. Say, “We will show relevant views. First, which recent incident should guide our review?” If no incident is available, ask about a planned operational decision, such as choosing an escalation path during a service slowdown. Avoid inventing a use case. A generic tour fills time without showing whether review connects to daily work.

Some teams resist incident discussion because details feel sensitive. Offer a fictional practice situation or a simplified sequence with names and customer details removed. Sensitive records are not needed for discussion of a handoff, alert, or response decision. Ask participants to choose a safe level of detail. Respect a refusal without pressing for material your team does not need. The goal is a shared test scenario, not an incident investigation.

Listen for decision words during early calls. “We waited for approval,” “we were unsure who owned this,” and “we did not know whether a change caused a problem” all point toward a useful test. Capture exact words in notes, then confirm your interpretation. Ask, “Was your important decision whether to roll back, or whether to page a database team?” Small distinctions reshape a demonstration plan.

Beware an easy mistake during a technical tour. An engineer asks to see alerts, then another person asks about logs, then a leader asks about incident coordination. A presenter answers each request in isolation. The session feels busy, yet no shared decision receives attention. Stop and ask participants to choose one response action from their incident story. Return other requests to a parking note with an owner and follow up date. A focused review gives each person a fair basis for assessment.

For a fictional practice exercise, choose an incident lasting less than ninety minutes. Write five times in sequence: alert, first investigation, handoff, delayed decision, response action. Ask a colleague to play an SRE leader. Begin with the incident question and ask only enough questions to identify a delayed decision. Place a fictional service owner on a review invitation, set a fifteen minute response target, and ask your colleague to choose a rollback or escalation action before your practice call ends.