Put the Plan on the Wall: Project Management in the Real

Why project managers need a physical space to think, not another digital tool

I build tools for science classrooms. The core idea behind all of them is simple: people understand complex systems better when they can construct physical models, rearrange them, and see the whole thing at once. 

A few years in, we started using our own tools to plan with teachers and the same dynamics showing up in our team meetings that we'd seen in classrooms. When a couple of project managers reached out asking about them, we started paying closer attention to whether what we'd learned in education actually translates to conference rooms.

Here's what we think we now. We're obviously still learning.

Most project management problems are not software problems. They're people problems. Specifically, they're problems of shared understanding. Who knows what the plan actually is, who had a say in building it, and who feels any real ownership over it.

Software doesn't solve that. In most teams, one person lives in the project management tool and everyone else occasionally glances at it when they're reminded to. The tool becomes a reporting mechanism for the person running it, not a shared thinking space for the whole team. The plan exists. It just doesn't belong to everyone.

A physical space changes that dynamic. When a team builds a plan together on a wall, moving pieces, arguing about sequence, physically placing tasks in relation to each other, something different happens. Everyone touched it. Everyone had a say. The plan on the wall is the team's plan, not the project manager's plan that everyone else is supposed to follow.

That's the core case for physical planning tools. Not that they replace digital tools, but that they do something digital tools are structurally bad at: creating shared ownership in real time, in a room, with everyone present.

The Problem with Abstract Planning

Project management is fundamentally about complex systems. Tasks depend on other tasks. People depend on other people. Timelines compress or expand based on decisions made three weeks ago. The whole thing is interconnected in ways that are genuinely hard to hold in your head.

Most planning tools make this worse, not better. A list of tasks in a spreadsheet looks like a list of tasks. A backlog in a digital tool looks like a backlog. Neither one makes the dependencies visible. Neither one shows you the hierarchy. Which things are big and which things are components of big things. Which decisions unlock other decisions, where the actual bottlenecks are.

When you can only see one part of a system at a time, you manage that part. You lose the whole. And losing the whole is how projects get into trouble, not because any individual task was mismanaged, but because nobody was watching how the pieces connected.

Physical modeling forces the whole into view. When your plan is on a wall, you can see all of it at once. You can see the dependencies without clicking through layers of software. You can see the hierarchy without scrolling. A team standing in front of a physical plan is a team that can actually see what they're doing.

Three Sizes, One Insight

Switch-Its come in three sizes. That's not an accident and it's not just aesthetics. Size is hierarchy made physical.

Large blocks are the big components of the system. Medium blocks are the workstreams or phases within those components. Small blocks are the individual tasks. When you're building a project plan with Switch-Its , the size of the block signals its place in the structure without anyone having to explain it. A new person can walk up to the board and immediately see what the major pieces are, what lives under each one, and how granular any given section has gotten.

This matters in practice because hierarchy is one of the hardest things to communicate in a planning conversation. When everything in a backlog looks the same size, everything feels equally urgent and equally important. Nothing looks like a component of something else. Physical size solves a communication problem that formatting in a spreadsheet never quite does.

What You Can Actually Do With Them

The frameworks that work well with Switch-Its are the ones built around visual arrangement — where the position and relationship of pieces carries meaning.

Kanban boards are the obvious starting point. To-do, in progress, done. Each task on a block, each block moveable. The difference from a digital kanban is that the whole team can stand around it, move pieces together, and have the conversation in front of the actual board rather than each person staring at their own screen.

The Eisenhower Matrix works well for prioritization. Urgent versus important, four quadrants, tasks physically placed in the space that represents their actual priority. When a team builds an Eisenhower Matrix together, disagreements about priority surface immediately, because you can't put a block in two places at once. The physical constraint forces a decision.

Flow mapping is where Switch-Its become particularly useful. When you're mapping a process or a system, you need to show how things move and connect. The magnetic blocks snap together to show connections. When you need to move a component, you move it, and the blocks attached to it come with it, so the relationships stay intact. If the system changes too much you simply rearrange all the components and redraw the dependencies. 

Sprint planning benefits from the same logic. Tasks on blocks, arranged by sequence and dependency, moveable as the sprint evolves. A sprint board on a wall that the whole team built together is a different artifact than a sprint board that the scrum master maintains in Jira. One belongs to the team. The other belongs to the tool.

Constraints Are Not Limitations

A base set of Switch-Its contains 28 blocks. Some people hear that and think: that's not enough. Most projects have more than 28 tasks.

That reaction is worth examining. If your plan requires more than 28 pieces to communicate to your team, the problem might not be that you need more blocks. The problem might be that your plan is too granular for the level of conversation you're trying to have. Physical constraints have a way of surfacing that distinction. A whiteboard has finite space. Switch-Its have a finite number of blocks. Both constraints push you toward deciding what actually matters at this level of planning and what belongs somewhere else.

The blocks are also dry-erase. Write on them, wipe them off, write something new. The same block that was a task last sprint is a different task this sprint. Nothing is precious. Everything is revisable. That quality: the ease of changing your mind is underrated in planning tools. Plans change. Tools that make change feel costly produce teams that are slow to adapt.

Multiple sets combine. For larger projects, you add sets. The physical space becomes the constraint at that point, which is a useful constraint: if your plan no longer fits on the wall, it's time to zoom out and work at a higher level of abstraction.

A Non-Digital Meeting

Here's a practical suggestion: try running one planning meeting without opening any laptops.

Put the plan on the wall before people arrive. Give everyone blocks and a marker. Ask each person to place their most important current task on the board and explain where it fits in the overall project. See what happens when the whole team is standing up, pointing at physical objects, and building something together rather than each person looking at their own screen.

This is not a productivity hack. It's a meeting design choice that changes who participates and how. People who go quiet in front of a shared screen will pick up a block and put it somewhere. The act of physically placing something in a space is lower-stakes than typing a comment in a tool that everyone can see and nobody quite reads. The conversation that follows is usually more honest and more useful than what you get from a status meeting where everyone is half-watching their notifications.

Digital tools are for tracking. Physical tools are for thinking. Both matter. Most teams have the tracking covered. Thinking together in a room, around a shared surface, without the mediation of software is what usually gets skipped.

What We're Still Learning

We built Switch-Its for the world of education. We've watched them work in science classrooms, math classes, and professional development workshops for teachers. The core insight is that people understand complex systems better when they can build and manipulate physical models of them.

Project management is newer territory for us. We're not going to claim otherwise. We've seen enough to believe that the same dynamics that make physical modeling powerful in a classroom make it powerful in a planning session. Shared ownership. Visible hierarchy. The ability to see the whole system at once. The low cost of changing your mind.

But we know that experienced project managers have spent years developing instincts about what makes planning work and what makes it fail. We're genuinely curious about what you see in these tools that we haven't thought of yet, and where the limitations are that we haven't run into.

If you're a project manager who wants to try running a planning session differently, we'd like to hear what you find. The tool is designed to be flexible enough that you can adapt it to whatever framework you already use. What we're building is the physical space. What you do in that space is yours.

Explore Switch-Its and see how physical modeling fits into the way your team plans.

AI Transparency Disclosure: This content was created with the assistance of artificial intelligence. While AI helped with drafting based on provided topics, the final version has been reviewed, edited, and approved by a human author who takes full responsibility for its accuracy and perspective.