Earlier quoted context omitted.
I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…
I think a mix of both is best. If support can quickly solve a customer issue they should. But they also should make note of it and pass it along.
I forced every engineer to take sales calls and they rewrote our platform
51–60 of 221 posts
Re: I forced every engineer to take sales calls and they rewrote our platform
#52> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…
The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.
From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.
Re: I forced every engineer to take sales calls and they rewrote our platform
#53The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.
Re: I forced every engineer to take sales calls and they rewrote our platform
#54> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…
Re: I forced every engineer to take sales calls and they rewrote our platform
#55> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…
Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…
I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault?
I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire.
That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.
Re: I forced every engineer to take sales calls and they rewrote our platform
#56> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…
Re: I forced every engineer to take sales calls and they rewrote our platform
#57While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating.
The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer.
Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.
Re: I forced every engineer to take sales calls and they rewrote our platform
#58User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?"
I was then enlightened.
Every screen after that had "Press F1 for help" on it either on the top or bottom line of text
Re: I forced every engineer to take sales calls and they rewrote our platform
#59> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…
That could be the case, but I work in a mechanical engineering group as the only person on the team who can write code or automate things with it. We're in a large corporation with a sizeable IT support group that builds a decent chunk of the software in-house, and our team views much of it as terrible. So, I've rewritten applications or supplemented the "terrible" but irreplaceable software with tools to make our jo…
1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility.
2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote...
I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself