5 ms·
PMs spending too much time on specific features is the key reason I advocate for problem-based roadmaps rather than feature roadmaps. All data points and feedba
by i386 8y ago
PMs spending too much time on specific features is the key reason I advocate for problem-based roadmaps rather than feature roadmaps. All data points and feedback is often retrofitted as support for the initial feature solution (aka the feature you thought of first) rather than being used to diagnose the underlying problem.
I wrote an article about this at https://medium.com/product-managers-at-work/the-product-roadmap-is-dead-welcome-to-the-age-of-problem-roadmaps-7c7745ac8ae0 https://medium.com/product-managers-at-work/the-product-road... if you want to learn more.
- soneca 8y agoVery interesting article! My doubt is about how to use a "problem roadmap" in practice. It seems to me that a client problem is rarely completely "solved". So how to decide when it is time to move on to the next problem? It is clear when a feature is "done", it is less clear when a problem is done.
- woolvalley 8y agoYour problems usually should be measurable, and sometimes %80 of the work is creating systems that can measure it. By thinking of how do I solve the problem first, instead of features, you might skip making a lot of stuff that is unnecessary in actually solving the problem. One example is application startup time. Or revenues. User survey scores and so on. The problem roadmap informs the feature roadmap.
- i386 8y agoWell said
- i386 8y agoYou might not ever close a distinct problem if it’s core to your products purpose. It just keeps accreting evidence and pushing you towards creating better solutions. Think about this problem as an example: Jane wants to listen to music when she’s mobile. Solutions: iPod, iPod Mini, iPhone, ??? Each iteration is making a better way of listening to music when you are mobile. As technology improves better solutions can be built to solve the same problem. Edit: I hate Apple scenarios but the iPod line up is the best example I’ve seen where iterating on solving the same problem vs solution had a remarkable result.
- LukaAl 8y agoInteresting point of view. I would challenge this article by asking you what you are using the roadmap for. For me, a roadmap is mostly a communication tool. Off course, if I say I'll do something there's a commitment to that. But I always try to create an understanding that my roadmap is more a vision open to refinement and improvement than a set of solutions. In this context, I find a feature roadmap easier to share most of the time. Discussing which problem I'm solving is always difficult for many reasons: 1) unless I'm really unfocused, the big problem I'm solving should be the same. I could tackle different parts of the problem, but it is more difficult to communicate 2) when you present a priority between problems you are solving, people develop a "negative" mood. Every problem is a priority. If you focus more on general features, there's more the issue of creating "pet projects". That said, I always use a problem point of view when working on prioritization and approaching a product.
- i386 8y agoYou use them in the same way you use feature roadmaps: a rough report on when you’re promising to develop and deliver value. You can combine the two if you think of the problem as a “theme of solutions” you’re going to go build features for in your feature roadmap. Thanks for this challenge - I think it deserves to be the topic of a follow up blog post :)
- capkutay 8y agoVery cool! How do you go about implementing and executing on problem roadmaps?