What to Build Next When Everything on the List Looks Important

It is the night before your planning call with your developer and you are looking at a Notion board with forty-one cards on it. Every card came from somewhere real: a customer who asked for it, a competitor who has it, a thing that broke last month, an idea you had in the shower. You have fourteen months of runway, and you are about to pick three of those cards and call it the plan.

What you are afraid of is picking wrong: spending a quarter on the wrong three and finding out in month nine, when there is no longer time to fix it.

You are right to be afraid of that, and the board is the reason. A list of features has no information in it about what the features cost, what you would learn from each one, or which of them you could walk back. So the ordering ends up coming from whoever argued hardest in the last meeting, and the plan gets re-argued every month.

The short answer

A technology roadmap for a startup is a short, ordered list of bets, and the order comes from two questions asked of every item: what do we learn by building this, and can we undo it if we are wrong? Cheap, reversible things that teach you something go first. Expensive, hard-to-reverse things go as late as you can push them, unless delaying makes them more expensive, and then they go early on purpose.

The method fits on one page, you can explain it to an investor in a minute, and it gives you a way to say no to card thirty-seven that is better than “we ran out of quarter.”

Why this matters now

Everyone is shipping faster. If your first version came out of Lovable, Replit, Bolt.new, or Cursor, or your developer is running Claude Code all day, the cost of building any single feature has dropped enough that choosing the order has become the bottleneck. A team that can ship a feature a week and picks them in the wrong order will burn the same runway as a slow team, and it will burn it with more confidence.

Three years ago a founder could ship in a bad sequence and blame the tooling. Now the tooling is fast, so the sequence is the only thing left to blame.

What a technology roadmap actually is

Strip the vocabulary off and a roadmap is a decision about order. The list of things you might build is the backlog (the pile). The roadmap is which pile items you are doing next, in what sequence, and why that sequence.

The “why” is what most founders leave off, and it is the part that turns a list into a tool. When the order is written down with its reasons, the next time a customer asks for something new, you can hold the request up against the reasons instead of against your mood. “This goes after the billing rewrite because it depends on knowing what a customer costs us” is a sentence you can defend in month nine. “It felt important” is not.

In one organization I led the R&D for a cloud migration and presented the strategy to the business stakeholders who would pay for it. I had the cost estimate, the risk analysis, and the target architecture, and the technology was honestly the easy part. What took the time was getting the people paying to understand what it would cost, what could go wrong, and what they would get, well enough that they could make a decision they were confident in. What they needed from me was the strategy broken into decisions small enough to say yes or no to, each with its own cost and risk attached.

Why the feature-list roadmap fails

The feature-list roadmap is the Notion board with a quarter label stuck on each card. Q1 gets onboarding, reporting, and Stripe, and Q2 gets the mobile app. It looks like a plan, and it carries exactly as much information as the board did, plus dates.

It fails for three reasons. First, it treats every item as the same kind of thing. A new report and a change to how you store customer data both look like a card, and one of them takes a week to undo and the other one takes a year. The board shows both as a card of the same size.

Second, it has no room for what you learn. If you ship onboarding in January and discover that half your signups are a customer type you never planned for, the February card does not know that. So you either follow the plan anyway or you throw the plan out, and either way the plan was not doing its job.

Third, dates on a startup roadmap are almost always a guess written down as if it were a commitment, and the team knows it. When the dates slip (they will), the roadmap loses its authority and people stop opening the file. A Gantt chart, if you have not been handed one yet, is the bar chart of tasks against a calendar, and it answers “when will this be done.” A startup mostly needs to answer “what should we do next and what would make us change our mind,” which is a different question.

How to sequence: the two questions

Take every item on the board and ask it two questions. Write the answers down; a single word each is fine.

What do we learn by building this?

Some items are pure delivery: the customer asked, you build it, you know exactly what happens. Some are experiments wearing a feature costume, and those are the valuable ones early on, because the answer changes what you build after.

On Mira, an AI exam-prep product for medical residency candidates that I built end to end as the sole engineer, I sequenced cost metering ahead of pricing. Before the product had a price, every AI request recorded what it cost in tokens, which meant that by the time the pricing conversation happened I could say that one quiz cost $0.009 in AI spend and the product broke even at seven paying users. That was a small piece of work next to the pricing decision it fed, and it meant the price was set with arithmetic behind it. Pushing the metering later would have meant setting the price blind.

The general form: if an item would change how you make a later decision, it goes before that decision, even if it is boring, even if no customer asked for it.

Can we undo it?

This is the question that separates a roadmap from a wishlist, and it is the one your developer can answer better than you can, so ask them directly: “if we build this and we are wrong, what does it cost to take it back out?”

Most features are reversible. You add a report, nobody uses it, you remove it, you lost a week. Some decisions are close to permanent: how you store customer data, how you handle who can see what, whether your product supports one kind of customer or many. Those are cheap to decide early and brutally expensive to change once there are customers on the other side of them.

Mira is the example I keep coming back to. The engagement was for one market, exam prep for one kind of medical trainee, and there was every reason to build for exactly that market. But the cost of designing for a second vertical on day one was small, a handful of decisions about how the data was shaped and how one customer’s world was kept separate from another’s (multi-tenancy, which means many customers sharing one system without ever seeing each other), so I made those decisions before there was a single user. Adding a second vertical now means inserting a data row, and nobody touches the code. The same decision made after launch would have meant reworking the data model with paying users already inside it.

