Fault tree analysis: how to use it in a PM interview

Fault tree analysis is deductive. You start at the known failure and work downward, branching into every combination of causes that could have produced it. This is the opposite direction from a fishbone diagram, which opens with a brainstorm of cause categories and works toward the problem. The directional difference matters in interviews: fault tree signals that you already understand the failure and are now making your hypothesis space exhaustive and auditable, not generating ideas.

Bell Labs engineers developed the technique in 1962 for the Minuteman missile program, where non-reversible failures demanded systematic proof that no causal path had been overlooked. The same logic applies to a 15% retention cliff or an AI feature satisfaction drop: you want to prove you have not missed a plausible path, not just name the obvious one.

The two gate types that matter

Every split in a fault tree is labeled with a gate that describes the logical relationship between a parent failure and its sub-causes.

OR gate: Any single sub-cause is sufficient to produce the parent failure. Most metric drops are OR trees. If DAU dropped 15%, that drop could be explained entirely by acquisition cohort degradation, or entirely by activation breaking, or entirely by the core loop deteriorating. You do not need all three to be true at once.

AND gate: All sub-causes must be true simultaneously for the parent failure to occur. AND gates appear in compounded system failures: a full outage might require both the primary database and the failover to be down at the same time. In interviews, AND gates are rarer but important for post-mortems on cascading incidents.

Getting this wrong is a tell. Candidates who treat a metric drop as an AND tree (implying multiple simultaneous failures are required) are modeling the wrong failure type. Start with OR, shift to AND only when the mechanism demands it.

When fault tree beats fishbone in an interview

Fishbone is the right opening when the cause domain is unclear and cross-functional brainstorming is needed. Fault tree is the right tool when:

• The failure event is clearly defined (a specific metric dropped on a specific date).
• You need to demonstrate that your hypothesis set is exhaustive, not just plausible.
• The question is an incident post-mortem where deductive rigor is expected.
• You are working with an AI product where independent failure branches (model, retrieval, product surface) need to be modeled separately before combining.

The sequencing rule: fishbone first if you genuinely do not know which category owns the problem. Fault tree when you know the failure and want to work the logic down. They are not alternatives for the same job.

Building a fault tree in an interview: five moves

1. Name the top event precisely. The top event is the failure as measured. Not “retention dropped” but “30-day retention fell from 42% to 36% for cohorts acquired in the last three weeks.” Precision here signals that you are modeling a real phenomenon, not a vague concern.

2. Draw first-level branches as OR-gated domains. Your first split should map to independently sufficient explanations. For a retention drop: acquisition cohort quality degraded, activation broke, the core loop deteriorated, re-engagement surfaces stopped working. Any one of these alone explains the top event. Label the gate.

3. Recurse each branch until you reach a testable leaf node. A leaf node is a specific, directly observable or queryable state: a funnel step’s conversion rate in a given date range, an error log entry, a feature flag state, a query returning a number. Keep branching until you can name a real data source that confirms or eliminates the node.

4. Identify your minimal cut set. A minimal cut set is the smallest combination of leaf-node failures that is both necessary and sufficient to produce the top event. In an OR tree, each leaf node is its own minimal cut set. Naming this concept, even briefly, signals genuine mastery rather than surface familiarity.

5. Prioritize one leaf node and state the evidence. Name which leaf node you would investigate first, why (timing overlap, available data, fastest to falsify), and what a positive result would imply for the branches above it.

Worked example: DAU dropped 15%

Top event: Mobile DAU dropped 15% week-over-week, starting Monday. Web and tablet flat. No marketing spend change.

First-level branches (OR-gated):

• Branch A: Acquisition cohort degraded. Users acquired recently churn faster, pulling the rolling DAU count down.
• Branch B: Activation broke. New users are not reaching the core value event, so they never return.
• Branch C: Core loop deteriorated. Existing retained users stopped returning.
• Branch D: Re-engagement surface broke. Push or email is not pulling lapsed users back.

Recurse Branch B (activation), because a Monday deploy is in scope:

• B1: Onboarding flow step-level conversion dropped (a specific step now has higher exit rate).
• B2: The value-delivery feature on day one has a bug (error log or feature flag state).
• B3: A permissions request now fires before value delivery, causing early abandonment (session replay or funnel data).

These are OR-gated: any one alone explains the activation failure. The minimal cut set for Branch B is whichever single leaf node is confirmed.

Prioritization: B1 is the fastest to query (pull step-level funnel for new users, segment by Monday as the breakpoint). If clean, move to B2. If both are clean, the timing correlation with mobile-only scope points back to a mobile OS or device-level change, not the deploy.

Strong vs. weak answer

The 2026 AI-product branch

For AI products, a standard four-branch fault tree misses the most common failure class in 2026. When an AI feature’s satisfaction score drops or task completion falls, the fault tree needs an explicit model layer branch alongside product, infrastructure, and user cohort branches.

A fault tree on “AI assistant satisfaction dropped 20%” would have OR-gated first-level branches: model causes, retrieval causes, product surface causes, user expectation causes. Recurse the model branch: hallucination rate increased (model update or prompt drift), latency spiked past usability threshold, context window overflow is truncating output, or a safety update changed output style. Recurse the retrieval branch: RAG index is stale, embedding drift has caused semantic mismatch, or the retrieval corpus was updated without revalidation.

PMs who draw this tree with the model layer explicit are demonstrating they can do root cause work on AI products without treating the model as a black box. In 2026, that is the deductive rigor interviewers at AI-first companies are rewarding. Feasibility is largely solved; the hard failures are now viability failures (inference cost makes the feature structurally unprofitable) and lovability failures (the model is technically correct but users have stopped trusting it). Both of those show up as leaf nodes on a well-built fault tree, not as vague hunches.

Use it, do not recite it

Announcing “I’ll use fault tree analysis” and then listing three hypotheses under one branch is not a fault tree. The value is in the gates (OR or AND, stated explicitly), the recursive branching to observable leaf nodes, and the termination criterion. If you stop at a high-level branch rather than a testable leaf, you have built a vague hypothesis list with a tree shape. Build the full structure, label the gates, name a leaf node, then prioritize.