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 of the engineers. 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.