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 optimizers. 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 Valley, 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 goes, 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, or Interaction Designer) is a specialist, focusing on designing both interaction and UI. The designer is much deeper in the details of the design (as it should be) but 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 or visual 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 market space than a 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 are 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. Like a CEO. Your bonus goes away when Google launches a competitor, your job disappears if you read the market wrong or your engineers estimated poorly. No matter who makes the mistake, it’s your responsibility to fix it.
Unlike the CEO, the PM don’t have firing power. So while they’ll have responsibility for making sure the product is successful, they are working with engineers and designers who report to someone else. They have to use persuasion and influence to shape the direction of the work. Those are good skills to learn if you want to grow into CEO one day and not be a micromanager. Sadly, some PMs use the only power they do have, over final product decisions, to try to get some control over their future.
Good PM’s lead teams, bad PM’s dictate product choices.
However, since the PM does not design nor code the product, the bad ones often find themselves made mostly irrelevant by the team they so desperately need. And since that team is likely missing critical data and market understanding (different than user understanding), the product fails.
Good ones set vision and goals, inspire, support and coordinate, and measure metrics to learn and refine the product. Sometimes it still fails. It’s still your fault.
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.