63% of product managers report to marketing and 24% report to development. 22% of requirements managers report to marketing with 55% in the development organization. These reporting structures can over-emphasize the needs of new users and super-users, while shortchanging the needs of the majority of users. Product managers will constantly be playing tug-of-war to get time to do the right thing.
The Softletter Survey
Softletter executed a survey earlier this year, which found that almost two thirds of product managers report to marketing, and a majority of requirements managers report to development. Detailed survey results are available by Subscription.
SVPG
The Silicon Valley Product Group recently published an article about this very issue. They point out significant problems with both reporting structures. Hat tip to Nils for finding this one. Nilsnet is on our blogroll and makes good reading – you should check it out.
Product management in the marketing group:
Further, what usually happens is that the product marketing role and the product management role get combined. These roles and the skills required so different that what usually ends up happening is that one or the other (or both) gets poorly executed.
Product management in the development group:
Moreover, it’s easy for the product management team to be consumed in the details and pressures of producing the detailed specs rather than looking at the market opportunity and charting a winning product strategy and roadmap.
Alan Cooper’s Take
In The Inmates Are Running The Asylum, Cooper points out that marketing people tend to over-emphasize the needs of new users. Their interactions are primarily with people who we want to buy the software. As such, they spend most of their time understanding the needs of people who haven’t used the software, or who have just started using the software.
Developers, or as Cooper calls them, homo-logicus, are a special breed of people who are much more capable of dealing with complexity than average users. They appreciate good algorithms, customizability, and full-featuredness. They don’t run into the problems that most people have when dealing with software that has too many features.
Johanna Rothman asked the question in April, “Do engineers use their own software?” Her point was simply that if engineers have to “eat their own dog food” they will introduce fewer bugs. There are definitely benefits to this mindset. However, the engineers should not be specifying the features for the products (unless the products are to be used only by other engineers).
Competent Users
Our priorities as product managers should focus on competent users. Most people develop a level of competence quickly and most people stop learning when there is no additional benefit to learning more. Therefore most people don’t become experts. With a lion’s share of our users being competent, we need to make sure we emphasize them in our requirements and design decisions.
Organizational Bias
As SVPG points out, product managers will tend to evolve into the activities most valued in their organizations. Combine this with Cooper’s take on the needs of the everyman, and we end up having to devote energy to overcoming organizational bias in order to prioritize the needs of the majority of users.
Conclusion
Product Management should be represented in its own organization. This allows a focus on the right users, and will likely make it easier to avoid tactical tangents that take away time from strategic decision making.
Latest Articles
Comments on all Articles
