Ask HN: How to properly manage a product roadmap?

I have been a PM for a few years (and an engineer for many years before that), and my experience is that you don't want your customers to decide your product roadmap, but you definitely allow them to influence it. Your job is to balance between features that will please existing customers and features that will move the business ahead to new customers.

In general, you should have an idea of the next projects you are going to work on. When customers give feedback, that can help to reorder the projects. If you are doing your job correctly, there won't be any huge surprises.

There will be occasional one-off customer requests. We call these "customer love" at my company. We reserve some percentage of our development time (maybe 10-20%) for doing these, because they do create a lot of goodwill with customers. But you have to be pretty disciplined about making sure that they are 1-2 days or less of work and not 1 or to months of work.

There will occasionally be things that customers demand as part of a deal cycle. In some cases you have to build these, but it is important to explicitly highlight what you are foregoing and to be conscious of this tradeoff. Note: hiring contractors doesn't really work well, because someone will have to support it (just went through this).

It's a lot of work to make it work smoothly, but I've done it at several places, so it absolutely can. :) Some notes:

> Most business stakeholders will never be able to describe

That's what planning poker helps with. The engineers envision what they think business wants. Then you go back with the estimate and a description of what will be built, and they either sign off or say "that's not it at all!" The latter happens frequently. You may have to do a couple rounds of planning poker, especially in early days.

> 2 weeks is an eternity is a fast moving business.

I've never experienced that. What industry are you in? Obviously there are urgent exceptions, but when you take into account design, engineering, testing, and deployment, it's hard for me to imagine things taking less.

> estimates will be low by either a factor of 2 or 3

That's what the points estimation and sprint burndowns are for. After a few iterations, estimates become surprisingly accurate. (They never are at the start.)

> everyone else will take it as a promise

You need management's support for the process. And it takes a lot of communicating. 10x more communicating than you think it will.

The rest of it sounds like you work somewhere that's pretty toxic. And of course no process can fix that. But if you call your job chaos management, I highly recommend looking for a new job. ;) That happened to me as well at one unfortunate job...

> "we NEED user feedback but it cannot dictate the roadmap"

Listen to your users but don't trust them.

A 2-week sprint backlog is not a roadmap. Yes, you can and should reprioritize every two weeks, but at a tactical level to better meet your long-term goals based on what you've learned since the last sprint.

A roadmap is a tool for communicating long-term direction and priorities. By making clear what the ultimate destination is, a roadmap helps you keep steady on the those priorities when doing your sprint planning. When sales says "we want this feature to close this deal," if it's something already on the roadmap, great. If it really doesn't fit with the long-term vision, you have a basis for saying no.

I wrote a book on this topic, Product Roadmaps Relaunched, Setting Direction While Embracing Uncertainty, for O'Reilly a couple of years back that goes into more detail: https://www.amazon.com/Product-Roadmaps-Relaunched-Direction...

A better, more up to date book for startups on OKRs is Radical Focus by Christina Wodtke. The examples are more real world. https://www.amazon.com/Radical-Focus-Achieving-Important-Obj...