3 ms·

One major issue to reconcile is the granularity of data and retention. For engineers incentivized to fix problems, they need extremely high granularity, which i

One major issue to reconcile is the granularity of data and retention. For engineers incentivized to fix problems, they need extremely high granularity, which is expensive to store long-term. Product Managers typically care more about aggregations that they want to track over a long period of time. In theory you could source these concerns from the same place, but it's challenging to do it, since you'd need to process, store, and query that data in different places. This doesn't make it impossible, and I think people should try it - but it may be too hard for a lot of organizations.

a_c 4y ago
I served both role as PM and engineer. Having high level metrics is great when things are going smooth. You will need to drill down, zoom in into user journey when things don't work as expected. E.g. increased drop-off, 404s, 400s. Another aspect is causality, given a result, what caused it? Is it because a deployment, is it because a marketing campaign, or is it just seasonality. As a product person, they should want the ability to zoom in into data. Right now the only option is through communication. As pointed out by sister comment, developer need to know how their code is impacting their business. I would even argue developers are inherently a product person. You are always building for someone, be it another developer, internal users of you company, or general public. You have to know how people are using your tool. Hence as a developer you should want to be able to zoom out from whatever observability platform is currently offering. Guess what, developer thinks product managers are stupid because all they know is either looking at data and measuring the wrong thing, or chasing for status update. Product managers thinks developer are nerds that only know punching on keyboard and not talking to the users. They are both right and wrong. But we create the chasm ourselves. There are alternative ways of building things.

a_c 4y ago

I served both role as PM and engineer. Having high level metrics is great when things are going smooth. You will need to drill down, zoom in into user journey when things don't work as expected. E.g. increased drop-off, 404s, 400s. Another aspect is causality, given a result, what caused it? Is it because a deployment, is it because a marketing campaign, or is it just seasonality. As a product person, they should want the ability to zoom in into data. Right now the only option is through communication. As pointed out by sister comment, developer need to know how their code is impacting their business. I would even argue developers are inherently a product person. You are always building for someone, be it another developer, internal users of you company, or general public. You have to know how people are using your tool. Hence as a developer you should want to be able to zoom out from whatever observability platform is currently offering. Guess what, developer thinks product managers are stupid because all they know is either looking at data and measuring the wrong thing, or chasing for status update. Product managers thinks developer are nerds that only know punching on keyboard and not talking to the users. They are both right and wrong. But we create the chasm ourselves. There are alternative ways of building things.