Ask HN: How to properly manage a product roadmap?

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 too.

Understand the real cost of each feature. That’s not easy. Try to predict the real value of each feature. That can be even harder. How many customers are asking for that feature? What’s the avg LTV of that cohort? Will the feature reduce churn? By what percentage? Own those metrics and tell the whole company that’s why you’re prioritizing those specific features.

Be prepared to go back and check your assumptions and see if your predictions were correct…If you were wrong, then your next job is figuring out why and then working towards improving your own models to predict the value/cost of each feature. The fact is once you start intensely measuring that type of data, you’ll find lots of gaps in your own process and fixing it as you go.

What’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 be trying 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.

I personally don’t have any problems with changing priorities as long as the cost/benefit calculation is done and some things that are easy for management to miss are considered:

* Developer context switches are expensive (both in terms of developer happiness and productivity)

* Forks staying off main branch are expensive.

* Components/Modules being half-polished due to changing priorities are expensive (both in terms of customer satisfaction and introducing technical debt)

So for me, who is in a similar position, it’s always a dance between what clients want, what management wants and what would keep my developers productive and happy and my product technical-debt-free.

If there’s something that my clients ask for and it’s really easy to implement, I would often ask my developers to drop other tasks and implement/hotfix it. But I’ll try to redirect some good feedback from the customer side to the developer because I know they feel exhausted by changing direction.

Oh, this is literally your job. There are different takes on this, and the detail is hard, but the broad strokes are:

* Follow your vision for the product – i.e. form a feature-set that combines the greatest compatible combination of requested features and your understanding of what the future of the product post those features will look like

* Solve the immediate next problem that will bring you most money fastest. Apply debouncing. i.e. the next blocker to money is feature A in the shape of a customer saying “we’re ready to sign if you have A”. Rank all amount of money, likelihood of customer actually executing (if you aren’t able to sign on to a pilot w/ “we’ll have it next week”), and divide by time. Do that. Do not re-evaluate for some duration of time.

* Find what you’re selling. Sometimes this can be very different from what you’re making. And the customer may be asking for a feature because they think that feature in the thing they’re being sold will solve the problem they’re having.

Honestly, no one here can help you with this. I suspect not even a course could help you with this. This you’re going to learn by attempting to constraint solve here. Just learn from the pain fast and do what’s necessary to keep the trust of your team (primary!) and your customer (secondary because there’s more of them than the team).

On 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.

> just decide your own roadmap and stick with it?

While this may sound like it’s easier to manage it usually ends up with a product that does not solve the problem of the customer.

As a product manager solving problems of your user or customer must be the first priority. The only way to do this is getting closer to the customer.

I find teams shielded from customers via business teams use the best part of their product management and engineering skills (microservices included) to manage their business team and not the customers.

There is a constant grooming of the backlog with features and pressure to keep the engineers managed and busy.

Start measurning the value of each feature to your customers. Have short customer feedback cycles for planned features. Your backlog should reflect solutions that make sense to the customer.

The book “Escaping the build trap” talks about this. I highly recommend the book.

Good books on the subject talks against roadmaps and shifting to a value and goal based approach.

I agree, this is anecdote but a dysfunctional company I have seen had engineering stick on their own roadmap disconnected from customers. The end result was a product that failed to evolve to the market, no features were added for years because the engineering roadmap was always to migrate to a new exciting technologies, or improve fun features to work on but that no customers were using.

A good roadmap allows you to take customer requests and go to the CEO/C*O and say “We can build feature X for this client in 30 days, but only if feature Z we’re currently working on gets pushed back 35 days. This will push the whole roadmap back 5-6 weeks. Is that okay?”

Reprioritization is good and normal, but decision makers need to understand the costs and a good roadmap allows you to communicate that better.

Communicate clearly with the business team about the consequences of churn: if everything is a top priority, then nothing is a priority.

There are multiple reasons for changing priorities.

Are there multiple business folks all generating requirements independently, insisting that their client is the most important? Get them all in a room to hash it out. Either they all agree on a ranking of the clients, or they each have to prioritize their own requests and choose a small number (say, 1-3) of truly critical requests to put into the engineering queue. If they can’t agree on this, escalate to the CEO. If the CEO can’t/won’t prioritize, you’re in bad shape. Your best bet is to make a judgment call as to which clients/features are truly critical and drop the rest on the floor. Be prepared to send out your resume if you make the wrong call.

