Scrape the Barnacles
Remove low-use features before their complexity spreads across the product
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 95%
Scrape the Barnacles is Biddle's reach-based rule for preventing feature bloat. Before building or retaining a feature, estimate what share of customers will use it and whether that reach can plausibly improve retention or another core outcome. He is especially skeptical of “two percenters”: ideas used by only a tiny minority. Their direct value is small, yet every customer must process another choice and every product team must remember another state, dependency, and edge case. After launch, actual usage replaces the forecast. If adoption remains too low to affect the target metric, remove the feature rather than preserving it because some customers like it. The precise threshold depends on the product, but Biddle's Netflix examples show the governing logic: a social feature reaching about 5% of members still failed to justify its complexity.
Origin
Biddle used the phrase at Netflix for removing features with very low adoption. He cites forgotten DVD profile dependencies and the Xbox Party feature, which reached roughly 5% of members and was later killed.
Core principles
- 01A feature needs enough reach to change a business outcome
- 02Every option adds complexity for users and builders
- 03Low adoption makes retention or margin impact unlikely
- 04Past social-feature failures are evidence for future reach estimates
How to run it
- 1
Forecast reach
Estimate the percentage of eligible customers who will use the feature. Use comparable past launches rather than relying only on enthusiasm from a vocal niche.
Pro tip Ask for a percentage before discussing implementation details.
Watch out A dramatic conversion lift among a tiny audience may still have negligible total impact.
- 2
Connect reach to an outcome
Specify how adoption should improve retention, revenue, engagement, or another core metric. Calculate whether the likely number of users is large enough to move it.
Pro tip Use an absolute member count as well as a percentage to expose the real scale.
Watch out Potential strategic value does not matter if too few customers experience it.
- 3
Price the complexity
List the new choices customers see and the additional states, platforms, and dependencies the team must maintain. Treat forgotten edge cases as a recurring cost, not a one-time mistake.
Pro tip Ask every adjacent team what they must now remember because the feature exists.
Watch out Low-use features can remain expensive long after their launch team moves on.
- 4
Measure and prune
Compare real adoption and outcome movement with the forecast. Kill features whose reach and impact cannot pay for their ongoing complexity.
Pro tip Make removal an expected outcome of feature review rather than an admission of failure.
Watch out Do not let sunk cost or a small group of fans override product-wide evidence.
In the wild
Netflix and Xbox let members watch together remotely. Biddle expected the feature to be a two-percenter; it reached roughly 5% of members. Despite the social and network-effect hypothesis, Netflix killed it because usage was still too limited to justify the feature.
→ Historical adoption became evidence against assuming that a later Netflix Party concept would reach enough members to improve retention.
Netflix already supported profiles for its DVD product. When streaming launched, the team forgot about that existing feature, illustrating how each additional capability creates dependencies that future builders must remember across product surfaces.
→ The incident showed that feature complexity persists beyond the original launch and can create omissions in later products.
Common mistakes
Confusing intensity with reach
A niche may love a feature while the total user population barely notices it. Strategic impact depends on both strength of benefit and number of users reached.
Counting only build cost
The larger burden may be the choices, dependencies, and forgotten edge cases that remain for years after launch.
Is it for you?
Best for
Teams auditing mature products or evaluating niche features whose passionate users may overstate their total reach.
Not ideal for
Safety, accessibility, compliance, or infrastructure capabilities that are essential even when few customers actively use them.
From the episode
Gibson Biddle on his DHM product strategy framework, GEM roadmap prioritization framework, 5 Netflix strategy mini case studies, building a personal board of directors, and much more