The scope plane: define what you’re building
 October 4, 2025 | Career

The scope plane: define what you’re building

How clear boundaries turn strategy into a plan your team can actually deliver

Scope is where strategy starts to get real.

You’ve aligned on the problem. You’ve got a clear outcome. Now you need to decide what you’re actually going to build — and just as important, what you’re not.

This is where teams start to spin. Someone adds “just one more feature.” Stakeholders chime in with ideas. Engineers want to future-proof. Designers want to fix five other things while they’re in there. Before you know it, the work bloats. Deadlines slip. The original problem gets buried.

The scope of the product is directly influenced by the strategy behind it.

— Jesse James Garrett, The Elements of User Experience

You can’t define scope in a vacuum. It’s the bridge between why you’re building and how it’s going to work.

When you do it well, scope brings clarity. It gives the team something solid to build on. It helps you say no to distractions and yes to what matters.

In this article, we’ll break down what the scope plane is, how to define it, and what tools, skills, and habits help teams stay focused.

What the scope plane is.

The scope plane is where you define the boundaries. What’s in, what’s out, and what it all needs to do.

It sits between strategy and structure. You’re not designing yet — you’re getting specific about the functionality and content that will support the user and business goals you already defined.

Jesse James Garrett breaks it into two parts:

  • Functional specs — What features will the product include? What behaviors and interactions are expected?
  • Content requirements — What types of information need to show up? Think descriptions, media, help text, or supporting materials.

It’s the same layer where Melissa Perri sees teams slip into what she calls the “build trap” — shipping features with no real connection to user or business outcomes. Getting clear on scope helps you avoid that pattern.

This is the layer where trade-offs happen. You balance user needs with business objectives. You say no to things that don’t serve the strategy. And you write things down clearly so the whole team knows what’s being built.

When teams skip this layer or treat it like a wishlist, things get messy. Scope creeps. Decisions get revisited. Structure and design suffer. But when the scope is clear, the rest of the work gets a lot smoother.

How to work in the scope layer.

Working in the scope layer is all about turning a clear strategy into a focused plan. You’re not solving every problem. You’re deciding which problems to solve right now — and how much of the solution belongs in this phase.

Here’s what that looks like in practice:

Use your product outcome and problem framing from the strategy layer to guide scope. What features or content are required to support those goals? What’s a stretch? What’s not needed?

This isn’t just a to-do list. It’s a filter.

If you need a system for this, Teresa Torres’ Opportunity Solution Tree is one of the simplest frameworks out there. It helps you connect outcomes to opportunities, and lets your scope grow from the right place, not just from stakeholder input.

Your team wants to help users stay on top of upcoming bills.

✅ In scope:
Add a “Scheduled Expenses” view in the budget, pull data from connected accounts to show expected bills, and let users manually add recurring expenses.

🚫 Out of scope:
Auto-categorization, long-term forecasting, notifications.

The scope here is tight. It solves one problem now and leaves room to expand later.

Your team wants to make it easier for users to find top-used features.

✅ In scope:
Update the global nav, move high-use features to the top level, and validate changes through card sorts and tree tests.

🚫 Out of scope:
Rewriting support docs, changing feature names, redesigning mobile nav.

You’re solving for clarity and findability without biting off everything at once.

Not everything scoped is built at once. Break things down. Map features or content to user needs and team capacity. Look for ways to stage the work so you can learn and deliver incrementally.

Even if it’s messy, even if it’s light. Get the scope into a doc, spreadsheet, or Miro board. Include functional needs (what it should do) and content needs (what it should include). This becomes your team’s source of truth.

This is one of those habits Marty Cagan pushes for in Inspired — writing things down to create shared clarity. Not a spec for the sake of process, but a tool for thinking clearly and building together.

Scope isn’t owned by one role. It’s shaped by product, design, and engineering together. Bring the trio into every conversation about trade-offs, feasibility, and phasing. Shared ownership here prevents headaches later.

Artifacts, hard skills, and soft skills

Defining scope isn’t about perfection. It’s about clarity. These are the skills, tools, and habits that help you make solid decisions and avoid spinning later.

