Short answer: Both require you articulate product strategies (problems to be solved), metrics (lead indicators), then guess which projects will move your metrics, over time. Choose what works for you.
This is gold! Been working on an outcome-based roadmap and have been facing some challenges with the engineering team. The engineering manager fears having this more "subjective" prediction instead of objective projects, which would allow him to foresee how many people he needs to hire and how to organize the team. Any tips on dealing with it?
One is about outcomes, the other is about output. I don't think there's a 'choose' but more like, why not use both? Focus on outcomes to plan your strategy, then look at your output and outline how and when things are meant to come through with the appropriate context. The issue generally is when people only choose project-based (timelines) that don't fully communicate the full picture and incorrect expectations are given. However, no harm in having both, if anything, it's probably better!
Thanks, Gib. Great write-up. It may also be a cultural thing as to which approach you want to use. In our organization, it is helpful to align to the project-based approach but the SMT slide was missing. This will be where I will focus my attention.
Love this write up. I find that anytime I present any sort of timeline (even if represented as fuzzy and as a best guess), my stakeholders take it as a commitment. How do you navigate around this using an outcome based roadmap? I find it difficult to believe that no one will ask when you think a solution would be implemented.
Gibs this was really insightful and well thought out. Somewhat related but I recently went through a product prioritization exercise with my PM breaking down features into Now, Next, Later, and Needs validation (qualitative feedback). I really like the Outcome based strategy above because it really leans into the narrative and, as you mentioned, avoids the implication of a rigid schedule.
I'm confused. The outcomes based roadmap still contains the features in the boxes? Shouldn't something like "voice recognition" in the SMT roadmap be "Detect who's watching" in the outcomes based roadmap?
And then underneath have opportunities that could produce the outcome that need validation:
- Voice recognition
- Facial recognition
- Behavioural pattern recognition
I'm no expert, just what I've garnered from around the web about what an outcomes based roadmap is all about. Seems here we don't have dates (good) but we are still married to features rather than outcomes?
Let me point out the obvious flaw. Netflix is not about tech and it is not about 'product', or rather, its product is not the digital wrapper around content but the content itself. The only thing in your roadmap that can increase retention is great content and that is not something that the tech product team can influence. The real product person at Netflix is the producer -- not the 'product manager' who is akin to a logistics person.
This is gold! Been working on an outcome-based roadmap and have been facing some challenges with the engineering team. The engineering manager fears having this more "subjective" prediction instead of objective projects, which would allow him to foresee how many people he needs to hire and how to organize the team. Any tips on dealing with it?
One is about outcomes, the other is about output. I don't think there's a 'choose' but more like, why not use both? Focus on outcomes to plan your strategy, then look at your output and outline how and when things are meant to come through with the appropriate context. The issue generally is when people only choose project-based (timelines) that don't fully communicate the full picture and incorrect expectations are given. However, no harm in having both, if anything, it's probably better!
Thanks, Gib. Great write-up. It may also be a cultural thing as to which approach you want to use. In our organization, it is helpful to align to the project-based approach but the SMT slide was missing. This will be where I will focus my attention.
Love this write up. I find that anytime I present any sort of timeline (even if represented as fuzzy and as a best guess), my stakeholders take it as a commitment. How do you navigate around this using an outcome based roadmap? I find it difficult to believe that no one will ask when you think a solution would be implemented.
Gibs this was really insightful and well thought out. Somewhat related but I recently went through a product prioritization exercise with my PM breaking down features into Now, Next, Later, and Needs validation (qualitative feedback). I really like the Outcome based strategy above because it really leans into the narrative and, as you mentioned, avoids the implication of a rigid schedule.
I'm confused. The outcomes based roadmap still contains the features in the boxes? Shouldn't something like "voice recognition" in the SMT roadmap be "Detect who's watching" in the outcomes based roadmap?
And then underneath have opportunities that could produce the outcome that need validation:
- Voice recognition
- Facial recognition
- Behavioural pattern recognition
I'm no expert, just what I've garnered from around the web about what an outcomes based roadmap is all about. Seems here we don't have dates (good) but we are still married to features rather than outcomes?
Let me point out the obvious flaw. Netflix is not about tech and it is not about 'product', or rather, its product is not the digital wrapper around content but the content itself. The only thing in your roadmap that can increase retention is great content and that is not something that the tech product team can influence. The real product person at Netflix is the producer -- not the 'product manager' who is akin to a logistics person.