Product

Treat your roadmap as a list of promises.

The moment you show a roadmap to a customer, it stops being a plan and becomes a promise. We started treating every item that way, which meant putting far fewer things on it and keeping the ones we did. Trust went up. So did focus.

A few years ago I watched a product roadmap turn into an apology tour. The plan was ambitious, the kind of slide that makes a sales team happy and a board nod approvingly, with a dozen items spread across four quarters. By the second quarter, half of it had slipped, two items had been quietly killed, and the largest customer on the list was emailing to ask where the feature was that they had been shown in the deck. Nobody had lied. Someone had simply confused a plan with a promise, and the customer heard a promise, because that is what a roadmap is the moment it leaves the building.

That is the reframing that changed how I do product management. A roadmap shown to a customer is not a forecast of what we hope to build. It is a commitment, and they will hold us to it whether or not we meant it that way. Once you accept that, the entire discipline shifts. You put far fewer things on the roadmap, and you keep the ones you do.

The internal plan and the external promise are different documents

The root of most roadmap pain is collapsing two very different things into one artifact. Internally, a product team needs a working hypothesis about what to build next, full of uncertainty, reordered constantly as you learn. That document should be messy and honest, and it should change every week. It is a thinking tool, not a contract.

The external roadmap is a different object entirely. It is what you are willing to stake your credibility on in front of someone who is deciding whether to trust you with their money and their workflow. The mistake is publishing the internal document, with all its hopeful maybes, to an external audience that reads every line as a commitment. We now keep the two strictly separate. The internal plan is rich and provisional. The external roadmap is short, deliberate, and treated as a promise we intend to keep.

Fewer items, higher conviction

When you decide that every public roadmap item is a promise, the list gets short fast, and that is the point. We went from a dozen committed items per cycle to three or four. The discipline of asking "are we willing to be held to this in nine months" kills the speculative entries immediately, because the honest answer for most of them is no.

What surprised me is how much focus that created downstream. A roadmap with three promises is also a statement about what the team will not be distracted by. It gives engineering air cover to say no to the urgent request that does not serve a committed outcome. It makes product strategy legible to everyone, because the priorities are not buried in a list of fifteen, they are the only three things on the page. Shipping got faster, not because we worked harder, but because we stopped scattering ourselves across a wish list.

There is a hard part to this, and it is saying no to genuinely good ideas to protect the promises you have already made. The pressure to add "just one more" item is constant and it comes from good people with good reasons. Holding the line is most of the job.

How to talk about the things you are not promising

The fear I hear most when I describe this is that a short roadmap looks like a thin product vision. It does not have to, as long as you are honest about the different levels of certainty. We talk publicly in three tiers, and we are explicit about which tier we are in.

  • Committed. A small number of things we are promising to ship, with a rough window. These are the items we will be judged on, and we treat them accordingly.
  • Exploring. Directions we are seriously investigating but have not committed to. We share these to invite input, and we say plainly that they may not happen.
  • Listening. Themes we hear from customers and care about, with no timeline at all.

Customers are far more sophisticated about this than product teams give them credit for. They do not need everything to be a promise. They need to know which things are. A customer who understands that "exploring" means exactly that will not feel betrayed when an exploration does not ship. They will feel betrayed when a committed item slips, because that one was a promise, and they were right to treat it as one.

The "exploring" tier does something else useful that I did not anticipate. It gives the sales team a way to talk about the future honestly. Before, a salesperson under pressure would point at a speculative roadmap item and imply it was coming, because the slide did not distinguish a hope from a commitment. Now they can say "that is something we are actively exploring, and I cannot promise a date," which is both more truthful and, oddly, more credible. Customers trust a company that admits its uncertainty more than one that promises everything. Honesty about the tiers turned out to be a better sales posture than confidence about the list.

What changed when we kept our word

The clearest payoff shows up in trust. When a customer can point to the last three roadmap promises and see that all three shipped, roughly on time, the next promise carries real weight. Trust is the compounding asset in any product strategy, and the roadmap is one of the most public places you either build it or spend it. It is easy to spend it for years without realizing, every time a confident slide quietly fails to become a feature.

Internally, planning got calmer. A roadmap full of promises forces you to do honest capacity work up front, because you cannot commit to four things if you only have room for three. That conversation used to happen halfway through the quarter, in a panic. Now it happens at the start, on purpose, and the planning is better for it. We build and track all of this in Atlas, keeping the messy internal plan and the clean external commitments as separate views of the same work, so the team always knows which is which.

The whole shift comes down to one habit. Before anything goes on the public roadmap, we ask whether we would be comfortable having a customer read it back to us in nine months as the thing we said we would do. If the answer is not a clear yes, it is not a promise, and it does not belong there. Keep the list short, keep your word, and the roadmap stops being an apology tour and becomes the most trustworthy thing you publish.

F

Farhan

Farhan is the solo builder of wrxstack. He designs, writes, and ships Atlas and Portfolio on his own, and writes here about product, engineering, careers, and the craft of building software as one person.