4 ms·

This is very idealistic and removed from reality. Most companies are so messed up that there is no coherent strategy, so you cannot require a single product man

This is very idealistic and removed from reality. Most companies are so messed up that there is no coherent strategy, so you cannot require a single product manager to have an excellent roadmap, when the conditions for creating one is not there. You also may be working on a product or area that is far below the high level strategy, so it's goals would be different. If an engineer really goes and thinks they should evaluate a roadmap like this, that's toxic.

xyzelement 3y ago
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.
- user_named 3y ago
  Right, so you're claiming that everything in your roadmap is scoped? That's what the article says to require.
  - xyzelement 3y ago
    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.
    - eropple 3y ago
      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.
  - fooster 3y ago
    Scoping is pretty much bs until the thing is mostly done anyway.
  - mfrommil 3y ago
    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.
mmmmpancakes 3y ago
It may be ideal to have all these items checked off. I think a productive way to look at this is "how many of these items does the roadmap check"? If the answer is "very few" then that might be an early warning sign you're working for a product or org that is headed for serious problems. As a technical IC who can't hope to solve those large scale management problems, this can be useful a red flag. Don't wait for shit to hit the fan to leave. I have seen a large scale failure of this kind and the items listed here line up very well with some of the root causes I observed. - Is the roadmap flexible or iterative? The roadmap was hard, aggressive business targets. - Are the roadmap initiatives scoped and prioritized based on evidence? The roadmap initiatives were derived by working backwards from business targets and then evidence was found after the fact. - Does the roadmap identify major dependencies or risks? Many risks were identified much later because techincal teams were not part of input to initial planning. - Does the roadmap feel aggressive but achievable? Aggressive but not physically possible. - Does the roadmap take on appropriate risk? No, there was multiple possible independent points of failure. Anyways, if you ever see this kind of product culture I suggest running for the hills unless you like having your time wasted. And if you are a technical manager I hope you push back like hell when presented with this situation.
deleted 3y ago
[deleted]
spuiszis 3y ago
Author here, thanks for sharing your feedback. To your point, product is a high-stress, demanding role, and in reality, you might not hit every item from this list all the time. This ambitiously attempted to define greatness from when I've been fortunate to get there, see it, or be part of it. Getting to greatness can be done; it's just hard to achieve. I think it deserves that caveat up front, and I will update it. I also agree that low-level teams might be very far removed from strategy, especially in large orgs. However, that team should have a clearly defined goal or mandate instead. So much of the product is context-driven, and the first few drafts were 3-4x longer to account for these differences between organizations, hierarchy, teams etc. I removed most of that to focus more on basic principles because this guide was starting to look like it was written by Charlie Kelly chasing Pepe Silvia accounting for all the edge cases :)
- doctor_eval 3y ago
  I did enjoy this article and agree with almost everything. One piece of advice I’ve learned the hard way, however, is if the road map doesn’t make sense, it’s unlikely that making noise is going to make your life better. I was reminded by this article of the time when my role as a PM was stymied by a lack of clear corporate strategy - I was told to make a road map without the support of any kind of goal or vision, told even that having a strategy would take “11 weeks” (yeah, an oddly specific number). Of course, I pushed back - but the outcome of doing so was very poor for me. A road map doesn’t need to perfectly align with the very good points in your article, but there is a point at which it’s probably just better to cut and run.
  - datadrivenangel 3y ago
    It's so very rarely worth trying to fix pathological organizations.

xyzelement 3y ago

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.

user_named 3y ago
Right, so you're claiming that everything in your roadmap is scoped? That's what the article says to require.
- xyzelement 3y ago
  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.
  - eropple 3y ago
    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.
- fooster 3y ago
  Scoping is pretty much bs until the thing is mostly done anyway.
- mfrommil 3y ago
  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.

mmmmpancakes 3y ago

It may be ideal to have all these items checked off. I think a productive way to look at this is "how many of these items does the roadmap check"? If the answer is "very few" then that might be an early warning sign you're working for a product or org that is headed for serious problems. As a technical IC who can't hope to solve those large scale management problems, this can be useful a red flag. Don't wait for shit to hit the fan to leave. I have seen a large scale failure of this kind and the items listed here line up very well with some of the root causes I observed. - Is the roadmap flexible or iterative? The roadmap was hard, aggressive business targets. - Are the roadmap initiatives scoped and prioritized based on evidence? The roadmap initiatives were derived by working backwards from business targets and then evidence was found after the fact. - Does the roadmap identify major dependencies or risks? Many risks were identified much later because techincal teams were not part of input to initial planning. - Does the roadmap feel aggressive but achievable? Aggressive but not physically possible. - Does the roadmap take on appropriate risk? No, there was multiple possible independent points of failure. Anyways, if you ever see this kind of product culture I suggest running for the hills unless you like having your time wasted. And if you are a technical manager I hope you push back like hell when presented with this situation.

deleted 3y ago

[deleted]

spuiszis 3y ago

Author here, thanks for sharing your feedback. To your point, product is a high-stress, demanding role, and in reality, you might not hit every item from this list all the time. This ambitiously attempted to define greatness from when I've been fortunate to get there, see it, or be part of it. Getting to greatness can be done; it's just hard to achieve. I think it deserves that caveat up front, and I will update it. I also agree that low-level teams might be very far removed from strategy, especially in large orgs. However, that team should have a clearly defined goal or mandate instead. So much of the product is context-driven, and the first few drafts were 3-4x longer to account for these differences between organizations, hierarchy, teams etc. I removed most of that to focus more on basic principles because this guide was starting to look like it was written by Charlie Kelly chasing Pepe Silvia accounting for all the edge cases :)

doctor_eval 3y ago
I did enjoy this article and agree with almost everything. One piece of advice I’ve learned the hard way, however, is if the road map doesn’t make sense, it’s unlikely that making noise is going to make your life better. I was reminded by this article of the time when my role as a PM was stymied by a lack of clear corporate strategy - I was told to make a road map without the support of any kind of goal or vision, told even that having a strategy would take “11 weeks” (yeah, an oddly specific number). Of course, I pushed back - but the outcome of doing so was very poor for me. A road map doesn’t need to perfectly align with the very good points in your article, but there is a point at which it’s probably just better to cut and run.
- datadrivenangel 3y ago
  It's so very rarely worth trying to fix pathological organizations.