Great product managers know when to say no.

As a PM, feature requests come at you from all sides: marketing, engineers, designers, sales, services, customers. When flooded with requests, it’s the PM’s job to evaluate each and say no to those that don’t align with the product’s strategy. Saying no to additional feature requests keeps the team focused, decreases scope creep, and draws a line on what not to include in the product.

There’s been a lot written about how to decide what to say no to. For that subject, I really like Des Traynor’s post Product strategy means saying no.

But as important as it is to know what to say no to, I’ve found that knowing when to say no is just as valuable.

I like Andy Grove’s lowest-value-point inspection principle as a model for this.

In Andy Grove’s High Output Management, he discusses product quality within the context of inventory production flows, and how to ensure acceptable product quality a manager must reject defective material at a stage where its accumulated value is at the lowest level possible.

Here’s Grove (emphasis my own):

“As we have said, manufacturing’s charter is to deliver product at a quality level acceptable to the customer at minimum cost. To assure that the quality of our product will in fact be acceptable, all production flows must possess inspection points. To get acceptable quality at the lowest cost, it is vitally important to reject defective material at a stage where its accumulated value is at the lowest possible level."

In the visual below from Grove’s book (with my own $$$ annotations included,) you can see how the value of material (and thereby the cost of its rejection) gets higher for a single item as it gets further into the production flow.

To port Grove’s idea into product management, a PM should attempt to say no to feature requests at their lowest value stage, i.e. when they’re in consideration on the backlog. The longer a PM takes to say no, the higher the cost of doing so.

For a PM, the cost of saying no comes from two places.

The first is the work of the product team itself. Just like Grove’s widget factory, product, too, follows its own process flow with its own inventory. And just as in Grove’s production flow, holding inventory in product gets more expensive the further it gets in the product lifecycle. It’s much easier to say no to a request from the backlog than to remove one that’s in-flight with engineering.

But the cost of saying no doesn’t just apply to the direct value contributed by the product team. As a feature request moves out of the undefined backlog and into the tangible roadmap, it starts to accumulate indirect value with the business as sales and services teams discuss the feature with their prospects and customers. Again, as the feature gets closer to shipping, its cost-to-say-no gets higher.

All of this means a lot of downstream impact when moving a feature request out of the backlog. In the face of these implications, a PM’s first response might be to keep all backlog requests in a holding pattern, an indefinite hiatus for future consideration. But this, too, has downstream implications.

When a feature request sits in backlog purgatory, its value of material inches forward, even without the PM’s influence. When a PM says “maybe” to a feature, the business says “maybe” (or “on the roadmap”) to prospects and customers, which further accumulates value on the feature request.

Keeping a clean and realistic backlog is one of the highest leverage activities available to a PM. By saying no to a feature request at its “lowest-value-point,” a PM can reduce downstream impact on their company’s product team, business, and customers, and avoid buildup of unrealized value.

It’s not enough to know what to say no to. When it comes to feature requests, timing is everything.