Sometimes you are the user

I joined the platform team at Dynatrace a month ago, after the last five years in consumer IoT. One of the first lessons has nothing to do with the technology. It's about how much depends on actually using the product yourself, end to end, the way a real customer would.

This doesn't replace research, interviews, or watching real users work. Those still matter. It adds a kind of context that's hard to get any other way, especially on a platform where the user is doing serious technical work and the situations that matter most are the ones nobody can fully describe in a session.

Observability is a good example. It isn't really a data problem, it's a sense-making problem, and that makes it a design problem. When something breaks in a distributed system you don't have too little information, you have too much. Logs, traces, metrics, events, dependencies, deploys, alerts. The person trying to fix it isn't missing data. They're trying to figure out what matters. Designing for that from a single slice of the product is hard, because the slice rarely tells you what the whole experience feels like under pressure.

There's a version of design orthodoxy that says you are not the user. For a lot of consumer products that holds up. Platform tools sit in a different place.

The job turns out to be similar to the one I had at Electrolux. Connected appliances throw hundreds of possible error states at you. Sensor failures, connectivity drops, motor issues, software faults, edge cases nobody planned for. The temptation is to surface all of them, because technically they're all real. The actual work is figuring out which ones matter, and translating the rest into something the person can act on.

Same job now. Different scale.