I have now worked at several software companies who have either entered or considered entering the US federal government market. From a distance, this market appears very attractive. After all, the government spends about $90B per year on IT services, an addressable market size that dwarfs private sector IT spending of whole countries. Sometimes, individual solicitations like the (recently-cancelled) $10B JEDI initiative can do so as well.
However, many tech CEOs often make the mistake of assuming that the capabilities needed to service this market are similar to those that need to be developed for pure geographic expansion. Simply hire a sales specialist and you’re done, right? Wrong. Failure to anticipate and build critical product features that are mandatory for successful entry into this market, as well as understanding the peculiarities of the go-to-market capabilities necessary to do so, are the two biggest mistakes I’ve seen when tech CEOs seek to capture US federal government market share.
Below are the various product, marketing, sales, and channel requirements that CEOs and product managers must consider prior to entry so that you do not unintentionally turn that attractive top line into a negative bottom line.
- Product security and compliance. Although security and compliance are obviously not the same thing, compliance regimes and certifications are a relatively reasonable proxy for good security practices, both operationally and in your software development process. For a SaaS, you will likely be expected to hold a SOC 2 Type II certificate as well as be certified under FedRAMP as a CSP (Cloud Service Provider), the impact level of which will vary based on the agencies (either civilian or military) you are selling into, as well as the type of data being transacted through your product and stored. Your cryptography will also be expected to comply with Federal Information Processing Standards (FIPS 140-2 or 140-3) which can introduce extremely specific engineering challenges especially if you are producing on-premises software that requires compiling and operating Cryptographic Module Validation Program (CMVP)-certified security libraries (OpenSSL FIPS, etc.)
- Application hosting venue. Not applicable if you are producing purely on-premises software, although you should be cognizant that many government data centers are completely air-gapped from the Internet, which could inhibit product functionality as well as hinder product upgrades. You also obviously won’t be able to collect usage telemetry from these isolated environments. If you are a SaaS — again, depending on which agencies you are selling into — you may be required to deploy a version of your platform into one of the special government-certified clouds (Amazon GovCloud, Azure Government, etc.) If you do not already have prior experience architecting your SaaS to be multi-service-region aware, this could be a substantial engineering undertaking. Most SaaSes, at least early in their lifecycle, assume one global execution venue for all customers and a single infrastructure control plane (logging, monitoring, CI/CD, etc.) servicing that.
- Accessibility. Because of the Section 508 Amendment to the Rehabilitation Act of 1973 (“Section 508”) and other related agency rules and policies, your product’s user interface will need to comply with certain accessibility standards, largely specified in the Voluntary Product Accessibility Template (VPAT) issued by the Government Services Administration (GSA). Should your product’s interface(s) already be designed to be compliant with WCAG 2.0, you’re already in good shape, but if not, you are likely in for a retrofit. And while the V in VPAT definitely stands for “voluntary”, you are required to enumerate all the accessibility gaps in your product should you issue one, which could reflect poorly on your product if it has a low level of accessibility. If you do not publish a VPAT, you may also lose business to a competitor who does. Realistically, the level of scrutiny over accessibility will vary from agency to agency. You can imagine the Department of Veterans Affairs, for example, is one that pays a great deal of attention to product accessibility.
- Sales specialists. The tribal knowledge needed to understand the peculiarities of each agency, how they like to buy, their level of technology maturity (early adopter versus laggard), as well as the personal relationships to buyers with budgetary authority inside each agency, etc. are all factors that call for the hiring of government sales specialists. It’s also critical to understand that buyer motivations in the public sector are significantly different than the private sector: being mission-oriented, they often care much more about mission success and operability rather than cost reduction. Accordingly, there are government account executives who spend their careers moving from ISV (Independent Software Vendor, which you are) to ISV, because all of this specialized knowledge and “mission orientation” is a valuable accelerator for government sales. Hire them.
- Channel. Much government procurement is conducted via specialized channel partners such as Carahsoft, and there is also an enormous ecosystem of system integrator (SI) partners specifically targeting the government market as well. Of course, the global SIs (GSIs) have government practices, and if you already have good partnerships with GSIs then by all means expand those. But don’t overlook the boutique SIs and implementation partners, who may have a higher level of agility and technological savvy, yet know how to drive more cutting edge technology like yours into agencies.
- Programs and Contract Vehicles. Not only is procurement typically conducted via channel partners, but the actual work is often funded under a contract put up for bid (opportunities can be found on the GSA’s SAM.gov website), which can substantially lengthen the time to close a sale — and may, like JEDI, end up cancelled. Additionally, contract scope is often sufficiently large that ISVs need to partner with other ISVs and/or SIs in order to successfully bid on the contract and satisfy its full scope. Make sure you have the legal and contract management expertise to deal with this level of complexity.
- Citizenship status of technical staff, and security clearances. Security clearances are pretty obvious, but are required only in very specific situations that don’t make up an enormous part of the addressable market. Citizenship status of your technical staff and those of your SI partners, however, including any professional services consultants, comes up more frequently than you may think — even in what would appear, on the surface, to be innocuous situations. For example, many years ago, I, as a Canadian citizen on a TN work visa (at the time), was not allowed to teach a product training class to system administrators at the US Federal Reserve.
While this list is not an exhaustive inventory of all requirements that you need to consider before entering the US federal government market, I hope that it gives you a sense that market entry is not trivial. Too often I have seen CEOs check off one of these requirements and then hope the revenue follows, only to encounter substantial friction when, for example, the requisite product features are not present. Or they make an assumption that just because a deal was consummated at one agency, it’s easy to land the next one, which is not automatically true due to the high variance in missions between agencies.
Final piece of advice: Because this market is so specialized, it’s imperative that you hire talent — or at least contractors — who have done this before.
Many thanks to Galen Emery for reviewing this article and adding several invaluable contributions to it.