Building a Product Roadmap: Prioritization Criteria and Weighting User-Driven Features

Using any product you like as the example (you may also focus on one feature area within it), explain how you would put together its roadmap. The interviewer splits the question into three parts. ### Clarifying Questions - Should the example product be new and still looking for product-market fit, or mature with an established customer base, or is that my choice? - What period should the roadmap cover, and who will use it: the product team, executives, sales or customers? - Does "user-driven features" mean features that users explicitly ask for, or features suggested by observed user behavior and research? ### Part 1 — Building the roadmap How would you determine the roadmap for your chosen product? Walk through your process from the first inputs to a plan the team works from. ```hint Start upstream Before listing any features, decide what the roadmap must achieve over its period, then trace where candidate work comes from and how it becomes a sequenced plan. ``` #### What This Part Should Cover - The inputs that feed the roadmap and where each one comes from - The steps from goals to a committed, communicated plan - How the roadmap stays current once work begins ### Part 2 — Criteria What key criteria would you use to decide what goes on the roadmap and in what order? ```hint Separate worth from cost Think about what makes an item worth doing and what makes it expensive or risky, then explain how you would weigh those against each other rather than only listing them. ``` #### What This Part Should Cover - The criteria, each with the reason it matters - How the criteria are weighed against each other to produce a ranking, and the limits of that method - How dependencies and timing turn a ranked list into an order ### Part 3 — Weight of user-driven features How much weight should user-driven features carry on your roadmap? ```hint Ask what it depends on Pin down what you count as user-driven, then think about the situations that would make you give it more or less weight, and how you would decide whether a particular piece of user input earns a place on the roadmap. ``` #### What This Part Should Cover - A stated position on the weight, and the conditions that would change it - How user input is collected and evaluated before it can shape the roadmap - What happens to user-driven ideas the team decides not to build ### What a Strong Answer Covers - One concrete product used consistently as the running example - A visible link from the product's goals to individual roadmap items - Parts that fit together: the criteria and the stated weight are the ones the process in Part 1 actually applies - How the roadmap is shared, and how firm commitments are told apart from tentative plans ### Follow-up Questions - Your largest customer threatens to leave unless you build a feature that does not fit your strategy. What do you do? - A quarter later, how would you judge whether the roadmap was a good one? - How would your process change for a platform product whose users are internal engineering teams?