Tag Archives: product managers

Product Managers & Innovation

Thanks everyone for the great conversation in the most recent #prodmgmttalk chat session!  This week, Roger Cauvin inspired us to think about product managers as innovators – or enablers of innovation.  Each week, I find myself thinking about at least one of the #prodmgmttalk questions long after the hour is over.  This week’s thought – organizations prevent product managers from innovating.

Continue reading

The Conversation Ecosystem

The previous article, The Conversation Economy, lays out a perspective of approaching the success of your business, and of your product, in light of the conversations that flow around them.  You can view the ecology that defines your market in terms of the kinds of conversations you’re having with your customers, users, and prospects.  This article explores that ecosystem in more depth – categorizing the types of conversations that are critical to the success of your product.

Continue reading

Michael Arrington’s Inbox is Fat!

techcrunch logo

Michael Arrington has 2400+ unread emails in his inbox. And he needs someone to fix it.

If you are the person with the idea to save us all, send me an email and tell me all about it. Actually, strike that. Drop by my house and tell me all about it. I don’t want your message to get lost in my inbox.

Michael Arrington

Michael is looking for the email equivalent of a magic diet pill. He can’t change his behavior, so he needs a dietary supplement. The dieting-market is huge, and products succeed playing on that emotion for dieters. Is email management the same?
Continue reading

Superhero Product Managers

Superhero

Product managers are the leaders in organizations that lead by unfluence, adapt to changing circumstances, understand domains and markets, and communicate effectively with executives, customers, and development. They set scope, understand value, prioritize and define direction. They leap tall buildings in a single bound…

Killer Quote

In my opinion, there are two really hard jobs inside a company. One is being a CEO, and the other being a product manager. A few reasons why I believe this. Both the CEO and Product Managers are expected to be the most flexible acrobatic kind of leaders — adjusting to people’s styles, making sure to communicate with clarity the requirements of what is needed, translating vision into specifics and constantly at the beck and call of many constituents. It’s a wonder someone would take the job. Either one.

Nilofer Merchant, Founding Principal at Rubicon Consulting

Great opening to a great article! And a hat-tip to Steve Johnson at Pragmatic Marketing for sharing it with us. Definitely check out Nilofer’s article.

Visionaries

Like CEOs, product managers have to be visionaries. They identify exploitable market opportunities. They inspire their teams to strive towards the success of the products designed to meet those needs. And they help get the message out to customers about the solutions.

Organization of the Organization

silos

Nilofer points out that the old corporate silo structure (design/build/market/sell/deliver) is no longer “the best way.” Product management is a cross-discipline skill. As product managers, we have to work with, understand, and inspire people in all areas. When we optimize on each silo achieving independently, we lose out on cross pollenation.

Nilofer suggests that “B players” who work together well are better people to have on the team than “A players.” We respectfully disagree. A true “A player”, like the free electron developer (see the people section of this article), is not someone who is good in their silo, but can’t work with others. An “A player” is someone who is good at executing within their area of expertise and collaborating with people in other areas. Are people with good collaboration skills better to have on the team than people who can’t collaborate? Absolutely. Should we sacrifice execution ability for collaboration? No. But we don’t have to. It isn’t an either-or proposition, it is more of a magic square.

a players

With a focus on combined collaboration and capability, Nilofer offers some suggestions on how to best succeed:

  1. Create a culture in which product management leads.
  2. Get the right information (to the PM) and peer support (for the PM).
  3. Listen to customers, executives, and competitors.
  4. Hire product leads and engineers who can collaborate.

We also believe that it is important to

  1. Execute incrementally. Feedback is organizational learning. Incremental delivery yields more feedback, therefore more learning, and ultimately better products.
  2. Keep product managers strategic. If product managers are doing other people’s jobs, who will do the product manager’s job?

Conclusion

Let product managers drive direction for the company. Make sure they, and their collaborators across the company work together, not in isolation. Deliver incrementally with this organizational structure.

Product Managers Play Tug-of-War

tug of war

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.