meta design

Why our roadmap is a tech tree

We render the public roadmap as an interactive graph instead of a list because that's what shipping software actually looks like. Showing it that way changed what we chose to build first.

JAN WILLEM 6 MIN READ

Most public roadmaps are a list with three columns: Now, Next, Later. We didn't want that. The work has prerequisites, branches, and uncertainty. Pretending otherwise on the marketing site felt dishonest.

So we rendered the roadmap as a tree. The same tree shape the product itself uses, applied to the work of building the product. You can see it here. Hover, trace, click, drag, scroll to zoom.

This post is about why we did that, what the shape forced us to confront, and what the roadmap currently says about where Tree is.

What a list hides

The Now / Next / Later format is the dominant convention for public roadmaps. It's clean, it's scannable, it fits in a marketing page. It also lies about how building software actually works.

A list assumes the items are independent. In reality, "Multi-tree projects" can't ship before "First interactive tree." "Templates" needs "Node states" before it makes any sense. "Public API" needs "Comments and activity log" because half of what an API exposes is the activity stream. The list format hides all of that. Readers see three buckets and assume the items inside each bucket are roughly equivalent. They aren't.

A tree forces the dependencies to be visible. If "Visual feedback" is locked, you can trace back and see exactly what's blocking it. If a node is sitting in the "available" tier, you know its prerequisites are done. The shape carries information the list format throws away.

What the shape forced us to confront

Building the roadmap as a tree changed what we chose to ship first.

The clearest example is the brand branch. We hadn't planned to take brand work seriously this early. The instinct, like most pre-launch teams, was to wave at it and focus on product. Then we drew the tree and found that "Public roadmap," "Marketing site," "Press kit," and the entire distribution branch all had a brand prerequisite. Tone of voice. Visual style. Logo. Without those, every downstream node was locked.

We had a choice. Build product features into a void with no brand to wrap them in, or do the brand work first and unlock everything downstream. The list format wouldn't have surfaced the choice. The tree did. Brand went first.

The product branch tells a similar story in reverse. We thought "Templates" would be an early feature. The tree showed it depending on "Node states," which depends on "First interactive tree," which depends on "Core data model." Templates is four prerequisites deep. It's not coming soon, and pretending otherwise on a Now / Next / Later list would have set expectations we couldn't meet.

The honest answer is that templates ship when the four things they need are done. The tree says exactly that, without us having to write a paragraph explaining the dependency chain.

What we kept visible on purpose

The instinct with public roadmaps is to hide the locked work. Show what's done. Show what's coming. Skip the rest because it's far away and might change.

We did the opposite. The locked nodes are visible, greyed out, with their prerequisites traceable. "Companion mobile app" is on the roadmap. It's also six prerequisites deep behind "First interactive tree" and "Multi-tree projects" and several other things. A reader looking at the roadmap can see both at once: yes, mobile is planned, and no, it isn't soon.

This is more honest than the alternative. The alternative is a list that says "Mobile app: Later" and lets the reader assume Later means three months. With the tree, Later is a position in a graph, not a vague time bucket. You can count the unlocks between now and then.

The cost is that the roadmap looks fuller and more daunting than a curated list would. A locked node still takes up space. We accepted that. We'd rather show the real shape of the work than make the roadmap look smaller than it is.

The standalones

There's a row at the bottom of the roadmap labeled "Standalones." It contains: Pissed the in-house designer off. Survived first DNS propagation. First user who isn't a friend. First feature request received. 100th tree planted.

These aren't prerequisites for anything. They're not features. They're the events that don't fit the dependency graph but are real milestones in building Tree. We kept them on the roadmap because the alternative was pretending the only things that matter are the boxes that unlock other boxes.

Some of them are jokes. Some are real. The 100th tree planted node will activate when the 100th user creates their 100th project tree. The "first user who isn't a friend" node will unlock when someone we don't know signs up. These mark the moments that make a startup feel real, and we wanted the roadmap to mark them.

A list format wouldn't have a place for this row. The tree does, because the tree is a shape, not a sequence.

What the roadmap doesn't promise

A few things the roadmap deliberately doesn't say.

It doesn't have dates. Pre-launch dates are fiction. We could put estimates on each node and they'd be wrong, and then we'd be a startup with a wrong-dated public roadmap, which is worse than a startup with a date-free one.

It doesn't have a "Done" tier in the traditional sense. Completed nodes turn green and stay on the tree as the foundation for everything above them. Done work doesn't disappear. It becomes the thing the next tier is standing on.

It doesn't pretend to be exhaustive. Some work isn't on the roadmap because it isn't decided yet. Some work isn't on the roadmap because it's too small to be a node. The roadmap shows the shape of the work we're committed to. It doesn't show every line of code.

What this means for Tree

The roadmap is also the product, in a small way. It's running on the same tree-rendering logic the app will use. Every choice we made building the roadmap is a choice we'll have to make again, at scale, when the product ships.

How do you show locked nodes without overwhelming the user? How do you make dependencies traceable without making the canvas a maze? How do you handle nodes that don't fit any branch (the standalones)? We've been answering those questions on our own roadmap because we have to answer them in the product, and it was easier to start with our own work as the test case.

When Tree ships, the projects users plant will look something like this roadmap. Branches, prerequisites, locked tiers, the occasional standalone for the milestones that don't fit the graph. The dogfooding starts before the product does.

If that shape sounds right for the work you're trying to plan, join the waitlist.

Subscribe via RSS
Frequently asked questions

Tree's roadmap is a graph because the work has prerequisites, branches, and uncertainty that the standard Now / Next / Later list format hides. The graph makes dependencies visible, shows what unlocks what, and forces honest answers about which work is far off because it's blocked, not because it's been deprioritized.

Standalones are events that don't fit the dependency graph but are real milestones in building Tree. The current row includes "Pissed the in-house designer off," "Survived first DNS propagation," "First user who isn't a friend," "First feature request received," and "100th tree planted." Some are jokes, some are genuine signals that the startup is becoming real.

Pre-launch dates are fiction. Estimates on each node would be wrong, which would make the public roadmap actively misleading. The graph shows position rather than time: how many unlocks stand between now and a given node. That's more honest than a Later bucket that could mean three months or three years.

The roadmap shows the shape of the work we're committed to, including nodes locked behind several prerequisites. They're not promises with deadlines. They're the planned shape of the project. Some will ship as drawn. Some will get re-evaluated as we learn more. The locked-but-visible default is honest about both possibilities.

Yes, in a limited way. The roadmap uses the same tree-rendering logic the application will use, applied to the work of building Tree itself. Every UI decision we make for the public roadmap is a decision the product will face at scale. The dogfooding starts before the product ships.

More often than we expected. Nodes move, branches get added, prerequisites get re-evaluated as we learn more. The roadmap is a working artifact, not a frozen plan. Major structural changes are rare. Adjustments to which node depends on what happen weekly.

The interactive roadmap is at /roadmap. Hover to trace prerequisites, click to focus, drag to navigate, scroll to zoom. Locked nodes show what's blocking them. Available nodes show what we can start now.