A team can agree that an application feels slow while disagreeing about which action is affected, when the delay happens and what evidence is available. Those differences change where an investigation should begin and who needs to help.
The first useful deliverable is a brief someone else can act on. Name the workflow, explain the impact, preserve what is known and identify the next decision. An unknown belongs in the brief when resolving it would change the investigation.
The brief below is a proposed intake tool. It extends the starting questions in my Teardown Stack and the inquiry prompts on this site. It is intended for the point where a reported problem needs an owner and an evidence-gathering step.
Begin with the affected work
“The application is slow” leaves the action open. “Opening the pending-order list delays the receiving team's next step” identifies work to investigate. At this stage, the complaint can remain qualitative. Record who reported it and what they observed; leave the duration unknown if nobody has measured it.
Describe what the person is trying to accomplish. What can they see or do when the action has completed? What happens to their work while they wait? Does the report concern a particular role, environment or sequence of actions?
Impact helps decide what deserves attention. A blocked task, a workaround and an inconvenience may require different responses. Record actual consequences separately from estimates of wider impact. If cost, frequency or affected population is unknown, identify who could establish it.
Record conditions and evidence separately
Write down when the issue was noticed and the conditions reported around it. Include recent releases, configuration changes, imports or workflow changes when relevant. A nearby change is a lead to examine; its timing alone does not establish the cause.
For each evidence item, note its source, context and coverage. A user report names the experience. A screenshot may preserve what was visible. A measurement needs its recorded interval and conditions before it can support a timing claim. Identify what each item helps answer and what remains open.
Keep explanations separate from observations. “The operator reported waiting after an import” and “the import caused the delay” carry different commitments. The brief should let another engineer see where the evidence ends and a hypothesis begins.
Copy the investigation brief
The editable template has eight fields. Fill them briefly enough that a colleague can read the record before choosing the next step.
- Affected workflow: The action, user role and environment; what successful completion means in everyday terms.
- Impact: The reported interruption, workaround or consequence; affected scope and the source of that information.
- Conditions and recent changes: When it was noticed, its reported pattern, relevant conditions and changes. Include the chronology and whether any relationship to the symptom is established or suspected.
- Evidence available: Reports, recordings, measurements or other records, with locations, context, coverage and access arrangements.
- Unknowns and competing explanations: Missing facts, hypotheses and anything ruled out, with the evidence and scope supporting that exclusion.
- Constraints and correctness: Permitted access, reproduction limits and behavior any investigation or later change must preserve.
- Owner and collaborators: Who owns the next step, who can confirm the workflow and who can provide evidence or access.
- Next decision: The question to resolve, the next observation needed and the point at which the owner will review it.
Leave unavailable fields marked unknown. Assign an evidence-gathering action where it matters rather than filling the gap with a convenient explanation.
An illustrative filled brief
The following scenario and records are invented to demonstrate the tool. They describe no client engagement, measured result or diagnosed fault.
- Workflow: A receiving operator opens a pending-order list after a routine import. Completion means the expected orders are visible and selectable.
- Impact: In this example, the operator reports waiting before selecting the next order. Frequency, affected population and business cost are unknown.
- Conditions and changes: The report concerns the sequence immediately after the import, and the operator mentions a larger list. Other times have not been compared. Dataset size, import behavior and release differences have not been verified.
- Evidence: An illustrative operator note describes the sequence; a dashboard image is available, but its relationship to the list-opening action is unspecified. No workflow timing record exists in the example.
- Unknowns: The location of the wait, its repeatability, the included measurement boundaries and whether the import is related.
- Constraints: Use an approved test setting and sanitized records. Preserve the expected order contents and selection behavior.
- Owner: An application engineer owns evidence collection; the receiving lead confirms the workflow and completion meaning.
- Next decision: Choose an observation that can locate the reported wait. Start by recording the action and completion in the approved setting and relating that interval to existing measurements. No implementation change has been selected.
The useful output is a specific next step with an owner. There is enough context to begin examining the report, while the cause remains open.
Move from the brief to the investigation
Choose the next action from the uncertainty that matters. If the sequence is unclear, confirm it with the person affected. If a relevant observation exists, inspect its context. If the existing evidence cannot describe the user's wait, define the observation needed before interpreting more results.
Use the workflow measurement contract when that next step requires exact start and end events, eligible attempts, completion signals and targets. Use the prediction record once there is a candidate change to evaluate. The brief gives those tools an actionable starting point.
At the review point, update what is known and choose the next action. A useful brief can lead to a better question, an observation plan or a supported change. Its value is that the decision and responsibility are visible to the people doing the work.
Source: my July 9, 2026 post on signals and decisions.
Related tools: The Teardown Stack · Workflow measurement contract · Prediction record.
Discuss a performance problem · Browse writing · Browse case studies