There’s an interesting thread going on across several blogs about the Agile development method (Agile, here and across other posts, is being used as a catch-all for many rapid release methodologies) and the role of Product Management. I have posted an article and made comments on several of these blogs, but this post isn’t about that. It’s about the relationship between Product Management and Engineering.
The Cranky Product Manager, in her post about Agile, and a response from one of the other bloggers involved in the discussion demonstrates the tension between Product Managers and Engineering groups.
Engineering and Product Management by their very functions have a somewhat adversarial relationship. Product Managers want as many new features and bug fixes in a release as possible as quickly as possible. Conversely, Engineering wants to minimize the development and QA effort and insure that their are no regressions.
This conflict is not necessarily bad. Paul Sherman, in a post at UX Matters in Jan07, wrote the following–
“In fact, some conflict between the disciplines is a necessary part of the process. For example, product management wants to build more in a given timeframe than its developers’ capacity allows. Or developers need more time to build complex features, but because of their company’s business requirements, product management wants to allocate less time for a development cycle. Or maybe QA identifies what it thinks is a severe defect, but development views it as a minor or moderate bug and would rather publish a workaround in the release notes and fix the bug in Release 1.1.”
The conflict helps balance all of the needs of product constituencies, but it can be an uncomfortable balance. If one party dominates the conversation, the balance is lost and product value will suffer.
An example of this is when the Product Manager constantly demands that features be added or changed well past the code freeze deadline. They may be trying to address a market or customer need, but this level of change is very taxing on the Engineering group and can lead to animosity and poor quality or even be as disruptive as causing key members of the development team to ask for reassignment or leave the organization altogether.
Engineering dominance can be just as problematic. Take the case of a Dev manager who is totally inflexible with regard to scheduling or who adds so much pad to the timeline that hardly any valuable features can be added within a reasonably sized release. The end result is that the product continues to lose ground to competitors or does not have enhancements or bug fixes in sufficient amount or quickly enough to satisfy customers.
Both of these scenarios spell trouble for the product. But can the appropriate balance be struck without all of the friction commonly associated with the relationship between these two groups? The truth is, it depends.
It depends on whether the Product Manager and Engineering leads see themselves as adversaries or not. In reality, they both benefit by making a better product (read: one that generates more revenue for their company), but they generally have different world views. If they can come to some consensus about a unified world view of the product, they are much more likely to move forward together in giant leaps, rather than inching along while grappling each other.
Granted, this is a LOT harder to do than it is to write about. Trying to overcome years of collective experience within an organization is not a task for the meek. Be prepared to experience what it feels like to be in a mosh pit at a Black Flag concert. You’ll likely have some bruises and scars to show for it, but you could come out liberated from the confines of the traditional Product Management/Engineering relationship.