Migrating 60,000 Products: Lessons in Data, Process, and Patience

The systems behind a product shape what customers experience—even when those systems remain invisible.

Product decisions become more useful when we understand the forces around them: the events that move through the system, the teams responsible for responding, and the moments where context can disappear.

The mental model

Start with a simple question: what happened, who needs to know, and what should become possible next? This shifts a conversation away from screens and toward the behavior of the whole product.

Good architecture gives a team better questions before it gives them faster answers.

Why it matters

A shared mental model helps product, engineering, data, and operations discuss trade-offs using the same map. It also makes failures easier to reason about because ownership and evidence are explicit.

// An event describes a fact, not an instruction
product_viewed → context captured → signals evaluated

Putting it into practice

1. Name the customer or business event.
2. Identify the decisions that depend on it.
3. Make observability part of the product requirement.
4. Design for late, missing, and duplicated signals.

Closing thought

Technical fluency is not about becoming the architect. It is about collaborating with enough clarity that product intent survives contact with the system.