Before You Build, Make Sure the Brief Names the Real Problem

Editor’s note: This is the first piece in a 3-part Deckers mini-series. Deckers is the parent company behind UGG, HOKA, and Teva. We’re starting with the question that sat underneath this project from the beginning: was the brief naming the real problem? The Deckers project is the grounding case. The point is broader.
‍

This careers-site project started with a question that sounded practical, sensible, and responsible. At Insurgency, we’ve been around long enough to know that’s usually when we start looking for the problem sitting underneath the one everyone can already see.

"Can you build it?"

Usually, yes. The bigger risk is that everyone's about to build around the wrong assignment.

We saw that clearly on the Deckers project. The original ask looked contained: support the HR section of the site, translate supplied creative into responsive UX, handle the technical build, and account for analytics. Once the work started, it was obvious the brief was hiding bigger organizational and experience problems nobody had named yet.

The request sounds narrow, so the project gets framed that way. Then the real job shows up after the work already has momentum.
‍

The brief was smaller than the job

The Deckers assignment widened quickly. It wasn't only an HR section build. It touched culture, parent-brand clarity, and how a visitor was supposed to move through the experience. The brief described pages. The real assignment involved audience understanding, ownership, and how the site would live after launch.

If the people shaping the project know what they want to say but haven't worked through how the audience understands the company, who owns the experience, or what the inherited system can actually support, the team is walking into diagnosis work with deadlines attached.
‍

The useful questions sit upstream

Before the project turns into templates, QA, and launch dates, better questions need answers.

• What does the audience need to understand right away?
• Who owns the experience once the external team is gone?
• How maintainable does this need to be in real life, not in theory?
• What implementation constraints are already sitting in the inherited platform, access model, or handoff plan?

They're less glamorous than design review, but they do far more to decide whether the work holds together.

Deckers gave us a simple example. Someone could move from a brand site into the parent-company careers environment and wonder if they had landed in the wrong place. That kind of confusion isn't fixed by prettier layouts alone. Every handoff has a cost.

Other items that can land  in the same category:

• Maintainability:  If the site is supposed to improve the experience but the internal team still can't update it with confidence, the project has only solved the visible part.
• Implementation constraints: If backend visibility is limited, ownership is split, or the handoff model depends on several teams interpreting the work the same way, the brief should surface that early.

Absent of the above two examples, effort can come back later as delay, rework, or slow-motion confusion about what the project was really trying to do.
‍

Better questions change the quality of the build

That's why we care so much about the opening questions. The build inherits whatever the brief failed to settle.

When the right questions get answered early, the work gets clearer for everyone involved. The audience journey is clearer. Ownership is less vague. Maintainability becomes an operating decision instead of a polite afterthought. Implementation constraints stop showing up as late surprises.

When those questions stay fuzzy, teams still move. They just move with unresolved decisions baked into the work.

That's usually the moment to stop and ask the harder question: are we even solving the right problem?

The weak brief didn't stop at scope. On Deckers, it showed up next in audience confidence, because the last thing any company wants is a visitor feeling confused the moment they arrive. Coming up next is post 2 in this 3-part series, which gets into what happens when the click lands and the explanation doesn’t.