If the clients themselves can’t decide what they want, or can’t communicate it effectively through the business team, you need face time with customers. If you have a product-minded engineer who is good at speaking the customer’s language, include them too. The more direct exposure and intuition the engineering team has about what’s really important, the more support you’ll have in making those calls.

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.

Lots 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

Priority changes, expanding scope and switching work from one project to the other all have a cost. Too much of this and you don’t get anything done: you’re just treading water. It doesn’t matter if you or customers drive your roadmap and it’s changes (though you would want to have a prioritisation framework to decide based on what business metrics you prioritise projects).

The first thing you should do is create stability within an ever changing business environment and also capture the cost of the priority churn. So create a roadmap, and have a process to capture priority changes, and how much WIP work is wasted (=not shipped, as it’s deprioritized) as a result.

There’s a bunch of tools and methodologies you can use for this. Sprints, scrum, OKRs etc.

As an engineering manager in a similarly fast-moving environment, the two main rules I follow are:
1. We don’t do any work that does not have impact defined: what happens or what we expect to happen when this project is shipped. This is usually in some numeric value. And we always work on the best impact/effort project next.
2. The team _always_ finishes what we start and we do small enough work items/milestones that enable us to iterate quickly.

Good luck!

There always needs to be a balance between external forces changing your priorities and your internal vision and strategy.

This being said, if the roadmap changes mostly based on new customer asks.. then you’re not building a product, but doing custom development / professional services work.

You have to include multiple perspectives. Make a list of the top 5 features…

– you think your customers need

– your customers want (ask them!)

– which offer the highest return on invest

– your product needs when being compared with your competitors

When you have answered those questions, you should have a good feeling about which features you want to implement first. Next, ask the devs how your priorities match up with the development of the application and how much time it would take to build them. Some features might technically depend on each other.

Edit: Btw. changing priorities is okay, as long as nobody has started to work on a feature. As soon as the implementation started you better finish it. Make sure your business team commits to the things you start implementing and get the commitment from the dev team to finish things in time.

> 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.

Two approaches that can fix the root cause of mis-alignment between sales & product:

1) Teach your sales team how to pitch your product roadmap, so that customers are buying into the bigger vision. When customers are bought in, they will accept that they don’t get their small feature because they will gain something larger faster. Sales LOVES when this is successful because then their deal can close faster.

2) Challenge the sales team to find at least 2 other customers that need the same feature before you agree to re-prioritize your product roadmap. This creates alignment between them & your need to prioritize the most impactful features.

It is impossible. It depends the scope of the project and the company mentality. In my 12 years as PM, I understood that no roadmap is useful unless it is a short-term roadmap with achievable objectives. It is much easier to plan and scope.

I really don’t appreciate when other PMs come to me with a 1 year roadmap. Who knows how many thing we will not do, or change or pivot based always on the data we’re getting? That’s why I preffer better planned things (docs, teamwork) than a document with a nice unrealistic roadmap.

You have people constantly changing their minds.

Before you can make a roadmap, you need a sense of direction.

Maybe you need to zoom out a bit. What do you offer? To whom? Why? Why them? What do you not offer? Why not?

Can you get those answers without asking your engineers to constantly build shit that they’ll need to throw away?

Can you collect information cheaply? Can you ask your bizdev people to get answers to questions that will help you? What is the cheapest way to learn?

The more you build, the more you’ll have to support.

Are the clients paying you to fulfill their requests or are you just making their unfunded dreams come true? If they are paying is it a reasonable proportion of the cost for your teams development work? How strong was the product vision originally?

Use roadmunk or Asana because they have timeline view. Stakeholders love that.

The right way is to collaboratively change your roadmap over time. The wrong way is to restrictively stick to spec from the start.

Roadmaps are not things like Jira tasks, and vice versa.

First, everyone needs a place at the table. There is an ungodly amount of distortion, omission, and loss in transmission between prospect/customer and engineering. If you have a prospect, meetings should include people from business, and engineering. If in any case only one person was there, this person should write up their notes or be downloaded/debriefed while the memory is still fresh. If someone is updating you on the phone get the most you can when they just got out of the meeting. Sometimes you ask a question and they can go back to the person they just met who’s probably having a break by now and ask, take copious notes and dispatch them. If you got anything wrong, they’ll correct.

