Common PM Problem Areas

Recently I was at a dinner with several product leaders, and I was asked what the most common areas of confusion I encounter in product teams today?

I thought it was a good question, and I described several situations, and judging from their response at least, these seem to be problems they had seen in their organizations as well.

So I thought it would be useful to get these problems out on the table so we can watch for them, and more aggressively and intentionally try to tackle them.

Validating Ideas vs. Discovering Solutions

There is a lot of discussion about the many techniques we have for quickly identifying and testing our assumptions and validating product ideas.  Most teams have got to the point where they can usually do this pretty effectively.

Of course, in many organizations, the majority of ideas still come from execs and stakeholders.  But now, rather than just proceeding to designing and building, product teams know they have an obligation to make sure they’re not wasting the company’s time and money by building something that fails to solve the underlying problem.  So they identify the risk, and craft a test – usually by quickly creating a prototype and getting either qualitative or quantitative feedback on the idea.  And no surprise, very often they find the idea is not a good one, so they go back to the stakeholder and report that they aren’t going to build this because the idea was not going to work.

But after doing this several times, pretty soon the stakeholders get pretty frustrated.  After all, they are trying to run their part of the business, and getting told “no” all the time gets old quick.  Eventually, the stakeholders and execs have had enough and they tell the teams either build this or they’ll find others that will.

What I try to explain to the product teams is that their purpose is not to serve as gatekeeper and just validate the requests that come in; their purpose is to discover solutions that work.

A good product team ensures they understand the underlying problem to solve, and then will try out several ideas or approaches until they discover one that does work.  The stakeholders come to view the strong product team as problem solvers, that are committed to finding a way to deliver the necessary results.

Planning vs. Prototyping

There are several good techniques for framing and planning our discovery work.  I advocate for several of them in my book.  However, they should be quick, because most of our time needs to be going to figure out a solution that actually solves the problem.

I often find teams spending far too much time stressing over evaluating the relative merits of the different ideas and approaches (usually described as prioritization), and not enough time actually trying out the ideas and approaches.

Partly this gets to the core product principle of knowing what you can’t know.  I tell people they are wasting their time pretending they can predict how effective an idea or approach might be without actually fleshing that idea out.  The real learning happens when we collaborate with our designer to create a prototype and get it in front of a) ourselves; b) users; c) engineers; and d) stakeholders.

Product Manager Competence

I’ve written many times before that cross-functional product teams are only as strong as their product manager, and as an industry we have a real problem with product managers that are not yet competent.

I summarize competence as: deep knowledge of your users and customers; deep knowledge of the data that’s generated about your product; deep knowledge of your industry; and deep knowledge of how your business works.

It’s this last one that I see product managers having the most trouble.  They have not done the homework necessary to learn the various aspects of their business – marketing, sales, service, finance (revenue and costs), business development (especially partnerships), privacy, security, and legal are the most common dimensions.  So the result is that they’re not able to provide their team – especially their designers and engineers – with the context and constraints necessary for them to come up with the best solutions to the problems they’re tackling.

Ethics and the Product Manager

There is little debate today that our industry has not done nearly enough to prevent bad actors from causing damage to our business and our society.  The good news is that now, at least at most companies I meet, this is a much more prominent topic than it was.  More generally, the role of ethics is now becoming an explicit topic at more companies, and while this falls primarily on the company’s senior leadership, the product managers are often the first to see the brewing issues in the products being created.

Dealing with ethical issues is never simple, and it takes some real skills for a product manager to have constructive discussions with senior leadership about potential problems and solutions.  If the product manager does not have a strong understanding of how the business works – especially in terms of monetization – then they simply don’t have the necessary credibility with senior leadership.  This gets back to the PM competence topic.

Product Manager as CEO of the Product

Many of you know that I’ve been advocating this metaphor especially to emphasize the importance of the product manager understanding the different dimensions of the business.  You probably also know that the main objection to this metaphor is the product manager that decides to act like the boss of the team.

Recently I’ve been writing and speaking more about team dynamics and the need to ensure that every member of the team is both competent and not an asshole.  What I’ve come to realize is that what I think people react negatively to is when the PM is an asshole.

Some have argued that the PM role attracts more than its fair share of assholes (and the same has been argued about the CEO), but I’ve come to believe that’s the real issue, and not so much the PM role.

Coaching Product Managers

All of the above is really an argument that the directors of product management need to significantly step up their game in terms of coaching the product managers that report to them.  This has for too long been viewed as a secondary responsibility, and for many, not even that.

By my reasoning, this is the absolute top responsibility for every people manager of product managers, product designers, and engineers.  And when product teams don’t have competent members, it is their managers that we need to hold accountable.

I have long advocated a tool for the purpose of coaching and developing product managers. But I think there is much more that I can and should write about this all-important topic of coaching, and I plan to do so in the coming months.