How to scope a project you've never built before

The hardest part of building software isn't building it. It's knowing what to build, in what order, with what dependencies, before you've started.

This is the scoping phase. Most teams handle it badly. Tickets get written and rewritten. Roadmaps get drawn and redrawn. The team loses two weeks to planning meetings that produce a plan everyone privately knows is wrong. Then the work starts, the wrongness becomes obvious, and the plan gets rebuilt mid-flight while the team is already shipping against the broken version.

The scoping problem isn't about discipline or process. It's about thinking with the wrong tool. Most project tools are built for execution, which means they assume the plan exists. The scoping phase, where the plan doesn't exist yet, is where these tools fail hardest.

This post is about how to scope a project you've never built before. The technique isn't tied to any specific tool, though it's much easier with a graph-based one. The general principles apply whether you're using Tree, a whiteboard, or sticky notes on the wall.

What scoping actually is

Scoping is the work of turning "we should build X" into a plan specific enough to start.

That definition hides most of what makes scoping hard. The phrase "specific enough to start" is doing all the work, and the right level of specificity varies by project. Some projects can start with a one-line spec. Some need a hundred-page document. Most need something in between, and the team has to figure out which kind of project they're in before they can scope it.

Three questions distinguish good scoping from bad.

What are we actually trying to ship? Not the high-level goal. The thing that, when complete, will make the project done. Most projects fail this question because the team agrees on a goal but disagrees on the artifact. "Improve onboarding" is a goal. "A redesigned welcome flow with five steps and three new copy components" is an artifact. The first is unfinishable. The second is buildable.

What has to be true before we can start? This is the dependency question. Most teams answer it shallowly ("we need the design done first") and miss the deep dependencies that bite later ("we need the data model decision that the design assumes, which depends on a product decision nobody's made"). The deep dependencies are where projects derail.

What are the branches we haven't picked yet? Most projects have decision points where multiple approaches are possible. The team usually picks one approach early, sometimes implicitly, and forgets the others existed. Months later they realize the rejected approach was better and the project is half-built on the worse foundation. Scoping should make the branches explicit.

The teams who scope well answer all three of these. The teams who scope badly answer the first one and skip the rest.

The list-first scoping failure

The standard scoping process in most teams looks like this.

Someone writes a doc describing the project. The doc has goals, requirements, and a rough plan. Other team members read the doc and leave comments. The doc gets revised. After two or three rounds, the doc is approved.

Then the team translates the doc into tickets. The tickets go into Linear or Jira. They're prioritized, assigned, scheduled into sprints. The work starts.

Within two weeks, the team discovers the doc had hidden assumptions. The third sprint reveals that two tickets depend on a decision nobody made. The fifth sprint reveals that one branch of the project should have been a different branch. By the time the team realizes, half the work has been done on the wrong path.

This is a list-first scoping failure. The doc was prose. The tickets were a list. Neither format is good at expressing dependencies, branches, or the relationships between pieces of work. The structural information was lost in translation, and the team rediscovered it the expensive way.

The fix isn't a better doc or a tighter ticket process. The fix is to scope in a structure that preserves what the doc and the ticket list both throw away.

The graph-first scoping approach

A graph-based approach to scoping uses the same structure the eventual project will run on. Tasks are nodes. Dependencies are edges. The whole scope sits in front of the team as a visible graph from the moment it's drawn.

The process has four steps.

Step one: identify the artifacts. Start with the question "what does done look like?" The answer is a set of artifacts: a redesigned page, a new feature, a published API, a refactored module. These artifacts are the leaves of the graph, the things that, when complete, mean the project is shipped.

The artifacts should be specific. "A welcome flow" is too vague. "A welcome flow with three screens, four copy components, and an opt-in checkbox" is specific enough to plant as a node. If the artifact can't be described in one sentence with concrete nouns, it's not yet scopable.

Plant each artifact as a leaf node. Don't worry about ordering yet.

Step two: trace the prerequisites backward. For each artifact, ask: what has to be true before this can be built? The answers become parent nodes, with edges pointing from the prerequisites to the artifact.

This step is where most of the real scoping work happens. The shallow answers are obvious ("the design has to be done"). The deep answers are where the project's actual structure lives ("the design assumes a data model decision, which assumes a product decision, which depends on a customer interview that hasn't happened yet").

Keep tracing backward until you hit prerequisites that are already complete or that don't need further breakdown. Those are the entry points: the work you can start now.

Step three: identify the branches. Look at the graph for places where multiple approaches could lead to the same artifact. These are decision points.

Most teams hit decision points implicitly during scoping and resolve them invisibly. The graph approach forces them to be explicit. If there are two reasonable ways to build the artifact, plant both as parallel branches feeding into the same node. Don't pick yet. Let the branches sit there as visible alternatives.

The team's decision-making improves dramatically when the alternatives are visible. The implicit "we'll just do the obvious thing" stops being possible because the graph shows two reasonable things and the obvious one isn't always right.

Step four: prune deliberately. When the graph is complete, the team makes the decisions that resolve the branches. Each pruned branch is a deliberate choice. The graph remembers what was rejected, which means six months later, when somebody asks "why didn't we just do X," the answer is on the graph instead of in someone's head.

Pruning is where scoping ends. The remaining graph is the scoped project, with entry points (the work you can start now), structure (what depends on what), and a record of the decisions that got you here.

