3 ms·
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
by soneca 8y ago
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.
- 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.