The features we deliberately won't build

Most product roadmaps grow by accretion. Customers ask for features, the team adds them to the backlog, the backlog becomes the roadmap, the roadmap becomes the product. Over time, the product accumulates everything anyone has ever asked for, and the original shape of the tool gets buried under a decade of feature requests.

This is how most project management tools became the bloated, configurable, feature-stuffed messes they are today. Each feature was a reasonable response to a reasonable request. The cumulative effect is a product nobody designed.

Tree is going to be different, mostly because we've decided in advance which features we won't build. This post is the list, with the reasoning for each refusal.

No custom workflows

We won't ship configurable workflow engines.

In Jira, a workflow is a state machine that defines how a task transitions between statuses. Admins configure the states, the transitions, the conditions, the approvals, the side effects. Each project gets its own workflow, often with dozens of states and hundreds of rules. The workflow engine is one of Jira's most powerful features and one of its most damaging.

Tree has four states: locked, available, in-progress, complete. They're not configurable. They're computed from the graph: a task is locked if any prerequisite is incomplete, available if all prerequisites are complete and it hasn't started, in-progress if someone has claimed it, complete if it's done.

This is enough. The thousand workflow states that Jira admins build are usually re-encoding structural information that should live in the graph. "In review" is a node whose review prerequisite is incomplete. "Blocked on legal" is a node whose legal prerequisite is incomplete. "Ready for QA" is a node whose preceding work is complete and whose QA prerequisites are met. The graph already knows.

We won't build a workflow engine because the graph makes it unnecessary. Building one would mean accepting that the graph is insufficient, which would mean having built the wrong tool.

No marketplace

We won't ship a third-party plugin marketplace.

Atlassian's marketplace is a clever business model. Third-party developers build features Atlassian didn't ship, sell them to Jira customers, and split the revenue with Atlassian. The marketplace fills feature gaps without Atlassian having to build them. Customers get more capabilities. Everyone wins, mostly.

The cost is that the base product can't ship features that compete with marketplace partners. Native time tracking would compete with the time tracking plugins. Better Gantt charts would compete with the Gantt chart plugins. The marketplace becomes a moat that prevents the base product from improving in obvious ways. Atlassian can't fix Jira's missing features without breaking the partner ecosystem.

We're not building a marketplace because we want the freedom to ship the features ourselves. Time tracking, if we ship it, will be native and free. Better visualization will be native. Integrations will be native. We won't have third-party developers depending on our gaps, which means we won't have a structural reason not to fill them.

No AI assistant

We won't ship an AI feature that pretends to do project management for you.

The current generation of project tools is racing to add AI features: AI-powered task generation, AI-powered status updates, AI-powered priority suggestions, AI summaries of project state. The pitch is that the AI handles the boring parts so the team can focus on the work.

We don't believe this works. The boring parts of project management aren't boring because they're mechanical. They're boring because they're cognitive overhead the tool shouldn't have created in the first place. An AI that summarizes status updates is patching a tool that needs status updates because its data model can't show status from the graph. An AI that generates tasks is patching a process where humans were generating tasks for ceremonial reasons rather than building reasons.

The right fix is to build a tool that doesn't produce the overhead in the first place. The graph shows status without anyone writing updates. The structure shows what to work on without anyone curating a backlog. The tool generates the answers from the data model, not from a language model trained on what answers usually look like.

We might ship AI features eventually, but only for tasks that genuinely benefit from AI: pattern recognition across large graphs, natural-language interfaces for users who prefer them, possibly some kinds of structural suggestions. We won't ship AI as a way to paper over a weak data model.

No mobile-first design

We won't optimize the primary product for mobile.

Project planning is a desktop activity. The graph is a visual artifact. Reading it on a phone is technically possible but cognitively miserable. Editing it on a phone is worse. The teams we're building for plan on laptops, not phones.

We will ship a mobile companion, eventually, that does the things mobile is genuinely good for: quick status checks, notifications, completing a task you've already started, capturing a quick thought. The companion is a satellite to the desktop product, not a replacement.

We won't build a mobile-first version because we won't compromise the desktop experience to make the mobile version reasonable. Tools that try to serve both equally end up serving neither well. The graph wants screen real estate. The phone doesn't have it. We're choosing.

No infinite hierarchy

We won't ship arbitrary nested hierarchies.

Some project tools support unlimited nesting: epics contain features contain stories contain sub-tasks contain sub-sub-tasks contain whatever. The hierarchy can go as deep as the team wants. The pitch is flexibility.

The reality is that infinite hierarchy produces unmaintainable structure. Teams nest things deeply because the tool lets them, not because the work is naturally that deep. The fifth level of nesting is rarely meaningful. The seventh level is almost never meaningful. The tool's flexibility encourages structural patterns that the team will regret.

Tree's graph supports parent-child relationships through edges, which in practice produces hierarchies as a natural consequence. But we don't expose "depth" as a UI primitive, and we don't optimize for deep nesting. The graph wants to be wide, not deep. Branches are first-class. Nested sub-sub-sub-tasks aren't.

No "for everyone"

We won't make Tree a tool for every team and every workflow.

The dominant marketing pitch in project management software is "we work for any team of any size doing any kind of work." Asana, Monday, ClickUp, even Notion all sell this. The pitch is that the tool is flexible enough to fit any use case.

Tree is for a specific use case: technical teams working on dependency-shaped projects who want structure to be visible. We'll work for software teams. We'll work for some kinds of design teams. We'll work for technical PMs. We won't work for sales pipelines, customer support workflows, content calendars, recipe collections, household chore charts, or wedding planning.

We won't shoehorn Tree into use cases it isn't built for. This costs us audience size. It also produces a tool that's actually good at the use case it serves, instead of mediocre at every use case it could plausibly support.

What this list is for

The features above aren't ones we haven't gotten around to. They're ones we've decided in advance not to build. The decisions are public so users can hold us to them.

If we ship a workflow engine in two years, somebody can point at this post and ask what changed. If we add a marketplace, same. If we pivot to mobile-first, same. The post is a precommitment device, designed to make it embarrassing to violate.

The features we will build are on the roadmap. The features we won't build are here. The boundary between them is part of what makes Tree a coherent product instead of an accumulating one.

If the boundary makes sense to you, join the waitlist.