Jaime Levy’s book UX Strategy is helpful here, too. It breaks down how to link UX decisions to real business value — something that’s easy to lose when scope is scattered.

These don’t need to be fancy. They just need to make the work visible and shared.

  • Scope doc or feature list
  • Content requirements or inventory
  • Functional spec or jobs-to-be-done map
  • Opportunity solution tree (zoomed in on a branch)
  • Card sort or tree test results
  • Prioritized backlog tied to user outcomes

These help you ground your scope in reality, not just opinions.

  • User research synthesis
  • Feature mapping to outcomes
  • Prioritization methods (e.g., RICE, value vs effort)
  • Documentation (lightweight specs, scope summaries)
  • Content modeling and audits
  • Experience mapping or use-case flows

These help you keep scope focused and collaborative.

  • Critical thinking
  • Facilitation and decision-making
  • Saying no clearly and respectfully
  • Working through trade-offs
  • Communication across roles and stakeholders
  • Listening for what’s really being asked

Real world example

Our team was working on a major restructure of the global navigation for our main site. The nav had become cluttered over time. It didn’t reflect how the company had grown, and users were getting lost trying to find key pages.

But the minute we started talking about changes, the resistance kicked in.

Some stakeholders didn’t want to touch it. They knew users were finding their products and services through the current nav. Changing it could disrupt that flow — and that flow was driving revenue.

The fear was valid. So we paused and got clear on the scope.

We weren’t overhauling everything. We weren’t changing the brand. We weren’t touching the mobile yet.

The scope for this phase was tight:

✅ In scope:
Simplify the primary menu, group related services more clearly, and test the structure with real users.

🚫 Out of scope:
Renaming features, rewriting page content, and redesigning the entire header.

Once we defined the boundaries, the tension eased over time. The project had guardrails. We were able to run tests that showed users found what they needed faster — and that conversions didn’t drop. We moved forward with confidence because the scope was focused and the risk was clear.

Getting alignment on scope didn’t just help the team. It helped the stakeholders trust the process.

How it connects to the other planes

The scope plane sits between strategy and structure. If your strategy isn’t clear, scope gets scattered. And if your scope isn’t solid, the layers above start to wobble.

Structure falls apart when you’re not sure what features or content you’re supporting. Skeleton gets messy because the flows weren’t grounded in a shared understanding. Surface decisions get made in isolation because no one knows what’s actually in play.

Scope is the bridge between strategy and structure, transforming abstract ideas into specific decisions.

— Jesse James Garrett, The Elements of User Experience

That bridge only works when you take the time to define it well.

The scope layer forces you to focus. It turns vision into constraints. It lets teams make trade-offs, prioritize, and build toward the same goal.

When the scope is clear, the rest of the work gets lighter. You don’t have to guess. You don’t have to redo decisions two steps later. You move with purpose and fewer surprises.

The Design Council’s Double Diamond reminds us that we need to define before we decide. That’s exactly what the scope layer gives you. It lets you frame the solution space before structure and design start moving too fast.

In Conclusion

Scope is where strategy becomes real. It’s where big ideas turn into actual plans.

When teams skip this layer, the work expands in every direction. You get rework, missed expectations, and a product that tries to do too much.

But when you pause to define what’s in and what’s out, everything gets sharper. You can say no without drama. You can make trade-offs without losing focus. And you can build with more confidence because the team knows exactly what matters right now.

Scope isn’t about shutting things down. It’s about making space to do the right work well.

Take Action

Before your next feature or project kicks off, pause to define the scope. Start with this:

  • Go back to your product outcome and problem statement. Let those guide what’s in and what’s out.
  • Make a list: What do we need to include? What’s intentionally out for now?
  • Break big ideas into smaller pieces. Ask, “What’s the version we can ship to learn?”
  • Write it down. Use a doc, board, or spreadsheet. Just make it visible.
  • Align as a trio. Make sure product, design, and engineering all agree before the work begins.

You don’t need a big process. You just need a shared understanding. That’s what keeps the team moving in the same direction.

Further Reading