What military supply lines can teach us about technical product management

Tanks! Send the tanks now!

A gruesome, weeks-long battle is being fought in the city of Lutz, Zubrowka. Your side holds the city, and you, as Chief Engineer, need to deliver reinforcements to the city. “Tanks! Send the tanks now!”, pleads the captain of the besieged troops.

Your army’s tanks, trucks, and infantry arrive at the port, where you are located. Three types of terrain separate the port from the city.

• First, a forest, two kilometers wide, filled with trees and brambles
• Next, a mountain range, one kilometer wide
• Finally, a river, eight meters across

You quickly deduce that the two most important decisions you must make are what path to build to the city, and how wide a path to build. Your options are to build:

• a narrow path, allowing only infantry to pass
• a wider path, allowing infantry and trucks to pass
• the very wide path, allowing infantry, trucks, and tanks to pass

You have chainsaws and machetes to cut through the forest. Your map shows several mountain passes wide and flat enough for tanks to pass through. You possess one inflatable bridge that can support the weight of a tank. There are no enemies on your side of the river.

You weigh your options and decide to build a road wide enough for a tank

Having decided the width of the road, choosing your route is straight forward. Using a map of the terrain, you decide on a path straight through the forest, from the port to the to nearest mountain pass wide enough and flat enough for a tank. The river 8 meters wide at all points, so you decide to cross just after the mountain pass. From there only 200 meters of grassland separate you from the city.

As you begin to clear a path through the forest wide enough for a tank, problems emerge immediately. You must cut down trees, and it takes longer than expected for your troops to learn to use chain saws effectively. Days pass.

Then, halfway through the forest, your troops discover a deep, wide ditch. You’re forced to select a different route. You end up abandoning most of the road you completed to this point.

When your troops finally arrive at the mountain pass, they discover that the ground will crumble under the weight of the tank. You’ve already built the road through the forest, so it’s too late to select another mountain pass. You’re forced to reinforce the pass. Days are lost.

Finally, you have some luck. The inflatable bridge deploys flawlessly. As your tanks roll over the bridge, you radio the besieged captain, telling him that you’re a mere 200 meters away. He sounds relieved, mentioning that he was about to request paratroopers.

KABOOM. It’s at that moment that you learn that the 200 meters of grassland between the river and the city is a mine field. You’ll need to move your bridge.

Your troops report that there is a clear path to the city a mere 100 meters south. However, your inflatable bridge isn’t designed to be moved. As you scramble to decide what to do next, the city is captured.

What went wrong

Stripped of your command and rank, peeling potatoes in the bunker, you reflect on how things went so badly.

You realize that your mistake was starting with a road wide enough for a tank.

Instead, you should have started by building a narrow path for infantry, all the way to the city.

In half a day, your troops, using chainsaws or even simple machetes, could have cut a path through the forest’s brambles wide enough for infantry to pass through.

As your troops passed through the forest, they would have discovered that the original route was untenable. The narrow path, up to that point, would still have been abandoned, but only a half day’s work would have been lost. More importantly, when the path for the tanks was eventually built, the correct route would have been chosen.

Once your troops were traveling through the mountain pass, they would have been able to test whether the pass could support tanks. Having not yet built the road for a tank, you could have then selected a different mountain pass.

Instead of using an inflatable bridge, your troops would have spent only a few hours to set up a zip line to move infantry and light equipment across the river. When your troops encountered the minefield, moving the zip line would have been trivial. Most importantly, you’d have known the correct place to deploy the inflatable bridge for the tanks.

Once your troops arrived in the city, there may also have been advantages that you could not have anticipated. You might have learned that snipers and infantry armed with rocket launchers are nearly as effective as tanks. At a minimum, the arrival of additional troops would have raised morale.

Your decision to build a wide road from the start lost the battle.

How this applies to software

Customers will often ask for the first version of a product to have many features. In the world of data, customers ask for every type of data that they think they might at some point need.

Building these features before creating a working product that delivers value to the customer is wrong. Contrary to expectation, building all the features from the start delays the delivery of those features. The reason is that there will be unanticipated changes to the design of the product, and each additional feature will increase the amount of re-work or even lock in a bad design.

Instead, build the narrowest, most simple product possible, that fully delivers value to the customer and validates the overall design. When you do this, unanticipated problems will occur, and changes to the design will be made. However, you’ll be able to easily navigate around these obstacles because there will be considerably less code to re-write.

Design decisions should create a path for the final product to be delivered. A simple rule of thumb is to minimize writing, debugging, and deploying code that you know will be discarded. Usually, simply leaving out features does not result in code being discarded.

Communicate the approach to the team

Building a minimal, complete product first is the fastest, most direct path to building a fully featured product. However, the end user is often distrustful that their needs are understood and will be met. Fearful, they will argue to build a full-featured product in stages.

To avoid this destructive behavior, educate all team members, including engineers and the stakeholders, on the reason for building a minimal product.

Make it clear to stakeholders that you understand their concerns.

Communicate in writing what will be delivered in your initial release. Communicate explicitly the features that will not be included, and why. Communicate design decisions with which stakeholders disagree. Communicate the appropriate method for appealing your decisions.

Finally, communicate how product decisions are made. Make sure people don’t confuse the right to complain, give advice, and openly debate with the right to make decisions.