Hacker News Reader

Comment by xyzelement | Hacker News Reader

I am a "Group Product Manager" and at least on skim, this article doesn't seem crazy. I would expect myself and folks on my team to articulate these things - or call out when we don't have something for a good reason (eg we're making a speculative bet.)

The thing that I don't expect is that the roadmap would stay static. Reality changes over time, you encounter new customers and opportunities, learn what's harder or easier than you thought, etc. So I would say "this is what we have today" and if that evolves somewhat even a few months down the line as we learn more, great. But at any given point, you should be able to articulate your best understanding in something that does hit against these checkpoints.

View on HN

Right, so you're claiming that everything in your roadmap is scoped? That's what the article says to require.

At least on some level, sure. Meaning if we have something far out and we just say "build for x and we'll figure that out closer to the date" that's fine.

But if it's say in the next few months we better have a good stab at what the MVP or the next iteration and the initial market could look like.

I agree with this. If you're working in now/next/later terms, you should have a more detailed definition of scope as things move from 'later' to 'next' and especially to 'now', but things shouldn't get onto the roadmap without at least an idea of what kind of lift you're planning to take onto your schedule.

Roadmaps come in many different flavors depending on the company/culture/processes/etc. For an org where roadmaps are more formal/solidified - a healthy level of "product discovery" should be happening before items are put on the product roadmap. We do it this way at my current company (am a Product Director, leading multiple Product teams). When items are put on the roadmap, scope may not be 100% final, but there is a relatively high level of certainty for what's in/out of scope based on customer & business value, as well as clear prioritization based on value/effort. And for larger scope/high priority items, they've already been aligned to a good extent across key stakeholders & partner product/engineering teams before formally being put on the roadmap.

Scoping is pretty much bs until the thing is mostly done anyway.

Reply on news.ycombinator.com