Root Cause Analysis Series: when briefs do not deliver the real information, use Barrier Analysis to unblock marketing planning

What Barrier Analysis is and where it came from

Barrier Analysis grew out of safety engineering and risk management work led by the US Department of Energy, where engineers used it to explain how unwanted events occurred despite the controls in place. Something should have stopped this, and that thing either did not exist or did not work. The same logic was later adopted across industries that depend on layered controls before moving into product and marketing work.

When you apply it to digital product or marketing work, a barrier is rarely a physical device. It is information, a process, a person, or a shared understanding that should connect people and decisions but does not. In a marketing planning workflow, barriers include things like a structured discovery template, a customer journey document, an internal data source from sales, or a recurring cross-team review meeting. The framework keeps the team focused on what should have caught the problem, not on who happened to be in the room when it slipped.

How Barrier Analysis works (with an example)

Step 1: Define the undesired outcome

Example: The marketing team built a campaign on the wrong premise because the brief from a major enterprise client was interpreted incorrectly.

Step 2: List the ideal barriers that should have prevented it

The ideal barriers include input from operations and customer service about how the client actually behaves, a cross-team review meeting before planning starts, a current customer journey map, and a maintained buyer persona document.

Steps 3 and 4: Check whether each barrier is missing or failed, and why

This split matters because the fixes are completely different.

Missing Barrier: the control never existed. There has never been a structured brief form or formal discovery process, so what the team learns depends entirely on what the client happens to remember. The fix is to design and install the barrier from scratch.

Failed Barrier: the control existed but did not work. Cross-team review meetings happen but no decision maker attends, so the inputs carry no weight. Or a buyer persona document exists but has not been updated in 18 months. The fix is to repair the process or change the incentives that broke the barrier, not to add a second barrier on top.

In this case, the failed barrier pattern dominates. Teams holding the most useful information had no incentive to share it, and the basic data governance picture (who owns what, who updates what, who consumes what) was unclear across the company.

Step 5: Build an action plan for each barrier type

For Missing Barriers, roll out a structured discovery format like a Brief Canvas that asks layered questions in a consistent order, and name a single owner accountable for collecting the insight, not just running the form.

For Failed Barriers, train the relevant teams on data collaboration so each side sees what they get out of sharing, and rewrite the meeting rules so a decision maker is a required attendee. If decision makers are not in the room, the meeting does not happen.

Common pitfalls

Barrier Analysis looks simple on paper, but it goes wrong in predictable ways.

The first pitfall is skipping the split between Missing and Failed Barriers. Teams that do not classify the type often stack a new control on top of a broken one. The result is a process that looks more rigorous but still leaks in the same place. Every barrier you name has to be tagged Missing or Failed before any fix is designed.

The second pitfall is defining ideal barriers too loosely. Phrases like "we should communicate better" cannot be checked, owned, or built. A useful ideal barrier names the artifact, the owner, and the cadence. If you cannot point at it on a calendar or in a shared folder, it is not a barrier yet.

The third pitfall is using Barrier Analysis as a blame tool. The framework was built to look at controls, not at people. When the team interprets a Failed Barrier as evidence that someone underperformed, candor disappears and the next round gets sanitized. The right posture is to assume smart people working inside a broken control will produce the same outcome again.

The fourth pitfall is treating the analysis as one-and-done. Barriers decay. A persona that is current today is stale in 18 months. A cross-team meeting that works in a team of 12 fails quietly in a team of 40. Revisit on a cadence, especially after team growth, reorgs, or tooling changes.

The fifth pitfall is mistaking documentation for a barrier. A wiki page that nobody reads is not a barrier. A barrier requires an artifact, a moment of use, and an owner who notices when the moment is skipped.

Compared to other tools in the RCA Series

Inside the broader Root Cause Analysis Series, Barrier Analysis has a specific lane. Problem Analysis sits at the front as the 4-axis gateway that classifies a problem before any technique is chosen. Fact-Based Thinking is the layer that separates verified fact from assumption before analysis begins.

Against the other techniques, the picks are roughly as follows. The 5 Whys fits when you need to drill down a single chain of cause one layer at a time. Change Analysis fits when there is a clear before-and-after to compare. Fishbone Diagram fits when the problem is complex and likely has several parallel causes. FMEA fits before the problem occurs, when the team wants to rank risks proactively. Fault-Tree Analysis uses AND and OR gates to map combinations of factors. Parent Analysis asks what foundation should exist but never has. Management Oversight focuses on gaps in executive decisions that ripple into the operating team.

Barrier Analysis is the right call when communication and process exist but the result still falls short. It names which control failed or was never there, instead of relitigating who was at fault. It also pairs well with the 5 Whys. Use Barrier Analysis to identify which control broke, then run the 5 Whys on that control to find out why.

When NOT to use Barrier Analysis

Barrier Analysis is not the right tool when no process or communication exists in the first place. If a team has never had a structured brief, persona doc, or review meeting, asking "which barrier failed" returns nothing useful. Parent Analysis is the better start, because it defines what should exist at the structural level before any control can be measured against it.

It is also a poor fit for urgent firefighting that needs an answer within an hour. Barrier Analysis depends on cross-team interviews and a review of existing artifacts. Compressing that into a same-day exercise produces shallow conclusions. If the problem started right after a specific change, Change Analysis gets to the answer faster. And if the problem is a purely technical fault inside code, Fault-Tree Analysis or the 5 Whys are better suited.

Use case for digital product teams

Digital product teams use Barrier Analysis at several natural moments. After a Sprint Retrospective that surfaces a story shipped without complete Acceptance Criteria, the question is which barrier should have caught it first. The Definition of Ready may be Missing, or the Product Owner Review may exist but be Failed because it gets skipped under deadline pressure.

Another common case is the Design-to-Engineering handoff. The barrier could be a Design Token Documentation that was never written (Missing), or a Design Review Meeting that engineers do not attend (Failed). For an agency like SUFFIX, Barrier Analysis is especially useful when client work depends on inputs flowing from sales, account managers, and the client's own teams. Most "the brief did not have what we needed" stories are about a barrier, not a person.