Product Management Within the Federal Space
You may be wondering, “what does Product Management have to do with executing a federal contract?” And you would be exactly right.
The role of Product Management is one which defines either a Product or feature which addresses the needs of a group of users. So how and why has the Product Management role spread like wildfire in the Federal Contracting space? There is a very simple explanation.
The simple explanation is that the term Product Manager gets mixed up with Product Owner, which gets lumped into the world of Agile by default. The Agile frenzy has completely taken over the federal government for a few years now, with many contracts explicitly outlining that Agile ceremonies must be followed, and that a Scrum Master must be part of the staff, even though they are rarely used correctly. This is to no real fault of the government, as they are an entity that has unfortunately fallen behind industry compared to their glory days in the 50s and 60s. The real fault lies with Government Contractors, who in the beginning sold Agile as a competitive advantage so much so, that Government totally bought in and that Waterfall Development term is now forbidden. So along with Agile development came the Scrum team, consisting of a development team, a Scrum Master, and of course a Product Owner. However since the government is very hierarchical (many commercial orgs are guilty of this too), the Product Manager was born - the step above a Product Owner. This has now been confused between the two industries, and it is rarely a joy when seeing a bright eyed Product Manager who has spent their career in the commercial industry dipping their toes in the federal contracting space, because their expectations and reality rarely meet.
Problems with the Federal Product Manager
The Product Manager role within the federal government is currently in a state of evolution. Its initial form came in the shape of a role underneath Program Managers, where Product Managers would simply develop the technology, while the Program Manager actually manages the client, budget, contractual obligations, as well as making any additional sales through contract modifications. This also meant that many times a Product Manager would also double up as a Scrum Master, because the Program Manager took many responsibilities that a Product Manager would typically have, and nobody really understood what Scrum Masters did. This was obviously met with a bit of conflict as one would expect because:
As many organizations put it, the Product Manager needs to be “customer obsessed”, and that doesn’t exactly work when there’s a Program Manager adding a layer of bureaucracy.
Product Managers, who are the day-to-day management of development, would never be approached by senior leadership, and a Program Manager would, who would have outdated and inaccurate information.
Product Managers didn’t have control over staffing, and depending on how (in)competent your Program Manager was, you could have engineers or testers yanked off of your team with a day’s notice due to budget that you had no insight into.
This was the cause of a lot of struggle internally within organizations. At this point, having a Program Manager and a Product Manager led to a lot of fat in teams, there was a lot of undermining going on, and there was just a general increase in the amount of conflict between teams.
Once that that was identified, the role of a Program Manager in many organizations started becoming a bit more obsolete, in favor of the brand new Product Manager. The paragon of Agile, the showrunner of the project. However, there is a new conflict that is occurring now - there is a lack of understanding between what a Product Manager does in industry, versus what they do in Government Contracting. When managers who were in charge of this shift are coming up with “OKRs” for their team and Google “What is a Product Manager OKR?” they were met with the duties and parlance of actual Product Management, which is what begins the divergence of how people began thinking about Product Managers entirely. Product Managers are people who identify gaps in the market, perform user analysis and create prototypes, more akin to a startup or, dare I say a Product company. So the only thing that’s really changed is the name of the role, but the work is still somewhat similar, in that you sign a contract with the Government outlining specific work, and you just have to execute on that work.
The Opportunity
Now comes the fun part, and our current stage in the evolutionary cycle, at least for the more forward thinking organizations. This paradigm shift of Program Management into Product Management has now brought us to a state of actually understanding why these roles were necessary in the first place. I’ve gone over the responsibilities of both in the section above, and now that management in some organizations have understood that they have people who are capable of building products geared towards multiple customers, the role enters the most important step of its evolution. Program Managers are very important people, and they are the ones who need to be utilized on Programs, but now that we have these Product Managers, how can we as Government Contractors work some of our federal contracts in a way where we own our own code, but sell it to you as a platform to subscribe to? Obviously that doesn’t work with highly classified applications and the like, but a large chunk of work, specifically software R&D work, aren’t necessarily classified systems. The government doesn’t want the overhead of paying not only for the creation of an application, but also the maintenance of it. They are comfortable with working with something that already exists and works, and just licensing themselves to using it. After all, security and cloud infrastructure are much more commoditized, which means better practices and much more widespread adoption, this includes the Government’s lesser classified applications that don’t require on-premise servers.
We have now entered the territory of market analysis, ideation and testing of ideas through MVPs, roadmapping dynamically based on market needs, and things that you would typically ascribe to a Product Manager. In a stroke of irony, the role that was born out of a misattribution of terms by the Government has evolved into its actual role, and is potentially a disruptor to how Government Contractors, and in return the Government itself does business.
Challenges
In my experience thus far in the evolution, this is a difficult thing to do. You have very precise (but poorly worded and communicated) requirements handed to you by Government entities who have been doing things a certain way for many years, or there is actual legislation dictating how processes should work. This doesn’t lend itself well to the general market, as that normally requires some semblance of flexibility, so there needs to be some level of synthesis between the two customers’ needs to create a product that will ultimately serve both. It requires masterful client management in the scenario that, god forbid, the Government slightly change their processes, but even more so it requires the ability to create a vision that is bigger than the box your stakeholders try to put you in, especially one as archaic as the U.S. Government.
The reason why the Government is so far behind is because they have to be. You have to keep in mind that an embarrassingly large percentage of the Government is using laughably outdated modes of operating. They build processes around these methods of operation, and thus are unable to change their ways easily. I have seen programs run only through e-mail, with a single Excel spreadsheet being passed back and forth and updated. The bar is very low for what needs to be done; the real issue is in selling to people who have created an intricate process of doing something a certain way for such a long time, they refuse to change.
Another issue I have seen is internal company goals. A startup Product company and a Government Contracting company have two very different origin stories. Product companies have been known to not make a profit for years, and in most cases they don’t even end up making a profit before they fail. Winning a contract comes with immediate profit, as that is typically built in to your contract pricing. The mindset behind these two things are very different, because one is very short term profit oriented, while the other has a much longer turn-around, being fueled by things like seed funding and angel investors. The level of discipline and understanding of products required to use government funds to create a scalable product outside of just Government (or even just that specific agency) is one that most contractors simply don’t have. The idea of having razor thin profit margins in the short-term for potentially massive margins later is foreign concept to many contractors. Instances in which releases are forced when they were not ready to be, significantly underfunded development teams to increase margin, and a lack of expertise in building scalable applications from a business and technical sense is the downfall of this idea.
Everyone understands that this is the path forward, that this is the next step in the evolutionary chain will be achieved. Once contractors and the government collectively come to understand why things are moving in this direction, the more quickly the next stage in the evolution will be reached. Once this occurs, I believe it will have significant impact on the productivity of the Government, because of the simple idea that if an idea dies in the commercial marketplace, it won’t be used by the Government. This will eventually weed out the horrible processes and the terribly built and inefficient applications plaguing the Government.