5.0 Understanding Your (Real) Customer

Understanding Your (Real) Customer

Lets talk about your actual customer, the Program Manager, the person who’s job it is to “own” a particular piece of technology, to oversee the requirements development and validation, look for updates and upgrades to their thing, budget and fund development, delivery, training, the whole thing.

They are often hard to get a hold of, some of them don’t put their phone numbers in their signature blocks (yeah we notice), they may not attend conferences, they may be elusive at industry days, some of them seem downright reclusive.

Again, have some empathy, these folks have a lot going on. The have delivery schedules, contracts issues, cost/schedule/performance targets, etc. Add to that, many PMs (at least the military folks) didn’t sign up to be acquisition professionals when they joined the military, they may have gone from being a ground pounder or a pilot and by a twist of fate and branch management, found themselves managing the next generation water filtration system.

Now, if you’re doing your job, chances are good that you found some end user, someone who would actually use your thing. You convinced them that your thing is mana from heaven.

Good.

If they actually want to capture that mana, they have to tell someone, they need to express that need to someone who can do someone about it, someone with a budget, and a delivery schedule, someone like a PM.

Now, as we mentioned earlier, not all end users are created equal. MOST have NO IDEA who manages the programs that provide the things they use. It’s not their fault, they have day jobs.

But, if you did your homework, like we suggested earlier, you probably figured out to whom they need to express their needs.

But be forewarned, most don’t know how to express themselves properly. More on that in a minute.

Let us add another level of complexity, the PM does not actually perform the act of buying, they don’t have the authority to obligate the government to pay anything, only a Contracting Officer (KO) can do that. So even if your end user wants your unicorn, and the PM is open to buying it, they have to give their program funding to a KO to actually cut the contract, through which they spend the money. So the PM is the customer of the KO, and the end user is the customer of the PM. See how the layers make things tough sometimes.

As I said, acquisition professionals (PMs) work with “descriptive” requirements, not “prescriptive” requirements. Your unicorn may be the best on the market, it may be the best value for the money, BUT your customer should not ask for your thing, they can’t “prescribe” what fills their requirement, they must “describe” what they require. Ideally/typically they should also describe WHY they need it, in the context of their operational mission, and why they unicorn they have isn’t good enough “I want an Acme Unicorn, Pegasus Model, in blue”. They have to articulate a requirements for a horned equine mode of transportation, with the capability to fly short distances that has camouflage for maritime environments.

To add another layer in the acquisition telephone game, the KO then has to convert that into a solicitation “we want to buy unicorns” document to solicit unicorn proposals from industry. Industry like you.

There are “requirements” and there are “desirements” – and the two are not created equal. If your customer wants you, they need to describe you in a way that you have a good chance of winning the solicitation, and not some who sells something that seems similar. Otherwise, they get what they get and they don’t get upset. Can they write it so hyper targeted that it’s clear that only your thing could possibly satisfy the requirement? No. A decent KO will shoot that down a mile away. (I know, I know, sole source J&A’s, good luck with that).

But they can do themselves a big favor by doing the PM a big favor.

But don’t stop there, PMs and Kos have to do a ton of work just to get a solicitation on the street. They need a valid requirement that’s tied to a mission, most of the time they need to justify the new thing (your thing) over the old thing – ideally that it’s better/faster/cheaper. They’ll need to write a Statement of Work or Statement of Objectives for the solicitation, they’ll have to do market research and clear the rule of two and choose a set-aside if applicable.

Guess what, you can do all that for them. You know the end-user’s mission, you know the technology, you know what they’re currently using, you know what the difference is between your thing and their current thing, you know who your competitors are. So package all of that useful knowledge up and give it to them, or give it to your end user to give to them. Save them the time.

Do they have to use your stuff? No.

In fact, if they're worth their salt they shouldn't use just your stuff, they should go out and do thier own due diligence. But if help them get started, you have much better odds of getting what you want.

If you don’t know all of those things, frankly, go figure it out, because that’s just basic business.

The objective end result is to have the PM say “I have a budget for this and I want to buy it in the future.

At this point, you have a target, a base-funded landing point on the other side of the valley.

Is this easy?

NO! It’s hard.

You will probably fail several times before you find a customer/PM who is able and willing to write your thing (or something that sounds a lot like it) into their program plan.

But what’s the alternative?
Be the 97% of tech that doesn’t jump the valley.