Written meeting notes should be disseminated, and then corrected and augmented so that:

– Those who weren’t there get an idea of what was actually said (we have meeting minutes in version control and anyone in the company can pull them and know exactly what I discussed in X town at which hour with whom)

– Those who were there realize they didn’t hear/understand the same thing or plug holes. One catches what another has missed.

– Track rationale and decisions: All development through issue tracker. Avoid the “why was that feature added/removed two months ago again and now it’s to be removed/included?” and not knowing why.

This should bring everyone to the same “initial conditions”. If you don’t do that, it’s telephone game and you get a human-centipede like result.

Include form to request a feature in the product itself. Directly from the users so there’s no distortion. Everyone should get that issue.

Also, if there’s no product there is no business, which makes me wonder why the tech side is taking the backseat in a fintech startup. Fintech is like an airplane: you take a bus, you add wings, and you have an airbus that can travel faster and farther. Remove the tech, and it’s just finance.

Add monitoring and analytics. We’re working on that ourselves after putting out a lot of fires that looked the same.

Second: customers drive product roadmap in terms of raw data. Whenever users or customers ask something or raise an issue, ask yourself what is the underlying issue and what are they really trying to do. “Job to be done”. Drill vs hole. Customers complaining is similar to patients complaining: they’ll tell you about symptoms and then want you to fix those symptoms and they’ll propose solutions and features. You gently take notes, and then dig deeper.

The analogy I use is that customers will ask for a robot with IoT and blockchain support that automatically integrates with Amazon API and orders mops, tracks the item, and has AI and image segmentation and recognizes Amazon drone, and receives the mops and automatically loads them. Because AI, blockchain, and IoT. Yes, it’s not a sentence.

Your job is to ask why, figure out they always find water on the floor, and then look up and find there’s a leaky pipe, then fix the leak.

In other words: do not really listen to the “implementation” or the “solution” customers propose. These only fix symptoms and are easily swayed by whatever piece with a clik-bait title prefixed by “This AI robot” someone with 2 minute attention span has written that the customer half read taking their morning coffee, and wanted to bring to the product not to be left behind by the competition.

What one really looks for is the problem. The problem almost never manifests itself, you have to dig to get it. It’s muddy. People could be pissed at you because “What do you not get in an AI IoT robot that orders mops?”. This is where having social skills and getting good at interviewing comes in handy.

People demands and their behaviors are the solutions they have come up with to a problem. The problem is that they almost never tell you about the problem, and you may have a better solution. Think of it like code review: code I push is my implementation or a solution to a problem. The implementation is dictated by my skill, experience, sophistication, sleep I had yesterday, etc. Code review helps find better ways.

Third: all developers do support. This focalizes and aligns everyone. You have a hundred issues in your issue tracker. You have thought of great features. A lot of the issues are about bugs.

We opened our internal ML platform to about 30 students of our colleague so they could get a one click notebook with all libraries installed, a lot of RAM, a sweet K80, and hundreds of gigabytes of data for their project. We added the students to a dedicated Slack workspace. The platform is not ready, but precisely. This is a jolt.

Users would complain about something. We would notice a pattern. We would investigate, then figure out what to do.

They’re doing two things:

– Exposing things we wouldn’t have found

– Putting the finger on what hurts the most amongst the issues we are aware of.

One person who complains about something is one thing. Ten people complaining about the same thing that prevents them from working, that’s another thing.

We have worked differently in the past. There have been changes to the company and changes in how product development is done. The business side of our company used to talk to the executives of the client company. We have been paid for all our products, whe have shipped them to spec, none of them is used, none of them can be reused, all of them left us with scars, and that way of working almost destroyed the company.

Fourth: everyone should be clear on what the team is doing, and what the team is not doing. This issue is not a priority. We will handle this one, this one, and this other one by this date. This part is handled by this person. Avoid the “I thought Alice was working on it”.

Fifth: -good engineering practices go here-. Good test coverage. Patches get their tests, good commit messages, root cause analyses, and eventually knowledge base. A test harness is not “directly” good for the customers, but it gives confidence that you won’t break everything. Loosely coupled, modular code: it allows for people to develop with different speeds and reduces dependency on unrelated parts, which is really frustrating.

