| My company is going through a dynamic shift to more closely align to the "best" situation you outline here. Previously engineers were presented with functional requests, i.e. solutions, and not feature requests or problems. E.g. a lot of our stories were defined as "set a value on page foo, display it in table bar" without any context. This caused a lot of frustration on the engineering side because we didn't know why we were doing something, and were never given a chance to actually engineer something. It was compounded by the fact that these "solutions" were often reversed or made obsolete a month later by a new "solution" that could have been there from the start. Thankfully, we've started having the real problems brought to the engineering side and work together with product management to come up with a solution. Yes, this means more meetings, but in the long run we're saving ourselves a ton of time un-doing work and avoiding traps in the code early on. I firmly believe when you remove the "why" context from the conversation with engineering, you lose time and, more importantly, trust in the product team. I've not once come into contact with a product team/person who can accurately translate the "why" into the "how" seamlessly. The most value I, as an engineer, get from the product team is their help in prioritizing work and coordinating across teams. Let us solve problems together. |