Any good courses anyone can recommend on tech product management? Seems like very relevant here.
Ask HN: How to properly manage a product roadmap?
31–40 of 124 posts
Re: Ask HN: How to properly manage a product roadmap?
#32> the business team is constantly changing priorities based on new client requests, so the tech team cannot cope with all the new features and these end up suffering continuous delays.
I would recommend...
— keeping a list of feature requests sorted by popularity, number of client requests, and impact to your KPI / north star metric
— prioritize each milestone / sprint based on this list, this can be for the next week, month, quarter, depending on the complexity of the project, then measure
— agree with the management team to not change the priority midway unless there is a very good reason to do so
You can use a variety of tools to do this, from the traditional Google Suite of tools to more specialized task management tools like Asana, Trello. We mainly use a combination of GitHub issues and Taskade (our own tool) to do this.
Re: Ask HN: How to properly manage a product roadmap?
#33Lots of good suggestions about questions to ask, thinking about aligning business and development needs, settings expectations with customers, giving them a chance to pay for development and other 'what are you even doing?' sort of ideas. So instead I thought I'd give a very simple recipe and set of rules how to deal with customer requests that I follow, to try to align with this:
- Never promise a feature immediately when receiving a feature request. Say "Thank you for the feedback, we'll discuss this with the development team and get back to you if there's any news regarding this" (tag the user, so you can actually do so)
- Never choose to develop a feature until you've gotten at least three separate requests for it. This will help you not over-adapt to random noise, and make sure the product stays relevant to a majority of users.
- Never promise a timeline if you choose to promise a feature. Keep stress levels manageable for you and your dev team.
- If you have something 'up next' on the roadmap already, you may choose to share the estimate with the inquirer - but favor not doing so, and underline that it's an estimate not a promise if you do. Estimates also become much more reliable if random stuff doesn't get to jump to the top of the priority list all the time. Your roadmap is a priority queue, not a stack
- Consider thinking of it as two priority lists. One is for smaller feature requests and improvements, the other for larger projects and system/business needs (e.g. refactoring, features to target new demographics rather than existing users). Not progressing on either list is frustrating for everyone, so think of yourself as a scheduler trying to guarantee progress on both threads. For example you could have a rhythm where it's ~1 month of work on one or two big projects (until completed), then ~1 week of work on smaller feature requests and polish, then repeat. This way you batch up many smaller tasks so you don't incur the cost of context switching for your dev team while they are working on a bigger feature (which typically require deep concentration over many days), you don't block major projects, but you also get to be relatively responsive to customer requests.
- Remember that things take time. Your job as a product manager isn't to cater to every user's every need immediately, it is to plot a path through an endless and evolving roadmap in order to 1) Keep the business alive and prospering 2) Keep the development team productive and sane 3) Make customers happy. In that order
Re: Ask HN: How to properly manage a product roadmap?
#34What's been key to my startups on executing and following a roadmap was to use OKRs at the company level. The roadmap has become a consequence of the company's annual and quarter OKRs.
As a product manager, you are responsible to come up with a roadmap and priorities based on your team's (engineers, designers) interpretation of the OKRs.
The same way you won't be telling the business team which client and opportunity they're chasing, they shouldn't try to draft your roadmap as they have no understanding of the technical challenges linked to your roadmap.
Using OKRs has been a common ground for multiple departments to agree on priorities and communicate progress. The challenge can be that there must be mutual trusts across teams. I recommend reading Measure What Matters. Ping me if you need more resources for OKRs and I'm ready to share more personal stories and experiences.
Re: Ask HN: How to properly manage a product roadmap?
#35What's been key to my startups on executing and following a roadmap was to use OKRs at the company level. The roadmap has become a consequence of the company's annual and quarter OKRs. As a product manager, you are responsible to come up with a roadmap and priorities based on your team's (engineers, designers) interpretation of the OKRs. The same way you won't be telling the business team which client and opportunity…
How do you pick the right OKRs?
Re: Ask HN: How to properly manage a product roadmap?
#36On top of all the good advices here, I would say one important thing is to be able to fail quickly.
This is more on the engineering side, but if you can shorten the idea to client feedback cycle, then it's much easier to deal with all those requests.
It's also much easier to tell the business team "let's work on the what's necessary to get feedback on this feature (which probably mean not even an MVP) and we'll get result by the end of the month" than "I'm sorry, your feature has been deemed priority 12, we expect it to be complete in 6 months to 1 year, provided priorities do not change (they will)".
Once you get this feedback, then it's much easier to quantify things.
Re: Ask HN: How to properly manage a product roadmap?
#37There'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.
Re: Ask HN: How to properly manage a product roadmap?
#38There'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.
Top 75+ Resources for Product Managers: https://www.sachinrekhi.com/top-resources-for-product-manage...
Re: Ask HN: How to properly manage a product roadmap?
#39What's been key to my startups on executing and following a roadmap was to use OKRs at the company level. The roadmap has become a consequence of the company's annual and quarter OKRs. As a product manager, you are responsible to come up with a roadmap and priorities based on your team's (engineers, designers) interpretation of the OKRs. The same way you won't be telling the business team which client and opportunity…
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.
Re: Ask HN: How to properly manage a product roadmap?
#40There'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…
This is a great comment. Love it.
On my end, I’ve recently started working on documenting (still very, very early) on the “measuring” part at https://datadriventeam.org. It is backed by an open source GitHub repo and I hope people would contribute once I’ve gotten the initial version out.