Dear all,
during a workshop last week with a client’s IT „product team“ and their „business“ counterparts, we experienced a typical conflict. Working through a particularly thorny backlog of requirements from the business’ side, we came across an item, which described and demanded a particular feature. The representative of the dev team immediately rejected the implementation as described on technical grounds, as the feature would not work as intended under various circumstances.
When we discussed the item in more depth, it quickly became apparent that the requestor had a very desirable outcome for the product’s users in mind. Still, he had chosen to request a specific feature (an output) that in his mind fulfilled the perceived requirement – rather than describing the intended user’s benefits and asking the dev team to fulfill them in the best possible fashion within the accepted constraints (the outcome).
For this reason I would like this week to come back to the ontological question of Outcomes v. Outputs driven roadmaps and product development.
Ship outcomes, not just features, with the Product Impact Framework
– Brian Donohue and Robbie Allan discuss Intercom’s Product Impact Framework and why outcome orientation still may not work under all circumstances. VERY thought provoking!!
Do This Now: 8 Ways to Focus your Product Team on Impact, Not Features
– John Cutler clearly sides with outcomes, discussing 8 ways to focus on impact, not features
Outcome-Driven Roadmapping: The Secret to a Focused Product Strategy
– Heather McCloskey makes the case for an outcomes driven product strategy and roadmap.
Frankly, I tend to side with proponents of outcome and impact-driven product strategies, but regard Brian’s and Robbie’s profound discussion quite thought-provoking.
Enjoy the extra February day! (I’ll be visiting my Mom who’s had way fewer birthdays than me by now…)
Cheers,
Godehard