I Set a 1% Adoption Rule at PlayStation. Then I Had to Walk It Back.

At PlayStation, every PM on my teams had a feature they were sure the platform needed.

The list was impossible. Every feature drew on the same shared team resources, and every one taxed every team that had to get it out the door.

So for the teams I owned, I set a rule. Make a convincing case and we'll build it. Then show us it's actually adopted and used by at least 1% of the user base.

Back then that base was roughly 115 million, so the bar was just over a million people.

Several PMs took the challenge. They built it, shipped it, and landed nowhere near 1%.

So in the next round of releases, we told them to shut those features down and remove them from the code, so nobody had to maintain them.

Mostly, that worked. Next to no customers ever saw them.

Then it didn't. A few of the features we removed were critical corner cases, needed by small audiences, and needed badly. Those users noticed. They were unhappy.

So I went back to the stakeholders and told them the rule was wrong for those features.

A usage threshold tells you how many people use something. It can't tell you how much they need it.

What replaced it was much finer-grained audience and persona targeting. Before we built anything, we had to be clear about who the feature was really for, and what data would show it was a good investment for that audience rather than for everyone.

A 1% bar is a good filter for features built for the many. It's a bad filter for features built for the few who can't do without them.

Which feature in your product would fail your own adoption bar, and who would notice if it disappeared?