The unbundling of project management

For twenty years, the dominant assumption in project management software was that one tool should hold everything. Tasks, docs, sprints, roadmaps, dependencies, comments, time tracking, reports, integrations. Atlassian sold this as Jira and Confluence. Asana sold it as a unified workspace. Monday sold it as a work OS. ClickUp sold it as the everything app. The pitch, repeated for a generation, was that the right tool consolidates all of project work into one place.

That assumption is breaking. The teams shipping the most interesting work right now use four or five tools instead of one, and they're getting more done with less friction than the teams who insisted on consolidation. This isn't a temporary phase. The unbundling is structural, and it's not reversing.

This post is about why the all-in-one project tool failed, what's replacing it, and where Tree fits in the new shape.

How the all-in-one became the default

The bundled project management tool emerged from a real problem. In the early 2000s, software teams used a chaotic mix of bug trackers, spreadsheets, email threads, wikis, and standalone task lists. Information was scattered. Context was lost. The team's understanding of its own work lived in fragments across half a dozen systems.

Atlassian's pitch with Jira plus Confluence was elegant. One tool for issues, one tool for docs, both integrated, both searchable, both in the same workspace. Add Bitbucket for code, Trello for lighter tracking, and you had a single vendor covering most of what a software team needed. The unification was real, and the productivity win was real, especially for teams coming from the chaos.

Other vendors followed the same logic at different scales. Asana bundled task management, projects, portfolios, goals, and reporting. Monday added time tracking, CRM features, and HR workflows. ClickUp made the bundling explicit ("one app to replace them all") and added a feature roughly every two weeks for years. Notion bundled docs, databases, wikis, and light project tracking under the all-in-one workspace banner.

The argument behind all of this was that switching costs are real. Every tool boundary is a place where information falls through. Consolidation reduces those boundaries. Therefore: the team with the most consolidated tool wins.

The argument was correct in 2008. It stopped being correct around 2018, and most of the industry hasn't caught up to the change.

What broke

Three things changed simultaneously.

The first was that integration got cheap. By 2015, the API economy meant any two tools could talk to each other through Zapier, native integrations, or webhook-based glue. The "boundary where information falls through" argument depended on tools being islands. Once tools became archipelagos, the integration penalty for using multiple tools dropped from "significant friction" to "minor configuration."

The second was that bundles got worse at being good. A tool that does ten things well is hard to build. A tool that does ten things adequately is easier, and almost every all-in-one converged on the latter. Jira's documentation features got worse than dedicated wikis. Notion's project management features got worse than dedicated project tools. ClickUp's everything-app pitch became a meme because every individual thing in the everything app was worse than the dedicated alternative. The bundle's value proposition (consolidation) ate its quality (excellence at any one job).

The third was that user expectations shifted. The 2008 user accepted "good enough at everything" because the alternative was building integrations from scratch. The 2024 user grew up on tools like Linear and Figma, which are excellent at their specific job and trivially integrate with everything else. The new default expectation is best-in-class for each piece, with the integration layer doing the consolidation work that the bundle used to do.

These three changes compounded. Cheap integration removed the bundle's main reason to exist. Bundle decay made the alternative more attractive. User expectations shifted from "consolidation" to "excellence." The all-in-one's competitive position eroded from three directions at once.

The shape of the unbundling

What's replacing the bundle isn't another bundle. It's a stack of specialists.

A modern software team's project work increasingly lives across:

Linear for execution. Tickets, sprints, status, the work currently in flight. Linear is opinionated about workflow and ruthless about UI density. It's the best tool made for tracking defined work through a clean pipeline, and the team using Linear knows what Linear is for.

Notion or its peers for docs. Specs, RFCs, meeting notes, internal documentation. The wiki layer. Notion is brilliant at unstructured knowledge work and the team using it doesn't try to make it hold a roadmap.

Slack or Discord for discussion. Real-time conversation, threads, decisions made in the moment. The chat layer.

Figma for design. The visual workspace. Figma's native commenting and version control absorbed work that used to happen in tickets.

GitHub or GitLab for code. The code layer, with issues and pull requests handling the parts of project work that are tightly coupled to the codebase.

