More PM Problem Areas
Last month I published an article describing common areas of confusion I see product managers struggling with. That article generated considerable discussion, and lead to some very good conversations. It also made visible several other common problems, which I decided to focus on here.
Playing Defense vs. Offense
There are a whole series of problems I see out there that I loosely characterize as playing defense rather than playing offense.
Playing defense is characterized by a team that is very risk averse, to the point of actually acting scared. Scared they’ll break something. Scared they’ll get in trouble for advocating their own ideas. Scared they’ll fail. It becomes more about not losing ground, rather than moving the ball forward.
If all the teams are acting this way it’s very likely a serious cultural and leadership issue. But more often it’s specific teams, and it’s a common consequence of a team where the members, especially the product manager, is not yet competent.
This is a pretty serious issue, but let’s discuss several ways this problem manifests itself in teams.
Teams Confusing Optimization with Discovery
I can’t tell you how many teams I meet that think product is all about making minor, low-risk tweaks to the work-flows they are responsible for, and A/B testing to see if their tweak helps or not. Now don’t get me wrong – this is called product optimization work and it’s typically a good thing to do. There are lots of good tools out there to help you with this as well. But this is value capture work and not value creation.
I have met teams that have literally been doing exclusively optimization work for multiple years, and everyone is frustrated with the miniscule progress the team has made. The team is confused because they thought this was what they were supposed to be doing.
Removing friction that gets in the way of our customers trying to do what they need to is a good thing to do, and it’s work that’s never really done (although you can reach the point of diminishing returns).
But this optimization work is very unlikely to identify the opportunities to create significant new value for our users and customers.
Qualitative Learning
A decade ago my big emphasis with teams was to encourage them to get serious about leveraging data and doing more quantitative learning. Now I find more teams that have moved so hard to quantitative that they have been neglecting the qualitative.
As all good teams know, it is not one or the other, we need both.
I’m suggesting here that the team get out of the office and talk directly to users and customers.
I try to explain this to teams this way: the quantitative data will tell us what’s happening or not happening; but it can’t tell us why something’s happening or not happening.
If users and customers are not buying your merchandise, or not signing up for your services, or not reading your content, your job is to go figure out why. You can of course continue to come up with product ideas and try them out, but you can easily see months and years go by without a real breakthrough.
Instead, get out there and talk to people about why they aren’t feeling it. You won’t get “the answer” from any one person, but everyone you talk to will provide another piece of the puzzle.
Eventually you’ll have some new theories about what might turn things around, and that’s what you’ll want to focus your product work on.
Exploring Alternative Solutions or Approaches
I’ve written countless times about the dangers of typical roadmaps full of features. But even in the case where the team is instead given a business problem to solve, like an objective around improving customer retention, the teams too often zero in on a particular solution they believe will solve the underlying problem.
The team gets all excited about the feature, and jumps right into designing and delivering that feature, and when it doesn’t work, they iterate or they give up.
But they all too often ignore much more promising avenues of discovery. With a business objective like “improving customer retention” there will be many different avenues that could be pursued. Some of those possibilities we probably already know of (from analyzing the data), and others are waiting for us to discover (usually from talking to users). And then for each of these avenues, there can be any number of potential solutions.
The point is that there are many potential ways to solve a hard business problem. We don’t want to put blinders on and just chase the one in front of our nose. We want to make sure we’re focused on the areas that have the highest potential to make the biggest impact.
An opportunity assessment is intended to help teams quickly frame this product work so they don’t just jump right into a particular solution, but if you need more structure for thinking about this, check out Teresa Torres’ Opportunity Tree technique.
Thinking Broadly Enough About Risks
There are always four potential risks when it comes to tech product work: value, usability, feasibility and business viability. If this is news to you, please pause here and read The Four Big Risks.
I think it’s human nature to focus on what we’re most comfortable, and where we feel we have most control. For so many product people, that’s usability risks and feasibility risks.
While those are certainly important risks, they are usually the easier of the product risks. With strong product teams, we need to spend most of our time on value risk and viability risk.
Coaching Product Managers
At the end of my earlier article on common PM problem areas, I pointed out that the root cause of the five issues I discussed is an inadequate level of coaching by the directors of the product management. The same is true with this new list of five more problem areas.
I promised I would focus more on the tools for those responsible for coaching product managers, and this is an example of that. But I have lots more in the works.
But if you’re a manager of product managers, I hope you’ll sit down with the product managers you are responsible for coaching, and discuss these ten common problem areas. See if these are problems or not, and if so, how you might be able to help to improve.