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.


Hungry Artist Paints Way Better

When you are running a startup, it’s easy to imagine how great life is for the head honcho of the Microsoft Bing group. They have all the resources in the world available to them. The company is pouring money at them – BILLIONS every year! There are thousands of people working on the product! With that might, anything should be possible, right?..

You compare your tiny 20-person startup to Bing, and you feel inadequate. You’re worried about making payroll. Investors are holding you by the balls. You sort-of have market traction, and there are a lot of ideas, but you don’t have the resources to try most of them. Any mistake can be your last. You compare yourself to the giant Bing, that keeps pouring HUGE sums of money into every imaginable experiment, and are feeling like your constraints make you ineffective.

And here’s where I’ll jump in: Au Contraire. The constraints are making you MORE effective.

YOU are in a much better position. You’re a hungry artist, and you know that you have your butt on the line. Calculate your financial projections wrong, and you’ll run out of cash and won’t make payroll. The friends that you brought into your business – your *personal* friends – will not be able to pay their mortgage. Your *personal* reputation is on the line.

Since you’re desperate – hungry, constrained, call it whatever you want – you’ll become a maniac of perfectionism. You’ll POUR YOUR SOUL into every decision you make. The people on your team will do the same – if this company succeeds, each of you will be rich. If it doesn’t – and you’re on the clock here, seed money is running out – you all won’t be able to provide for your families. And will have a sad story to tell when interviewing for your next gig.

Let’s look at an example of what the lack of hunger can lead to.

First, it’s lack of commitment – when less is on the line, people tend to be less committed. Passionate people tend to do well and get better at their craft – and the lack of the passion often zeroes out all the other great qualities.

Second, it’s randomization. I’ll give you an example of what over-investing in product management will do. The core value of PM is to be the advocate for the user; they are the gatekeepers of end-to-end experiences. If you have too many PM’s for a product, then instead of owning large chunks and scenarios, you have each junior PM own a couple checkboxes. With this level of ownership, you get (a) zero motivation and (b) people start inventing work for themselves. And PM’s inventing work often leads to “running around with your heads cut off” for the entire organization – highly tactical efforts that don’t add up to a significant improvement in the end.

Third, it’s the famous Mythical Man Month effect. The larger an organization gets, the higher the communication costs. At some point, adding resources to a project makes it go SLOWER, not faster.

So the key phrase for me is “Strategic Under-Investment.” If you’re in a large organization with lots of resources, give people a little less resources than what they need. Force them to make tough choices.

So, rejoice and embrace your constraints. They are making you work harder, thus increasing the chance of your success. They are forcing you to make careful choices, all while facing accountability in the face of your personal friends. Just like with a hungry artist, your painting will be better.

Startup Factory

What do you do if your business succeeds? If you make up a startup, struggle for 7 years, and become the overnight success – suddenly exploding to a hundred people – what do you do?

You’re by no means Microsoft, and you’re most likely not Mint.com either. You’re probably in some niche business, and your customers love you – but you aren’t about to go public or be acquired by Google for $6B. You are, however, in a pretty good place – you’re no longer worried about making payroll or paying rent.

A new worry then enters your mind – I already have a golden egg; how do I make another golden egg and grow my business?

Or, look at another situation: imagine that you’re a successful company like Oracle. You have an entrenched position in a couple markets; you have established businesses that are bringing in over a billion dollars. Those are your “golden eggs.” The question again is, how do I make more of those golden eggs? How do I grow my business?

I’ll argue that by searching for golden eggs, you’re making a mistake already. You need to be looking for a goose that will lay those golden eggs. That goose is a framework for generating, vetting, and incubating ideas. That goose is an internal “startup factory.”

Let’s look at a standard way of going into new businesses.  You get together with your executives, brainstorm, and based on your gut – and, hopefully, a little bit of solid data – make a call on where you’ll go next. You then bet your farm on that idea – investing half of your company’s resources over the next product cycle into that idea.

But what if the idea was, ahem, dumb?.. What if you were wrong? Do you have a plan B?

Allow me to offer you an alternative – a framework of innovation I’ll call the “startup factory.” Here’s how it works:

1. Start with idea generation.

