What strategy games taught us about project planning

Civilization V has a research tree with 87 nodes across nine eras. Stellaris has a randomized tech pool with thousands of possible unlocks. Factorio's research dependencies form a graph so dense that experienced players plan their entire factory layout around the next three unlocks. Slay the Spire's deck progression is a directed graph with synergy paths the player has to read three turns ahead.

These are video games. They're also the most thoughtful project management interfaces we've ever used.

This post is about what strategy games solved that project tools never adopted, why the gap exists, and what we took from games when we designed Tree.

The progression UI problem

Strategy games and project tools are solving the same UX problem. Both have to show a user a large set of possible actions, indicate which ones are currently available, hint at what's coming, and let the user plan a path from where they are to where they want to be.

Games solved this. Project tools didn't.

Open Civilization V's tech tree. You see ninety-something nodes laid out across the screen. The ones you've researched are filled in, glowing, marked as foundation. The ones you can research now are highlighted. The ones locked behind prerequisites are visible but dimmed, with the prerequisite chain traceable by hovering. You can click any node to see what unlocks downstream from it. You can click a far-future node to see the path required to get there. The interface answers every question a player asks: where am I, what's available, what's next, what's the long path.

Open Jira. You see a backlog. The list is sorted by priority, or sprint, or some other field, and the dependencies are buried in a "linked issues" panel three clicks deep. There's no path. There's no available tier. There's no visualization of what unlocking the current task makes possible. The interface has been optimized for ticket throughput, not for the user's actual question, which is "what should I think about right now and what comes after that."

The gap isn't because games have more design budget. Civilization V shipped in 2010 with a UI design team measured in single digits. The gap is that games and project tools made different assumptions about what the user needs to see.

What games assume

Strategy games assume the user is the protagonist of their own progression. The tree exists because the player is supposed to look at it, plan paths through it, make tradeoffs based on what's downstream, and feel something when a long-awaited node unlocks.

Three design decisions follow from that assumption.

Locked nodes are visible. A Civilization V player can see Atomic Theory in the Industrial Era from turn one of the game. They can't research it. They might never research it. But they can see it, count the nodes between here and there, and decide whether the path is worth it. The information is freely available because the alternative (hiding it) would make planning impossible.

Paths are traceable. Hover over Robotics in Civ V and the prerequisite chain lights up. You can see exactly what stands between you and that unlock. Click any locked node and the same information appears. The graph is queryable through direct manipulation, not through reading documentation.

Progression is the structure. The tree isn't a visualization of the database. The tree is the database. There's no underlying list of techs that the tree happens to render. The tree is how research is stored, how prerequisites are computed, how unlocks fire. The game's progression logic and the player's UI are the same object.

What project tools assume

Project tools assume the user is a worker, not a planner. The data model is built for ticket execution: create issue, assign owner, track status, close. Everything that isn't ticket execution is grafted on afterward.

Three opposite design decisions follow.

Locked work is hidden. The default view in Linear, Jira, Asana is the work currently in flight. Anything not in the current sprint is in a separate panel, a separate filter, or a separate page. The architecture assumes you don't need to see far-future work because future work changes. The architecture is wrong, because the user does need to see it. They need to see it to plan, to scope, to make tradeoffs, to understand what their current work unlocks.

Paths are not traceable. Even when project tools support dependencies, they don't visualize the dependency chain. Linear shows "blocked by" as a line of text on the issue page. Jira shows linked issues in a side panel. Neither lets you trace the chain three steps back to find the root prerequisite, or three steps forward to find what unlocks when this finishes. The dependency information exists. It just isn't queryable through the interface.

The list is the structure. Tasks are stored in a database table. The list view is the canonical rendering. Boards, timelines, dependency graphs are alternative renderings of the same underlying list. The list-first architecture means everything that isn't list-shaped is a feature ticket. Dependency visualization isn't a feature in Civilization V. It's the entire game.

Why the gap exists

Project tools didn't ignore games. They came from a different lineage.

The dominant project management interfaces inherited from spreadsheets, which inherited from paper forms, which inherited from clipboard task lists. Microsoft Project shipped in 1984 as a desktop app modeled on Gantt charts, which were invented in 1910 for factory scheduling. Atlassian shipped Jira in 2002 as a bug tracker, which is a list of issues that need fixing. The list is the default because the tools that came first were lists, and every subsequent tool inherited the assumption.

Games inherited from games. Civilization's tech tree borrowed from earlier 4X games (Master of Orion, Master of Magic) which borrowed from board games (Civilization the board game, 1980) which borrowed from war games. The whole lineage assumes the player is making strategic choices, which means the player needs to see the strategy space.

The result is two parallel design traditions solving the same UX problem with opposite assumptions. Games assume planning matters. Project tools assume execution matters. Both are right for their original use case. Most modern project work is closer to the game's use case than the form's use case, and the tools haven't caught up.

What we took from games

Tree's tech tree metaphor isn't decoration. It's a deliberate import of UX patterns from a tradition that solved this problem better.

From Civilization, we took the locked-but-visible default. Future nodes appear on the tree from day one. The user can see them, plan around them, decide whether the path is worth taking. The information is free.

From Stellaris, we took the idea that branching is a planning act. Stellaris randomizes which techs become available, forcing players to make tradeoffs between competing branches. Tree lets users plant parallel branches deliberately, develop them in isolation, and prune the loser when they commit. The branching is structural, not metaphorical.

From Factorio, we took the assumption that the project graph should be navigable. Factorio's research dependencies are dense enough that the game ships with a planner overlay showing what each tech unlocks downstream. Tree's hover-to-trace and click-to-navigate work the same way. The graph is queryable through direct manipulation.

From Slay the Spire, we took fog of war. Slay the Spire shows the next battle and hints at the one after, but obscures the rest of the run. The player plans with imperfect information, which forces them to think structurally rather than optimally. Tree's fog of war does the same job for project work. You see the next tier clearly. You see the tier after that dimly. You don't see the whole graph at once, which would be overwhelming, but you can lift the fog when you need to.

These aren't aesthetic choices. They're functional patterns from a tradition that thought harder about progression UX than the project management tradition ever did.

What this isn't

Tree isn't gamification. We aren't adding XP bars to your tasks or achievements when you close a ticket. The point isn't to make work feel like a game. The point is that strategy games solved a UX problem (how do you show a complex progression space to a user planning a path through it) that project tools never solved well, and the solution generalizes beyond entertainment.

The metaphor is structural, not decorative. The tree is how the data is shaped. The unlocks are how the status model works. The fog of war is the visibility configuration. None of it is reskinned ticketing.

If you've ever finished a Civilization run and thought "why doesn't my project tool work like this," the answer is that nobody made one until now. Join the waitlist.

What games still do better

Two things, honestly.

Games tell you when something unlocks. The fanfare matters. A long-awaited tech finishing in Civilization V triggers a cinematic, a sound cue, a notification you can't miss. Project tools that fire a desktop notification when a Jira ticket closes are doing the same thing badly. We're working on this. Done well, it's a real moment. Done badly, it's noise. We'd rather get it right than ship it fast.

Games make the path visible to the goal. Civilization's "Recommended path to victory" overlay shows the shortest tech route to a chosen win condition. Tree doesn't have a "victory condition" yet, partly because most projects don't have a single one. We're thinking about whether goal-oriented path highlighting makes sense, or whether it imports a game pattern that breaks down when applied to real work. Open question.

The pattern import isn't done. We took what generalized cleanly. Some patterns don't, and we're not going to force them.