Why You Should Never Answer the First Question You’re Asked

The Core Argument

When a user asks a seemingly straightforward question—“how do I split a Perfetto trace into multiple files?”—the instinctive response is to give a direct answer. Maganti argues that the more valuable move is to pause, ask why, and explore the broader context. The first question is often a symptom of a deeper misunderstanding of the tool, a hidden workflow need, or a hint that the product itself should evolve.

Key Arguments

1. The First Question Is Rarely the Real Question
   • Users frequently frame their problem in terms of a specific action, but that framing masks the actual goal they are trying to achieve.
   • Treating the ask as a puzzle to decode (the classic XY‑problem approach) stops short of leveraging the conversation as a learning opportunity for both parties.
2. A Structured Diagnostic Checklist
   • Have I seen this before? – If the pattern is familiar, a quick answer may be appropriate.
   • Does the request make sense given the tool’s design? – If not, probe the user’s mental model.
   • Is the user fighting the architecture? – Identify mismatches between expectations and the system’s intended use.
   • This mental checklist guides the engineer toward the right follow‑up question rather than an immediate solution.
3. Three Typical Outcomes of the Follow‑Up
   • Missing Philosophy – Users often treat Perfetto traces as a universal metric source, not realizing that traces are heavyweight and expensive. By explaining the tool’s design philosophy, engineers steer users toward lighter‑weight metric collectors for routine data.
   • Hidden Path – Sometimes the product already offers a better solution. In Perfetto’s case, periodic trace snapshots replace the need for a single massive trace, eliminating the desire to split files.
   • Product Gap – Occasionally a request uncovers a genuine missing capability. The engineer must then weigh the cost of building it against the real, articulated need, often waiting until the problem is validated by multiple teams.
4. Case Studies from Perfetto
   • Trace Splitting: Users wanted to slice large traces, but the real need was for periodic snapshots. By redirecting them, the engineer solved the problem without adding a new feature.
   • Ad‑hoc UI Customisation: Early requests led to a tangled codebase. Recognizing the underlying desire for team‑specific UI extensions prompted the later development of a clean plugin API.
   • Trace Merging: Repeated requests were met with temporary work‑arounds until the team fully understood the use‑case, then a maintainable implementation was delivered.
5. Benefits for Both Sides
   • Users leave with a clearer mental model of the tool and often discover a more efficient workflow.
   • Engineers gain insight into where documentation, onboarding, or product design may be confusing.
   • The organization avoids premature engineering effort, reducing technical debt and focusing resources on truly valuable features.

Implications

• For Engineer‑Facing Teams: Adopt a conversational stance that privileges why over how. Embed the diagnostic checklist into support tickets and code‑review discussions.
• For Product Management: Treat repeated “odd” requests as data points indicating potential design blind spots rather than a backlog of feature tickets.
• For Users: When seeking help, be prepared to explain the broader goal, not just the immediate step. This accelerates the path to an optimal solution.

Counter‑Perspectives

Some may argue that the extra back‑and‑forth slows down support and frustrates users who simply want a quick fix. In high‑volume environments, the cost of additional dialogue can be non‑trivial. However, the long‑term savings from reduced mis‑use, fewer support tickets, and avoided feature creep often outweigh the short‑term latency. Moreover, teams can streamline the process with templated probing questions that capture essential context without lengthy conversations.

---

If this resonates, consider subscribing to the author’s newsletter or following the RSS feed for more reflections on engineering practice.