I made the opposite call on the shape of the codebase itself. Mira is a modular monolith, which means one deployable application with strict internal walls between its eleven areas, and those walls are enforced by automated tests that fail if one area reaches into another. I could have split it into separate services from the start, and plenty of engineers would have. I did not, because splitting later is a decision I can still make, and building it split from day one would have cost months I did not have. Reversible things go late, and that one I still have not needed to make.

Put the two questions together and the sequence mostly writes itself: cheap and teaches you something, first; irreversible and cheap now but expensive later, also first; reversible and does not teach you anything, whenever a customer will pay for it; irreversible and you do not have enough information yet, deliberately delayed, with a note about what information would unblock it.

Now your forty-one cards. Onboarding goes first because you honestly do not know who will sign up, and the answer changes what you build next. Keeping each customer’s data separate, and who can see what, go first too: cheap before anyone logs in, a rework with paying users inside it after. So does taking money, one flat price through Stripe Checkout: prices can change, and the thing to learn is whether anyone pays. The pricing model waits on the metered AI cost. The report your biggest prospect asked for is reversible and teaches you nothing, so it ships when they sign. Same for the mobile app. The rebuild sits in the last bucket with its unblocking condition written next to it. Nine of the forty-one come out like this, reasons included, and the version to hand your developer has a question attached: which of these answers would you change?

How far out should a startup roadmap go?

Ninety days in detail, and past that just themes, by which I mean sentences as loose as “get to a second customer segment” or “get off the prototype codebase.”

The next ninety days should have specific items with their two answers attached. Past that, you know the shape of what you want but you do not know the items, and pretending you do is how you end up with the Gantt chart nobody opens.

The honest reason for ninety days is that it is about how long your current information lasts. A quarter in, you will have learned something from the experiments you sequenced first, and the roadmap should be rebuilt from that. A roadmap that survived unchanged for a year either got lucky or stopped being read sometime in March.

One more thing on detail. The roadmap should be short enough that you can hold the whole thing in your head. If it does not fit on one page, you have written down the backlog again with better formatting.

“My developer keeps their own roadmap”

Good, ask to see it.

Developers keep a list of things the code needs: upgrades, cleanups, the piece that was built in a hurry and everyone knows it. This is real work and it belongs on the same roadmap as your features, run through the same two questions. Some of it is irreversible-and-getting-worse (a data model that gets harder to change with every customer added), and that belongs near the top. Some of it is tidiness that can wait for a quiet month.

The failure is two roadmaps, one for features and one for “tech,” that never get compared. Then the founder feels blindsided when a quarter goes to something invisible, and the developer feels like nobody values the work that keeps the product standing. Put both on one page, rank them together, out loud, and expect the ranking to take the whole hour.

This is also where the rebuild question lives. If your prototype has a ceiling, the rebuild is an item on the roadmap with two answers like everything else: it teaches you very little (you already know what the product does), and it is close to irreversible. That puts it in the “deliberately timed” bucket. It goes in when the cost of staying on the old codebase starts rising faster than the cost of the rebuild, and you sequence the things that would change the rebuild’s design ahead of it, so you rebuild once.

When the roadmap should change

The roadmap changes when one of the two answers changes. A customer conversation reveals that an item you thought was reversible has a contract attached to it. An experiment comes back and tells you the market you were building for is the wrong one. A vendor announces a price change that makes a “later” decision an urgent one.

It should not change because a big prospect asked for a feature on a Tuesday. That is the moment the written reasons do their job. You hold the request up against the order, and either it changes an answer (in which case, re-sequence) or it does not (in which case it goes in the backlog with a note, and you tell the prospect a real date instead of a hopeful one).

The market moving is the usual objection here. “Things change so fast, why plan at all?” A plan that assumes the world holds still is the Gantt chart, and this method assumes the opposite, which is why it comes with a ninety-day expiry date.

Anti-patterns to avoid

Sequencing by loudness. The item goes first because the person who wanted it argued hardest, or because the biggest customer asked. Neither is a reason. Run it through the two questions in front of everyone and let the answers do the arguing.

The permanent “later.” An irreversible decision gets pushed because it is uncomfortable, and every month it stays pushed it gets more expensive. Multi-tenancy, how you store payment data, and who-can-see-what are the usual suspects. If an item has been “next quarter” three quarters in a row, somebody is avoiding it.

Roadmap as promise. The roadmap gets shown to a customer or an investor with dates on it, the dates slip, and now you are managing a broken promise instead of a plan. Share themes externally and keep the ordered list internal, where it can change.

The rewrite that ships nothing for six months. The rebuild goes on the roadmap as one giant item with no learning inside it and nothing customer-visible until the end. If a rebuild is genuinely needed, sequence it in pieces that each ship something, so that something reaches customers every few weeks while it happens.

How to start, gently

This takes a Tuesday afternoon with your developer, and no tool, template, or workshop.

Take the board you already have. Write two columns next to it: “what we learn” and “can we undo it.” Fill them in together, one word each, and argue about the ones your developer answers differently than you do.

Pull out anything that scored “teaches us a lot” or “cannot undo, and cheaper now than later.” That is your next ninety days, in roughly that order. Everything else stays on the Notion board.

Write one sentence of reason next to each of the items you pulled. People skip this step, and it is the one that makes the roadmap useful in month nine.

Then put a date on your calendar ninety days out to do it again, and agree in advance on the two or three things that would make you do it sooner.

If you want a second set of eyes on the order, bring the board to a clarity call.

What is the item on your list that has been “next quarter” for three quarters?

#FractionalCTO #StartupTech #TechLeadership #StartupFounder #SoftwareArchitecture