TL;DR: In a nutshell, product management is shifting towards principles, outcomes, and the use of cheap AI experiments, and this approach works very well when the product can be altered tomorrow. However, it is less effective when tomorrow begins with a thousand printed NFC tags lying on your desk. Roadmaps are not obsolete; rather, they have two speeds. For reversible work list it under Now / Next / Later and place a named gate on any item that crosses the Commitment Line, which is the observable event after which changing your mind involves a cost.
On July 24, I returned from the mailroom with a box containing one thousand NFC tags. Each of them was forty millimeters in size and bore our fox together with the name Trevean Spice, a detail which will never be seen since, in practice, the tags are positioned hidden beneath the cork liner. I opened one of the sleeves and had a look at the tags before noting the word ‘perfect’ in my journal.
I then recalled that the tap still wasn’t working.
It wasn’t the tags that were the issue; they were fine. The real problem was the destination. The short URL on all of them pointed to a path that didn’t work because the domain wasn’t active. So, I had a thousand pieces of finished inventory that could only direct someone’s phone to a place that didn’t exist.
Two weeks later, things changed unexpectedly. The developer I hired to set up the tap destination informed me that the tags I purchased were from a different chip family and used a different protocol than we thought. While the tags could still be used, the feature to automatically include each tag’s identity in the URL wouldn’t work. This feature was essential for knowing which jar was tapped in which kitchen and was the only important part of the entire project.
I have previously discussed the idea of freezing a decision and then proceeding. In my article ‘The Night We Stopped Changing the Lid’ I claimed that the argument you are still having at 11 p.m. is rarely the result, and that freezing is the way you begin to learn. I still agree with every word I said. The point I had omitted was the other part of the sentence, namely that a freeze is only as good as what you knew on the night you made the call.
The case against roadmaps is a good case.
I want to give the argument I am about to complicate a fair hearing since it is mostly correct.
According to Product School’s assessment for 2026, the practice is ranking towards the top of its list of trends: teams are giving up on long-range roadmaps and instead focusing on principles, outcomes, and ongoing AI-assisted prototyping, with small teams that build, learn, and quickly discard dead ends (Product Management Trends: 11 Shifts Shaping 2026). The alternative that teams most frequently turn to wasn’t created as a mere fashion. Janna Bastow, founder and CEO of ProdPad, developed the Now / Next / Later roadmap with Simon Cast as far back as 2012 for a particular reason: putting features into dated columns turns every date into a promise, and when priorities change, those promises are broken.
She’s correct, and I can attest to that. A plan which states that Feature A should be introduced in March, Feature B in June, and Feature C in September tends to express more confidence than actual evidence. Customers change, markets change, and teams pick up new knowledge. Unlike fixed dates, horizons acknowledge this fact.
In his 2015 letter to shareholders, Jeff Bezos arrived at the same idea by considering the decision aspect at Amazon, dividing the choices into Type 1, which are one-way doors and therefore require careful consideration, and Type 2, the two-way doors for which you should quickly go through them on about 70% of the information you want. Most of the good advice in product management is just a variation of this: first work out which type of door you’re facing and then act at the speed that the door permits.
None of that made sense to me, but a box of tags did. It’s one thing to know a door is one-way, and another to realize you’re the one inside it; that’s when I lost real money.
Some decisions get less reversible while you wait.
The flexible roadmap assumes that uncertainty is evenly distributed throughout the product, when in fact it is not, and the uneven distribution is not arbitrary. The longer you delay making a decision, the more difficult it becomes to change that decision.
I will be able to rewrite a headline on the Trevean website this evening, and I can change a recipe on Thursday without anyone being affected. However, a printing slot doesn’t wait until I am ready, and the ingredient statement on a jar ceases to be editable at a specific moment which I can name down to the second — that is, the second when the final proof reaches the printer. No magical thing occurs to the artwork at that instant; it is simply at that point that the decision crosses a line.
I’ve been calling that the Commitment Line, and it varies from one section of the product to another. Until you cross it, it’s cheap to change your mind; after you’ve crossed it, changing your mind involves paying money, losing weeks, dealing with inventory, or damaging a relationship with someone who then has to redo work they’ve already done.
The tags are the clearest example that I have. I crossed a Commitment Line on the day I approved that order, even though I didn’t realize it, since ordering the tags seemed like a step forward rather than a commitment. The evidence that ought to have been available first, namely, which chip family, which protocol, and what the destination actually does when a stranger taps it, did not arrive until two or three weeks after the box had been received. I carried out the tests in early August: using eight phones, four iPhones and four Androids, with ten trials per phone for each condition, and 160 adjacent-jar attempts to ensure that tapping one jar never opened the neighbor’s story. All 160 attempts resulted in the correct URL; the read distance was four to seven times the margin required on the weakest device, and the floor turned out to be an iPhone XS. All of this was good news, although it still arrived two weeks too late to be of use as a decision input, since the decision had already been made regarding inventory.
I made a similar mistake in Name the Cause Before You Name the Price, when I almost set out an acceptance criterion that no one could have met. In this case, too, I gave a price for a commitment before I had worked out what exactly I was committing to.
The question I should have been asking was not about having dates; instead, it should have been about choosing the shorter option.
When does this decision become too expensive to change?
A product has two speeds.
I currently divide roadmap work into two categories and deliberately use different tools for each.
Lane 1: Reversible
The website copy, the recipes, the educational material, the experience associated with the tap destination, the campaign concepts, the choice of photography, the onboarding process, and the recommendation logic can all be altered without harming the business, so they should all be included in a flexible roadmap. We should focus on outcomes rather than on promises regarding features. Use the Now / Next / Later framework. Conduct experiments and be willing to change our minds when a customer tells us that we are wrong.
Next to a recipe recommendation engine, putting in ‘November 12’ wouldn’t make me more disciplined; it would only make my guess more specific.
Lane 2: Committed
The amounts produced, the final dimensions for packaging, the print files, the label text, the barcodes, the tag encoding, the orders for ingredients, the manufacturing time frames, freight costs, and the launch inventory all have lead times, minimum order quantities, and invoices associated with them; a flexible roadmap does not eliminate any of these things, it only means that they appear as a surprise rather than as part of the plan.
The date for a software experiment is generally just an estimate, while the date for a print run can be based on a purchase order. It’s only when you treat both of them in the same way that you end up with a thousand tags and no tap.
What this looks like in practice
The strategic layer continues to use themes, and reversible work still operates on the Now / Next / Later basis. If anything comes near the Commitment Line, it is given four additional fields. Here they are, checked against the decision I made wrong, so you can see what the correct answers should have been.
1. Decision. Instead, use the specific noun rather than the general category. For example, the production encoding configuration for a batch of one thousand 40mm tags, together with the URL that is carried by each one. Using general categories conceals the decision, whereas using specific nouns reveals it.
2. Commitment Line. You should name the observable event, not a feeling. In the case of the tags, it was the moment when I approved the encoding on the order. In other instances, it is proof of approval, a deposit, a purchase order, the start of production, a database migration, a contract signature, or a shipment. If you are unable to name an event, then you probably do not yet have a commitment, which is also useful to know.
3. Proof is required. Instead of listing activities, provide evidence: one physical tag from this production lot which has been read by at least one iPhone and one Android device, directing to a live page, with the chip family verified against what the software design expects. That amount of work would have taken about two hours and would have picked up both problems before the money was transferred.
4. The cost involved if you decide to change your mind. Give it a figure or a time period, even if it’s only an approximate one. For example, fifty dollars, five thousand dollars, six weeks, or one pallet in a skip. You don’t need accounting accuracy; what you need is enough to distinguish a decision that can easily be reversed from one you’ll have to live with for the entire quarter.
A commitment line that has no requirement for evidence is merely a deadline with more sophisticated branding.
Run across a real roadmap, the output looks like this:
| Decision | Lane | Commitment Line | Evidence before commitment |
| Tap landing-page content | Reversible | None | Customer usage |
| Tag encoding configuration | Committed | Production encoding approval | Cross-device tap test on a live URL |
| Homepage messaging | Reversible | None | Conversion and customer feedback |
| Final label artwork | Committed | Printer proof approval | Physical proof plus copy review |
| Recipe library | Reversible | None | Usage and engagement |
| Ingredient purchase | Committed | Purchase order | Approved production lot, not a sample |
| Manufacturing run | Committed | Production start | Formula, packaging, and QC sign-off |
What is missing from that table is a fake date next to each item. I’m not aiming at making the flexible decisions appear more certain; rather, I’m trying to make the irreversible ones impossible to ignore.
AI makes this harder, not easier.
A strange side effect of developing anything in 2026 is that AI has greatly sped up the reversible layer. I am now able to start with a rough idea, produce a product page, rewrite the copy, compare three different options, and draft the acceptance criteria all within the course of an afternoon, the result looking extremely finished.
It causes your internal clock to reset, and as a result everything begins to seem fast.
You give a label to a printer or arrange for the ingredients or wait for a factory, or realize that it is not your software but the operating system which controls part of the experience. In the case of my own tap, there is an interstitial banner which I have been treating for weeks as if it were a bug; it’s the iOS system NFC notification. It cannot be removed even if you pay any amount, and Android doesn’t display it at all, which is why the jars now have two sets of printed instructions.
The digital aspect of a company operates at AI speed, while the physical side continues to operate at truck, pallet, print, harvest, and human speed. The danger lies in letting the faster side lead you to think the slower one has changed; it hasn’t. The more quickly experimentation takes place, the more important it becomes to know exactly where it stops.
Software has Commitment Lines too.
You needn’t produce jars for this effect to occur; a database migration is a one-way door, just as is a pricing change made public to thousands of customers, a multi-year vendor agreement, a published API that people then begin to build against, a regulatory claim, and ten new hires taken on in accordance with a strategy.
Physical products make the line incredibly obvious: there’s a box in front of you, and you’ve paid for what’s in it. With software, we can pretend the commitment never took place since there’s still an Edit button somewhere, even though this doesn’t make the decision reversible; it only makes the consequences harder to see. I came across the same kind of illusion when working on the AI agent in Stop Tuning the Prompt. The parts that seemed endlessly editable were the ones I had already committed to without having written them down.
The PM lesson
Product managers teach people to keep options open, and that’s sound advice until it turns into an excuse. There comes a time when optionality expires, and a product must become a product. When a file is sent to a printer, a purchase order is signed, a supplier begins production, a database is moved, and a customer receives a promise.
The purpose isn’t to steer clear of such situations; rather, it’s about knowing when you’re about to enter one and having already decided in advance what you need to believe. That approach isn’t simply waterfall planning with a different name; it’s acknowledging that some doors can be opened in both directions while others close behind you, and that a roadmap that can’t tell the difference is incomplete.
I’d also like to remove one point from consideration since I noticed it in July and it turned out to be of no use; if you’ve made a costly mistake such as this, you haven’t missed a step. No one ever teaches this. All the roadmap courses that I’ve done have taught me about prioritization and sequencing, but none of them taught me to recognize the moment at which a choice ceases to be a choice.
What to do this week
- Open the roadmap that you currently have and include two columns, one for Reversible or Committed and one for Commitment Line. Make sure that you carry out this action on the actual artifact and not on a copy.
- For each committed row, identify the event (for example, proof approval, purchase order, production start, migration, signature, or announcement). If you are unable to name an event, then the row is most likely reversible, and you can therefore relax about it.
- For each named event you should produce the evidence bar, making sure that it includes proof and not just activity. Instead of saying ‘do testing’, say ‘tested on a device from this lot’.
- Next to each row headed ‘Committed ‘, put a number indicating the cost in money, weeks, or units if the number is changed later.
- Identify the worst mismatch and deal with that one; the only item that warrants a meeting this week is the one which is currently being managed like a casual backlog card and is three weeks from becoming expensive.
What I’m doing differently
I am still employing Now / Next / Later, still moving quickly in the prototype stage, and still altering the website every time the evidence causes me to do so. The only thing I have introduced is including two questions before any physical, contractual, or operational matter is finalized.
What is the Commitment Line and what kind of evidence do I need before I cross it?
This month I entered into a fixed-price development contract, which is the biggest single commitment I have ever made in this company, and I checked it against both questions before I agreed to it. That is also why the gating dependencies for that project now have dates written on my calendar rather than appearing in the list I look at. Those two questions would have been very valuable before the arrival of a thousand tags; they will be worth a great deal more before the next ten thousand arrive.
What to steal
Before your next planning session, carry out every important initiative using this procedure; you can do it by hand or copy the prompt into Claude or ChatGPT and attach your roadmap at the end. The only change you need to make before running it is to replace my example commitment events with the ones that your business actually has.
You are reviewing a product roadmap for hidden irreversible decisions.
For each roadmap item, return:
1. DECISION
Rewrite the vague initiative as the specific decision being made. Use a concrete noun or a named choice.
2. LANE
REVERSIBLE if the decision can be changed later at low cost inmoney, delay, customer impact, or operational disruption.
COMMITTED if changing it later creates material cost, delay, inventory loss, contractual exposure, migration risk, or customer disruption.
3. COMMITMENT LINE
Name the specific observable event after which the decision becomes materially harder to reverse. Examples: purchase order, production start, print approval, contract signature, customer announcement, API publication, database migration, shipment. If no meaningful commitment event exists, write NONE.
4. EVIDENCE REQUIRED
List the minimum proof that must exist before crossing the Commitment Line. List proof, not activities.
5. COST OF REVERSAL
Estimate what changing the decision after the Commitment Line costs in money, time, inventory, customer impact, and operational disruption.
Use LOW / MEDIUM / HIGH if exact numbers are unavailable.
6. ROADMAP TREATMENT
Recommend exactly one:
NOW / NEXT / LATER for reversible work where learning matters more than dates.
DATED GATE where an external dependency creates a real deadline.
DECISION GATE where commitment should wait until named evidence exists.
STOP where the team is approaching an irreversible commitment without enough evidence.
Finally, identify the three roadmap items with the largest gap between how casually they are currently managed and how expensive they will be to reverse.
ROADMAP:[paste roadmap here]The issue isn’t the classification; it’s the surprise. You’re searching for the item which everyone else regards as just another item on their backlog that is about to become an invoice.
Related reading from PMJ
- The Night We Stopped Changing the Lid. The design-freeze argument this post completes. A freeze is only as good as what you knew when you called it.
- Name the Cause Before You Name the Price. The same failure one layer down, in an acceptance criterion nobody could have passed.
- The Bottleneck Was a Decision I Parked. What postponing a decision costs when it gets less reversible while it waits.
- The Subtraction Audit: A Framework for Removing Features. The companion move for the reversible lane, where cutting is still free.
- Your Moat Is the Part You Can’t Demo. Why the tap itself was never the asset, and the tap data is.
- Stop Tuning the Prompt. Your AI Agent Needs a Contract. The software version of a commitment you made without writing it down.
FAQ
Are product roadmaps dead?
No, the practice of drawing up fixed feature roadmaps which pretend that a team knows precisely what it will build months in advance is becoming less useful, particularly since AI has made prototyping inexpensive. Roadmaps still include strategic considerations, dependencies, and actual commitments. The roadmap style should be chosen according to the type of decision rather than applying a single style to all situations.
What constitutes the Commitment Line?
The observable event after which changing a decision becomes materially more expensive: a print approval, a purchase order, production start, an API publication, a database migration, a contract signature, or a public promise to customers. It’s an event you can put a date and a name on, not a feeling that the decision is getting serious.
How is this different from Bezos’s one-way and two-way doors?
The Type 1 and Type 2 split tells you how fast to decide once you know which kind of decision you have. The Commitment Line asks the question underneath it: which event closes the door, and what do you need to believe before you walk through? Most expensive mistakes I’ve made weren’t from misjudging a door. They were from not noticing I was in one.
Can Now / Next / Later work for physical products?
Yes, for the reversible parts, which are more of a physical product than people assume: discovery, experience design, content, software, positioning. It works less well for manufacturing dependencies with real deadlines. Use horizons for the flexible lane and dated gates for the production lane. Janna Bastow’s original argument was against false date promises, not against real deadlines.
When should a roadmap contain a specific date?
When the date is an external constraint rather than a prediction: a manufacturing slot, a regulatory deadline, a contractual milestone, a print cutoff, an event launch, a supplier lead time, never add a date to make uncertain work look predictable.
What’s the one thing I should change this week?
Add the Reversible or Committed column to your live roadmap, then write the evidence bar for every Committed row. If you find an expensive commitment coming with no evidence bar defined, that’s the work. Everything else on the list can wait a week; that one can’t, and it’s getting less reversible while you read this.
If you found this useful, grab the free Startup PM Toolkit, five frameworks I actually use. And if you’ve crossed a Commitment Line without noticing, hit reply and tell me. I read every one.
Dan
Leave a Reply