Who are all the stakeholders that can provide input to a product roadmap? What are the stage gates to help decide if something should land in the roadmap?

I like to get as much input as is reasonable both internally and externally.

• Internal examples of stakeholder input: partnerships, sales, marketing, product support, operations, finance, data science, design, execs… 

• External sources of roadmap input: press reactions & professional product reviews, app store ratings and reviews, customers support requests, user research, inbound marketing research, and above all behavioral data from your logging/analytics.

In terms of gates... during the planning process, you don't really have gates, just the process you follow that encourages all good ideas to flow in, but then rates those ideas by expected impact toward your goals, and level of effort to design/build/test/release. See my other answer to the question about the end-to-end roadmap prioritization process.

When the team is executing, not planning, ideally all ideas coming in can wait for your next update or refresh cycle. This might be quarterly or even monthly in a very lightweight way... but since your teams have established goals, new projects will only bump other projects out of the roadmap if they're more likely to have higher impact in achieving the goals.

Occasionally there's a disruptive change that should cause you to think through changing the team's goals or an immediate pause/change to work-in-progress in the roadmap. But these should be rare, and very important, because you're going to thrash your team to consider the change/pivot.

Input from customer facing teams such as Sales, Support and CSM are helpful to the product roadmap as they represent the input/requests from customers. Additionally, getting alignment with Engineering and Design leads is important to understanding feasibility and trade-offs that will impact product roadmap.

Less about stage gates, more about grooming backlog and assigning attributes to each feature to help prioritize the features. Attributes can be weighted and aggregated. For example, a feature might be assigned 3-4 attributes (e.g. customer reach, ease of implementation, adoption impact) which can roll up to a score. Then each team decides where the cutline is (i.e. which features with scores higher than X will be prioritized for upcoming releasing).

You should try to split your stakeholders into two categories:

• Primary Stakeholders - The ones which will be directly benefit or impacted by your work. These should not just be your customers who will use the product, but also the teams who will help get this work to the finish line, upper management who need to report this work to higher above. Primary stakeholders can be of various functions - PMs, eng partners, user researchers, design, PMM, leadership

• Secondary Stakeholders - These are the ones who will be indirectly impacted by your product. The teams who are at the tailend of the consumption pipeline of your product.

How to decide if something should land on the roadmap - There are a few factors you should consider while building a roadmap:

1. Business impact - How much value it is delivering to the business. How does it map to the top level business objectives and key results

2. Level of effort - Sometime the feasibility and level of effort can help you make a decision

3. Tactical Vs Strategic - Sometimes tactical work is throwaway work in the long term, sometime it's not. You need to gauge that and decide accordingly

If you want to use a framework for prioritization, I would recommend RICE - reach, impact, confidence and effort.