Why are product roadmaps are all about output?
There are 2 inconvenient truths about why product roadmaps are all about output and why they lead to poor results.
- Half of the product ideas are not going to work. Why?
- Customer's are not as excited about the product as we are (no value)
- Sometimes it's complicated to use the product and the users don't use the product (usability isn't there)
- Sometimes it takes a long time to build it (feasibility isn't there)
- Legal, financial or other business constraints become a blocker (no business viability)
- Even when the ideas are valuable, usable, feasible and viable, it takes several iterations to deliver the product to customers
As a PM, it is important to acknowledge these truths and tackle them head on by iterating fast to an effective solution. With tools like Claude Design, Bolt, Lovable, Replit, Cursor, v0, etc, it has made prototyping much more efficient. PMs can quickly create a mock-up within mins and share it with stakeholders, engineers, users and customers and get real feedback.
When the roadmap gets filled with a list of ideas, these are interpreted by people across the company and you become committed to build them even if doesn't solve the underlying problem. PMs need to solve the underlying problem, otherwise we are just delivering a feature (output), not outcome.
To build roadmaps that are outcome based (outcome based roadmaps), product teams should align each item on the roadmap as a business problem to solve rather than a feature or project that may or may not solve the business problem. Outcome based roadmaps are similar to the OKR system.