The Three Constituents of Government Engagement

This article will take approx 3 minutes to read.

The other day, I had a chance to speak with Congressional staffers on Capitol Hill about blogging and social media. It was an interesting opportunity that few people get, but I was honored to be given a chance to have that opportunity. It was also interesting to me that, the Democrats had a different set of interests, it seemed, than the Republicans. The Republicans definitely seemed to be interested about the concept of Twitter and microcontent and finding ways to communicate on behalf of their bosses (the members of Congress). The Democrats, on the flip side, seemed oriented to ethical communications, almost shying away from talking to bloggers for journalistic integrity and ensuring that all activity online feel in lines with the rules.

Regardless of the various conversations going on inside those halls and the various interests conveyed, they all have the same three constituencies to cater to. In fact, any government entity has to concern themselves with these same three constituencies. I had this conversation, in fact, last night at TechCocktail DC, where an entrepreneur was building a product that would directly serve government agencies. As a new entrepreneur with a new product in active development, he wanted my thoughts on how to bring the software to market. I advised him to think about these three different constituencies because, for a technology or movement to succeed in government, all three of these groups must have their needs addressed.

The Citizens (or the Users)

In the United States, rightfully, the federal government exists because of the American people. Every dollar spent on a program, project, contract or other investment is money that is gained through taxes or borrowing, which is in turn, paid for by taxes. Therefore, the American people have a direct vested interest in every line item in an agency budget, including product investment. This is why it is so important that the ideas that are brought to the table and utilized are done with careful consideration of ROI.

If a government agency decides to use a product, it is in the American people’s best interest that the idea is well vetted and has a high chance of success. Unlike other areas of the marketplace where experimentation can be tried, it is a much more difficult sell if large amounts of money are at play with an unknown chance of success.

The Elected Government (or the Board)

The second constituency, and the political side of the whole conversation, is the elected government. These are the Obamas, the Cabinet members, the department heads and other political appointees that set the policy and direction for their fiefdoms. They are the ones only concerned with the 50,000 foot view, that look at the puzzle as a whole and strategize about direction.

The elected government, at the end of the day, are likely to make the big decisions. Those decisions, might not be decisions about the adoption of a software product or technology, unless those products are major direction-changing products. However, they offer a significant stake in formulating the thinking surrounding adoption. In order to meet the need of this group, the entrepreneur has to think about the mission of the agency, and how strategically, their product or service is going to affect the strategic thinking at the top.

The Established Government (or the Employees)

The third important constituency in the ecosystem of government selling, is the established government. While the tenured feds who have been carreerists for 20 or 30 years, may not look at the larger strategy decisions, they are intimately involved in the day to day. They are the foot soldiers that, regardless of who is in office, continue to do what they do. They have their kingdoms that have been built up over years, making decisions not based on the high-level strategy, but based on executive orders, court rulings and the practical ebb and flow of day to day work.

The established government cares little about the “why’s” (many are just there to do their job and go home, which is not to say that they don’t care – they just have a different level of buy-in), and instead are focused on the “how”. They might argue, “It’s great that we want to adopt Linux as the operating system of choice in our agency to save money for the taxpayers, but we have significant interoperability concerns with other agencies.”

In order to bring a product to market, an entrepreneur must understand the practical challenges that are faced in an operational environment. This cannot be done with a single meeting in a conference room for an hour or two, and it can’t be done by simply reading blogs or newspapers. An entrepreneur should take as much time to understand that landscape intimately, and ensuring that any solution brought forth is going to address challenges as best as possible.

This group is also going to be the one that is most likely to derail a “pitch”.

Summary

Whenever you want to bring a product to market, the government (like business), is going to look at what you do from the perspective of their own understanding and perceptions. Taking the time to listen first, and understand the challenges of the three constituencies, is going to go a long way in extending your product reach to this audience.

It would be presumptuous to walk into Google and suggest better software for a perceived internal problem without first understanding if your solution extends Google’s mission to organize the worlds information. If it doesn’t help Google gain market share with their own products, then it’s not likely something that the Google brass care to entertain. If it doesn’t help Google, in some way, make money, then it probably doesn’t have wings. A sensible entrepreneur would look at these concepts before walking in the door. Why aren’t we doing the same thing with the government?

Comments

  1. says

    Excellent advice to that entrepreneur. I have found that all too often research and development don’t go in to products enough and they suffer from one of the following:

    Slow load times
    Simplifying Usability (easy navigation)
    Effectiveness
    Lacks User Reporting
    Redundant
    Extensibility (easily updated)
    Hierarchical Relationships
    Design Issues
    Enable Expansion & Contraction of software (install what you need, that’s it)

    Ultimately, the best thing that software programmers can do is invest in extensive testing before product launch.

    Being that I am not a programmer, I am sure much more could go in to this list.