The Myths of Product Management

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 multidisciplanary 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.

People, 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 the 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 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.


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 one on one, 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.

I have a new book out on goal setting and execution:

Marty Cagen has a old book out on Prouct Management that is my favorite:


Add Yours
  1. 1

    I have worked in Web Design since 1999 and I do not agree with the idea that the UX Designer and the Project Manager, specially the business oriented one, are very different. I believe that to be a good designer you should take a holistic view of the problem to solve and understand the market you are designing for. Design should be intrinsically involved in business strategy and business development.

  2. 2

    You make some good points here so I’ll leave a couple of comments.

    Is the UX misunderstanding of PMs similar to the misunderstandings between other roles? For example, in the debate about “unicorn” UX designers. The same logic seems to apply to “full stack” developers. “What’s so great about [discipline you don’t know enough about]? I can do what they do too!”

    As an aside, I’d love to know whether this happens in other industries. Do surgeons say the role of anaesthetist is too similar to theirs? Do accountants resent quantity surveyors for similar reasons, or do technical draughtsman say architects are over-rated?

    On a separate point, your illustration of “UX Flavored PMs” arguing about a submit button with the designers because they’re worried about click-through is interesting. If skills and interests *have* to overlap (and it’s not entirely clear from your post why they need to really), then if you’re a PM and you disagree with what a designer has done because it will be erode conversion, then the designer needs to recognise that. But not if it’s on a point of branding. That’s what teamwork is, isn’t it? People need to be responsible for their “home turf”, regardless of how t-shaped they may be, no?

    Which leads to your point 5 about the “CEO of the product”. What would happen if the organisation knew the difference between a product failing due to PM decisions vs failing due to UX (or indeed development) decisions? Why can’t the PM, UX and Dev actors share responsibility for their actions equally to the business? That would seem to help the situations you complain about, that is if the business is interested in knowing why a product succeeded or failed, of course.

Comments are closed.