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.
