3 ms·

Mixing up these two concerns is a bad idea. Your product manager now has to convince engineers to implement the metrics they want. Data that is irrelevant to en

Mixing up these two concerns is a bad idea. Your product manager now has to convince engineers to implement the metrics they want. Data that is irrelevant to engineers now needs dragging along to places inside the system so that events are useful to both engineers who car about data and latency and product managers who care about individual user behaviour. So while there is indeed overlap, the two types of metrics involve different people, different teams, different concerns, different data, different privacy concerns, and different reliability/uptime concerns.

a_c 4y ago
Structure follows strategy. There are various reasons product manager exist but the role doesn't exist unless the team grows to a certain scale. All founders serve as a product manager some point in their start up journey because they need to know if the thing the built works. There are companies wanting to spend energy on building things that work and skipping a layer of communication is one way of doing it. That's also how compiler speed up a program sometime, by inline expansion or by loop unrolling. It doesn't work all the time. But as an option. Right now there seem to be an orthodox in product development
GauntletWizard 4y ago
All of your arguments are great, for why you need to treat observability as a core product feature and tie it to core product features. Engineers need to be serving the orgs goals, and one of the best ways to do that is to give them incentive and tooling to be thinking about the same things the product owner is. Have them build metrics for business metrics. Those are the things you should be alerting on, and to the extent you alert on technical pieces it should be in the service of those business metrics; don't alert on latency because it's an arbitrary goal, alert on latency because you can see how it affects user experience.

a_c 4y ago

Structure follows strategy. There are various reasons product manager exist but the role doesn't exist unless the team grows to a certain scale. All founders serve as a product manager some point in their start up journey because they need to know if the thing the built works. There are companies wanting to spend energy on building things that work and skipping a layer of communication is one way of doing it. That's also how compiler speed up a program sometime, by inline expansion or by loop unrolling. It doesn't work all the time. But as an option. Right now there seem to be an orthodox in product development

GauntletWizard 4y ago

All of your arguments are great, for why you need to treat observability as a core product feature and tie it to core product features. Engineers need to be serving the orgs goals, and one of the best ways to do that is to give them incentive and tooling to be thinking about the same things the product owner is. Have them build metrics for business metrics. Those are the things you should be alerting on, and to the extent you alert on technical pieces it should be in the service of those business metrics; don't alert on latency because it's an arbitrary goal, alert on latency because you can see how it affects user experience.