Live data from Hacker News

Ask HN: How to properly manage a product roadmap?

news.ycombinator.com

41–50 of 124 posts

Re: Ask HN: How to properly manage a product roadmap?

#41
> Do you let new customers drive your product roadmap, or just decide your own roadmap and stick with it? Which approach works best in order to gain more product velocity?

Both, but you need to learn how to listen and translate customer wishes into the actual jobs to be done. "I want feature x" from customer A, and "I want feature Y" from customer B might be related to the same context and underlying problem, so it's best if you create a level of abstraction to sort customer wishes into. How the actual feature works and how it looks like should be your core competency, not the customers imo.

Re: Ask HN: How to properly manage a product roadmap?

#42
"Do you let new customers drive your product roadmap, or just decide your own roadmap and stick with it? Which approach works best in order to gain more product velocity?"

Customers' needs should always drive the product roadmap. That said, it's not uncommon for customers to not know what they really need until it's already been built. This is where the Product Manager comes in to the picture. The PM needs to ensure everything added to the roadmap is of the highest priority and will solve real customer problems or have a positive impact towards the org's key objectives.

A couple tips that may be helpful for you as you navigate this situation:

1. Before any feature-specific debate, you need to be closely aligned on the overall vision and objectives with your key stakeholders, including the "business team". What are your most important objectives to hit this quarter, this year? Growth in active users? Increased transactions? Improved bottom line profitability? etc. Once this is aligned on, it becomes much easier to have these prioritization/tradeoff discussions.

2. Many "business" teams and the leaders of those teams don't understand the basics of software development. Over time, it's beneficial for the PM to help educate key non-technical leaders about the costs of constantly changing direction. Help them understand how technical teams plan and execute, and show the impact to timeline and quality when reckless decision-making gets in the way of the engineers doing their jobs effectively. I like to this of this as a "help them help you" mindset.

Re: Ask HN: How to properly manage a product roadmap?

#43

Earlier quoted context omitted.

How do you pick the right OKRs?

The first step is: encourage everyone in your team to read "Measure What Matters" https://www.whatmatters.com Then decide what matters to the company and all those involved and write it all down in a shared document.

This book has plenty of real life examples and there's one that might sound close to your reality. I wouldn't say that the whole leadership team needs to read it but I think that the CEO or COO needs to lead an objective based framework such as OKRs to make it successful. Tability also has good readings on their blog: https://blog.tability.io/the-4-stages-of-goal-tracking-how-t...

Re: Ask HN: How to properly manage a product roadmap?

#44
No single customer owns your roadmap, your roadmap is yours.

Unless you're actually billing hours to customers for features, the features you add are yours. Sell what you have now, do not sell based on a future promise.

You need to balance the value of a single customer against the opportunity cost of not building a feature that all customers want.

The way I've found to do this: Qualify every feature request. Get in touch with 10 customers and have a list of the outstanding feature requests, and give them a virtual $100 and say, if you can spend this $100 on these n features and you only have $100, how would you spend it? Then take the answers from the 10 customers and see which added to the highest $$$ income. If a single customer is an outlier with all $100 on one feature, establish with their account manager the state of the account, are they happy? At risk? and prioritise accordingly.

Throughout this process, always have your vision hat on. Is the ask for "add this toggle" or is there an underlying common theme that a different approach could satisfy. This is the "most people wouldn't ask for a car, they'd ask for a faster horse" (not said by Ford but always mis-attributed) symptom... you need to see how features align to your vision, and bear in mind that the customers today may not be the ones you need in the future, startups go through wave of customers and you need to be working up that food chain, so what are the right features to satisfy needs, but put you on a path to the customer you want in the future.

Oh, and I'm an engineering manager not PM but had my own startup and had to do this stuff.

Re: Ask HN: How to properly manage a product roadmap?

#47
I really recommend to check GIST [1] as a replacement for pure roadmaps. It focuses on goals and some kind of experiments to define what should be implemented sooner.

GIST is as close to scientific approach as we have right now.

RICE model might help as well [2]

However, being 100% honest, I tried all the models above and they did not stick to me. I'm playing Product Manager role for 16 years already and rely on customers feedback + intuition. When you have deep experience in the domain, you internalize many models and your neural network in the brain quite often just makes the right decisions. Don't decide quickly though, rely on your "slow" subsystem, decide as late as possible (and collect evidence).

Another trivial observation is that customers almost always ask you about some kind of solution. They rarely provide real problems. PM job is to dig into problems as deep as possible and then find a solution. In many cases solution is completely different from what customers asked. In some cases problem can be solved without new features.

[1] https://medium.com/@itamargilad/why-i-stopped-using-product-...

[2] https://www.intercom.com/blog/rice-simple-prioritization-for...

Re: Ask HN: How to properly manage a product roadmap?

#48
post #44

No single customer owns your roadmap, your roadmap is yours. Unless you're actually billing hours to customers for features, the features you add are yours. Sell what you have now, do not sell based on a future promise. You need to balance the value of a single customer against the opportunity cost of not building a feature that all customers want. The way I've found to do this: Qualify every feature request. Get in…

I personally don't use this approach because I feel like it leads you to a grab bag of features and not a cohesive product. A lot of product management in my experience is laying conceptual groundwork that no client or stakeholder directly asks for. That said, the following article expands on the "Monopoly money" approach, but applied to stakeholders:

https://firstround.com/review/This-Product-Prioritization-Sy...

Re: Ask HN: How to properly manage a product roadmap?

#49
To (ab)use a completely overused quote "If I had asked people what they wanted, they would have said faster horses" -- Henry Ford

You should most certainly listen to your customers, after all, if you're not serving them, what's the point in the product? However, you shouldn't be reacting to their requests to the detriment of the product either.

Do you AB test new feature ideas? Do you gather data to suggest that the requested feature is actually going to make a positive impact? Do you measure impact after releasing a feature to see if it was the right call? If not, how the heck can you ever actually know if you're building something better?

You don't need to ignore your customers, but you also don't need to change priorities so often. Make a roadmap for X months and stick to it (we use 3 months, but something else might work better for you). Use the time that the roadmap is being worked on by the tech team to do discovery and research so that you know what the most valuable requests from your customers are. Collect metrics, create prototypes (design/ux prototypes, not technical prototypes) and test them with your customers, do customer interviews. Then when you're ready to, you'll have better prioritisation, and your teams will have had the space and stability to release the previous features (and hopefully had tech investment time as well to keep your systems maintainable).

Re: Ask HN: How to properly manage a product roadmap?

#50
There is really no simple answer but I would start by clearly defining roles on who is responsible for priorities, who is responsible for facilitating the prioritization process and who is responsible for defining what processes are used to change priorities.

If it is decided that business us responsible, utilize a single backlog that the business can see and let them fight over the prioritization with defined practices.

Depending on the size of the company and overall development model I might use some framework (or pick suitable parts) like Less or SaFE to kickstart the new development process and then utilize larger scale retros to optimize the workflow continuously but in a structured manner.

Post reply on HN