Tree, or a tool like it, for project structure. The tree layer. What depends on what. What unlocks what. The shape of the project across all the other layers. (We have a bias here, obviously. The point isn't that Tree specifically wins this slot. The point is that this slot exists.)

That's six tools. The team using all six has more friction than the team using one tool, in theory. In practice, they have less friction, because each tool is excellent at its job and the integrations between them are good enough to make the boundaries invisible. The total friction is lower than the bundled alternative even though the tool count is higher.

This is the unbundling. Not a single replacement for Jira. A stack that makes Jira unnecessary, with each piece doing one thing well.

Why bundles can't catch up

The bundled tools are aware of this trend. They're responding by adding more features, deeper integrations, and AI assistants that promise to make the bundle feel cohesive again. None of this is going to work, for a reason that isn't obvious.

The bundle's problem isn't features. It's architecture.

A tool built to be good at one thing has its data model, its UI, and its mental model aligned with that thing. Linear is shaped like execution because execution is what it does. Notion is shaped like a wiki because wikis are what it does. Tree is shaped like a graph because graphs are what we do. The architecture is the product.

A tool built to be good at everything has its data model shaped like a generic database with optional features layered on top. Jira's "issue" is a generic record that can be configured to act like a task, a bug, a story, a sub-task, a sub-sub-task, an epic, a feature request, a customer ticket, or any of two dozen other things. The flexibility is the pitch, but it's also the problem. None of those use cases are first-class. All of them are configurations of a generic substrate.

When a specialized tool ships a new feature, it's an extension of an architecture optimized for that domain. When a bundled tool ships a new feature, it's a configuration of a generic substrate trying to act like a specialized tool. The first one is good. The second one is, at best, adequate.

This is why ClickUp can ship features faster than anyone in the space and still feel worse than every dedicated alternative. The features are real. The substrate they're built on is wrong.

The objection: stack complexity

The standard objection to the unbundled stack is that it's too complex. Six tools is too many tools. Onboarding is harder. Switching costs are real. Information still falls through cracks. Surely the bundle's consolidation argument still holds.

It doesn't, and the reason is empirical. The teams using six-tool stacks ship faster than the teams using bundles. We can argue about why. The fact pattern is consistent across most of the indie software companies, design studios, and product teams we know.

Three reasons it works in practice:

Each tool's onboarding is simpler than the bundle's. New hires learn Linear in an afternoon because Linear does one thing. New hires learn Jira over weeks because Jira does fifty things, and the team's specific Jira configuration has its own learning curve on top.

The integration layer matured. Native integrations between modern tools are good. Slack notifies on Linear changes. GitHub PRs link to Linear issues. Figma comments thread into Slack. The "information falling through cracks" problem has been engineered around at the platform level.

The team's mental model is clearer with specialized tools. When tickets are in Linear, docs are in Notion, and structure is in Tree, the team knows where to look for what. When all of those things are in Jira, the team has to know which Jira configuration represents which kind of work, and the cognitive load is higher even though the tool count is lower.

The bundle's consolidation argument assumed tool boundaries were the friction. They aren't, anymore. Configuration overhead is the friction, and the bundle has more of it.

Where Tree fits

The unbundling created a slot the older bundles never recognized. The slot is project structure, separated from execution, separated from docs.

Linear shows you what's in flight. It doesn't show you what depends on what. Notion shows you the spec. It doesn't enforce the prerequisites. Slack shows you the conversation. It doesn't survive the week. There's a layer underneath all of these tools, the structural layer, that the unbundled stack hasn't had a dedicated tool for.

Tree is that tool. Tasks as nodes. Dependencies as edges. The shape of the project, visible across all the other layers without competing with any of them. We don't replace Linear, we sit upstream of it. We don't replace Notion, we organize what Notion documents. We don't replace Slack, we give the conversation something to refer to.

This is a different pitch from "switch from Jira." Switching is a hard sell because Jira users are usually trapped by something larger than the tool itself (org-level mandates, compliance, sunk cost). Tree's pitch isn't to replace Jira. It's to be the structural layer in a stack that Jira was never shaped for. The customers we're after aren't Jira refugees. They're the teams already using Linear plus Notion plus Slack plus Figma plus GitHub, and noticing that nobody's holding the structure.

What's next

The unbundling isn't done. We expect three more developments over the next few years.

Specialist tools will keep eating bundle features. The pattern is well-established now. Each year, a new specialist tool launches in a slot the bundles thought they owned, and the bundle's feature parity becomes less defensible. We'll see specialists for sprint planning, for OKRs, for retrospectives, for portfolio management. Each one will be better at its niche than the bundle ever was.

Integration platforms will get more important. The glue holding the unbundled stack together is currently a mix of native integrations, Zapier, and custom webhooks. We expect a category of integration-first tools to emerge that treat the stack as the primary abstraction, with the individual tools as plug-in components. This is already happening at the edges (n8n, Pipedream, the AI agent space) and will mature into something more coherent.

The bundles will pivot to enterprise. Jira's business is increasingly enterprise compliance, not project management. Asana is moving the same direction. The bundles' competitive advantage in the regulated, audited, governance-heavy segment is real and probably permanent. They'll lose the indie and SMB market to specialists, hold the enterprise market on compliance, and the two markets will diverge.

The teams reading this post are mostly in the first market. The bundle's pitch was never meant for you. It was meant for the buyer above you, who needed governance more than productivity. The unbundling is your permission to stop pretending the bundle was a fit.

Join the waitlist if Tree is the structural piece your stack is missing.