How to Use Spaces Without Recreating Your Org Chart

Every team that starts using Spaces eventually hits the same question: what do I group by?

The obvious answer is teams or departments. Engineering, Design, Marketing. One Space per function. It feels tidy. It mirrors the org chart you already have. The problem is that it doesn’t mirror how product work actually flows — which is almost always across functions, not within them.

Here’s what tends to work better.

Group by initiative, not by team

The most useful Spaces cluster projects around a shared goal or time horizon rather than an owner.

Q2 2026 is a Space that immediately tells anyone — engineer, designer, PM, stakeholder — what phase of work they’re looking at. Every project inside it belongs to this quarter. The status of cards across those projects is a rough read of where the quarter is headed.

Checkout Redesign is a Space that tells you the initiative. It might contain a canvas for the backend API changes, a canvas for the frontend redesign, and a canvas for the analytics work needed to measure success. Three projects, one goal, one Space.

When you open the Space, you see the initiative as a whole — not the engineering backlog, not the design handoff board, but the connected system.

Time-based Spaces expire gracefully

One advantage of grouping by time period: old Spaces stop being relevant on their own.

Q1 2026 is interesting to look back at. Q2 2026 is where active work lives. You don’t need to archive it or change its permissions or restructure anything. Time passes; the space moves from active to reference. That’s a clean separation.

Team-based Spaces don’t expire. The Engineering Space is always relevant, which means it becomes a dumping ground. Everything technical goes there. Eventually it’s too large to be useful, and the work required to reorganise it is more than anyone wants to take on.

Keep Spaces flat

The instinct when building any organisational structure is to add hierarchy. Spaces within Spaces. Folders within folders. Categories within categories.

Resist this. Spaces work because they’re a single level of grouping above projects. Adding a second level — using one Space to hold projects that themselves should be in different Spaces — removes the clarity that made the first level useful.

If you find yourself wanting a sub-Space, ask whether you actually need two separate Spaces instead. Most of the time, the answer is yes.

Permissions at the Space level

Spaces also serve a permissions purpose that’s easy to overlook.

If you’re working with an external partner or a contractor, adding them to a Space — rather than to each individual project — means they automatically get access to new projects as they’re added. You don’t have to remember to invite them to each one. You don’t risk the situation where a project falls outside their view because someone forgot a step.

This is particularly useful for client-facing work, where the client should see everything in a given initiative without requiring you to manage access project by project.

The one-sentence test

Before creating a Space, try to describe it in one sentence — without naming a team.

“All projects we’re shipping in Q2.” Clear. “Everything the platform team is responsible for.” Vague, team-centric, will grow without bound. “The three projects that together deliver the new onboarding experience.” Clear. “Engineering.” This is not a Space. This is an org chart.

If you can’t describe the Space in one sentence without naming a team, it’s probably the wrong unit of organisation. Group by what you’re trying to do, not by who owns it. The work will be easier to find, easier to share, and easier to reason about as a whole.