Once a quarter, have your engineers, product managers, and marketers drop whatever they are doing for ONE day. Obviously, don’t drop the ball on the urgent customer matters. Instead, plan for this “hack day” in advance and include it into your schedules. During the hack day, everyone is free to work on whatever they want. There are no management chains there; people are encouraged to self-organize by interest. The only requirement is that at the end of the day, they get to present their work at an informal all-hands – ideally, over beer.

You will be SHOCKED to see the kind of ideas that get presented. Your people WANT to innovate; they HAVE ideas, you just need to get out of their way for a day. They are so booked up with fires that they have no time to try out some of the bold ideas they’ve brewing. Some of those ideas will be truly revolutionary – unlike the “faster horse” asks you get from your clients, some of the ideas from your staff will be in the “build a car” realm.

I’m by no means an inventor of the “hack day” concept. It’s been mentioned in my favorite Autonomy, Mastery, and Purpose TED talk. Microsoft Live Labs called this exact concept an “out of the box week” (it was actually a week-long engagement there). Google’s 20% time is essentially the same thing – except that its ongoing nature makes it a lower priority for participants, thus reducing its effectiveness.

2. Create a funnel for ideas.

At the end of your Hack Day, have a committee of senior folks select three projects that will get “funded” to be incubated. Let the person who presented the idea run the effort – they’re by definition most excited about it. Give them some extra resources – one other person to bounce ideas off of. Then, allow them to leave their current job responsibilities – completely – for three months, so that they can incubate the idea.


Yeah, that’s exactly what I said. If your organization has such a strong tactical dependencies on any individual contributor that you can’t have them work on a strategic incubation for three months, you’re in trouble and long-term success should be at the end of your list. You’re about to see short-term failure when that person leaves.

3. Create accountability and an evaluation framework.

Your 2-person, shielded incubations have been running for 3 months. They’ve built some prototypes and demos. They’ve done some market research. They might have talked to some customers. They’ve been RUNNING THEIR OWN STARTUP within your company – a startup that’s on a short leash, a startup made out of the people that know your marketplace and are working on ideas that YOU have hand-picked.

Now it’s time to decide whether it makes sense to continue investment in any of these incubations.

Create an evaluation framework for your decision making. Try to be as specific as possible: Are we convinced in the market value enough? Do we think the roadblocks that were obvious have been researched enough? Before any of the projects are funded for this 3-month stint, make sure to advertise your decision-making framework broadly.

4. Make decisions on what to do with your incubations next.

I bet you anything that most of your incubations are going to fail for one reason or another. Why? Because luck was a HUGE factor in the initial success of your enterprise. Because 99% of the startups fail. Because most ideas turn out to be crap for one reason or the other.

Here are the good news: if at the end of these 3 months, you decide to kill an idea, it’s a GREAT THING. This means that you were convinced that something will work, ready to put a ton of money behind it, but you didn’t bet the farm on it – instead, you put something like 2% of your company’s resources behind it for 3 months. So now that the idea failed, your company’s existence is not in danger in any way.

Moreover, now, you have a plan B. You have 2 other ideas that you were pursuing in parallel. One of them might be the next big thing – all pieces of the puzzle will add up, and you’ll be so excited to finally throw all your company’s might behind it. AWESOME.

Let me recap the key benefits of the Startup Factory approach:

  • Generate groundbreaking ideas.
  • Incubate the most promising ones – without risking your entire business – and evaluate these incubations.
  • Build up internal expertise before major resources get assigned to the new idea, so that roadblocks can be discovered early, and tackled by a surgical team – instead of blocking progress for a bigger group.
  • Amazing effect on the morale. I won’t get tired of preaching Autonomy, Mastery, and Purpose. This framework hits on all three.
  • Entrepreneurial growth of your employees. When running a 3-month incubation, your employees get to wear many hats – working as mini-CEO’s for that project. Don’t be surprised when an engineer starts understanding marketing much better after this 3-month stint.

A couple other intuitive ways to look at this framework:

  • Startup factory is really about diversification of seed investment – something that VC’s have been doing forever.
  • It’s an insurance policy that lowers your risk exposure by gradually increasing the investment over time – instead of the binary 0 to 1 change, you slowly move the dial from 0 to 0.1 to 0.5 to 1. Like any insurance policy, you pay a little upfront to get its benefits.

Go create a golden goose in your own organization and watch it lay golden eggs for you.