In 2017, McGill's X-1 Accelerator asked me to teach the product workshop to that year's founders cohort. I was VP of Product at GradeSlam at the time, and I spent the session showing them how to build a product roadmap. The deck is still online, if you want to take a look.

I read it again the other day, half expecting to cringe. I did on the design. On the content, I didn't. The method still works. Managing a product roadmap in the agile way is still the way to go.

What changed is the world it was built for. Since then, AI has changed how products get made and how fast you can ship them. A lot of what I taught that day, the slow and manual parts, breaking the work into tickets, estimating each one, building it all by hand, you can now do in an afternoon. But the reason you build a roadmap in the first place hasn't moved. If anything, AI made it more important.

And that reason is simple. A roadmap isn't a promise about what you'll build. It's a plan for what you'll learn next.

I learned that at GradeSlam, where some of our best wins never showed up on a roadmap. We found them by watching people get stuck and testing assumptions fast. One small change to how students started a session lifted session starts by about 25%, and I've written about it already, so I won't retell it here. The point is the pattern. The value wasn't in the plan. It was in the loop: try something, watch what happens, learn, go again.

You're placing bets, whether you admit it or not

Why a list of bets? Because of one rule nobody gets around. You can't build everything at once. There's always more you could do than time to do it. So a roadmap, under all the colors and quarters, is just the order you've chosen to test your ideas. You pick the few most likely to work, you build them, you watch what people actually do, and the results pick the next one.

That's the part I rushed in 2017. I handed founders a clean framework and they left happy, but the framework was never the point. The learning was. A plan that lists features and dates but can't tell you what you expect to happen, or how you'll know, isn't a roadmap. It's a to-do list in a nicer outfit.

Building got cheap. Judgment didn't.

For most of my career, building was the expensive part. You chose your bets carefully because each one cost weeks, and a wrong guess was slow to undo. That's over. With AI, you can describe an idea in the morning and put something real in front of users by the afternoon.

So AI changed the speed, not the logic. When building gets that cheap, the hard part just moves. It moves to the two things AI still can't do for you: deciding what's worth building, and reading what really happened after you shipped. Both are judgment. Both are yours.

Here's the part I didn't see coming. You'd think cheaper building would mean looser planning. The opposite happened. The old advice was to keep plans light and figure it out as you go. AI rewards the reverse, because it follows a clear brief beautifully and fills a vague one with confident nonsense. The careful spec is back, and the plain requirements doc is useful again, this time as the brief you hand the machine. You don't need fifty pages. For an early product you need one page sharp enough that a fast, literal builder can run with it without you in the room.

Plan in bundles, not features

When building is cheap and feedback is fast, the way you package work changes too. Here's what that looks like in practice.

Say you want more new users to finish their first session. A few years ago you'd write that as six user stories and ship them over a quarter. Now you treat it as one bundle: simplify the first screen, cut a step, add a nudge when someone stalls, show a clear finish. One outcome, one bundle of work behind it, one number to watch. You ship it in days, read the result, and decide whether to push or drop it.

So you stop tracking a long list of small tasks and start tracking a short list of bets, each one aimed at a number you care about. The roadmap gets shorter and more honest. It also changes more often, because the feedback finally comes fast enough to change it.

A test you can run Monday

It comes down to one check. Open your roadmap and read it line by line. For each item, ask two things. What do I expect to happen? How will I know? If you can answer both, it's a real bet and it earns its place. If you can't, it's not a plan. It's just something you decided to build.

That workshop at McGill was really about those two questions, even if I didn't say it that plainly back then. The loop is the whole game. Make a bet, ship it, learn from it, choose again with better information. AI hasn't replaced that loop. It's just made it spin faster than I could on a whiteboard in 2017.

Which is why you should hold every plan loosely. Write it in pencil.