Missionaries in Product Management: Build Teams That Believe

In product management, missionaries are teams with a genuine belief in the product they are building and the problem they are solving. They are not simply executing a list of feature requests, they are guided by purpose, empowered to push back, and measured by customer impact rather than delivery velocity. The concept is credited to venture capitalist John Doerr, who argued that the best product organizations run on "teams of missionaries, not teams of mercenaries."

That distinction matters more today than when Doerr first articulated it. In a market where most product teams are technically capable, the differentiator is often not what a team can build — it is whether they care enough to build the right thing. Missionaries do. They ask harder questions, maintain closer contact with users, and understand the business context well enough to make genuinely autonomous decisions.

This article breaks down what the missionary mindset looks like in practice, why the divide between missionaries and mercenaries so often mirrors the divide between mission and vision, and what it takes to write an agile mission statement that gives a team the clarity to act like missionaries from day one.

‍

Missionaries vs Mercenaries: Why the Mindset Divide Matters

The missionaries vs mercenaries divide is about the origin of a team's motivation. Mercenaries execute what they are told. Missionaries own the problem.

Knowledge at Wharton's account of John Doerr's framework captures this well: mercenaries are driven by opportunism and short-term thinking, while missionaries are driven by passion and long-term strategic conviction. Missionaries think in years; mercenaries think in quarters. Mercenaries focus on financial metrics; missionaries focus on customer value.

In everyday product decisions, the difference looks like this:

• A mercenary team builds a feature because a stakeholder requested it. A missionary team questions whether the feature solves a real user problem.
• A mercenary team measures success by delivery velocity. A missionary team measures it by customer impact and business outcome.
• A mercenary team rarely speaks to users. A missionary team embeds user research into every sprint.

The consequences extend well beyond product quality. McKinsey's research on what makes product teams effective, based on data from more than 1,700 teams across 75 organizations, found that teams organized around a clear mission and held accountable for business outcomes consistently outperform those structured around input actions or functional capabilities. Teams working toward a collective goal also report significantly higher employee satisfaction, which connects directly to retention in a field where talent is competitive.

The uncomfortable reality is that many organizations hire capable people and then systematically create the conditions for mercenary behavior. When discovery is separated from delivery, engineers are kept away from customer conversations, and roadmaps are handed down as mandates rather than informed by team input, teams default to executing instructions regardless of how the culture is described internally.

This is why product leaders who have engaged with Marty Cagan's work on empowered product teams often recognize the missionary framework but struggle to implement it. The missionary mindset is not installed through a training session. It emerges when teams are given the context, access, and autonomy to genuinely own outcomes.

‍

Mission vs Vision: The Foundation for Missionary Teams

One of the most direct ways to inadvertently create mercenary behavior is to conflate mission and vision, or to have neither. The mission vision difference is frequently treated as a semantic exercise, but it has practical consequences for how a team makes decisions every day.

A vision describes a future state. It answers: what does the world look like if we succeed? It is aspirational, durable, and directional. A useful vision is specific enough to exclude options. If it applies equally to every company in your industry, it is not doing its job.

A mission describes what the team does today in pursuit of that vision. It answers: what problem are we solving, for whom, and how? A useful mission is narrow enough to act as a filter. If it could justify every feature request in the backlog, it is too broad.

The two failure modes that follow from getting this wrong are predictable. Teams with an inspiring vision but no actionable mission develop high-level conviction but no tactical alignment. Teams with a detailed mission but no larger vision produce activity without meaning. Both conditions suppress the missionary mindset in different ways.

Strong product teams operate with both. The vision creates the conviction that the work matters. The mission translates that conviction into daily trade-offs: which features to prioritize, which stakeholder requests to push back on, which user research questions to ask.

Product leaders who want to test whether their team has this alignment can try a simple exercise: ask each team member, independently, to describe the product's mission in one sentence. If the answers diverge significantly, that is not a communication failure. It is a signal that the mission has not been defined clearly enough to anchor decisions. This is a common finding when interim product managers step into organizations at a point of change. The capability is present; the shared direction is not.

‍

Writing an Agile Mission Statement Teams Will Rally Behind

An agile mission statement is short, outcome-focused, and genuinely used. It is not a tagline, a values declaration, or a paragraph written for the company handbook. It should answer three things in a single sentence: who the team serves, what problem they are solving, and what success looks like.

A common working format: "We help [customer segment] to [achieve outcome] by [key differentiator]."

The word "agile" matters here. In agile product development, the mission statement is not a fixed artifact. It is a living reference that should be pressure-tested at major planning moments and updated when the environment changes. McKinsey's research on value-driven agile organizations identifies this principle directly: missions in high-performing agile teams are "loosely coupled but tightly aligned" — specific enough to guide autonomous decisions, flexible enough to adapt as the market evolves.

Writing the mission statement should be a team exercise, not a leadership deliverable. When the team participates in drafting and pressure-testing it, they build ownership over it. That ownership is what creates missionaries. A mission handed down from above tends to produce compliance at best.

Practical steps:

1. Start with the problem, not the product. A strong mission is problem-first.
2. Write it in one sentence. If it takes two, it is trying to do two jobs — simplify or split.
3. Test it against your last five shipped features. Would each survive scrutiny against this mission? If not, either the mission or the roadmap needs to change.
4. Revisit it at the start of each planning cycle. A mission that never changes in a fast-moving market is probably a mission that is not being used.

Product teams that do this consistently find the agile mission statement becomes a genuine decision filter. It reduces the volume of escalations because the team can reference the mission to explain a decision, and stakeholders begin to trust that the team is guided by something principled rather than arbitrary. Setting SMART goals at team level works best when the mission is already clear enough to make those goals feel connected to something larger than the sprint.

‍

FAQ

‍

Conclusion

Missionaries are not hired, they are cultivated. The mindset emerges when a team has genuine ownership of a problem, a vision they believe in, and a mission clear enough to guide real decisions. Without those conditions, capable people become mercenaries regardless of their intentions or the culture deck on the company intranet.

If your team is producing output but not ownership, start with the mission-vision foundation before changing any process. Clarify the difference between the two, write the mission together, and use it as a live decision tool rather than a planning artifact. That shift alone can change how a team shows up.

‍