Product Manager Behaviours That Get in the Way of Great Products
Being a product manager is tough.
The quest to find product-market fit and create products that are valuable, usable and feasible is not an easy one.
All product managers have their own individual style and approach when it comes to navigating the unruly, unpredictable world of product and that variety is something that should be celebrated — variety is good. No-one wants a world of carbon-copies who all think and act the same.
There is however something that all product managers share — we all operate within the intersection of ‘technology’, ‘business’ and ‘UX’.
Yet, the relationship we have with each of these three worlds can have a profound effect on our ability to create great products.
Over the years, I’ve noticed some common behavioural traps that product managers can fall into, where the relationship we have between the worlds of technology, business and UX is not functioning as well as it could.
And why should I know about any of this? Because at one point or another, I’ve fallen into these behavioural traps myself (and lived to tell the story).
I’m hoping these experiences can help other product managers to identify if they ever spot these characteristics in themselves (or even others) and do a little course correction.
So here it goes…
Traffic Controller
This first scenario may sound familiar — business stakeholders approach the product manager with a pre-defined list of ideas / solutions to be implemented, often with some kind of supporting value statement to back up why x or y is important.
The product manager here simply acts as a traffic controller, reviewing incoming idea requests, checking in with the developers to see how much work it would be to deliver and feeding back when it can be worked on.
The dialogue between product manager and stakeholder might go something like this… ‘Ok, that sounds really important. We’re busy working on feature x right now, but we think we could pick up your request and fit this into the next sprint’
Things can get particularly chaotic when there are multiple stakeholders all providing their own requirements and the traffic controller is working double-time to try and satisfy everyone, effectively keeping multiple planes circling in the air whilst deciding which one can come in to land.
The killer issue here is that the product manager is effectively being fed solutions from the business and is not actually connecting with the needs of the actual end users to uncover what would actually work best — i.e. rather than user-centred design, they are following a stakeholder-centric approach.
Dictator
Rather than connecting with users, the business and technology teams to discover the most valuable, usable & feasible product opportunities, the product manager assumes a role of authority in these areas themselves and then effectively dictates their own position on a given subject.
For example, you may hear any of the following types of statements…
‘Our customers would love this feature’ — yet the product manager has not engaged with user research to actually find out.
‘This feature wouldn’t be complicated to implement, maybe one sprint to complete’ — without actually talking to the technical team.
‘Feature x would drive more valuable business leads than y’ — when there is no communication with the relevant business team.
The key issue here is that they are cutting out the essential dialogue with end-users, the business and technology teams and instead are simply using their own intuition to make key product decisions — effectively going it alone.
A common reason for this behaviour is actually not down to the rise of power-hungry megalomaniac product managers looking for world domination — but more often down to the pressure placed on product teams to deliver impact quickly, where substituting the role of user/business/tech short-cuts the process, making it quicker and easier to build and ship products.
But at the end of the day, that should not be an excuse, as the product, and ultimately the end-user, is likely to suffer as a result.
Magpie
Here the product manager has one key issue — they are attracted by shiny new things, and these things end up getting built by the product team.
They may be talking to users, the business and technology teams (so far so good), yet they are easily lured towards ideas presented to them from any of these camps (e.g. directly from a user interview, a stakeholder or a discussion with the technology team) and gravitate towards it because it is in some way new or interesting.
The one statement to really watch out for here is… ‘Wouldn’t it be cool if we could build [insert idea here]’
E.g. when talking with the technology team, a suggestion may be to build an image recognition feature using machine learning as it would be really interesting for the devs to get involved in that field.
That may be true, and there is certainly some merit in that statement, yet once again, starting with the solution is not the right approach — it is only a good solution if it is going to actually create value for the end user.
Wrapping Up
So there you have it — the Traffic Controller, Dictator & Magpie.
I’ve certainly adopted some of these characteristics at one time or another in the past (and hopefully much less now).
The key is to be able to recognise these behaviours — if you are able to identify when you are slipping into them, that is when you can take a step back and make a conscious change.
To discover products that are valuable, usable and feasible it is essential to connect with all three worlds of technology, business and UX and to use each of these as inputs to make informed, balanced decisions.
Oh, and keep focused on outcomes, not solutions. That is when the magic really happens.
No-one said it would be easy though :)
