I read articles in the past about how Microsoft’s product managers were formerly software developers. Also, I recently saw an inspiring article about Google’s APM (Associate Product Manager program) that Marissa Mayer oversaw. What I’ve come to realize over my career is that people involved in the product decision making process for technology/software MUST come from a software background.
Landing a role as a product manager is no easy task, but I’ve often seen inexperienced people or those who lack the tech savvy skills and never have been in the trenches achieve such a role. The problem with this situation is that software development requires explicit details in the design aspect. I’m not talking just about the look-n-feel but the software as a whole. Because developers work from requirements thought up by product people, those lacking experience will not be able to provide every little detail that the software engineer needs. As a result, software development often ends up having their requirements becoming tester driven as opposed to test driven.
Naturally, a tester driven requirements based product is bad because that implies both an anti-pattern in organizational behavior and the lack of thoroughness in the decision making process. The thing about developers is that most will adhere to the original specification and not take up the responsibility for handling more boundary cases. The reason for this is that most developers more than likely are overburdened and will make attempts to simplify their burden anyway they can.
However, the core problem is never cured, which is that the requirements need to be well defined and scoped out. The hidden issue, as I’ve witnessed, is that the people responsible for defining the requirements tend to be lazy to put it bluntly. In all honesty, it’s impossible to define every single boundary case, but where I’ve seen issues specifically with product managers is that an oversight in a requirement leads to feature creep. In short, a bug becomes a feature. And the reason why this is a major issue in software development is that a feature may not necessarily be trivial to implement.
The other thing I’ve seen with regards to poor product management is what I feel is the lack of appreciation for the effort something can take. Part of the reason why this can occur is that the product manager has little true insight in the way a product is developed. The only way this scenario can be avoided is if the product managers themselves perform a fair share of the software development or perhaps were a part of the software development process at one time.
I think part of the problem with product management is that people seem to confuse making a product with just throwing out ideas and doing a few mock ups. For software development in particular, ideas need to be reigned in with feasibility and combined with usability testing. Second, there needs to be a road map of how something evolves that is shared with the developers. The developers need to know ahead of time how something will work to take into account the architecture and design of a piece of software. Features cannot just appear out of nowhere, especially for time sensitive projects. And product managers need to learn to let go.
But I think that these issues can go away by strategically placing more software developers into product management roles. There generally is huge respect between software developers because of the mutual understanding of what their respective roles are. They understand what is necessary to get things done as well as the structure and processes needed to make things work. More than that they can simply communicate with each other. The non-technical product managers I’ve worked with often could not understand the technical details necessary to realize why something could be difficult. As a consequence, product may not be what was originally envisioned or delayed. Having someone there who recognizes the difficulties early on could potentially help define scope better.