Doerr’s Law on Product Teams

We need teams of missionaries, not teams of mercenaries.

John Doerr

I first read this quote in an SVPG post from Marty Cagan several years ago, but nowadays, it gets quoted so often in product literature that we should make it official. I hereby name it Doerr’s Law.

I like the mental framing of Doerr’s Law, because it is simultaneously self-evident yet also nuanced enough to reward deeper reflection.

The surface interpretation is something like this: “Missionaries believe in what they’re doing, in their mission. Mercenaries are just here for the paycheck.”

That’s the answer you’ll get if you ask most product managers, and it’s certainly valid. It’s not too different from Cagan’s description from the post above:

Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.

Marty Cagan

Yet if we are paying attention to Cagan’s quote, we start to see hints of deeper nuance. It’s not merely differences in motivation or passion. It’s also about empathy and empowerment.

Who Cares

I’ve been an engineer my entire career, my entire life really. There’s a story in my family about an incident when I was 4 years old. My older brother walked into his room to find me sitting in the middle of the floor surrounded by his disassembled Atari 2600.

I’d found a screwdriver and taken the whole thing apart, somehow. I guess I wanted to see how it made the pretty pictures or maybe why my brother liked it so much? I can’t guess a 4-year-old’s motivation, but that drive to understand has always been part of me. I think it’s a part of all good engineers.

A good engineer must be curious about their tools and what specific solutions are better for certain contexts. What is the best way to solve this problem given our constraints? Who needs to be involved to solve this?

A great engineer must be curious about the problem itself and the people affected by it. Why does this problem need to be solved? Who cares about this problem? Why is a technical solution the right answer?

Simple Thread has a very unique skill that sets them apart from other custom software developers. They have the ability to immerse themselves in the company’s culture, learn the product that company sells and then use that knowledge to guide the development process. This is an invaluable skill that was hard for my company to find before we had the pleasure of meeting Justin and Al.

Simple Thread’s First Major Client

That drive to understand has always been in the DNA of Simple Thread, and for a long time, I thought that’s what mattered most. I want a team who gets it. I want a team who cares.

That’s still true. I still want that, but increasingly, I think that’s just the baseline. A great product team needs more than understanding, more than caring. A great product team needs empowerment.

Missionaries Say No

As my career progresses, I find myself gravitating towards product design and product management more than engineering. My drive to understand remains the same, but I continually find myself wanting to be in the meetings that happened before engineering got pulled in, before it was even decided that this was necessarily an engineering problem.

The earlier I can be involved, the more mistakes I can help the team avoid. The more I can be involved in defining the problem, the easier the solution becomes.

The framing of a problem is often far more essential than its solution.

Albert Einstein

Framing a problem is largely about choosing what to focus on. Narrowing the scope of the problem ultimately means saying no. Saying no to features. Saying no to complexity. Saying no to legitimately great ideas if they are distractions.

I was recently reviewing my notes on Cagan’s formative product management book, Inspired. Being in this power of no mindset, I was struck when I re-read the discussion of missionaries vs. mercenaries.

Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that’s very much the intention.

Marty Cagan

Yes, yes, missionaries are true believers who care and all that, but what got my attention is that first line: Mercenaries build whatever they’re told to build.

But missionaries feel empowered to say no. They understand the customers and problems deeply enough and are so engaged with the vision of the product that they will fight against changes that could harm the product or harm the user.

That is more subtle than merely dividing on lines of compassion versus compensation.

Voice of Authority

This nuance around empowerment also helps me reconcile a personal dissonance I’ve always felt in Cagan’s advice. He has traditionally advised against using consultants on a product team.

“It’s nearly impossible to have a team of missionaries when your engineers work for another company and are under contract to build what you tell them to.”

There is some truth in that statement, sadly. I’ve seen many messes created by contractors who clearly had no long-term stake in a system.

But I have also seen our team at Simple Thread help clients build fantastic products based on deep understanding of the business context and empathy for the customer.

We indeed hire for empathy and communication skills, and I’d love to write about that in another post. But I think a large part of what makes us distinct comes back to empowerment.

It is a core value of our culture, and we tell our engineers and designers this all the time:

• We are not order-takers.
• We are not robots where requirements go in one side and deliverables come out the other.
• If we are not pushing back and saying no, we are doing a disservice to our clients.

And this brings us to a truism of modern workplaces: Consultants are often more empowered than internal employees.

While this isn’t inherently good or bad, the reality is that internal employees will propose ideas and ask for resources but get continually ignored by management. Then a consultant comes in, recommends nearly the same thing, and they get immediate buy-in.

That’s why I think, for many companies, the best product team is often a blend of internal and external contributors. Employees bring the subject matter expertise and deep institutional knowledge. Consultants bring the execution expertise and deep technical knowledge – and yes, that outside voice of authority.

Of course, just like hiring internally, finding the right consultants is critically important and too big to cover here. I’m happy to answer any questions about it though.

Creating Missionaries

The last point I want to make is that this mercenary versus missionary split is not really about the people on the team. It’s about the mindset of the team. You can often change that mindset without replacing any of the people.

• Involve delivery leads as early as possible – As I mentioned above, the earlier you can involve design and engineering, the more they will understand the problems, in context, and the better that can help shape the solution. Like everything, this is a balancing act. Too many meetings can distract and frustrate, but in general, early involvement is key for creating legitimate, organic engagement and empowerment.

• Ask for feedback & alternatives – This one is obvious, but often overlooked. Just ask. We’re so busy being leaders and product managers that it’s easy to default to one-way communication. “I have to run to a meeting in 10 minutes. Here’s an info-dump of everything you need to know. Go!” If you merely ask your team to poke holes in your idea and suggest better alternatives, you may be surprised by what they come back with.

  NOTE: A lot of people don’t need to be asked; they’ll provide feedback regardless. But many of the most empathetic, thoughtful people will feel reluctant. They’ll correctly understand how busy you are and not want to bother you, unless it’s a serious problem. But you’ll miss some amazing ideas that way. The simple act of asking lets them know you truly want to hear their ideas.

• Explain intent – Always try to explain the why behind the what. Thankfully, this doesn’t necessarily require more time; it’s more a matter of how requirements are captured. Understanding what needs to be built is a fine first step, but it’s equally important to understand why, what value it provides to the users, and in what contexts they’ll be using it. This helps the team not just be order-takers. This lets them apply their expertise, which will always, always result in a better solution.

• Minimize hops between user feedback and execution team – This is another balancing act. You can’t have delivery leads sitting in constant user research meetings and reading every support ticket that gets opened. That would eat up too much of their time. However, you want to prevent your product team from living in a bubble where they never see direct feedback. That will quickly erode empathy and understanding of the problem space. Instead, I like to think of the ideal scenario as curation, not translation.

  For example, don’t have the support manager merely summarize and paraphrase feedback; instead have them choose novel or important ones and provide them in raw format to the product team – while still summarizing the feedback that represents known ideas. I think there is something magical about reading the actual words of the user, rather than a summary.

These aren’t always easy to do and certainly don’t guarantee success, but they will help you foster a culture of empathy and empowerment on the product team, and help them be a team of missionaries.

And that’s ultimately the deep truth of Doerr’s Law: Your product is a reflection of your team.

If you can shift your team to the missionary mindset, your team will feel understood and empowered. And that’s a team who will create a product that users love, because the product makes them feel understood and empowered.