What this looks like in practice

Consider a real example: redesigning the onboarding flow for a SaaS product.

The artifacts are the deliverables: the new welcome screen, the new account setup flow, the new email sequence, the analytics tracking for the funnel.

Step one plants four leaf nodes, one per artifact. The graph has four nodes and no edges yet.

Step two traces prerequisites. Each artifact has its own chain. The new welcome screen needs a design, which needs a content strategy, which needs a customer research synthesis. The account setup flow needs the same content strategy, plus a backend decision about authentication providers. The email sequence needs the content strategy plus access to the email service provider. The analytics tracking needs an event taxonomy that doesn't exist yet.

After step two, the graph has roughly fifteen nodes and a clear shape. The content strategy is a critical prerequisite for three of the four artifacts. The customer research synthesis is upstream of everything. The authentication provider decision is a single critical dependency for one artifact. The event taxonomy is a new piece of work that wasn't in anyone's head when the project started.

Step three reveals branches. The authentication provider decision is a branch: build with Auth0 or build with Clerk. Both lead to a working account setup flow but have different downstream implications. Plant both as parallel branches. Similarly, the email sequence has a branch: send through the existing SendGrid setup or migrate to Customer.io for better behavioral targeting. Plant both.

Step four resolves the branches. The team discusses, decides, and prunes. Auth0 wins because of existing infrastructure. SendGrid wins because the migration cost isn't justified. The graph now shows the chosen path with the rejected branches faded but visible, so the decision is documented.

The scoped project is now ready to start. The entry points are the customer research synthesis and the event taxonomy work, both of which can begin immediately. Everything else is locked behind those, and the lock is structural, not procedural.

Why this works

The graph-first approach works because it makes three things visible that list-first approaches hide.

Deep dependencies become visible. Tracing prerequisites backward forces the team to articulate the chain of "X requires Y requires Z" that prose docs and ticket lists obscure. The team can't claim the project is scoped until every chain bottoms out at something already done or trivially achievable.

Branches become visible. Most projects have decision points the team would otherwise resolve implicitly. The graph forces explicit choice, which produces better decisions because the alternatives are evaluated rather than skipped.

Entry points become visible. The team always knows what to start now, because the graph computes it. The available tier is the set of nodes whose prerequisites are all complete. There's no "what should I work on" question because the answer is mechanical.

These three properties compound. A team that knows what to start, what's blocking what, and which branches are still open has structurally less project failure surface than a team that has a doc and a ticket list. The failure modes that show up in week three of execution have been pre-empted in week zero of scoping.

What this isn't

Graph-first scoping isn't waterfall.

The classic waterfall failure mode is to scope everything up front, freeze the plan, and execute against it without revision. This is bad because plans change, requirements change, and the team learns things during execution that the original scope didn't anticipate.

Graph-first scoping is different in two ways.

First, the graph isn't frozen. It's a working artifact that evolves as the project does. Nodes get added when new work surfaces. Edges get redrawn when dependencies turn out to be different than predicted. Branches get planted when new alternatives appear. The graph is the team's evolving understanding of the project, not a contract.

Second, the graph supports incremental commitment. The team doesn't have to scope the whole project before starting. They can scope the first tier deeply, the second tier roughly, the third tier as a sketch, and start work on the entry points while continuing to refine the rest. The graph makes this kind of progressive scoping natural because the tool already supports nodes at different levels of resolution.

The right level of scoping depth depends on the project. A two-week project can be scoped in an hour. A six-month project might need a week. The graph adapts to either, because it doesn't impose a process. It imposes a structure.

What you need

Graph-first scoping doesn't strictly require a graph-based tool, but using one matters.

You can do this on a whiteboard. The whiteboard version works for small projects, but it's hard to maintain over time, hard to share with remote teammates, and hard to reference when execution begins. The whiteboard is a sketch, not a plan.

You can do this with sticky notes on a wall. Same limitations as the whiteboard, with added physical fragility.

You can do this in a graph-drawing tool like Miro or Whimsical. These work but are general-purpose drawing tools, not project tools. The graph you draw doesn't connect to the work that follows. Once execution starts, the scoping artifact becomes a separate document that drifts from reality.

You can do this in a project tool with native graph support. This is what Tree is built for. The graph you scope with becomes the project structure during execution. The locked nodes are the work that's still locked. The available tier is the work you can start now. The pruned branches are visible as a record of what you decided not to do.

The tool matters because scoping isn't a separate phase from execution. It's the first phase, and the artifacts it produces should carry forward into the work that follows. Tools that don't support that hand-off force the team to redo the scoping work in a different format, which is where most of the structural information gets lost.

The summary

Scoping a project you've never built before is hard because the structural information is hidden, and most tools are bad at making it visible.

The fix is to scope in a structure that preserves dependencies, branches, and entry points. The graph-first approach does this by treating tasks as nodes and dependencies as edges from the start. The process is four steps: identify artifacts, trace prerequisites backward, identify branches, prune deliberately.

The output is a scoped project with explicit structure, ready to execute. The process takes longer than writing a doc and shorter than discovering the structural problems during execution. The teams that scope this way ship more reliably than the teams that don't.

If you want to scope your next project as a graph instead of a list, join the waitlist.