twitter verification — when product design conflates two different jobs

Two jobs, one feature

Twitter's verification checkmark started with a specific purpose: help users distinguish the real @Drake from @SixGodDrake, the real @NYTimes from a parody account. Authenticity in a pseudonymous network is a genuine product problem. The blue badge solved it.

But in 2014, Twitter made a decision that planted a slow-burning product failure: they started giving verified users special features. Priority in search. Reduced harassment controls. Access to analytics tools unavailable to regular accounts.

That single decision — bundling identity authentication with platform privilege — is the root cause of every verification-related crisis Twitter faced for the next seven years. The product design mistake is clean in retrospect, and the reason it kept compounding is worth understanding precisely.

The Decision: authentication or status?

The verification system Twitter built was an answer to a real problem. In 2009, Kanye West's team contacted Twitter because fake @KanyeWest accounts were proliferating, some of them posting content that was being attributed to the real artist. The verification badge was Twitter's operational response: a way to tell users "this account is who it says it is." Not "this account is important" — just "this is the authentic account for this identity."

That's a binary, factual designation. You either are who you claim to be or you aren't. It requires no editorial judgment. It doesn't imply endorsement. A verified badge on the account of a convicted fraudster is not Twitter saying the fraudster is trustworthy — it's Twitter saying this account is actually him.

The problem started when verified status acquired perks. Once verification came with search priority and reduced harassment exposure, it stopped being purely an authentication signal. It became desirable independent of its authentication function. And the people controlling who got it — a small team inside Twitter Support — now had to make judgment calls about whose identity was "important enough" to verify. These are inherently subjective, politically fraught decisions that no team of any size can make consistently across millions of requests.

Twitter had collapsed two independent features into one object. The right architecture would have separated them:

• Verification — a binary, factual flag: authenticated or not. Set by a neutral identity process. No perks. Never revoked for content violations, because it's factual, not evaluative. Jason Kessler exists and runs a white nationalist organization. Verifying his account means "this is him," not "we approve of him."
• Platform standing — a separate, adjustable signal based on follower count, engagement rate, or editorial selection. This can carry perks. This can be revoked for conduct. This can be applied with different criteria to different account types.

Keeping them separate means you can do both jobs without each one corrupting the other. Collapsing them meant that every verification decision became an implicit values statement, and every revocation became a political act.

How the conflation caused damage

In 2017, Twitter verified the account of Jason Kessler, organiser of the Charlottesville Unite the Right rally that resulted in a death. The backlash was immediate. Twitter's support account issued a rare public acknowledgement: the team had been conflating verification-as-authentication with verification-as-celebrity-endorsement, and the confusion was partly their own making.

The self-awareness was notable. What followed was less coherent.

Within days of acknowledging the confusion, Twitter's support account posted that they would revoke verification from accounts that violated civility norms. This about-face made things catastrophically worse. If Twitter takes away the badge for bad behaviour, they are definitionally admitting the badge is a reward — not an identity marker. Which means every decision to verify or de-verify is a values judgment about whose speech deserves amplification.

Now Twitter was in an impossible position: they couldn't strip verification from @realDonaldTrump for norm violations without a political firestorm, but they couldn't apply different standards to different verified accounts without appearing arbitrary and capricious. The product design choice made in 2014 had created a governance trap that no policy decision could resolve cleanly, because the policy problem was downstream of the product design problem. You cannot fix a governance mess created by bad data modeling with better policies. You have to fix the data model.

What Worked / What Failed

What worked was the original conception: authentication as a neutral, factual service. This is still useful, still necessary on any platform with multiple accounts claiming the same identity. The badge does real work when it's limited to that function.

What failed was the feature bundling. The decision to add perks to verified status seems minor in isolation — a small incentive to make verified users feel valued, probably made without a document or a debate, almost certainly as a growth or retention nudge. These are the most dangerous product decisions: the ones that don't look like product decisions. Adding analytics access to verified accounts doesn't feel like a policy choice about whose speech Twitter endorses. But once the badge carries benefits, the question of who gets it becomes a question about who deserves those benefits — and that is explicitly a values question.

The Elon Musk-era decision to sell verification for $8/month through Twitter Blue attempted to resolve the problem by commoditising it: remove the editorial judgment by making it available to anyone who pays. This solved the consistency problem (no judgment required) at the cost of destroying the authentication function entirely. If anyone can buy a blue badge, the badge no longer tells you whether the account is who it claims to be. The solution eliminated the feature's original value in order to eliminate its governance overhead.

The deeper failure was the organisation's inability to hold two things to be simultaneously true: that the authentication problem is real and worth solving, and that a badge that solves it must be completely free of platform privilege to work. Every time those two conclusions were in tension, Twitter defaulted to the governance problem in front of them rather than the structural fix underneath it.

What a PM should take from this

Feature scope creep usually looks like a good idea. Adding perks to verification probably seemed sensible: verified users are often high-profile creators and brands, they should feel valued, analytics access will make them more successful on the platform. Each incremental addition has a local rationale. The problem is that each addition is also a commitment — it changes what the feature means to users, which changes what the governance rules around it need to be, which changes the team and process that manages it. By the time the cumulative cost is visible, the feature has already calcified.

The Twitter verification case is a clean illustration of what happens when you don't define the job-to-be-done at the feature level with precision. "Verification" is a name, not a job. The job was identity authentication. The moment the badge began doing a second job — platform status signalling — it needed a different name, different governance, and different criteria. The failure to make that separation explicit is what made every subsequent crisis inevitable.

For PMs: when a feature starts serving a second use case, that is the moment to split it — not to add the second use case and manage the tension informally. The informal management always breaks in public, usually at the worst possible time, and usually in a way that looks like a policy failure when it was always a product architecture failure.