Live data from Hacker News

Ask HN: How to properly manage a product roadmap?

news.ycombinator.com

71–80 of 124 posts

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

#71
You don't have a roadmap problem, your company has a sales leadership problem, which if left unchecked will kill your company.

Sales leadership should know that they need to build a sales team capable of selling what you have now while providing a vision of the future. Just guessing, but it appears they are caught up in trying to sell using features rather than selling your product as a solution to the problems your potential clients have.

If they can not sell the solution and keep getting caught up in a feature to feature competition, your company is in significant trouble.

That said... the feedback from potential customers, new customers, current customers, what you see competitors doing, your support organization, and the engineering team plus your vision of what the product needs to become are all critical for you making decisions on what to build.

As many here have said, there is much more to your question than can be answered here. I'd be happy to talk if you'd like to.

By the way, I have a single KeyNote slide for our roadmap. Not fancy, but it is simple, cheap, and gets the job done so we can focus on the product.

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

#72
there are two types of features: 1) Features that affects the overall product 2) Features that makes life easier for users

For the first category you need to look at the whole picture, as they often affect many parts of the system, and there need to be a coherent strategy/plan.

For the second category, just go ahead and implement any such feature if have the time to do so. But don't forget that all new features have a future cost, as users would miss those quality of life features if you remove them in future versions.

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

#73

Earlier quoted context omitted.

Any good courses you can recommend on tech product management? Seems like very relevant here.

Top 75+ Resources for Product Managers: https://www.sachinrekhi.com/top-resources-for-product-manage...

Thanks so much!

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

#74
What's helped our team has been just writing down the product roadmap. It's as simple as a bulleted list in a google doc with some estimates about how long things will take, who's working on them, and what's already been completed.

Every feature request from the business and customers goes on the roadmap, along with any features engineering needs like supporting infrastructure, and there are regular meetings to make sure the list is always in priority order.

We've found having everyone looking at the same roadmap greatly reduces tensions. Instead of arguing over badly-remembered, vague requests, we work together to strategize the best approach. It's actually fun.

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

#75
post #6

There's no way to answer this in a comment...you can take a full course on tech product management and still not have all the answers. But I'll at least offer some advice: Just be very good at measuring and presenting data from all the channels in your company. Your customers, your prospective customers, your customer engineers, your sales people, your support team, your engineering managers, directly from developers…

Any good courses you can recommend on tech product management? Seems like very relevant here.

Inspired by Marty Cagan is a great book.

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

#76

You don't have a roadmap problem, your company has a sales leadership problem, which if left unchecked will kill your company. Sales leadership should know that they need to build a sales team capable of selling what you have now while providing a vision of the future. Just guessing, but it appears they are caught up in trying to sell using features rather than selling your product as a solution to the problems your…

Sales != Marketing.

Like the difference between Test and QA. Complimentary, but still distinct.

Marketing's job is to divine the business case. Size of market opportunity, price points, window of opportunity, initial MVP thru mature feature set, projected P&L, and so forth. While collaborating with devs, for sanity checks and buy-in, ideally.

Real marketing is a real job with real skills. Once you've seen a pro in action, it kind of ruins you for all the pretenders.

In my 30 year career, I've worked with precisely 2 marketing pros.

(Sales pros are pure gold too.)

PS- Lisa Horwich is one such marketing pro. If your product has a business case, she'll find the critical path. Watching her in action still seems like magic to me. https://www.linkedin.com/in/lisahorwich/

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

#77
Lifelong Serial Founder/PM here. The one biggest thing I see missing from most comments (which in general are quite good) is that the role of the PM and the decision framework depends very highly on the stage that your company is in. Are you pre product/market fit? Are you just seeing traction? Are you in hyper growth? This should massively change your decisions.

There are endless frameworks for balancing these choices. For me, they all come down to this:

Value

1. Dollar value; in either revenue unlocked or money saved (and money can be customer support time)

2. Strategic alignment; how is the item aligned with overall vision & goals? If this item is completed, does it make us stronger or dilute our value / competitiveness? This is really where stage of company comes into play.

...vs...

Cost:

1. Time; Estimated time to build/support. This can be a wag from the engineering team.

2. Risk; what is the uncertainty around the time and maintenance estimates?

Using a framework like this allows you to include architecture, technical debt maintenance, etc into your overall planning and decision process. This will help make visible to business stakeholders the true complexity of operating the product and hopefully lead to better PM decisions. Everything is a trade-off.

Remember: one of the most important jobs of a PM is to say NO. You are the process gatekeeper to how the company spends a ton of resources.

Happy to discuss further.

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

#78

Earlier quoted context omitted.

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.

That's interesting, I understand the need for feature flags, but don't they reduce code readibility?

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

#79

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…

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?

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

#80

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…

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?

In my case, "the business" (executive team) has broad overarching ideas. The PM then works out the specifics, works with UX to design the screens, put together the copy, talks to engineering to understand what technical challenges may exist, then works with individual teams to break down the high level into small specific tasks. During development, they manage our todo column, answer questions, help make adjustments when previous assumptions prove false or we run into unexpected challenges, etc. As an engineering manager, I've actually found it quite helpful.
Post reply on HN