Over the past few months, I’ve worked with several defense companies and military technology units.

This environment is not new to me. 

After all, my career started in a technology unit within the Navy, where my team and I took an active role in developing one of the key systems of the Navy.

Reconnecting with these organizations got me thinking: How should product management function in defense organizations?

You see, there are quite a few key differences between a high pacing, lean & mean Saas company, to a defense organization. Let’s discuss those for a second, and what it means for product managers working in such environments.

Notable differences in defense organizations

Large scale systems

As a product manager in a defense organization, you’ll likely work with large-scale systems, each with deep complexity and broad responsibilities.

Opportunities to work on such systems in the civilian world are rare.

In fact, to this date, I’ve yet to work on a system as comprehensive and big as I had in the Navy.

With such large systems, even small product decisions can have a major impact. And impact is what we’re after, right?

On the ‘less bright’ side of this – there is a very good chance you won’t be the first product manager of this project, nor the sole one. It could even be that the system existed for years before you came on board.

It doesn’t mean that your contribution can’t be meaningful. 

When I came to the Navy the system I was assigned to indeed existed for a few years already. During my time there we reworked some meaningful parts of it that are still operational to this date. So, don’t be discouraged by this.

Meaningful products

Let’s address the elephant in the room head-on:

Some avoid working in defense, believing these systems exist primarily for destruction.

Here is my take on this:

Some systems have offensive purposes, true, but most I’ve encountered are either ‘neutral’ or purely defensive. When I say ‘neutral’ I mean they are aiming to provide a true tactical picture of the world and let the decision makers take it from there, and when I say ‘truly defensive’ I mean that the systems are designed to actually save lives rather than take ones (for example – intercepting incoming missiles).

So all in all, if you are judgemental about it – then firstly, you don’t have to work in this industry. Secondly, instead of dismissing this interesting opportunity too quickly, maybe get some more details about the project that is being offered and see for yourself whether it’s truly defensive, or the exact opposite. Maybe you have a true opportunity to actually save the lives of people.

If a project is truly about defense and saving lives, what could be more meaningful?

Many people I know who work in  defense companies/military organizations are very content and motivated because they believe they are doing something meaningful.

Limited and restricted access to networks and data

Defense organizations naturally impose strict access limitations. A great portion of the data is classified, and very often there are several levels of classifications.

These restrictions go beyond standard SaaS permissions. Even physical access is tightly controlled. You’ll need some sort of a security clearance and sometimes even a keycard or some other physical device to get through a door, or to get access to a machine.

From a product management perspective there are several things that you’ll need to keep in mind:

1. A strong permissions model is essential, but not enough. Most organizations already have the infrastructure, but as a product manager, you must ensure it doesn’t harm usability.
2. The separation of networks makes access to the Internet non-trivial. Since the Internet is a working tool for many product managers, especially with the various AI engines (see my post on how to improve your productivity with AI here), then you need to understand how to work around that. Some organizations have already solved this problem, to some extent. But uploading CSVs to the AI for analysis is most likely a big NO-NO and even sending an answer from Claude to your peers may not be as easy as you think. This can make the research & discovery processes much more challenging than you think.
3. On a personal level – working from home is usually not feasible, unless your organization has very strong security infrastructure. Even then, your employers won’t be thrilled that you are going to work remotely, and most likely will allow you to do it in very extreme circumstances. For many people this is a deal-breaker. You need to consider where you stand on that front, before accepting a job in such an organization.

On-premise installations

In defense organizations, systems are typically installed on-premise with limited external connectivity.

For product managers, this presents challenges such as:

1. Making it challenging to collect product analytics. You can’t really be data-driven if you don’t have an easy way to track your product analytics. When designing a new system that is going to be installed on-premise you need to consider how you are going to tackle this one. Depending on the security limitations, you have several options. The best one would be to transmit them over the air in realtime, or at least once per day. For many systems I know, though, this is a no-go. The second best option is that the system will provide a manual (but easy) option to transmit logs and analytics by the operator. Hence, when the system is not under load, or in the middle of an operation – the operator can click on the button and the analytics will be transmitted. The last and worst option happens when a transmission is not allowed, and in that case – someone will need to manually collect the analytics logs every period of time and get them to you for analysis. Whatever it is, you need to make sure you will get access to your product analytics on an ongoing basis.
2. Being truly agile can be quite challenging. Agility means delivering value quickly, gathering feedback, and iterating – rather than waiting for a full cycle like in waterfall development. Most defense systems I came to know – don’t really work agile, even if they perform all the agile ceremonies. You need to recall the agile ceremonies (dailys, sprints, retros, demos, etc..) exist to support you, but they don’t determine your agility. Your team is truly agile when you are able to release mini-versions in small iterations, get feedback and make adjustments based on that feedback. On-premise installations make it hard to accomplish that, but it’s not impossible. You just need to plan for this carefully, get the buy-in of everyone around you to such an approach and then maintain discipline around that (probably the most challenging aspect).
3. Many of the systems need to be developed in-house. Because of the confidentiality and the strict security restrictions, defense organizations tend to develop many of the systems in-house, especially when it comes to operational systems. From a product management perspective, when it comes to the end-user applications – this is actually not a bad thing. It can generate plenty of interesting opportunities for you as a product manager. However, any large scale application requires a lot of infrastructure to support it. Most of the infrastructure your application will need is not very unique, nor interesting. There are probably plenty of off-shelf products and libraries that you can use for accelerating your development. However, the security restrictions may limit you severely on the selection of such products/libraries, and sometimes the best service that could have helped you accelerate your development will be unavailable for you to use due to various security restrictions. This is very true for AI development sadly. Many defense organizations won’t allow you to leverage OpenAI’s APIs for example, as there is no way you will be authorized to upload sensitive data or prompts to an external service. In such cases you’ll have no choice but to develop an in-house alternative, and when it comes to AI – setting up a state of the art LLMs infrastructure inside your organization is far from trivial, even with the existence of open source LLMs. This is because LLMs are expensive to run and you’ll also need to support it with proper hardware and need the skill set for that. As a product manager you may find yourself dealing a lot with infrastructure rather than your actual application.

