Customers Not Clients

From Merriam-Webster:

• client: a person who engages the professional advice or services of another.
• customer: one that purchases a commodity or service.

Customer and client mean almost the same thing, but the definitions hint at a subtle distinction that I hope to show is important.

Clients are best served when the “advice or service” is tailored to their needs, situation, and values. Often, this means a client-provider relationship is long-term and includes a personal touch. For example, my dad’s a financial advisor; he has clients. A stock broker isn’t very good if they give the same advice to a late-career empty nester with a seven-figure salary versus a new college graduate with $80k in student loans. Primary care doctors, real estate agents, therapists, and personal trainers — good ones at least — have clients.

But it would be both exhausting and inefficient if all transactions required bespoke engagement. Sometimes Most of the time, I just want to be an anonymous customer. I want eggs, and perhaps a couple of suppliers to choose from, but I don’t need the curriculum vitae of the hen.

These are my working (and in-work) heuristics to distinguish between customers and clients, fully acknowledging that this reduces a continuum of potential interactions, along multiple axes, to a simple dichotomy.

So with this framework in mind, let’s turn to aerospace.¹ For most of my career, the government’s been paying the bills. We always referred to them as “the customer”, but they weren’t customers buying AAA batteries from the GSA schedule; instead, they:

• used past performance as a selection criteria
• paid us via cost-plus contracts
• didn’t just want the end-item, but had an entire Contract Data Requirements List (CDRL) full of ancillary documents that provided insight into and oversight over the design, costs, schedule status, etc.

They were clients.

This client-based paradigm is so pervasive it creeps into contractors’ internal lexicons. The best example is the term “Operational Excellence”, which became a thing just before I left Lockheed Martin. Previously, the buzz phrase de jour was “100 percent mission success”. (Whether that’s healthy is a completely separate conversation, since it’s pretty clear to me that the marginal value of reliability falls off pretty quickly.) The new term, OpEx, as it was eye-rollingly abbreviated, was meant to capture that we weren’t just providing products that worked, but also a “positive experience” during development. Except positive experience didn’t mean good customer service, but a prioritization of the path over the destination. I wasn’t attuned to it at the time, but this corporate speak was meant to drive home that we didn’t have customers buying our products; we had clients we needed to mollify at every step in the process.

Mollify sounds more pejorative than I intended, so I’ll clarify. To mollify is to appease anxiety, and given the circumstances, the government had plenty of reasons to be anxious:

• They had to underwrite the entire development. It costs a lot of money to develop something fancy, like a space station or a nuclear-tipped inter-continental ballistic missile. So it’s natural, when that much money is changing hands, to be nervous when you’re accountable for how it’s spent.

• Custom products serve small markets. This means the government has to foot the bill for the entire lifecycle, not just development. A successful program might sign the government up for decades of future expenditures, so it’s not surprising they want lots of insight and the ability to course correct during execution.

• By definition, any critical part of the government (e.g. higher-ups in the chain-of-command, Congress, regulatory stakeholders, or other supporting agencies) can kill a program. Given all the parties empowered to say no, it’s not surprising that failure is the baseline expectation. The emphasis on process, interim deliverables, and intellectual property rights is an attempt to ensure program termination isn’t a complete loss.

So client-hood is a rational response to circumstances, but it also makes it too easy to cancel programs and creates a moral hazard for the contractor. Their costs are covered, and they earn fee as they go, so they’re not incentivized for the program to succeed, only for it to “keep sold” as long as possible.

Client-hood results in lots of money spent on slowly progressing programs, at least until one of the say-no-empowered stakeholders changes their mind and pulls their support. For the first ten years of my career I worked on systems that never shipped, and I’m not alone. My first mentor out of college had a long and distinguished career and was well-regarded and well-known across our industry. He once lamented to me, in the twilight of his career, that the only things he worked on that ever got built were commercial aircraft and a part of the ISS. The status quo wastes money and talent.

So what can be done? Hopefully my pitch is obvious: we should — more often than we think it’s feasible — strive to have (or be) customers, not clients. First, the benefits of this approach, then some thoughts on the how.

I first realized the benefits of customers, not clients, when I started working in commercial aerospace. Instead of supporting a large government program, I was the program manager for an internally funded project. And given the business model, we weren’t even developing an end-item, but a system to gather data for the next link in the value chain.² So I had neither clients nor customers (at least for a while, but that’s another story).