What a thorough and valuable comment. This is really valuable stuff – thanks for sharing your experience!

It is completely normal to include feature requests in a product roadmap and to be getting them developed when appropriate, that definitely isn’t a problem. Things are also different when you have 1 client versus when you have 10+ clients. When you have 1-2 clients you generally do things you wouldn’t and shouldn’t normally do under good product management standards.

So let’s assume you fall into the 10+ client category. The company should have a defined and published product roadmap that is being worked, new features should be vetted against the client demographic (e.g. it should benefit more then 50%, I usually set the bar higher early on like 80%) and if it passes that then it would be defined and put on the development schedule, but it should not disrupt the existing planned sprints on the roadmap. That means the client might have to wait to get this new feature, but the benefit is the product can be designed, kept reliable and stable and not get polluted with a bunch of make shift code and hacks. None of this has to be a crazy long process, it can be simple and quick and if sprints are 1-2 weeks, most likely many features can fit within the next 30-60-90 days at most (obviously assuming proper staffing etc).

The sales side of the business should never be in control of the development schedule, or product roadmap, it is a direct conflict of interest. Product management should be owned by an operations type person, CTO, COO but for sure a non-sales, and/or marketing focused person. This is what will make the company successful faster and help keep the product stable and on schedule. Founders when small have to wear many hats so they will be violating this all the time, but by the time they have hired a product manager, sales teams etc, the hacky crap has to stop if they want to succeed.

None of this means a client (or business) can’t get a new feature turned around pretty quick, it just means that there is alignment of features to more than one client and that product stability, reliability and schedule are managed as first class problems. Startups struggle with this thinking it will slow things down, and they will lose deals, when in fact it speeds things up and makes everything more predictable. The key is requests can be done faster when the development teams can keep tech debt low and design things into the product properly. It also prevents the scrap it and rewrite it that happens when you don’t plan well enough. To be fair, there is almost always 1-2 scrap code repositories early in the life of a startup, but it doesn’t have to be that way, just usually works out that way because of people repeating preventable mistakes they haven’t yet learned.

I do think it is important to recognize when you are first starting the company it is more free for all, scrappy and hacky, but even in those circumstances you should not be implementing features just because one client made a request.

I would actually recommend reading Steve Jobs biography. I know it seems weird but the guy launched products that changed the world. I think seeing how his brain worked with products could help a lot.

I believe a big problem for getting a good product roadmap is very fundamental… we don’t truly believe on the products we are working on or in the company we are working for. Is just a bunch of people with no real vision trying to influence one another over ego.

And then you have Sales of course who can actually talk smooth and influence better those who aren’t sure about why they do what they do…

fraserharris (1) is about bigger vision. That’s what I think makes a good product road map. A vision, extreme focus and caring about it.

The sales team is more important than ‘vision’ 9 times out of 10.

In consumer, where the customer may not really know what they want, and can be convinced, it’s more about vision and how that aligns with smart marketing.

With B2B the sales teams are it. Customers may also not know exactly what they want, but some discussion there will suss it out.

Note Apple was always pretty terrible in B2B, you wonder why?

I think with no vision is really hard to build a good product and without a good product what exactly are you selling?

I think sales is super important yes but it sort of works after having a product.

It is just as important for a company since no sales == no money coming in.

I guess in the context of this topic I believe that to manage a product roadmap effectively having a strong vision for the product is fundamental.

Apple was always pretty terrible in B2B, you wonder why?

I always thought that was a strength, they focussed on areas that companies like Microsoft were completely oblivious to.

You already know the answers. Sprint to build flexibility, infrastructure, table stakes, and other goals that are broader than any one customer.

productboard.com

honestly the best tool i’ve ever used for this. and phenomenal software in general.

Amazing tool. Won’t solve this problem. It might help with clarity and organization. But he is talking about structural problem.

Are you building your product for yourselves, or customers?

A roadmap isn’t concrete. You haven’t mentioned if you use agile methodologies or not, but sprints can buy some breathing time and deliver progress.

Once a feature request made sense to the product to add universally, if it wasn’t too disruptive, and depending on the feature, I might let clients vote with extra dollars to move it up the backlog.

Sometimes, a feature was requested by enough clients that hey might even split the bill on a extra body to get it done.