As I transitioned from active duty in the U.S. Marine Corps to a Product Management role at a robotics startup, I was intimidated by the steep learning curve I faced. While I had an academic background in engineering and tried to keep up with emerging technologies through various side projects, I had no idea what was required to launch a commercial product and scale it.
My new coworkers were quick to jump in and help me understand the differences between unit and integration tests or how to write a hardware Design Validation test plan, for example. Luckily, what was most surprising, was how much the fundamentals of planning a military operation resembled planning the development and launch of a new product, disguised under frameworks with different names.
At the end of the day, I realized one overarching principle: a military unit and a technology startup are both organizations that require decision making in ambiguous situations for survival.
They also share some other commonalities:
- Both place an emphasis on defining the problem before developing a solution.
- Both use divergent thinking to create several distinct plans, stress test them, and then converge on a single solution.
- Both ensure that the teams responsible for execution know both what to do and why they are doing it but are left to determine how to best do it.
The rest of this post examines some of these similarities and highlights some of the best practices in the military that product leaders should keep in mind when they develop and launch a new feature or product.
The Planning Process
A base understanding of both processes is important before jumping into the details.
Organizations are made of people, and those people need to collaborate together in order to accomplish a shared goal.
For the military, the output of the planning process is typically an order which is then executed by a military unit. For a product team, the planning process typically results in a Product Requirements Document (PRD) that is then used by engineers and designers to build a new product feature.
Mission Planning in the Marines
The Marine Corps Planning Process is used at all levels of the organization and consists of six sequential steps as depicted in the image below.
Here’s how the process unfolds. Planning starts by reviewing the Intelligence Preparation of the Battlefield document together so the entire planning team is aligned on the latest information about the adversary, terrain, and weather. The team also reviews the order from higher headquarters. At the end of the Problem Framing phase, the problem to solve is described as a mission statement, identifying what the command must accomplish, when and where it must be done and, most importantly, why—the purpose of the operation.
Next, the staff starts to develop Courses of Action (COA), different options for accomplishing the mission. Once the COAs are developed, the team then examines each plan through an iterative action-reaction-counteraction process to forge a greater understanding of the environment, the problem, and possible solutions.
The results are presented to the commander who then chooses an option or some hybrid of options. The staff translates the plan into an oral/written/graphic format for the subordinate teams who then execute the plan.
Product Planning in a Startup
Product teams commonly use the double-diamond design process model depicted in the graphic below.
The process starts with discovery, where the team studies the competitive landscape, the target market, and potential users. Insights are pulled from the research and a single user problem is defined as a focus for development efforts.
Next, teams iterate on different design concepts, typically in the form of prototypes. The prototypes are tested to get a better understanding of how to best solve the user’s problem. Eventually, a design is selected and slated for development. A Product Requirements Document is developed containing all the relevant information about the feature and how it will be delivered to customers.
What Problem Are We Solving?
Both organizations emphasize the importance of refining the problem statement before transitioning into a problem-solving mode. Military planning starts with a thorough understanding of the adversary, the environment, and friendly capabilities. In product development, the competitive landscape, the target market and users, and the business’ fundamentals are first analyzed.
While the images above may look like they depict a linear process, military planners and product teams are constantly learning more about the problem space as they conduct operations or ship new features. These learnings are continuously incorporated into the problem definition process.
The Marine Corps calls this the “planning-execution-assessment continuum“:
Planning should never be viewed as an isolated activity or process; rather, as a part of the planning-execution-assessment continuum. Success in such a fluid environment demands that Marines think critically, examine the nature of the problem as well as the purpose of the operation, and learn and adapt during the entire planning-execution-assessment continuum.
It’s important for product leaders to remember that the user research and market analysis artifacts are living documents and they should be continuously updated. These documents serve as the foundation of the product development process. Every user testing session, competitor blog post, or customer review is an opportunity to refine these documents so they reflect the most accurate understanding of the product’s environment. It’s not a single department’s job to create these documents either. It takes cross-functional collaboration to get the complete perspective needed to fully comprehend the problem space.
It should also be noted that just understanding the user is not enough to guarantee a solution will be successful. Military planners conduct reconnaissance missions to understand their adversary, similar in purpose to a product team’s user research interviews. However, military planners also take note of the operating environment to better anticipate potential impacts. Will the terrain prevent the use of certain vehicles? Are their aspects of the language, culture, or religion that would impact the mission? How does this mission fit into the higher headquarters’ strategic plan?
It’s important for product teams to have a comprehensive understanding of the industry, the competitors, and the business as well. What’s the size of our target market? How much do we think it will grow? Are there any market segments our competitors are ignoring? How does solving this problem fit into the overall mission of the business? At the end of the day, the product needs to solve real user problems, but the solution also has to add value to the business. Making sure the problem framing process addresses these aspects as well will ensure that the final problem that is selected will add value for both the user and the business.
Once the product team converges on a problem to be solved, it’s key to summarize the problem in a clear and concise statement. In the military, this takes the form of a mission statement consisting of a task and purpose. For product teams, whether you chose user stories, jobs to be done statements, or some other framework, the key is to articulate what goal the user is trying to accomplish and why they are trying to accomplish it before the team starts to brainstorm how to solve it.
What’s the Best Solution?
With a clear and concise understanding of the problem, it’s time to develop a solution. Again, the objective here is to use some divergent thinking exercises, stress test the ideas, and then converge on the single best solution to execute.
The military develops COAs while product teams develop prototypes. Both organizations recognize that there are no right or wrong answers but some are better than others. Both organizations encourage brainstorming a variety of solutions and then testing them to identify potential pitfalls as early as possible.
Every military COA must be “suitable, feasible, acceptable, distinguishable, and complete“:
- Suitable: Does the COA accomplish the purpose and tasks?
- Feasible: Does it account for the time, space, and resources available?
- Acceptable: Is it militarily and politically supportable?
- Distinguishable: Do the COAs differ significantly from other COAs?
- Complete: Does it address the entire mission?
Product development is focused on developing solutions that account for the “four risks”:
- Value risk: whether customers will buy it or users will choose to use it
- Usability risk: whether users can figure out how to use it
- Feasibility risk: whether our engineers can build what we need with the time, skills, and technology we have
- Business viability risk: whether this solution also works for the various aspects of our business
Military planning requires the participation of the entire staff. This ensures that the solutions developed meet each of the COA criteria. Product teams should remember to include members of other departments (engineering, operations, legal, etc) in the prototype development phase as appropriate. This isn’t meant to constrain the brainstorming process. The diverse perspectives improve the quality of the brainstorming while ensuring that the prototypes aren’t overly exposed to one of the primary risks.
What about the “distinguishable” criteria? One aspect that military planning emphasizes is the identification of critical assumptions and the development of COAs around those assumptions. These assumptions are “critical” because the plan will radically change if they are discovered to be true or false. If the harbor is full of mines, the military team will take helicopters instead of boats.
What does this look like in the product world? Maybe an assumption is made about how much information the user needs to have available on screen in order to complete a task. One prototype can display all the information by default, while another can have the information hidden and require the user to selectively reveal the information. Understanding the user’s preference will have significant impacts on the feature’s visual layout, information architecture, and UI element design.
Push the team to develop truly divergent ideas as much as possible. The more product teams can differentiate the prototypes, anchoring these differences on key assumptions, the more impactful the insights will be from usability testing.
Making it Happen
Planning culminates in execution. Up to this point, the focus of effort was on defining the problem and the best solution. All that planning is moot if the team fails to execute the plan. It’s important that the plan is translated into a format that can be reviewed by the team responsible for execution, especially if some team members weren’t involved in the planning. The Marines use the Five Paragraph Order format while product teams use Product Requirements Documents.
Rarely does all go exactly as planned. How can we account for that to ensure the team stays flexible? Marines use mission-type orders which place an emphasis on describing the outcome of the mission rather than the specific means of achieving it. The tactical details are left up to the teams responsible for executing the plan, allowing them a high degree of freedom and flexibility in determining how to best accomplish the mission.
The Marine order starts with several sections that describe the high-level context of the operation, information on the overall status of both friendly and adversary forces, and a mission statement defining what the unit must accomplish. Additionally, the “desired endstate” is provided which defines what the friendly, adversary, and civilian environment would look like if the mission is successful.
A comprehensive PRD has similar components. The PRD starts with the business and product objectives which detail the specific user problem to solve and how solving that problem moves the company closer to its high-level goals. Typically, some success metrics are defined which detail how the team will measure the impact of the feature. This section may also include acceptance criteria, which are a set of predefined requirements that must be met in order to mark a feature-complete.
These sections are critical for empowering the team responsible for developing the feature. It’s impossible for the product team to exhaustively describe a feature and every implementation detail. Even the most junior developer will make decisions that could have a significant impact on the user’s experience, especially as systems become increasingly complex.
The Marines call this the “strategic corporal.” In complex and rapidly evolving environments, even the most junior person on the battlefield will be required to make decisions that could have strategic consequences. For example, an altercation with a local civilian could lead to protests and create an international incident.
A thorough PRD serves as a guiding document that even the most junior developer can reference to ensure that their implementation decision aligns with the overall intent of the feature without having to constantly ask for feedback and guidance.
Tackle Uncertainty Efficiently
Military and product teams have refined their planning processes in order to support their decision making in uncertain and ambiguous situations. As technology advances and the world becomes increasingly connected, organizations are required to embrace the complexity and make timely decisions. Waiting too long to make a decision could result in failure, but making the wrong decision quickly could also have outsized negative impacts.
Resources are limited in every organization. They need to be invested in the items with the highest leverage. They can’t be wasted solving a problem that is unclear or not aligned with the organization’s higher goals. They can’t be wasted on solutions that aren’t technically feasible or acceptable by the business. They can’t be wasted on teams who are blindly executing a plan without any context or understanding of what success looks like.
Product owners may craft the product vision, but they are dependent on the entire organization to execute on the vision. Product owners need to recognize this and ensure those decision-makers are focused on the right problem, with a robust solution, and a clear vision of success so their actions can have positive and outsized results.