> 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…
I forced every engineer to take sales calls and they rewrote our platform
11–20 of 221 posts
Re: I forced every engineer to take sales calls and they rewrote our platform
#12> 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…
Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.
Re: I forced every engineer to take sales calls and they rewrote our platform
#13> 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
#14The TL;DR message should be make sure the real needs get serviced.
Re: I forced every engineer to take sales calls and they rewrote our platform
#15Earlier quoted context omitted.
Are you saying that you follow directions better because you wrote them... or that you are just ending up with a better UX because of your involvement?
Human communication is incredibly lossy (sometimes intentionally), plus humans will try to fill in gaps with assumed information. The more people you cut out between the message sender and the receiver, the more likely the message is to still be intact. The kindergarten game of telephone is the perfect demonstration. You only end up with distorted messages if you have many players between the sender and the receiver.…
Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.
Re: I forced every engineer to take sales calls and they rewrote our platform
#16Dogfooding works
Unfortunately, that's not always possible. I wonder if that's why I always liked building tools for "internal" clients, other users within the org - it was trivial to just Slack someone or ask if I could walk over to their desk.
Re: I forced every engineer to take sales calls and they rewrote our platform
#17Re: I forced every engineer to take sales calls and they rewrote our platform
#18> 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
#19I have been at countless places where the engineers are out of sync with the product.
And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product.
Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> product] loop is heavy. It takes a long time and major things get fixed but minor friction doesn't.
having [product engineer] can be amazing.
Engineers might have never encountered the full experience, or may merely be out of sync with how it works today vs last year.
Re: I forced every engineer to take sales calls and they rewrote our platform
#20> 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…