Turning scattered product behavior into systems
A recurring theme in product engineering: ambiguous, duplicated behavior across screens is more dangerous than it looks, and the fix is rarely glamorous.
Here’s a game every product engineer eventually plays without meaning to: “Where else did we say this exact thing?” You never plan to play it. You just fix one screen, and a week later a bug report shows up from a completely different screen with suspiciously familiar symptoms — like it copied off the first bug’s homework.
That’s not a coincidence. It’s a pattern, and it shows up constantly in product engineering work that touches many screens: hybrid telephony, analytics instrumentation, admin bulk-upload flows. Each one starts life as a single, innocent feature request. The real risk isn’t in the new screen you’re building — it’s in every other screen that’s quietly still assuming the old, simpler version of the world.
A few ways this actually shows up:
- A user who can call via SIM or cloud breaks every screen that assumed “this user is one or the other” — because now, for the first time, they’re both.
- An event taxonomy that grows organically breaks every dashboard the moment two engineers name a similar event slightly differently, and Amplitude politely treats them as two unrelated things forever.
- A bulk-upload flow duplicated across customer and allocation imports breaks consistency the moment one copy gets a bug fix and the other doesn’t even find out there was a bug.
Notice the shape: it’s never “the new thing is broken.” It’s “the new thing revealed that five old things never agreed on what the truth was.”
The unglamorous fix is almost always the same, and it fits in one sentence: find the one place that should own this piece of truth — a model, an enum, a shared component — and make every consumer read from it instead of re-deriving it locally. Nobody claps for this. It’s slower to build upfront, and it looks like doing less work, which is exactly why it’s tempting to skip. But it’s faster forever after, because the next dashboard, the next screen, the next edge case just… reads the answer instead of re-inventing it slightly wrong.
[!NOTE] This isn’t a call to over-engineer on day one. Centralizing truth has a cost too, and paying it before you need it is its own trap. The pattern only earns its keep once you’ve watched the same ambiguity cause a second bug in a second place. The first occurrence is just a bug fix — it’s the second one that’s trying to tell you something.