In Government Customer Breakdown: Who should you REALLY be talking to?, we broke down government customers into four general roles: the User, the Funder, the Buyer, and the Requirer.  The output was a rather vague picture of a customer network that needs to be engaged, which may have left you less confident in your traction, and more confused about what to do next.

To make things more complicated, the person or people most likely giving the appearance of traction to you and your team may not fit into any of these categories. It’s likely that they are a beneficiary. Your beneficiary does play a big role. They are an advocate who is going to help you succeed, but if they don’t fall into one of the categories above, you’ll need to be sure all four of those stakeholders are identified too. 

So how do you discern between this network of characters? 

While there are too many scenarios to break down in a single article, there are some patterns that lend to network “templates” and best practices to determine what your stakeholder network looks like. It’s also important to break this notion down a bit further so you can really understand who you need supporting your solution. 

Let’s start with your User. Your User is the person that’s going to use your solution most directly. Are you selling a SaaS product? Who actually needs to have the license or account? Are you selling a widget – is this something that needs to be integrated into a bigger system to be used, or can an operator hold it directly in their hands? 

Your User is likely not your sole beneficiary. More importantly, they may not be the ones most impacted by your solution. When it comes to identifying your user(s), you’ll want to be sure you’re including the groups who will benefit most from your solution, AND the person who is actually going to be using it. Both or all will play a role in your design process, and both must be bought in to support your success. 

If you’re building software, your true User is the person who’s going to be using the license.  Additional beneficiaries may be the groups impacted by the outputs of your product.  Are you selling a widget that someone can independently use - as a simple example, think like a flashlight. This one’s easy – whoever is going to hold it and use it is your user. There may also be maintainers or logistics managers who are important stakeholders supporting your user that fall into the additional stakeholder or beneficiary group. For example, your User may not care much about the difference between your product and another, but perhaps your product is much easier to maintain.  

If your product is integrated, your story is a bit different. Depending on the level of integration, there may be no real User other than the integration partner incorporating your technology into their solution. This is particularly true of deep tech sub-systems or component technologies. In this case you’ll want to focus on the teams that are affected by your product in its integrated form. This is most likely an operator or a leader. 

You are likely to find your biggest advocacy in your biggest beneficiaries. You may find your user IS your beneficiary, but if you don’t, you’ll need to make sure both are on board! It’s important to identify both and be clear on their roles, so that when you engage in customer discovery you’re optimizing both usability/user experience, and value of the output.

What about my Buyer? 

Strictly speaking, this is the person who can actually purchase your thing – generally speaking, this is a warranted contracting officer or a delegated individual such as a resource advisor.  There are some unique cases, such as a blanket ordering agreement, where others may play this role, but we’ll set that notion aside for now. They are a critical piece of the puzzle, but often someone you won’t engage with until it’s time to sign a contract.  

In a more broad sense, they may be the organization or agency tasked with finding and buying your things. So your actual buyer will be their contracting team, but for the sake of this breakout, it may be the program manager who has the authority to pick the product and work with their contracting team to buy it. In the military, the buyer organizations are usually in the acquisition community and fall under a program executive officer. Their task is to select the right tools to equip operators, who are focused on the tactical training of executing their mission, rather than tech scouting and development.

There are some agencies who reflect this type of structure, and others who are much more consolidated and less nuanced in their break out.  All government teams, however, will have designated individuals warranted or with delegated authority to spend government money.

How is the Funder different? 

Again, they may be. They may not be. This becomes most nuanced in research and development phases. When you’re working on a product in development, there are a number of funding sources available and you may need to pull in another team. There are also circumstances where an organization has funding they are willing to share or lend to another organization–being aware of these opportunities and connecting these stakeholders can be extremely lucrative.  

While it’s not a given, it is reasonably common for your funding organization to overlap with one of your other key stakeholders.  For larger efforts and portfolios, requirements owners also hold the funding. If you’re working in integrated technology, the funding has often been delegated and disbursed to your buying organization, so you can call them one in the same.  In other smaller dollar exchanges, you’re working with a user who has discretionary funding and can buy what you have directly. For big or recurring deals, however, it’s not common for your user and/or beneficiaries to also have funding. The instances where this is the case are usually low cost items that can be directly purchased. 

Requirers. This is the most complex group in the discussion, and I look forward to diving in deep on the nuances of this role, and some bigger insights on the requirements and funding process next week! 

Still trying to figure out how this applies specifically to you? Registration for our first Customer Network Workshop opens soon! In it we’ll go through tips and tools on how to map out your customer network, and we’ll walk through your real examples so you walk away understanding each of your stakeholders and how to bring them together for success! 

Your Fan,