I shipped four products solo in 2024-2025. A B2C SaaS platform. A Chrome extension. A piece of live media software. Even an enterprise tool. The longest one took six weeks. The shortest one took one.
I say this so you know I'm not throwing stones from the stands. I've built the thing. Alone. Fast.
I never created a roadmap for any of these products.
Not one shipped the way I planned it. The enterprise tool I thought I was building and the one that shipped has maybe 40% similarities.
Now let me tell you what I see when I look at how the big service firms build products. TCS. Cognizant. Infosys. Wipro. The rest. I see 1990. The tools changed. The year on the invoice changed. The method didn't. And at the center of that method sits a document everyone in the room has agreed to believe in: the roadmap.
It's fiction. You know it's fiction. And everyone believes it anyway.
You already know this scene
A client signs a statement of work. Someone writes a 40-page requirements document. It gets signed in blood. A team of thirty spins up offshore.
They build, for six months, exactly what the document says.
Then they ship it. And the client looks at it and says: "This isn't what we need right now."
You knew this would happen. But the contract was for the document, not the outcome. So everyone shipped the document. On time. To spec. And it moved nothing for the client.
Now ask the question nobody asks out loud. Of everything on last year's roadmap, how much actually shipped, as drawn, when drawn?
If you've sat through more than one of these, the answer is humiliating. A third, maybe. The dates slipped. Priorities lurched when a rival moved. Two "definite" features were bad ideas the moment a customer touched them. And the three things that mattered weren't on the roadmap at all, because nobody knew about them in January.
The roadmap was never a picture of the future. It was a picture of how the future felt in the room the day you drew it. A mood board with deadlines.
That's the thing the best builders refuse to do. Not the planning. The pretending.
This isn't my opinion. It's the consensus of the people who win.
You might think this is one consultant's hot take. It isn't. The people who call the feature roadmap broken are the people who built the products and teams the rest of us study.
Marty Cagan ran product at eBay. His claim is blunt: the feature roadmap is the single biggest source of wasted effort in our industry. Not because the features are bad, but because the format assumes you know the answer when the whole job is to find it.
Teresa Torres makes the next point. A feature list is a bet you place before you've learned anything. You can ship the whole list, every box, on time, to spec, and move no metric at all. John Cutler named the trap: the feature factory. It measures itself by stuff shipped, not problems solved.
Then there's the cruelest part. The moment a roadmap becomes a commitment, changing your mind becomes a failure to deliver. So a smart team gets proof a feature is wrong and ships it anyway. On time. As promised. Because shipping the wrong thing on schedule looks like success, and shipping the right thing late looks like a broken promise. The roadmap punishes the one behavior that separates good product work from bad: learning.
This is the consensus. You are not behind a trend. You are behind a settled argument the best teams resolved a decade ago.
Now, the part where you're right
If I stopped there, this would be propaganda. So let me make your case as well as I can.
Sometimes you must commit far out. Apple doesn't discover a new chip in a six-week cycle. Silicon, supply chains, and regulated industries need bets made years ahead. In those worlds, refusing to commit isn't humble. It's negligent.
And roadmaps do real work that has nothing to do with prediction. They align. They point marketing, sales, support, and three engineering groups the same way without a thousand meetings. Coordination at scale is not theater. It's the job. A client with no shared direction isn't free. They're lost.
So no, the answer is not to throw planning away. Jeff Bezos said it best: "We are stubborn on vision. We are flexible on details." Amazon held its vision for years and threw away the specifics again and again. The third-party marketplace took three failed tries. The vision never moved. The details were always disposable.
That sentence is the hinge. The failure was never committing to the future. The failure is confusing a direction with a schedule. And a feature-and-date roadmap trains you to do exactly that.
Why you didn't change
I'll be fair. You didn't stay in 1990 out of laziness. You stayed because the money worked.
The roadmap sells. It's easy to price. A document plus thirty people plus six months equals a number procurement can approve. Your whole business is built to sell that number.
The honest way is harder to sell. "We'll fix the time, chase the outcome, and find the features as we learn" terrifies a procurement team. It sounds like you don't know what you're doing. So you keep selling the document, because the document is what the client knows how to buy.
You optimized for the sale. You did not optimize for the result. For thirty years, that was fine. The client couldn't tell the difference, and switching cost too much.
That era is over.
What AI just did to your model
Here's what the old debate never had to face. AI collapsed the cost of building.
I now do in hours what used to take me weeks. A working prototype in an afternoon. Not a mockup. A thing that runs. Your junior developers can do this today, with tools that cost less than lunch.
Think about what that does to a business built on selling headcount and time. If the build is nearly free, the thirty-person, six-month project is dead. Not slower. Dead. A client who learns this will never again pay you for thirty people to spend six months building the wrong thing carefully.
And here's the twist that should keep you up at night. AI makes your old method worse, not better. If you build from a fixed feature list, AI just lets you build the wrong thing faster. You'll ship the useless product in three months instead of six. That's not progress. That's the same waste at double the speed. A feature factory running on AI doesn't fix the factory. It speeds up the waste.
So the math flips. When building was slow, prediction had an excuse: each feature was expensive, so each one earned a date and a defense. That excuse is gone. Why forecast twelve months of features when you can build three this week and let real users tell you which one mattered?
When anyone can build anything fast, execution stops being scarce. The scarce thing is knowing which problem is worth solving. The bottleneck moved from the hands to the head.
How to actually do it on the next project
It's easy to nod at all this and change nothing on Monday. So here is the playbook. Not theory. The exact steps. Run this on your next engagement instead of the old one.
Step 1: Replace the requirements document with one problem and one metric.
Before you scope anything, write a single sentence: what problem are we solving, and what number tells us we solved it? "Cut claims processing time from nine days to two." That's the brief. If you can't write it, you don't understand the work yet, and a 40-page spec won't save you. It will just hide the confusion.
Step 2: Fix the time and the budget. Leave the scope loose.
Don't ask "how long will all of this take?" That question has no honest answer. Ask the opposite: "What's the most valuable thing we can ship in six weeks?" The deadline becomes the input, not the casualty. The client gets a fixed price and a fixed date. You get the freedom to change what you build as you learn.
Step 3: Ship something real in two weeks. Not a mockup. A thing that runs.
Build the thinnest version that a real person can actually use. A skateboard, not a car wheel. This is where AI earns its keep. What used to take a quarter now takes days. Use that speed to put working software in front of a user fast, not to build more of the wrong thing.
Step 4: Put it in front of a real user and watch.
Not a steering committee. Not a demo for the sponsor. A person who has the problem, using the thing, while you watch. This is the step everyone skips, and it's the only one that tells you the truth. You will be wrong about something. Better to find out in week two than month six.
Step 5: Let what you learn rewrite the next two weeks.
Take what the user showed you and change the plan. Kill the features nobody touched. Double down on the one that worked. Then ship again. Repeat the loop. Each cycle, you're not guessing further into the dark. You're walking toward the metric with your eyes open.
Step 6: Report progress in outcomes, not features shipped.
Stop telling the client "we completed 14 of 20 stories." Tell them "claims time dropped from nine days to five." That's the only number that matters. It also rewires the relationship. You stop being a vendor who delivers a list. You become a partner who moves a number.
Run that loop and the roadmap takes care of itself. It stops being a list of features with dates, the fiction your clients have read enough of to ignore. It becomes a list of problems you're betting on, in rough order, held with exactly as much conviction as the evidence has earned. It commits to a direction and stays loose on the path. That's the thing worth selling. Not the document. The judgment.
The choice in front of you
So here's where you are. The build got cheap. The client got smart. The roadmap got exposed. And the honest method has been sitting in plain sight for ten years, free, while you kept selling 1990.
You have two roads.
You can keep selling headcount and time, watch your margins fall as AI makes the build worth less every quarter, and lose your best clients to firms half your size who ship in weeks.
Or you can change what you sell. Stop charging for people in seats. Start charging for outcomes. Build fast, learn faster, and use AI to find the right answer instead of building the wrong one at speed. Stop selling the schedule. Start defending the bet.
I've shipped four products and never once built the roadmap I expected to. That's not a confession. That's the method. I planned in pencil and shipped in ink, and the gap between the two is where every good decision lived.
Your clients have already started building this way inside their own walls. The only question is whether they'll keep paying you to catch up, or replace you with someone who already did.
It's 2026. Build like it.