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

91–100 of 124 posts

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

#91

Post by ethbro »

tootie wrote: post #87
aidanlister wrote: post #81

Earlier quoted context omitted.

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 l…

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.

My perspective, having worked with both good and bad PMs, is that a PM is a communication line aggregator.

In the example, every one of those lines consumes resources: time, context switching, misunderstanding, synchronization with the rest of the team.

A quality PM funnels all those lines through themselves. Their value is proportional to their ability to (a) bidirectionally extract, transform, and deliver useful information to both sides (developers and end users), (b) offload processing tasks that neither side is good at (merging similar requests, clarifying ambiguous requests, tracking down answers / requests for external teams), & (c) keeping a 10,000 view and coordinating tactical requests to align with strategic vision.

I like the CDC 6600's peripheral processors ( https://en.wikipedia.org/wiki/CDC_6600#Peripheral_Processors... ) as a computer hardware metaphor.

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

#92

Post by Zigurd »

I'm currently exploring the intersection of agile project management, establishing key milestones, product management, and real options analysis (ROA), among other things.

I think there's a way of tying these things together that reveals value and costs that can remain hidden. if you want an advance look at the manuscript, let me know.

It's definitely not for everybody, but maybe your fintech colleagues would find it interesting. it might prompt them to value what they learned along the way as well as the cost of changing course.

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

#93

Post by nradov »

aidanlister wrote: post #81
delusional wrote: post #79

Earlier quoted context omitted.

I get that this is a thought up example, but why is this role necessary in this case. If the business team knows what they need next, and the software team knows how long it takes, can't they just get together and work on it? Why do they need a middleman here that just creates meetings? To be bit more abstract: if the business team owns the roadmap, then what value does the role add?

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 l…

Where are the customer circles in that diagram? Product managers have to get out of the office (maybe virtually) and talk directly to real customers and qualified sales prospects.

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

#94

Post by brightball »

darkerside wrote: post #67
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.

I’ve been meaning to write a blog post about it soon.

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

#95

Post by cptaj »

alangibson wrote: post #88
crazygringo wrote: post #70

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 o…

This is a good 1000 foot view of the job, but never in my 22 years building software have I seen this work smoothly. Most business stakeholders will never be able to describe what they want in a way such that you can implement it. You will just have to live with the fact that you will often rework things you implemented because what you think you heard is not what they said. 2 weeks is an eternity is a fast moving bu…

Everything you say happens in real life. But these are all signs of bad management and a toxic workplace. They're not at all inevitable.

When a company works you don't hear about it. You just see their success, or maybe you don't since there's more to success than sound process. You always hear the bad and the ugly.

The software industry is plagued by managers without domain knowledge, people faking it till they make it and immature processes. I think this is probably the main reason you have had such a tough time all these years.

I think process definitely helps mitigate these things but you also need reasonable human beings at the helm. If a 2 week development cycle is not fast enough for you, then you have some serious problems.

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

#97

Post by alangibson »

cptaj wrote: post #95
alangibson wrote: post #88

Earlier quoted context omitted.

This is a good 1000 foot view of the job, but never in my 22 years building software have I seen this work smoothly. Most business stakeholders will never be able to describe what they want in a way such that you can implement it. You will just have to live with the fact that you will often rework things you implemented because what you think you heard is not what they said. 2 weeks is an eternity is a fast moving bu…

Everything you say happens in real life. But these are all signs of bad management and a toxic workplace. They're not at all inevitable. When a company works you don't hear about it. You just see their success, or maybe you don't since there's more to success than sound process. You always hear the bad and the ugly. The software industry is plagued by managers without domain knowledge, people faking it till they make…

I've worked everywhere from small startups to the Big 5, and the only thing that changes is severity. At some point you realize that the exception of disfunction is really the rule, and that smooth sailing is textbook theory.

I've been looking into ideas like No Estimates and delivery forecasting as a replacement for 'traditional' Scrum-flavored agile, but AFAIK these newer approaches aren't very battle tested.

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

#98

Post by csytan »

I'm bootstrapping a simple scheduling SAAS with my wife (https://www.cozycal.com/). As the sole developer, I definitely can relate to the feeling of constantly putting out fires.

We use Canny (https://canny.io/) for feedback tracking. It helps us with:

1. Transparency with our customers. On the support side, we can show that we're tracking their requests, and where they fit into our existing roadmap.

2. Less stressful development cycle. I'm still completing some work in our backlog, but after switching to Canny, it's much more clear what the next features will be.

Also, here's our public Canny board which lists our feature requests & roadmap: https://cozycal.canny.io/

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

#99

Post by BigBalli »

After years of leading product, I came to the conclusion that there always needs to be a process in place between customer feedback and development. All feedback is appreciated, acknowledged, saved. If it 's not critical feedback (ie crash), feedback/feature request bucket will be reviewed regularly and then assessed based on: user benefit (how much does experience improve) impact (how many users will benefit from this) consequences (will other users/features suffer from this) ROI (how will it impact the company's, not purely monetary) requirement (time/cost to implement) goal/mission (does it align)

Long story short: we NEED user feedback but it cannot dictate the roadmap (and therefore the mission). If you find yourself repeatedly needing to change your roadmap it might mean you're too quick/loose adding elements to it.

Hope this helps!

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

#100

Post by iratewizard »

alangibson wrote: post #88
crazygringo wrote: post #70

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 o…

This is a good 1000 foot view of the job, but never in my 22 years building software have I seen this work smoothly. Most business stakeholders will never be able to describe what they want in a way such that you can implement it. You will just have to live with the fact that you will often rework things you implemented because what you think you heard is not what they said. 2 weeks is an eternity is a fast moving bu…

One of the things I do as director is make pixel perfect mockups which can be clicked through. In a day's time, I can have two months of project work presentable. Work doesn't start until what we are building is locked in, and when it's locked in it doesn't budge without a change order. An added benefit of the mock ups would be that these types of change orders have become rare since I took over.
Post reply on HN