Hacker News Reader

Comment by i386 | Hacker News Reader

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-road... if you want to learn more.

View on HN

Interesting 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.

You 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 :)

Very 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.

Your 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.

Well said

You 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.

Very cool! How do you go about implementing and executing on problem roadmaps?

Reply on news.ycombinator.com