Your Roadmap Died the Day You Shared It. Here's What I Do Instead.

At Sonic Linker, I walked into week one with a crisp 12-week roadmap. We were building an AI SaaS platform, I had done my homework, and everything was prioritized by impact and effort.

By week four, half of it was garbage.

Not because we were bad at execution. Because a customer called and said, "This workflow you built doesn't match how we actually work." And they were right. We hadn't talked to enough people before locking in features.

I see this pattern everywhere now. PMs build roadmaps like they're committing to a construction blueprint. But software isn't a building. It's a conversation with reality, and reality talks back fast.

The roadmap is a promise you can't keep

Here's what kills most roadmaps: they're built on assumptions that haven't been tested yet.

At Finvestfx, I inherited a backlog full of features our enterprise clients had "requested." On paper, it made sense to build them. But when I actually sat down with treasury teams at these companies, I realized half those requests were workarounds for a core workflow that was broken.

We didn't need five new features. We needed to fix one thing properly.

But the roadmap had already been socialized. Leadership expected those features. Sales had promised timelines. And I had to go back and say, "We're throwing out two months of planned work because the plan was based on what people said they wanted, not what they actually needed."

That's the lie: roadmaps pretend we know more than we do. They create false certainty because stakeholders want certainty. But in early-stage products, certainty is expensive. It means you're not learning fast enough.

What I do now instead

I don't build roadmaps anymore. I build hypotheses with expiration dates.

At Sonic Linker, we worked in three-week chunks. Each chunk had one big bet we were testing. Not "build X feature," but "we believe users will retain better if we reduce onboarding friction by 40%." The feature was just the experiment.

If the hypothesis held up after three weeks, we doubled down. If it didn't, we killed it and moved to the next one. No guilt, no sunk cost fallacy.

This sounds chaotic, but it's actually more honest. I can't predict what customers will do. I can predict what I'll test next and how I'll know if it worked.

Here's what that looks like in practice:

The difference between this and a traditional roadmap is I'm not lying to anyone. I tell stakeholders, "Here's what we're testing this month. I'll know in three weeks if we're right."

That honesty buys trust. When I had to pivot at Finvestfx and redo our entire workflow layer, leadership didn't panic because I had trained them to expect learning, not certainty.

The one thing that stays fixed

I do keep one thing constant: the problem we're solving.

At Sonic Linker, the north star was "help teams move faster without breaking things." The features changed every month. The workflows evolved. But that problem stayed locked in.

That's the real roadmap. Not a Gantt chart. Just a clear problem and a willingness to keep testing until you solve it properly.

When I coached insurance advisors at NJ Group, I saw this same issue. They'd build these elaborate client engagement plans, then get frustrated when clients didn't follow the script. The good advisors didn't have scripts. They had a clear goal (get the client protected) and they adapted every conversation to get there.

Product management is the same. The goal is fixed. The path is not.

What this means for you

If you're building a roadmap right now, ask yourself: are you planning, or are you pretending?

Planning means saying, "Here's what I'll test next and how I'll know if it worked."

Pretending means saying, "In Q3 we'll ship Feature X and users will love it."

One of those is honest. The other is a lie you'll have to apologize for later.

I stopped apologizing. I started testing. And my roadmaps stopped dying because I stopped building them in the first place.