4 ms·

It is critical to expose workers to the problems that their customers experience, but if this is the only way to do it, then you have multiple failures in how y

by raiyu 5y ago

It is critical to expose workers to the problems that their customers experience, but if this is the only way to do it, then you have multiple failures in how your organization is structured. Really this is the job of the product manager, and if the product manager isn't actively using your product, or talking with your customers and end users, then they are failing at their job. But the number of product managers that take this part of the job seriously is abysmally low. Which is why companies have to instate other patterns to try and get this work done.

solidsnack9000 5y ago
Yeah, there may be a middle way, here. Some employees should have this kind of crossover experience; but it's probably not a requirement that all of them do.
Melting_Harps 5y ago
> It is critical to expose workers to the problems that their customers experience, but if this is the only way to do it, then you have multiple failures in how your organization is structured. Maybe, but direct feedback is incredibly insightful and worth it's weight in gold when time to market and product market fit are critical to the operation's survival: startup v Corp World. > But the number of product managers that take this part of the job seriously is abysmally... It really is, stepping into the Corp World starting from a bootstrapping co-founder position) was a total culture shock! Moreover, the lack of clarity and vision is toxic to a Team's overall productivity, coupled with the fact that the they are likely the one with the most TC it's hard to rationalize the drudgery that it becomes--it's less optimization of stand out core functionality, and more adding needless features and bug testing busy work to suit a PM's 'roadmap to success' they think will lead to the next rung on the corporate ladder. I can't think of a worst way top operate, actually.
Closi 5y ago
> Really this is the job of the product manager, and if the product manager isn't actively using your product, or talking with your customers and end users, then they are failing at their job. Eh, I've been a product manager and have taken my engineers to do the job, and it really changes how you talk about issues. I used to be PO for a team which developed warehousing software (a WMS) and would take engineers from my team to go picking for the day (if they were willing). Dev teams will push back on some tickets, and say for instance that latency is fine (and that it's not possible to fix and unavoidable!). Besides, they know it's not user-perceptible at the current rates, and they know the exact latency as we have telemetry built in. If they do try to reduce latency, it's a half-assed effort with eye-rolling. Then when they actually go and experience the job for a day they come back and are motivated and engaged to reduce latency because they have experienced it themselves, talked to users, and have watched other people working and can see the slight pause before the next pick. Suddenly maybe we should be pre-loading information before the next pick so that we don't need to wait for a web-service response? And as an added benefit - the engineers would come back actually understanding the job and problem fully in a non-academic and practical way (people don't really 'get' how something works in practice until they have done it themselves, regardless of how simple it sounds on paper). And my personal experience was that a team of engineers that actually understand the problem are more effective and motivated to solve it (even if they didn't enjoy doing manual labour for a day). I don't really buy the "only the PO needs to understand what the users want" - personally I see it as the PO's role to deeply understand what the users want and translate that into features / user stories, however everyone on the team needs to understand the job.

by raiyu 5y ago

solidsnack9000 5y ago

Yeah, there may be a middle way, here. Some employees should have this kind of crossover experience; but it's probably not a requirement that all of them do.

Melting_Harps 5y ago

> It is critical to expose workers to the problems that their customers experience, but if this is the only way to do it, then you have multiple failures in how your organization is structured. Maybe, but direct feedback is incredibly insightful and worth it's weight in gold when time to market and product market fit are critical to the operation's survival: startup v Corp World. > But the number of product managers that take this part of the job seriously is abysmally... It really is, stepping into the Corp World starting from a bootstrapping co-founder position) was a total culture shock! Moreover, the lack of clarity and vision is toxic to a Team's overall productivity, coupled with the fact that the they are likely the one with the most TC it's hard to rationalize the drudgery that it becomes--it's less optimization of stand out core functionality, and more adding needless features and bug testing busy work to suit a PM's 'roadmap to success' they think will lead to the next rung on the corporate ladder. I can't think of a worst way top operate, actually.

Closi 5y ago

> Really this is the job of the product manager, and if the product manager isn't actively using your product, or talking with your customers and end users, then they are failing at their job. Eh, I've been a product manager and have taken my engineers to do the job, and it really changes how you talk about issues. I used to be PO for a team which developed warehousing software (a WMS) and would take engineers from my team to go picking for the day (if they were willing). Dev teams will push back on some tickets, and say for instance that latency is fine (and that it's not possible to fix and unavoidable!). Besides, they know it's not user-perceptible at the current rates, and they know the exact latency as we have telemetry built in. If they do try to reduce latency, it's a half-assed effort with eye-rolling. Then when they actually go and experience the job for a day they come back and are motivated and engaged to reduce latency because they have experienced it themselves, talked to users, and have watched other people working and can see the slight pause before the next pick. Suddenly maybe we should be pre-loading information before the next pick so that we don't need to wait for a web-service response? And as an added benefit - the engineers would come back actually understanding the job and problem fully in a non-academic and practical way (people don't really 'get' how something works in practice until they have done it themselves, regardless of how simple it sounds on paper). And my personal experience was that a team of engineers that actually understand the problem are more effective and motivated to solve it (even if they didn't enjoy doing manual labour for a day). I don't really buy the "only the PO needs to understand what the users want" - personally I see it as the PO's role to deeply understand what the users want and translate that into features / user stories, however everyone on the team needs to understand the job.