Now that we’ve covered the limitations of the environment, let’s address more fundamental business questions that affect your reality as a product manager.

Do your users have a choice?

Many of the defense organizations out there in the world are quite huge. Especially when it comes to the military. We’re talking about closed ecosystems which can sometimes span over hundreds of thousands of people.

It’s not limited solely to armies, but also to governmental agencies which deal with sensitive data, such as the CIA or the NSA.

Due to the restrictions already mentioned, many of the operational systems will be proprietary and developed in-house.

If you are a product manager involved in building such an in-house product (or even when joining forces with a contractor), there is a big question that arises, and if affects a lot:

Once your solution is deployed, do users have any alternative? 

For most of the scenarios, the answer is no. You have a captive audience.

Even with the best intentions, a captive audience often leads to complacency. It’s human nature.

Do revenues matter to your product?

When developing internal products, revenue is usually not a meaningful metric. This is true for many internal products and not necessarily unique to defense or military environments.

The lack of revenue as a metric makes it harder to set up a north star, as one of the characteristics of the north star is to be a leading indicator for revenues (see my post on this here).

Setting up a north star is still possible in such scenarios, and I’ll write a post about it in the future. And while it is still possible, it’s trickier to set up, and I’m yet to meet a defense ecosystem which has a proper north star set up.

And with no existing north star – the question of what is ‘impact’ becomes blurry.

Combining the fact that your product is the only viable option for your users together with the lack of an effective measurement for ‘impact’ usually leave product managers confused. What’s your definition for ‘success’? Assuming you want to come up with a proper product strategy – how can you measure its effectiveness? What are you optimizing for with your product?

From my personal experience – in such environments the notion of a true product strategy is quite blurred and instead the notion of ‘next version’ and what it includes becomes the question that matters.

Implicitly, it means that over time your roadmap is mainly dictated by the requirements coming from ‘the field’ and you and your team are slowly becoming an execution team that stops asking questions and just focuses on delivering features. This is what Marty Cagan calls ‘Feature teams’ (reference here).

Impact on your next job

Here is a harsh truth, that I must tell you now, because it may impact your career growth:

I’ve met many product managers from defense ecosystems struggling to transition into the civilian world. Many defense product managers find their 10 years of experience valued as just two in the civilian world, making career transitions tough.

The main reason is the fact that product managers who are working within a closed environment, which is protected from competition and not focused on revenues, are not equipped to win in the demanding and competitive environment of the civilian world. 

The second main reason is what I just mentioned, and it’s the fact that in such environments, there is a good chance that you are not truly the product manager, but rather a product owner. It means that you are not experienced with identifying pains and user needs, never dealt with true product strategy and nor with roadmapping. Those were handed to you by the operational team most of the time.

Of course, individual experiences may vary. It could be that you actually interviewed a lot of stakeholders, identifying pains and designing a roadmap. But generally speaking – this is how product management in defense systems is perceived and evaluated by the external world.

Summary

Being a product manager in a defense or military environment can be very fulfilling and super interesting. The great majority of the systems are quite big and have a lot of depth and the work is usually very meaningful.

From a classic product management perspective, though, such environments are a bit different. They are slower, less agile and less strategic in nature. The question of ‘who is really the product manager’ is also always floating in the air. And lastly, there is a good chance that your target users are a captive audience and your efforts do not translate to revenues.

For these reasons, product management experience in defense is often valued lower than in competitive, revenue-driven civilian markets.

I’m not saying you should drop your job at the defense ecosystem and switch to the civilian world right away. If you enjoy your role in defense, there’s no need to leave. But if you want broader career options, be mindful of the challenges. 

In order to mitigate some of these challenges, you should strive to introduce true agility to your processes, make sure the decision makers are properly defining their mission, north star and product strategy (like I explain in the CAF Product Framework post here). These are all possible, but often overlooked in such environments. This will not only make you better prepared for the civilian career, but also improve the efficiency and impact of the current processes.

Alternatively (or additionally), you can start your career there and switch to the civilian world after a couple of years. Thus, ramping yourself up a bit slower, but working on meaningful stuff which are not tuned necessarily towards revenues.

Just recall – the longer you stay there – the harder it’d be to get out into the world.

Good luck!