Product management and the Bradley Fighting Veichle

I came across this gem of a movie clip (From the movie The Pentagon Wars) that in a nutshell explains product management regardless of market or industry. The challenges and problems are always the same and this clip pinpoint that flawlessly.

Naturally, this is exaggerated to prove a point but I still see the essence of the clip to be true. The movie itself is also said to be showing the actual truth of the development of the vehicle but I do not know the truthfulness of this.

Let’s break this down and see what parts we can learn from.

The stakeholders

The stakeholders of the Bradley Fighting Vehicle had many different views on what the vehicle was to be used for. The order was for a personnel carrier but instead of placing trust in the ones developing the vehicle the stakeholders then started to inject ideas into development to be able to show rank.

Even though a stakeholder outranks a specialist, this does not mean that the stakeholder has more information or knowledge about the product being developed.

My five cent from reality here is that this is very common. Often this is smaller things and questions on a design that should be touched neither by the stakeholder nor the product manager. It can be details so tiny that best value would be to let the implementation team solve it while implementing.

Stakeholders and product managers must define the vision and the large strokes of what is to be built. Details are to be dealt by specialists.

The product manager

The product manager of the movie clip, Colonel Smith, did not try to stand strong against the stakeholders and instead let the product bloat and lose usefulness. Where he had the knowledge to stop what was going on, to not go into a conflict he accepted the changes and built a worse product.

Conflicts are the constant elephant in the room if you work with product development. Instead of trying to avoid them, the product manager must learn how to embrace and ride the elephants.

Even when the budget was lifted by Colonel Smith, lack of presentation made the comment pass by all stakeholders. If Colonel Smith instead had been a project manager he would have screamed from the top of his lungs that the budget broke.

One of the three pillars have fallen, stop what we’re doing and regain control!

But again, to skip the conflict, Colonel Smith accepted the change and continued to build a product that was again one step further away from the goal.

The outcome

What was planned to be a personnel carrier, quickly in and get persons out, became something completely different? Instead of a personnel carrier with large space for troops, it became a tank with a high profile, little ammunition and space for a few troops. On top of this, it was hard to operate.

Stakeholders controlled the development, not the vision. Product manager controlled nothing, forced specialists to cut corners and ignored their feedback.

The product created was a consensus product without a clear scope and no purpose.

Could this be avoided?

Transparency and consequences could have helped to manage and stop the scope creep. New requirements should always come with an updated consequence list. And consequences are best measured with the three pillars or Cost, Scope or Time.

If every addition was instead measured in what value it brings to the product and what the consequence would be for the result it would have been easier to discuss and resolve the conflict. The stakeholders would also have the tools to understand what the changes mean and act on it.


Leave a Reply

Your email address will not be published. Required fields are marked *