Feature bloat for PMs: the job is saying no
Most PM roles are feature-factory roles. This is not an insult. It is a structural description of how most product organisations work. The PM takes requirements from sales, translates them into tickets, manages the sprint, ships the feature, moves to the next requirement. The cycle repeats. The backlog grows. The product accretes complexity. The PM gets promoted for shipping.
This page is for the PM who knows something is wrong with that picture. The PM who suspects they are doing project management, not product management. The PM who wants to stop being a feature factory and start being a product team. It does not require changing your organisation. It starts with changing what you measure and what you say.
01. The self-test
The feature-factory PM: symptoms and self-test
Your roadmap is a list of features, not a list of problems.
You measure your performance by features shipped, not by outcomes produced.
You cannot name the user problem that at least two of your last five shipped features solved.
You learned about the last major feature request from sales, not from user research.
You have not run a usability test in the last 90 days.
You have not removed a feature from the product in the last year.
You have a backlog of more than 50 items, none of which have an evidence requirement attached.
The word 'stakeholder management' appears in your job description under responsibilities.
If more than four of these are true, you are working in a feature factory. That is not permanent. The first intervention is to change what you measure.
02. The frameworks
Four frameworks worth knowing deeply
These are covered in full on the decision framework page. This is the PM-specific framing: what each framework does for your day-to-day work.
RICE
Use it to end subjectivity in prioritisation conversations. When a stakeholder says 'we need feature X,' ask for the RICE numbers. This turns a preference into a data question.
Kano
Use it to explain why the product does not need to match every competitor feature. Excitement features today become Basic features tomorrow. Adding Delighters is a maintenance commitment, not a one-time investment.
MoSCoW
Use the Won't column aggressively. The Won't column is your public commitment that certain things are not in the product, not just 'not yet.' Use it to close conversations about features that keep resurfacing.
Shape Up
Use the appetite concept in sprint planning. Before any feature is discussed, state the maximum time you are willing to spend on it. This creates the discipline to scope down rather than scope up.
03. The conversations
The PM conversations library
The four scripts on the team conversations page are your working vocabulary for the conversations that prevent bloat: the CEO pet feature, the sales-led customisation, the loud customer, and the engineer who wants to refactor. These are the conversations you will have repeatedly. Have good scripts for them.
The most important script is not on that page. It is the one you have with yourself. The hardest PM conversation is acknowledging which features you championed, shipped, and defended that turned out to be the wrong call. Every PM has a list of those. Naming them, learning from them, and applying the lesson to the next decision is the difference between a PM who improves and one who repeats.
04. The metrics
The PM metrics library
The metrics page covers the four measurements that tell you whether your product has feature bloat: feature usage rate, active feature count per user, time-to-first-value, and retention cohorts by feature adoption. These are the numbers you bring to a removal conversation.
For a PM, the most immediately useful metric is feature usage rate, because it is the one you can pull without custom engineering work if you have Pendo or Amplitude instrumented. Sort your features by active users. The bottom 20% is your conversation starter.
05. The hardest conversation
The hardest PM conversation: with yourself
The anti-bloat playbook is easier to recommend than to execute, especially when you have to recommend removing something you built. Most PMs have features in the product that they drove, defended, and are proud of, that a usage audit would show are used by fewer than 3% of active users. That is uncomfortable. The impulse is to explain why the usage data is wrong, why the feature is valuable in ways that are not captured by usage events, why removing it would damage the brand or the relationship with the specific customer who asked for it.
These explanations are sometimes right. Occasionally a feature is genuinely underinstrumented. Occasionally a feature is truly load-bearing in a way usage data does not capture. But more often, the explanations are rationalisations. The feature is low-usage because it is low-value, and the PM who championed it knows this and is unwilling to say it.
Owning the features you helped create, including the ones that did not work, is the PM practice that separates good product management from output management. The PM who can say “I built that, it did not work, I am proposing we remove it” is the PM who can be trusted to make honest decisions going forward.
06. Reading list
The PM reading list
The diagnostic for feature factories and the framework for product teams.
The leadership context for why product management is what it is in most organisations.
The operational methodology for preventing bloat at the process level.
The research foundation for why your instinct is to add and how to override it.
Related reading