But I did buy a lot of commercial aerospace hardware, as a customer. Most of it was already qualified, had well-defined performance characteristics and interfaces, was sold at a fixed price, and had competition in the marketplace. Yes, there were hiccups along the way, but we had the most problems when we were clients, or did things ourselves.

Being a customer had two other important benefits. First, the commercial products existed in a market with multiple options (not drop-in replacements, but similar enough), so it was possible to switch suppliers when that was beneficial. Second, when we didn’t pay for development, it helped to free us from a sunk cost fallacy that encouraged us to keep using our hardware just because we’d paid so much to develop it.

Ultimately, when we had customer relationship we got better hardware, faster, and at lower cost; it was easier to integrate (since we weren’t the first ones to do it); it was easier to design out later; and it was less expensive to manage.

A few things made it possible. The broader industry trend towards small sats, which I described in Agile Aerospace, is the reason there were any commercial products available at all. But we still had to make a conscious choice to leverage them, take some risk, and make something work with what was available, rather than pay someone to build what would be most optimal.

So how might this scale to the larger programs mentioned above? It’s not easy, but it starts with a conscious and deliberate decision to be a customer, not a client.

• Don’t build bespoke supporting infrastructure. For example, if you build a custom satellite that can’t fly on a commercial rocket, now you’re on the hook for a satellite and a rocket. And you’ll likely be stuck with the rocket’s lifecycle costs too, since the market already supports several commercial launch vehicles, but not the special one you need. If you have to build the product and the supporting infrastructure, consider the possibility that humanity isn’t ready to do the mission at all, yet. Not everything that’s possible should be done, and when things are done out of order they’re not sustainable.

• Think about how to do the mission with an existing product. The NGA using commercial imaging satellites is a great example of this. The product is probably not exactly what they want, or as good as the laws of physics allow, but it’s probably good enough.³

• Realize how much things actually cost. Prototypes should be cheap, and it’s important to stay scrappy when feeling out new markets. But I’m convinced that most people have no idea how much money it takes to deliver commercial products at scale. My favorite example is the Mach 3 razor, which supposedly took seven years and cost $750M to bring to market. I’d love to know how much has been spent developing and producing the iPhone, but given how much revenue the iPhone makes, I assume it’s over a trillion dollars. The point is that there are some things not even the government can afford to develop. If your want is in this category, the only way to succeed is to find a commercial angle so others will bring their capital to bear.

• Avoid cost-plus contracting. There may be no way around in-process payments, so the contractor can manage their cash flow, but don’t pay for hours worked. Pay only for actual progress, and preferably not intangible things like design reviews. Insist on receipt of valuable assets. This eliminates the safety net where the client gets paperwork and the contractor gets paid, but nothing gets built.

• If no existing product can do the mission, and it has to be done, don’t guess at whether what you’re about to develop can be commercialized. Structure the procurement so the customer can use traditional business logic to validate the product’s commercial potential. Public-private partnerships (PPP) are one tool. PPPs are a hybrid approach that still supports custom development, but requires the contractor to invest their own money as well. If properly structured, a PPP will put a contractor financially under water (or at least defer profits) until they sell something on the back end. This eliminates the morale hazard and forces the contractor to think about how they’ll recoup their investment by creating a product with a business case.

• Focus on the goal and not the process. Don’t have all the CDRLs and insight. Capture the minimum number of requirements that explain what you need. If it’s more than a page, stop, go up a level, and try again. Iterate on these requirements with multiple potential vendors until several are willing to work with you. Always buy from at least two, and preferably 3+ providers (if you, plus the commercial market, don’t have that much demand, reconsider everything), because scale is key.

• Take some risk. It’s scary to not have the insight, because we’ve been trained that paper is the best way of ensuring progress is being made. But in the new paradigm, the contractor has money on the table; that’s their incentive to finish and do a good job. Companies fail all the time, so this won’t always work; this is a feature and is why we insisted on multiple suppliers.

• Be willing to iterate. In retrospect, the original iPhone was both revolutionary and garbage.⁴ We can’t accomplish great things without ambition, but don’t try and jump straight to the finish line, as we rarely know where we’ll end when we start.