Feb 21, 2021
Mission-Driven Product Management
The military has been practicing strategies and tactics for centuries to coordinate and carry out their missions. If they fail, they die. What lessons can we learn from team management and product development?
Sir Basil Liddle Hart is one of the most famous military historians in the West. In his book, Strategy: The Classic Book on Military Strategy, he devotes the first part to making a strategic review of the most important battles between the 5th century BC and the 20th century.
More than 2,500 years of history go a long way. If we count three generations of soldiers for each century, we could say that modern military science draws on the knowledge of up to 75 previous ones. By contrast, those of us dedicated to Internet product development go for the second generation.
“Fools learn from experience. I prefer to learn from the experience of others. “ — Otto von Bismark
This post intends to present a leadership and management model for product teams that I’ve named Mission-Driven Product Management. It tries to condense hundreds of years of military experience into a simple set of guidelines that we can use in our day-to-day work.
March to the sound of guns
Few people doubt that Napoleon was one of the best generals in history, and it was precisely due to his Strategic and Leadership skills.
During his time, the prevailing military doctrine implied strictly following and complying with the orders set from the High Command. One of the keys to the French general's success was to change this doctrine by giving his commanders clear guidelines for action and independence to carry them out.
One of these guidelines was “march to the sound of the guns”. Napoleon incited his commanders to act without waiting for orders on their initiative if they heard the sound of the battle. Meanwhile, rival armies often stood still for days while waiting to hear from their superiors.
By the time the orders arrived, they had become obsolete in the face of the advance of the Grande Armée, rendering them useless. This speed of action and flexibility was one of Napoleon's primary keys to conquering much of Europe.
“Strategy is the art of making use of time and space. I am less concerned about the latter than the former. Space we can recover, lost time never.” — Napoleon Bonaparte
Auftragstactics
In Mission Command: An introduction Gavin Egerton, an Irish military man, tells how after the defeats at Jena and Auerstedt at the hands of Napoleon, the leaders of the Prussian army had to re-evaluate their doctrine.
Carl von Clausewitz, one of the most significant military theorists in history, was in charge of analyzing both defeats. He concluded that Napoleon’s willingness to foster initiative among his subordinates and his flexible approach to battle had been key to his success.
This reflection led Prussia to create a new military doctrine called Auftragstaktiks. Under it, the High Command was responsible for clearly defining the objectives of a mission. But, there were the subordinates on the battlefield, those closest to the action, to decide how to achieve them.
A central part of German military ideology ever since, a U.S. study in 1939 highlighted the German army's emphasis on developing its officers' leadership and initiative as one of the fundamental aspects of Poland's invasion success.
“The emphasis which the Germans placed on the development of leadership and initiative in commanders during years of preparatory training brought its rewards in the Polish campaign. With confidence that these principles had been properly inculcated, all commanders, from the highest to the lowest echelons, felt free to carry out their missions or meet changes in situations with a minimum of interference by higher commanders.” They recognized that “initiative, flexibility and mobility” were the essential aspects of German tactics. — Wikipedia
Commander’s Intent
Like Prussia at the time, almost all modern armies have their version of the Napoleonic doctrine of defining an objective and empowering their units to achieve it.
In the Anglo-Saxon world, it is usually known as Mission Command. And it is known as Commander’s Intent to clearly express what is expected of a mission without going into the details of how to achieve it, which is delegated to the teams involved.
Thus, military science recognizes how in high uncertainty environments, plans devised from the highs can become obsolete as soon as they come into actual contact with the enemy.
“No battle plan ever survives contact with the enemy.” — Helmuth von Moltke
Mission-Driven Product Management
For Mission-Driven Product Management, I define a doctrine of product development that draws on the same Napoleonic roots as AugsfrasTaktics or Mission Command that we can use while in high uncertain domains.
Under this doctrine, the Product Manager assumes the role defined by the Commander’s Intent. His primary duty is to clearly express the mission's objectives so that the team does not doubt what is being pursued. In terms of problem and solution, the Product Manager would define the problem.
The team, for its part, assumes responsibility for achieving the mission objectives on its own. They would be in charge of providing the solution.
To clearly express the problem, the Product Manager relies on a Mission Document, no longer than a page, containing at least the following keys:
- What is the problem we want to solve?
- Why is it important to solve it?
- How will we know that we have been successful?
Reading this document should help the team to understand what is expected of them. Additionally, it has the advantage that any other company member can read it and understand what is being done, which helps to promote internal alignment.
Companies like Intercom or Xing have experimented with their versions of mission documents. You can find a couple of examples here:
- Auftragsklärung (Xing)
- Intermission Document (Intercom)
Accompanying this document, there may be another one that would be the typical specification document. The Product Manager can use it to give more details about the business requirements, in the form of acceptance criteria, that the team's solution must satisfy.
He can also describe the use cases that we want to solve, provide additional context about the environment (competition, trends), and/or define the solution's scope by setting non-goals.
Therefore, the Product Manager's role is to give context to the team to design the best possible solution to the given problem. But it is not about working on isolation. Once the problem is defined, the Product Manager can collaborate as one more member on the solution side. Still, it is vital that the team, based on their low-level knowledge about the system, participate and even lead this part.
Mission-Driven Product Management Pros
In my opinion, this approach to product development brings several advantages.
First, making use of the knowledge of the entire team leads to better solutions. For example, engineers are among the most creative profiles out there. Having them limited to implementing solutions that come from above without participating is a complete waste.
In the same way, it is much more motivating. In which team would you prefer to work? In one where your room for maneuver is limited to merely coding the user stories that someone has devised from above, or in one where you contribute to creating the best possible solution to a problem? It is a fact that the best profiles demand to participate and not be left out. Adopting a model where you empower them will improve their satisfaction, and therefore, also your retention.
Lastly, I also believe that it is much more efficient because it allows the Product Manager to focus on adding the most value: the problem's domain. It is materially impossible to think that a Product Manager can define the problem and propose the solution simultaneously. In situations where this happens, either the Product Manager becomes a bottleneck for the entire team, or neither the problem nor the solution is the best it can be.
No one size fits all
Although I firmly believe in this model, it must be borne in mind that, as with almost everything in life, it is not all blacks and whites.
Returning to the military experience, armies do not really only to a specific operation mode but adapt it to the situation and the moment's circumstances.
They reserve Mission Command for high uncertain environments. It is usually used by elite troops specially trained in these situations, such as the Marine Corps.
As it happens, the uncertain environment is usually one of the most common characteristics in the Startup universe, so if you work in this field, it is really possible that you can benefit from applying this model.
But if by any chance you find yourself in environments that are not complex, where most of the uncertainty is resolved, other ones where a more centralized model of control is exercised are also possible. The classic military model representing them would be Command and Control.
Always keep also in mind that the profiles required for one scenario and another are also different. The elite soldier is not going to endure being in a rigid environment and vice versa. A few months ago, I wrote precisely about this in Three phases and attitudes of Product Development in case you want to go deeper.
So far, these were my thoughts today about Product seasoned with a touch of military history. If you have any comments, questions or feedback, don’t hesitate to contact me via Twitter at @simonvlc. It will be a pleasure to continue the conversation there 😀.
Thx for your time, Simón.
