close
Post Image

The Myths of Product Management

Christina Wodtke
By Christina Wodtke on 25th February, 2016 Updated on 21st September, 2021

There have been a bunch of articles lately from designers on product management in the Silicon Valley.

It’s making me slightly crazy, so I’m going to write a short and sloppy essay from my perspective. I’ve been a designer, a design manager, a startup CEO, a product manager and a GM who managed multidisciplinary teams. I’ve got some insights.

Caveats! I have lived in Palo Alto/San Francisco for over 20 years, and worked at good companies (Yahoo back in the day, Linkedin, Zynga, and more) with really good PMs. So my view is skewed by both place and luck.

1. Product Management is a New Thing in Tech.

I got into the interwebs in 1995, and software already had PMs. Web design was all shiny and new and half the companies had PMs, half had producers, and many had Project Managers. But by the time we were partying like 1999, everyone around here had product managers.

2. Product Managers Don’t Know What They Do.

No, YOU don’t know what they do. They know what they do, they do everything.

I used to be a restaurant manager. I hired, I fired, I greeted customers, and made sure they were happy, I did the books, and worked with the chef to pick the special, wrote it up on the board outside, and bought ads in the local paper. And when the prep cook didn’t come in, I chopped vegetables and frequently my fingers. Oh, and the when the dishwasher didn’t come in… you get the picture. That is what a product manager does.

They have their core job: keeping product/market fit, minding and growing metrics, and coordinating teams to that end. But the good ones, the ones I got to work shoulder to shoulder with, do whatever it takes to keep the product healthy and strong.

If that means designing an interface change in PPT because the designer left at 5pm and the engineer needs something to work with, he will. If that means running to Costco for beer for launch night, she does it. If that means setting up Google ads because marketing doesn’t have time for his product, he will. If it means learning SQL… well, you get the picture.

3. Product Management is Pretty Much Like UX Design. 

If only! Wow, the job would be so much easier if that was all there was.

Designers get all snotty when no one knows the difference between interaction design and information architecture. But what do you know about PMs?

People talk about product managers like they are monolithic, but there are three flavors: engineering, business analyst and UX.

Engineering flavored PMs are often ex-engineers, are great for working with engineers in hard problems like search & recommendations systems.

Business analyst flavored PMs are the optimizes. They are masters of AB testing, SEO and growth hacking.

UX-flavored PMs are great at product/market fit. They focus on user functionality & experience, and are good at onboarding, help & error msgs. In Silicon Valey, you’ll often hear them referred to as“Product People.” It’s frequently said in a tone of admiration. Product People really get their market and the humans in it, and care about making the right product for them that thrives and survives.They are the unique folks who can combine business and user needs into successful products.

Product People fight with design the most often because they are siblings. They care about the same things. They’ll get into a huge argument about where navigation does, or the shape of a submit button.

But they have different jobs with overlapping, not identical interests. The Product Person is T-shaped, caring both about the user and the business, and often fights about that submit button because she worries about click-through. This is part of a host of responsibilities she juggles, along with acquisition, retention, that upcoming software rearchitecture and the metrics review.

The UX designer (sometimes called a product designer) is a specialist. The designer is much deeper in the details of the design (as it should be) and can lose sight of the role the design plays in context of the larger business. He sometimes fights for the user to the detriment of the business’s health (as it never should be.) Companies that can’t stay in business don’t provide anyone any value. If you’ve ever had to tell a customer you are shutting down their favorite product, you’d feel how hard that is.

Business analyst PMs are often considered loathsome or tedious by designers, and engineering ones incomprehensible. Which is a tragedy, because algorithms could use some more user-centeredness, and qual and quant are like peanut butter and jelly.

Even though PMs have different skills and specialties, they rarely take on specialty titles. Unlike interaction designers and UI designers, a PM doesn’t have the luxury of not doing the part of the job they don’t understand. If you are a Product Person and the time comes to do your KPIs, you suck it up.

4. Product Managers Don’t Care About Process (or Love Agile/Lean/Waterfall).

I’ve heard a lot of folks ask where product management conferences are. There are a couple recent ones, but historically product managers are much more interested in their space than process. This means they attend conferences on search or local or wearables. Most get their process from their engineers and their designers, and are willing to adapt to what keeps their team happy and working.

Lean is changing that to a degree, but in my experience it’s the service disciplines obsessed with process, and the PMs willing to do whatever works.

5. The Product Manager is CEO of the Product.

I’m actually OK with this one. Not because the job of CEO and PM is the same, but because no matter what it is or who made a mistake, you, the PM, are responsible. Your bonus goes away when Google launches a competitor, you job disappears if you read the market wrong or your engineers estimated poorly.

Anyhow…

I recall back in 2002 when I worked at Yahoo managing a big team of designers, and one interaction designer just hated the PM she worked with. She didn’t get why this PM was always coming over, asking her to make changes, wondering why things were late (and they were. late, that is.) She just wanted to be left alone to design.

Then we rearranged seats, and designers were embedded in their product teams. We had a 1:1, and she said, “God, I feel so sorry for that PM. Everything is her fault. People yell at her all day.” And she decided she’d try to make that PM’s life easier, really listen to the PM’s needs rather than tell her what she should do. Oh, and try to deliver on time.

I’ve never forgotten that, even when I was the one everyone was yelling at, held responsible for numbers I couldn’t always control because of market forces. I realized that whenever there was conflict, there was probably a lack of understanding. And understanding leads to empathy.

Designer, have some empathy. Do some user research. Take your PM to lunch. Ask them what his dreams are, ask how she is compensated. Ask what his biggest challenges are. Ask her what the best designer she ever worked with was like. Maybe you’ll find out she has a hard job, and you are part of the reason why. Maybe you’ll find a way to be successful together.

Go give your PM a hug.

On a related note, I have a new book out on goal setting and execution for product teams.

Marty Cagan has an old book out on product management that is my favorite.

Originally posted on Elegant Hack

UXPin Editor’s note: If you found this post useful, check out the free Definitive 2016 UX Design Trends e-book bundle below. The bundle includes 350+ pages of advice and 300+ examples of mobile, web, and UX tactics.

Still hungry for the design?

UXPin is a product design platform used by the best designers on the planet. Let your team easily design, collaborate, and present from low-fidelity wireframes to fully-interactive prototypes.

Start your free trial

These e-Books might interest you

Follow Us

We use cookies to improve performance and enhance your experience. By using our website you agree to our use of cookies in accordance with our cookie policy.