Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to properly manage a product roadmap?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 124 posts

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

#61

Post by dberg »

After seeing so many Product Managers get this awfully wrong sometimes it also helps to understand what your job _isnt_

* Focus on outcomes over outputs. Your job is not to build a spreadsheet or JIRA backlog of features and then hand them to engineers to build like a coding factory. You do not have a crystal ball. You are not Steve Jobs.

* Involve the Business, Support and Eng parts of the org when defining _what_ to build. They all bring fantastic perspectives and really helps focus on the MVP and creates shared buy-in. Remember you are trying to solve a business problem not just crank out features aimlessly as a team.

* When mapping out _what_ to build, it always helps to use the collective team (in previous bullet) to outline Effort vs Impact. Forces really good discussion to keep things hyper focused and efficient.

* Instead of focusing on features focus on the strategy and the vision, let the team figure out how to get it there. As a PM you need to understand the market, the competitive landscape, how people are pricing their products, what customers are saying, industry trends, etc.

* Roadmaps in general are somewhat useless bc you don't have enough information and they create a lot of emotional commitments. Things change (hello Covid-19) and you don't know what you don't know. Instead outline your vision and strategy at a high level and make sure they are aligned to your overall business outcomes. This prevents people from saying "You said we would get feature X in Q2!!!". Instead you focus on metrics (Decreased Churn, Increase engagement by 3x, returning users more than X times in Y days, Revenue, etc).

* Be religious about data. Define your business outcomes, have good tools to track the progress of those outcomes, have a way to test/validate quickly and pivot as soon as it doesn't work. Keep fine tuning the machine

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

#62

Post by brightball »

I was running into a similar issue and after a lot of research ended up adapting the scaled agile framework (SAFe) to our team.

SAFe is designed for larger companies, so you have to learn enough about it to understand where you can trim the fat. The big applications to your issue come from 2 places.

1. Lean Portfolio Management 2. Program Increments

LPM is a process of setting priorities by using real numbers where possible and best guesses otherwise. The result is a process that tries to measure value and urgency against your development capacity. Small things with high value float to the top. Big things with low value drift to the bottom and don’t bog down your team.

The Program Increment (PI) is an intense process that lets your dev team put out a plan for the next 8-12 weeks and gets the business to agree to it. Aside from getting everyone to agree to the current plan, it changes future business requests to “be prioritized for the next increment” which happens via the LPM process.

The PI plan still adapts to new feedback and can change, but those changes come with “if we do this, we can’t do that...is that acceptable?” Time for small changed and some variability is built in, so those conversations only happen for something major.

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

#63

Post by brightball »

dberg wrote: post #61

After seeing so many Product Managers get this awfully wrong sometimes it also helps to understand what your job _isnt_ * Focus on outcomes over outputs. Your job is not to build a spreadsheet or JIRA backlog of features and then hand them to engineers to build like a coding factory. You do not have a crystal ball. You are not Steve Jobs. * Involve the Business, Support and Eng parts of the org when defining _what_ t…

Getting people to understand how useless roadmaps are is the hard part.

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

#64

Post by dberg »

brightball wrote: post #63
dberg wrote: post #61

After seeing so many Product Managers get this awfully wrong sometimes it also helps to understand what your job _isnt_ * Focus on outcomes over outputs. Your job is not to build a spreadsheet or JIRA backlog of features and then hand them to engineers to build like a coding factory. You do not have a crystal ball. You are not Steve Jobs. * Involve the Business, Support and Eng parts of the org when defining _what_ t…

Getting people to understand how useless roadmaps are is the hard part.

Unfortunately most companies don't know any better that it is not the job of a PM to "invent" a whole bunch of features that may or may not work.

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

#65

Post by jokull »

Your job is to bridge business and engineering. If both of these sides trust your judgement your job is easy. You will win arguments when you can translate between these sides. Turn business concerns into engineering projects and express engineering projects in terms of business outcomes.

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

#66

Post by satyrnein »

nurettin wrote: post #56
nurettin wrote: post #30

Hi, I'm also in the industry and in the same situation. The best life changing advice I can give is to introduce a one week delay between finishing features and releasing them. Adjust your software versioning so that you only release what was done a week ago. You have to stick to that one week delay as much as humanly possible. This gives a lot of confidence and room to breathe so you can enjoy work again.

To clarify, let's say you are asked for a feature. The normal workflow is to determine when it will finish and crunch for the deadline. Once the deadline arrives, you are going to finish and release at the same time and hope that you have done enough testing during development. At this point get ready for embarrassment because you will inevitably make a few mistakes and cut some corners. What I am suggesting is, you…

Ok, I think I understand better now. We typically turn on the feature for internal users first and then do a gradual rollout using feature flags so it's not as high stakes and can be rolled back easily in case of problems.

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

#67

Post by darkerside »

brightball wrote: post #62

I was running into a similar issue and after a lot of research ended up adapting the scaled agile framework (SAFe) to our team. SAFe is designed for larger companies, so you have to learn enough about it to understand where you can trim the fat. The big applications to your issue come from 2 places. 1. Lean Portfolio Management 2. Program Increments LPM is a process of setting priorities by using real numbers where p…

The first item (LPM) sounds a lot like our current process, which has worked well for reactive work based on business needs, but all of our long term work feels like it is prioritized ad hoc, based on gut, or worse, doesn't even get done. If be interested in hearing more about PI and how it works.

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

#69

Post by bisRepetita »

Vision, passion, and being realistic. All the management techniques won't replace that.

You need vision to gain a credible and influencal seat in front of management and customers, and hear from them. And not just saying yes to the last one who spoke.

You need passion to cope with all the crap (difficulties, management, engineers, customers, nay-sayers, finding ressources, etc).

And you need to be realistic and pragmatic to make something happen, even if not perfect/ideal. Maye next round.

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

#70

Post by crazygringo »

Welcome to being PM -- this is the job.

And this is exactly what the agile/sprint process is extremely helpful for.

Every two weeks, check in with the business team to bring them up to date with development and get them to prioritize/rank the features they want.

Then hold a big meeting with your team and use planning poker to estimate how long the top-ranked items will take. Inevitably it'll add up to 2 or 3 months of work.

Then go back to the business team with the realistic estimates for each task, and get them to pick what is actually most important to deliver or make progress on in the next 2 weeks.

Then work on those for the following two weeks. Rinse and repeat.

The key thing here is that there is an objective process. Nobody can blame you or any single developer -- there is a process. And after several of these iterations, the process will build trust among everyone, instead of blame or suspicion.

Also, you might think this leaves you with no room for input of your own. And in a way this is true -- welcome to being a PM. Your job is to manage and balance other people's priorities, not your own wishlist of features. But it is crucially your job to advise well and point out inconsistencies/dependencies -- e.g. sales wants feature A but the CEO wants feature B... but if we deliver B before A then together they'll take half the time, or will enable feature C earlier, or whatever.

And it's also your job to keep your eye on the long-term goals, which will generally be set by the CEO or management team -- sometimes you have to deliver feature X that management requires by the end of the quarter, over anything the sales team wants -- which you just gently explain to sales.

Post reply on HN