3 ms·

I ran into this pretty heavily recently when trying to talk through problems with users (who weren't also SWEs). My goal was always to approach the problem bott

by tmpz22 7y ago

I ran into this pretty heavily recently when trying to talk through problems with users (who weren't also SWEs). My goal was always to approach the problem bottom up by breaking down into significant detail where the problem originated from and the steps to arrive at a satisfactory solution. Their concern was top down and they could care less about any of the details other then 'ok its "fixed" now' - even when these details were necessary for them to contribute to the problem at all. Long story short I sighed deeply (in private), took a deep breath, and tried to turn off any emotional connection to the problem while I did all the work necessary to make it a non-problem.

vikramkr 7y ago
Perhaps users of a product don't want to contribute to solving problems based on the product since they expect that what they are paying for is the entirety of the involvement expected from them, and you making sure it's "fixed" now is part of what they are paying for? I imagine enthusiastic early adopters would be more amenable to working through solving the problem with you, but I don't see why your general later stage user would be willing to really dive in deep with you to solve the problem?
- tmpz22 7y ago
  You're absolutely right. To clarify this is an internal tool, not a paid-for product (though I prefer to think if it as a product). The problem in question was one of basic usage and training needs. Again in short we have a very subpar UI relative to what I think the potential of great UI is, and this conversation was about bridging the gap while the tool itself is still in development. So a million pieces of context, but I think the frustration caused by the event is the same thing this blog alludes to - as an engineer I looked at it one way, as ${SOMETHING_ELSE} they saw it a different way, and the result was a lot of negative emotion (frustration, anger, apathy, etc.). As a PM I see it as my job to find a way past that, and it was a great learning experience even if I would prefer to never go through it again!

by tmpz22 7y ago

vikramkr 7y ago

Perhaps users of a product don't want to contribute to solving problems based on the product since they expect that what they are paying for is the entirety of the involvement expected from them, and you making sure it's "fixed" now is part of what they are paying for? I imagine enthusiastic early adopters would be more amenable to working through solving the problem with you, but I don't see why your general later stage user would be willing to really dive in deep with you to solve the problem?

tmpz22 7y ago
You're absolutely right. To clarify this is an internal tool, not a paid-for product (though I prefer to think if it as a product). The problem in question was one of basic usage and training needs. Again in short we have a very subpar UI relative to what I think the potential of great UI is, and this conversation was about bridging the gap while the tool itself is still in development. So a million pieces of context, but I think the frustration caused by the event is the same thing this blog alludes to - as an engineer I looked at it one way, as ${SOMETHING_ELSE} they saw it a different way, and the result was a lot of negative emotion (frustration, anger, apathy, etc.). As a PM I see it as my job to find a way past that, and it was a great learning experience even if I would prefer to never go through it again!