Hyrum's Law
Once a product has enough users, someone, somewhere, is depending on every little thing it does — including the things you never documented or intended.
Why PMs should care
The full quote is: 'With a sufficient number of users of an API, it does not matter what you promise in the contract; all observable behaviours of your system will be depended on by somebody.'
In plain terms: what your product officially promises is a tiny slice of what users actually depend on. They also depend on how fast a screen loads, the exact wording of an error message, the order items appear in a list, the colour of a success tick, the fact that a button happens to sit where their thumb naturally lands.
Once the product gets popular, any 'small tweak' can break someone's routine. This is why redesigns feel risky, why a 10-minute copy change takes three weeks of testing, and why the right way to think about a mature product is not 'we designed this' but 'users have built habits on top of this that we can't fully list'.
Practical takeaway: make the expensive changes early, while the product is still young. In a mature product, assume every change will annoy somebody you can't predict — and plan the communication, not just the code.
Example in product work
A PM ships a 'tiny UX improvement': reordering the account-settings menu so Security moves above Notifications, on the reasonable grounds that security is more important.
Within 48 hours, three support tickets arrive from power users whose muscle-memory workflow has broken: they used to double-tap the account icon and swipe-right twice to get to notification settings, and now that gesture takes them somewhere else.
The affected users are 0.3% of the base, but they include two influential community members who post about it publicly — and one of them recorded a screen capture showing the workflow from a 2019 onboarding video the product team had forgotten existed.
The change is technically correct. The change is also a Hyrum's Law violation: the old ordering was an implicit interface, and somebody was using it. A smart product team ships this kind of change bundled with a visible 'what's new' flag, a grace period for the old behaviour, or at minimum a post-ship comms plan that doesn't leave affected users feeling ambushed.
What to do when you see it
- The documented API is the smallest part of what users rely on — timing, wording, and layout all count.
- With enough users, 'small' changes never stay small.
- The right time to make breaking changes is before you have the users who'd be broken by them.
- For mature products, plan the communication around a change as carefully as the change itself.
Sources & further reading
- Hyrum's Law — hyrumslaw.comThe canonical statement of the law by Hyrum Wright himself, on the eponymous site.
- Software Engineering at Google — Winters, Manshreck & WrightThe O'Reilly book that gave the law its name and its most detailed treatment in the context of large-scale systems.