Photo by Jean-Philippe Delberghe on Unsplash

So, You Want to be a Product Manager?

Eric S Perkins
Agile Insider
Published in
5 min readAug 3, 2022

--

Let’s keep it real in this post.

You want to be a product manager — you’ve seen the salary on Glassdoor, it’s appealing. You have former colleagues who got into Product Management at the fancy new startup and are changing the world one day at a time.

OR

Maybe you fell into it… Maybe a company took a chance on you because you have industry experience and you have no idea what Product Management is — terms like Agile, Sprints, Daily Standup, and Scrum remind you of something a Rugby team participates in. If that was you, we have a lot in common.

I interviewed at a company many moons ago for a role deemed “Product Manager” — and based on the description I thought “this is my wheelhouse,” Api’s, Real Estate, Multifamily, Property Management SAAS, B2B2C, Delinquency, PMS, you name it. It had everything that I was exposed to and can speak into the minutia of what it meant to be successful in the space.

Only one small problem — I had no idea what a product manager was — and it got exposed in the interview process in a big way with questions like “Have you ever worked in sprints, do you work with Engineers, or design. etc.”

NOPE.

But. I researched the company and understood what problems they were trying to solve and thought I had some cool insight that I could bring to solve the same problems — and I was right. The company took a chance on me and allowed me to grow as a PM. The CTO even said during my interview “It’s much harder to teach industry experience than it is to teach Product Management, so let’s go.”

Fast forward to present day, where I am now a Director of Product Management and here’s what I learned:

1. The Three Legged Stool

Product, Engineering, Design. Also known as your new best friends.

A customer or a stakeholder expresses a problem either in your weekly meetings or in an ad-hoc customer call — be it a customer complaint, business problem, growth problem, data problem, etc. You must, by any means necessary bring in your designer, and at minimum your tech lead to discover the problem.

Notice I didn’t say to solve the problem. Just to discover and understand the problem. Why? There is a good chance they have a different perspective. There is a good chance they may even know more than you about a concern from prior experience — and even if they don’t, fresh eyes have fresh perspectives.

Designers don’t want to just be thrown a solution, asked for a prototype, apply a company style guide, and move on. I promise you a designer didn’t go to design school to move pixels.

Nor do Engineers want to be brought in after a solution has been identified, only to have the solution thrown over the proverbial fence to implement code. They want to invent, not implement.

In short, bring your designers and engineers along for the problem discovery so that everyone understands the WHO, WHAT, and WHY.

Then you can worry about if it makes sense to prioritize.

2. “If Mama ain’t happy, nobody’s happy”

Mama is your customer — and you are the voice of the customer.

Have you ever gone an extended period of time without calling your mother, or forget to call your mother on her birthday? Don’t.

Well, similarly, keep your customer happy. They express concerns to you through various channels like your sales team, your customer success team, your stakeholders, or directly to you, and if they aren’t happy — rest assured, you and your company will not be happy either. Why? Last I checked they keep your lights on. Keep you fed. Keep you protected ~Mama~.

Example — If your customer expresses a concern in the data that they are seeing in their environment isn’t tying to what they expect to see, document it. Offer to provide the data to them directly within X timeframe. Don’t let them press you for it. Do the homework with your data team, dive into the SQL on your own. Learn (and also, bring your engineer and designer with you, see number 1).

Audits on data integrity suck. Especially coming from a customer. You know what’s worse? No customers. Hear them. Take notes and follow up with Mama. Make sure she is feeling the love, even if it has to go through the conduit of a customer success team member, make sure mama is heard.

3. The Spider-Man Meme

In other words, don’t point fingers when something goes wrong.

Or bluntly, own your mistakes and fix them.

I have fell on my face more times than I would like to count as PM.

I didn’t lead with data, I solved what I thought was the problem only to be wrong because I didn’t ask a customer, I didn’t follow rule 1 above, I didn’t keep stakeholders involved, I didn’t let sales know a new feature was live, I didn’t communicate with partners in a timely manner, and the list goes on.

Each time I fell I tried to figure out what went wrong, rather it was some piece of code that was wrong, something in the design was wrong, stakeholder/customer expectations were off…it couldn’t possibly be me who dropped the ball.

Let me give you a secret that will either scare the daylights out of you or it will encourage you to be better today. Ready?

If a product fails for any reason, look in the mirror. If the product succeeds, look at those around you. Give credit to the team.

If it’s ugly and the customer isn’t happy, how did the design and engineering team get the requirements? You. If it’s fantastic and the customer loved it, how did it go so smooth? Everyone. The team. Not you.

So, as I said at the top — don’t point fingers when something goes wrong.

Point them when something goes right.

Remember the three legged stool, keep mama happy, and wholly-own the mistakes but not the triumphs.

Good luck out there!

— Eric.

--

--

Eric S Perkins
Agile Insider

Trying to be a better Husband, Father, and Product Thinker