Ask HN: How to properly manage a product roadmap?

Get a piece of paper out and draw a bunch of circles on the left, and a bunch of circles on the right. This is your business team and development team respectively.

Now draw lines between all the circles. Those are your lines of communication without a PM. This is a sad diagram, no one knows the whole story.

Now repeat the exercise but draw an additional circle in the middle of the page.

This time, the lines on the left and right connect to the middle circle. This is a happy diagram, the developers aren’t pulled in a dozen different directions and one person has the whole picture.

That is the role of a PM.

A lot of good responses here, but they're all missing the core problem from your post:

> business team is constantly changing priorities based on new client requests

If you have a separate "business team" that changes the priorities, they are managing the roadmap, not you. If you have a situation where you are accountable for the roadmap but other people get to make all of the roadmap decisions, you are in a very difficult position. The most important thing for you to do is focus on communication and clarity.

If you aren't already, you need to be tracking everything from week to week. Record a snapshot of the priorities on a given week, along with any "business team" inputs that change the priorities. You need to be able to show in detail where each priority started, stopped, paused, or was re-ordered. You also need to be able to show who directed the priority change. Work on a report or slide format that can clearly show how the priority list has evolved over the course of the year, and don't be afraid to put names next to each priority change ("Moved to #3 priority on Mar. 3 after request from Bob").

If the priorities are constantly churning to chase whatever client requests are coming in, the sales team has hijacked the PM process for their own personal gain. The best way to push back against that is to shine some light on it by tracking it, visualizing it, and communicating it with leadership. Once you make it clear and obvious, it's much easier to get leadership to clamp down on priority changes and drive toward some commitment.

But as long as the business team can quietly reshuffle the priority list each week and let other people suffer the consequences, nothing will change.

Uhh... I imagine it's different with each situation and product.

But look-- if you're letting other people come in and define your vision for you... well, you're no longer doing management-- you're following someone else's vision and they're managing.

You own the product vision. You choose what to incorporate.

I'd ask google so you can find some books and in depth knowledge. A comment or two in a forum is decent for tips, but if you want knowledge, I'd go seek it where it is developed in depth: books.

This is a good point of view. Depending on your team or your org as a whole, it may be that you can manage communications just fine without one, but most of the time you can't. Also, in my org at least, the PM's main job is watching the budget.

In my experience as an engineer, and also as a founder, good PMs are extraordinarily valuable. Having lead engineering teams and also started a company, I can safely say that prioritizing feature development is one of the hardest and most important things that needs to happen, and it never stops, it needs constant attention. A PM is a liaison between multiple teams - executive, sales, marketing, design, engineering, testing, QA, and last but not least, customers. They are responsible for wrangling the priorities and the schedule, and doing that is a full time job, often in larger companies of many people, not just one.

There’s a lot of assumption built into the framing of your question. Why do you think a PM is a middleman and only creating meetings? Is this based on some experience? Why is your premise that the business team owns the roadmap? Bad PMs do exist, just like bad managers, and just like bad engineers. If that’s where your question is coming from, I’m sorry, but please don’t assume that a bad experience is universal; it’s not.

In a business, there usually needs to be a healthy tension between what sales and marketing ask for, what the executive leadership see in the future, what customers need (which is not always what sales and marketing are asking for), what is on the engineering backlog, how difficult features are to implement (both how long, and also how disruptive they are), and anything the product needs that is not on one of those previous lists. When one team or one point of view dominates, bad things tend to happen. If sales and marketing gets to dictate what happens and engineering is relegated to implementing whatever they say, the roadmap can be too short-term and full of churn, it will lack focus and forget about existing customers. If engineering has complete control over the roadmap, it sometimes drifts away from what customers need and toward what engineers like to do, with solutions that are neat but overly complicated or using new technology for the sake of learning. You need a little of each, as well as some pushback from every direction to keep everyone happy. A PM has their work cut out for them.