What are Product Managers for, anyway?

I’ve written about the core pillars that drive technologists. In this article, I’d like to drill in on the discipline that’s perhaps least understood – product managers, or PM’s.

Technologists have one fundamental weakness. Like all engineers, they like creating worlds from scratch. They liked disassembling toys when they were kids, and putting them back together slightly differently. They love the control, the thrill that comes from playing God in the virtual world where everything is possible. This causes a tendency to tinker – just because tinkering is fun. This is particularly true in well-funded startups and labs organizations in larger companies.

When your craft is fun, it’s great. You enjoy every moment of messing with the code, laying out those architecture diagrams on a whiteboard with your buddies… The rub, of course, is that at some point, you need to make a profit. You know – step 1: inspire everyone with an idea, step 2: execute on it, step 3: profit. If you keep tinkering forever, your VC will shoot you in the head, the department in your large company will get dismantled, and the bonanza will end.

Basically, you need adult supervision. You need someone who loves and understands technology, but doesn’t get the ultimate pleasure from creating the most robust and beautiful architecture in the world. You need someone who’ll kick you in the butt because your customers have a REAL PROBLEM and the elegant technical solution you’ve been pondering for a few days doesn’t really matter for the client. The client wouldn’t care less if you shipped a SPAGHETTI CODE UNMAINTAINABLE PIECE OF CRAP if it solved their problem.

You need a customer advocate. Someone who has EMPATHY as the core pillar that drives them. Someone who feels the pain of the client and wants to do whatever it takes to have that pain go away. Yet, they are technically savvy to be able to maintain an intelligent conversation with an engineer – they’re not an MBA with zero technical background and Excel financial models in hand. Joel Adams – he was the first to fund Michael Dell of Dell Computers – once said, “When I’m valuing a company, I usually subtract $100,000 for every MBA on the team and add $100,000 for every engineer.”

That customer advocate is your product manager (PM). If you’re a startup, you need ONE product manager. They’re going to be the CEO of your product. Yes, you heard me right – if you’re a CEO of a technology company, you have much more to worry about than just your product. Hiring superstars is your #1 concern; #2 is being the Chief Earnings Officer. You need somebody in the weeds, somebody that’s not distracted by the fundraising and making payroll and getting Jenn the signing bonus despite the fact that the board is against it.

I like to think of a product development as a triangle with these vertices: test, dev, and PM. Here’s what happens if either of the vertices is weak:

  • Test: product is buggy as hell and clients see crashes and data loss.
  • Dev: product cannot be improved over time and an incremental v2 costs an order of magnitude more than it should.
  • PM: the product is technically robust and doesn’t fail, but nobody wants it. It solves no real-world problem.

The mission of the product manager is to instill the customer pain into every single engineer on the team. Let me give you a contrast:

  • Product 1: the PM understands the client well, and defines the product through technical specifications in EXCRUCIATING detail. Field names in the database tables, error messages to the comma.
  • Product 2: the PM understands the client well, but instead of going deep into the details, they explain the reasoning behind the product to everyone involved. They help engineers understand who the client is, what they do every day. How the product will help the customers. They drag the engineers to user research studies, forcing them to watch how customers struggle to find the damn OK button.

Beside sheer capacity issues, the PM on the product 2 will be more successful simply because it’s not humanly possible to oversee every decision. Engineers will be making calls all the time, and some of them will be wrong if they don’t understand the WHY. This is exactly the reason for getting them to feel the pain of the customer – instead of spoon-feeding them the details like they’re dumb.

A couple more notes on what PM’s mission is not –

  • The PM should not be a people manager. Google, Facebook, Redfin, Zillow, and many other companies subscribe to this vision that was initially created at Microsoft 20 years ago. An amazing book on PM called How would you move Mt Fuji describes the formation of this vision beautifully; the crux is that if the ideas about what the product should do come from my boss, I’m highly unlikely to say that they suck. If the PM is my peer, I’ll freely tell them what sucks and outright refuse to code up their dumb solution. The key to PM success is the ability to influence design decisions without authority to force them down the throats of the engineers.
  • The PM should not be a project manager. A project manager is someone who’s responsible for the SCHEDULE. Someone who’s responsible for the resourcing. PM’s have no managerial power over the engineers – so they can’t tell an engineer to hustle or really promise a delivery date. Those responsibilities should land on Dev Lead’s shoulders.

If I got you interested in the subject of the role of PM, you might want to check out this article from my brilliant friend Angela.

Advertisements

5 thoughts on “What are Product Managers for, anyway?

  1. “PM should not be a project manager” – why not? Schedule and budget are just as important to an overall success of a project as the right set of features, their quality and usefulness to the customers. Just like being advocates for the customers, PMs should be advocates for the timeline and for the resources. As you said, without a real managerial power they can’t MAKE Devs deliver a feature on time but they can surely PARTNER with the Dev Leads to make this happen. And actually, there is nothing wrong with PMs telling Devs that they are a bunch of lazies and that they should hurry up and finish 🙂 After all, you are dragging us to watch how customers struggle to find the damn OK button. We actually know how to get thing done on time (after all, WE provided the estimates I hope), but we do need somebody to SHAME us into doing it!

    • Two reasons why PM’s shouldn’t automatically be project managers.

      1. I’m a believer in owning your destiny – and giving people responsibility ONLY for things they can personally influence. I think engineers should not be “children that need shaming.” Personal accountability is at the core of this – if a developer isn’t keeping to his commitments, s/he should themselves feel bad. If they need shaming, the team is dysfunctional. Everyone on the project has to be treated like an adult – engineers don’t need their mommy to walk around them and ask whether they have put their coat on. Or to bring coffee. Or to remind them to fill out the Completed Hours worksheet. They’re adults and should be treated as such. If they’re consistently behaving as children that need babysitting, they don’t belong to your company and should be kicked the fuck out.

      Moreover, if you ask PM’s to shame them – it’s even worse, because PM’s have no people power – i.e. ability to fire – the engineers. The lazy Dev will just laugh off the nosy fly that’s distracting them. I have personally been in exactly these shoes. If the reprimand is coming from the engineering manager – it WILL be taken seriously. Hopefully, a single reprimand is enough.

      2. The skill set that’s necessary for project management and product management is distinctly different. You can have a FANTASTIC product manager – someone who can instill empathy into every single member of your team – who’s terrible at maintaining schedules. Who’s not into keeping meeting notes. Who’s not into interrogating devs about their project status.

      Conversely, you can have a project manager that has no product management skills – someone who’s at their core an anal-retentive bookkeeper. A project manager is a non-technical schedule and budget keeper; they can be useful in any project – be it a software product or building a bridge. No technology background is necessary to introduce some order.

      I’ll claim that these two skills and internal driving forces are so different that it’s very difficult to find a person that embodies both of them. I have only met ONE (literally one) person that was good at both.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s