Sometimes an idea just strikes me out of the blue and sounds interesting enough to sit down and write a little bit about. This is one of those posts, spurred on by a discussion I had today with a newly-hired Product Manager with almost as much experience as me. As we were talking about our past experiences, where the current company is at, and how we can work together to improve some of the practices and procedures throughout the organization, I started to think about all the different things it is that we actually do as Product Managers, and all of the hats that I’ve worn in the past. These are some thoughts on a few of these hats…
The Customer Advocate
I would hope that this hat is the one that people are most familiar with — it’s the one that is perhaps the most important that we wear, and the one that we (hopefully) wear most of the time in our daily jobs. This is the role that requires that we actively seek out information about our customers, our market, and our competitors. This is the role that requires a thoughtful balance of qualitative data, quantitative data, and often gut instinct. The Customer Advocate is the one with the unending desire to create the best product to solve latent customer issues that they don’t even know that they have…in a way that not only satisfies their needs, but that delights them in the user experience.
When we wear this hat, we take on all of the desires, needs, and wants of our customers, users, and market — and along with those come the burden of convincing others.
The Facilitator
Which segues quite nicely into the second hat that most great Product Managers wear, likely nearly as frequently as the Customer Advocate hat. It’s this role that establishes us as the hub around which the organization spins. It’s this role that allows us to build social capital across the organization. When we’re wearing our hat as the Facilitator, we’re leading people to a decision or an action, guiding them subtly toward determining next steps. Unlike the next role, the Facilitator is a background role — people won’t notice it if you’re doing it right, but they will start to see the pattern of what happens when you’re not there, or when others are doing it less effectively.
When we wear this hat, we assume a neutral position in the organization, focusing on helping to guide others to their desired outcomes — especially when those desired outcomes coincide with our own.
The Dealmaker
While the Facilitator is the passive maker of fortunes, the Dealmaker is the opposite — an active advocate for doing the right thing for the customer. In this role, we’re required to not only understand the motivations, needs, and desires of our customers but also those of our stakeholders. In this role, we force people to justify their requests, to back them up with data or with some commitment of their own. The Dealmaker is the one who can see all of the moving pieces on the chessboard, and predict three turns ahead where they will be — then works to influence the outcome directly to support their own customer-oriented goals.
When we wear this hat, we challenge those who have requests of us, we demand data and commitments to back up changes in priority, and we understand what it will take to influence the board so that the pieces align in the way we would prefer.
The Stand-In UX Expert
A much more specific and tactical hat that many PMs wind up playing, the Stand-In UX Expert is one that comes as a direct result of being a strong Customer Advocate — the more expertise, exposure, and data that you have about your customers, the more natural it is for people within the organization to come to you with help solving customer problems. And, since one of the most difficult problems that we often try to solve for customers involve optimizing their user experience, it’s an obvious hat to put on in the appropriate context and with the appropriate people. The risk with putting on this hat is that you forget that you’re just the “stand-in” expert — even if you have prior UX experience. This isn’t to say that you can’t have opinions and give input or answer questions in the absence of a strong UX team, but if you have a UX team it’s usually best to defer to them and work with them rather than past them.
When we wear this hat, we provide feedback to our development teams on how to best approach a solution from the user’s perspective, and how to make it as easy, frictionless, and delightful as we can within the time and resource constraints we have to work.
The Technical Skeptic
The last hat that I came up with for this post (and I’m sure there are more, feel free to add your own in the comments), is that of the Technical Skeptic. Any experienced Product Manager will tell you that there are times when your technical teams will want to do something primarily because it’s fun, it’s new, or it’s interesting — but not necessarily because it’s actually the best solution to the problem. And if we let them get away with this, we run the risk of putting other efforts on the backburner, of wasting development time on risky or unnecessary code, and generally of wasting the time and money of the organization that we work for — not to mention creating solutions that weren’t based on customer need! There are times when we need to stop the engineering teams before they get too deep into a project, and ensure that they really are doing the right work for the right reason.
When we wear this hat, we can challenge some of those technical choices that seem as though they might be driven by shiny-object syndrome — in a respectful way, one that perhaps requires humility more than authority.
