How to be a product manager when no one knows what that is

When I was job-hunting, I thought the problem was that I didn’t understand product management.

Every time I interviewed, I heard a different story. Is it SQL that you need to know as a product manager? Or iOS development? Is it Agile, or design thinking? Do you need to be an Excel jockey? Have gone to engineering school? Have an MBA? Do you need to wake up at 6am for yoga, coffee, and to-do list making?

I realized pretty quickly that it wasn’t just me. It’s common for people to not fundamentally agree on what a product manager is supposed to do. And companies don’t agree either. It’s a job that hard to define and evaluate, and that varies from team to team depending on the team’s present needs.

With little more to go on than the intersection of Design, Business, and Tech— how do we make it as product managers when our companies, adjacent peers, and disciplines don’t know what we do?

Here’s how I’ve reckoned with it.

Accept now that you won’t get a single definition of PM (and that’s OK).

You’re not likely to get a straight answer about the responsibilities of product managers (unless you’re in a larger company with a well-established community of practice), and you are even less likely to get the same answer from everyone you work with. Know that as long as product is getting shipped, it’s creating customer and business value, and you played a hand in making it happen — you must be doing something right. Focus more on delivering value to the team and to the product, and filling the gaps when a skillset is missing. Worry less about whether something specific falls within your job description. All of those articles that you’re reading about what PMs do and don’t do are based on a context in another time, place, and company that’s different from yours.
One caveat here — this approach can go wrong when you end up pushed into a more engineer-like role or a more designer-like role because of your background, and end up losing sight of the broader product responsibilities. If you think that’s a risk, raise it with your team and be intentional about how you split your time. Your job is to connect and work across disciplines to create a better outcome for all (that’s the part of product management that people do seem to agree on).

Develop your own point of view on product management.

Whether it’s based on the POV of a PM you admire, or grounded in what your team especially needs, form your own POV about what a product manager is and isn’t. You can’t please everyone with different definitions of PM, but you can set expectations and stick to them. If your POV is based on a certain set of processes or product influencers, you can point to those resources to help your team reach a common understanding. Over time, this POV can help shape the work that comes your way.

Communicate openly with your team.

There isn’t a perfect way to be a product manager… but talking and listening will always make you a better teammate. As you move into new project phases or new roles, there may be different gaps to fill or different areas where your team needs additional support. Stick to your product POV guns, but make room for changes and improvement. Team responsibilities are co-created.
A PM I admire likes to say that being a product manager is an earned job — we have to continuously prove our value, because it’s hard to pin down and it shifts over time. Working with your team to build an understanding of what’s needed is a big part of that earning process.

People talk about being comfortable with ambiguity — I’ve found that that’s as much about roles and responsibilities as it is about making product decisions. We as product managers have to prove that a macro view combining design, tech, and business is valuable. We have to write our own definitions and our own how-to guides — this is my first.