When adding features actually is the right answer

Platform plays require completeness. AWS cannot have half of S3. Windows cannot have half a filesystem. iOS cannot have an incomplete App Store API. Stripe cannot serve payments without also serving authentication, fraud detection, and tax calculation, because the alternative forces every user of Stripe to integrate three separate vendors at exactly the point where they most need simplicity.

Platforms are judged on coverage. Products are judged on focus. If you are truly building a platform, the anti-bloat advice misfires because your users are developers who will build on top of you, and they need the surface area they can rely on.

The diagnostic question: are your users building on top of you, or using you? If they are building on top of you, platform completeness is a legitimate constraint. If they are using you, platform thinking is rationalised bloat.

A second diagnostic: when a platform feature has low usage, is that because users are not using it, or because users are calling it programmatically and the usage data is not captured in your product analytics? Platform usage is often invisible to product analytics. Low usage in Amplitude does not mean low usage in production.

A seven-figure contract that requires SOC2 Type II compliance, SAML single sign-on, SCIM directory sync, granular role-based access control, audit logs, and a 99.9% uptime SLA is asking for things that are not features in the consumer sense. They are table stakes for a regulated market tier. Refusing to build them is not a principled stand against bloat; it is a refusal to compete in the enterprise market.

The distinction is precise: enterprise compliance features are not features that expand what your product can do for the user. They are features that allow the enterprise's security team to allow your product to be used at all. SAML is not a feature that improves the product. It is a feature that removes an organisational barrier to adoption.

Build these. Build them in a separate enterprise tier. Document them separately. Price them into the enterprise contract. The trap is not the feature; the trap is thinking that the enterprise feature belongs in the standard product.

The diagnostic question: is this feature expanding what your product does, or is it expanding who is allowed to use it? If it is the latter, it is an enterprise access feature, not a product feature, and it belongs in the enterprise tier.

Marketplaces, social products, and messaging applications are judged by density and coverage, not by focus. A messaging app without voice messaging is genuinely less useful than one with voice messaging. A marketplace without reviews is genuinely less trustworthy than one with reviews. These are not features that expand what the product can do; they are features that strengthen the core network.

The historical examples are instructive. WhatsApp added voice memos. This strengthened the core messaging experience. iMessage added Tapback reactions. This strengthened the conversational layer without expanding into adjacent categories. These additions deepened the network, not the feature set.

Contrast with WeChat, which expanded into payments, food delivery, ride-hailing, government services, and banking. WeChat works in China because the regulatory environment and the scale of WeChat's network make consolidation rational. Facebook Shops, by contrast, was an expansion into e-commerce that weakened the social product without establishing a defensible commerce product.

The diagnostic question: does this feature make the network more valuable to everyone in it, or does it expand the product into an adjacent category? Voice messaging makes messaging more useful. Marketplace functionality in a messaging app makes messaging more complicated.

If the top three products in your category all lack feature X, and feature X is something that a significant portion of customers are asking for, building feature X is market positioning, not bloat. You are not copying a competitor's existing feature. You are identifying a gap that nobody has closed.

This is the rarest and most legitimate case. The condition is strict: the feature must be absent from all leading competitors, not just from one. It must be requested by customers who represent a meaningful segment, not a vocal minority. And it must be genuinely absent, not merely undiscovered or undiscoverable.

The historical example: when GitHub introduced GitHub Actions in 2018, it addressed a genuine gap in the CI/CD integration that all major repository hosts shared. This was not feature-matching GitHub's competitors; it was identifying and closing a gap that developers had been patching with third-party integrations. The result was strategic differentiation, not accretion.

The diagnostic question: is this feature absent from every major competitor, or absent from some? If it is absent from every competitor, why? Is it technically hard? Is it strategically outside all of their roadmaps? Or is it a feature that seems important but actually is not, which is why nobody has built it?

The single most reliable signal that you are rationalising rather than reasoning is that your justification depends on a claim about your users that you have not verified with user research. Platform completeness, enterprise requirements, network effects, and market differentiation are all empirical claims. They are true or false based on what users actually do and say, not based on what the product team believes they will do.

Run this check: can you point to user research that specifically validates the claim? Not user research that validates the feature (features always look good in user tests, because users love potential). User research that validates the structural claim: that you are a platform, that the enterprise segment requires this, that the network effect is present, that the differentiation gap is real.

If you cannot complete these sentences with evidence, you are in anti-pattern territory. Read /anti-patterns and use the decision framework before proceeding.