This is an excellent strategy for smaller startups, where every individual contributor needs to have an understanding of the customer's needs, in order to develop an understanding of what kind of product must be built. I have much more success in projects where I deeply understand the product requirements (because I am involved in defining them), than those where the product requirements are "handed" to me and I just have to implement something that satisfies them.

▲

ranger_danger 4 days ago | parent [-]

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?

▲

dghlsakjg 4 days ago | parent [-]

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. If you play telephone with 2 people, you end up with a boring game where any mistakes in communication are immediately resolved.

▲

davorak 4 days ago | parent [-]

The telephone game is the analogy I use too when explaining the value of having engineers in the custom calls.

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.

	▲	dghlsakjg 4 days ago \| parent [-]
		> engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next. The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week. Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.