Roadmap Prioritization and Saying No to Feature Requests

As a product manager, how do you decide which features your team builds and which ones it turns down? ```hint Saying yes has a price Before comparing any two features, ask what goal the team is trying to move this period. Then remember that every feature you ship must also be maintained, supported and explained to users long after launch. ``` ### Clarifying Questions - Is this about a product I own today, or about how I would approach any product? - Is the product still searching for product-market fit, or is it mature with a large user base? - Where do candidate features come from here: user research, sales and large customers, leadership, or the team's own ideas? - Is engineering capacity for the planning period fixed, or can people move between teams? ### What a Strong Answer Covers - Tying every decision to the product's strategy and the current goal metric before features are compared. - Turning feature requests into user problems, backed by evidence of how many people they affect and how badly. - A consistent way to compare options on impact, confidence and full cost, including ongoing maintenance, with the method's limits acknowledged. - Explicit criteria for "no" and "not now", and how those decisions are communicated to stakeholders. - Validating uncertain bets cheaply and revisiting decisions once results arrive. ### Follow-up Questions - A senior executive wants a feature that ranks near the bottom of your list. What do you do? - How much capacity do you reserve for reliability work and technical debt, and how do you defend it? - A launched feature is used by very few people, but those people love it. Do you keep it?