Five Obvious (But Not So Obvious) Truths About Service Design

There's a particular kind of observation that does more damage than a good idea.

Someone says a thing you immediately agree with. There's no argument to be had as it's plainly true. Then you notice that agreeing with it has cost you something. A practice you were proud of. A metric you've been reporting for three years. A category of work you thought was the whole job. These are obvious but not so obvious truths.

Now consider this: Once you realize that being able to speak to an interface means people can use technology without staring at a screen, you stop seeing phones the same way. Nothing about that sentence is controversial. But you can't un-know it, and afterward every glass rectangle in your life looks more like a workaround.

We've spent recent months pulling observations of exactly this shape out of two places: the second edition of Age of Invisible Machines, and the conversations that make up season seven of the Invisible Machines podcast. The test we applied was strict. An observation had to be trivially true the moment it was stated and it also had to invalidate a whole category of activity rather than a tactic. It also had to be irreversible—no nodding along and then doing the same thing.

Here is an uncomfortable but powerful sequence of ideas about service design. Through the lens of these five realizations your intent inverts, your service is invisible to you, your labor is invisible to your budget, your automation is the wrong shape, and your dashboard is lying about all of it.

1. The friction you added is selecting against the people you built it for

Jennifer Pahlka, who spent years inside government technology and wrote Recoding America, puts it with a precision that leaves nowhere to stand:

"You are, by definition, giving the resources to those who need it least …"

She's describing programs that ration by friction—document requirements, verification steps, forms that must be completed in a particular order during business hours. The obvious part is that people with the least capacity to navigate a bureaucracy are the people most likely to need what's at the end of it.

The not-so-obvious part is by definition. Friction isn't a neutral gate that some applicants happen to fail. It's a means test running backwards, and it works with mechanical reliability. Every hurdle you add filters most efficiently against exactly the population the program exists to serve.

For anyone designing a service, whether public or private, this converts a familiar complaint into a structural finding. You are not making a trade-off between access and integrity. You are building a machine that redistributes toward capability. Once you can see the mechanism, you can't design an eligibility flow again without asking which direction it sorts.

Pahlka has the receipts on cost, too. On work requirements in one state, she notes that more was paid to the contractor implementing the verification than was paid out in benefits that year—"welfare for Deloitte." Compute that ratio once and you'll compute it everywhere, and a lot of controls will stop surviving contact.

2. Nobody in your organization can see the service you actually deliver

Marina Nitze was CTO of the Department of Veterans Affairs and now runs a crisis engineering firm. Her diagnosis of why services fail is not that people are careless. It's that the end-to-end path is nobody's job:

"... it was nobody's job ever to look across those silos or to look at that process from end to end …"

Everyone has a role. Everyone performs their role. Everyone's account of their own part is accurate. But the service is broken in a way that no participant can report even in good faith, because in each person's version of the world, their piece is working.

That last clause does the damage. It means every improvement program built on interviewing role-holders is guaranteed to miss the actual cost. Nitze shares a story that should be printed and pinned above every service blueprint. Investigating a call center during the pandemic, her team walked into a large room of empty cubicles containing one man, who was very kind and very confused, because he did not run a call center. The number was routed randomly to employees' desks, all of them working from home at the time and none of them considering themselves as working for a call center.

"... the map—if you had looked at it and boy did we—had a fully staffed call center on it …"

The entire leadership chain had been truthfully reporting a capability that had never existed. This means your authoritative model of your own operation can be unanimously wrong and pass every review. Her remedy is appropriately physical: take the printed map, turn it over, and walk the process with your feet. The artifact has to be destroyed as an input, because as long as it's visible it re-anchors everyone to the fiction.

There's a real warning in here for anyone about to hand their process documentation to an AI system. Feed it the map and you don't automate the service. You industrialize the story the organization tells about the service.

3. Your people are the integration layer, and it doesn't appear in any budget

Age of Invisible Machines cites a study of 20 teams across three Fortune 500 companies, covering 3,200 days of work. The average worker toggled between applications and websites nearly 1,200 times a day. Reorienting after those switches consumed just under four hours a week—around five working weeks a year, roughly 9% of their time.

The obvious reading is that task-switching is wasteful and we should reduce it. The researchers' own framing is sharper, and the book quotes it: a sizable part of people's jobs is to act as the glue between disparate applications.

Not a leak around the job. For a large share of knowledge workers, it is a described portion of the job.

This means the integration layer of your organization has been staffed by humans this entire time—invisibly, and at enormous cost. It never appears on an org chart or a budget line. Nobody approves it. No one owns it. It has no line item. This is precisely why it has never been optimized.

The book's conclusion is that the opportunity is to make the machines the glue instead of the people. But notice what that actually is. It isn't a productivity improvement. It's the elimination of a job function that was never formally created, which is a very different conversation to have with a finance team—and a much better one.

4. You are automating a workflow that was shaped by a constraint that no longer exists

Avi Goldfarb, co-author of Prediction Machines, gave us the cleanest available definition of a point solution on the podcast. You look at an existing workflow, identify the steps a machine could do, remove the humans from those steps, drop the machine in—and then, in the phrase that does all the work:

"... you leave the workflow the same …"

This describes almost every enterprise AI pilot currently running. The trap? The pilot's return is capped by a workflow that was designed for expensive prediction. Measuring the pilot and scaling what worked is structurally incapable of finding the real opportunity. Beyond bad practice it's a category error—the measurement can't see the thing it's being used to look for.

Goldfarb goes further, and this is where it becomes a service design problem rather than an AI one:

"... we don't have to follow our standard operating procedures and just do what's on average best …"

Standard operating procedures are not accumulated wisdom. They are compression artifacts of expensive judgment. What you build when assessing each case individually is unaffordable, so you write a rule that does the best available thing on average and accept the cost at the edges. Goldfarb’s co-author, Joshua Gans, arrived at the same place independently in the preceding episode: rules are what you use when you can't predict the individual case.

Change the price of judgment and the entire procedural layer of the organization is revealed as a workaround. The target isn't the process. It's the policy manual. Process optimization has been aiming one level too low the whole time.

If standard operating procedures are a workaround, then the firms with the most refined procedures aren't the best defended, they are the most exposed.

5. Your metric records your best outcome as a failure

Here’s a short line from Age of Invisible Machines, buried in a chapter on analytics, that quietly invalidates a lot of dashboards: users abandoning an automated experience are sometimes on the golden path, if they left because they already got what they needed.

The fastest possible service—person arrives, gets the correct answer, leaves—is scored identically to total failure in nearly every analytics configuration in production today. Which means your instrumentation is systematically penalizing the experiences you most want more of, and rewarding the ones that keep people in the flow longest.

The book pairs this with a category it recommends tracking that almost nobody does: missing paths—the things users are looking for that the system doesn't handle. Which points at something structural about the medium. A graphical interface cannot express a need it doesn't support; there is no click for the thing that isn't there. A conversational interface logs the request anyway. That makes it a demand sensor, and it means the roadmap can be written by users rather than inferred from research.

Jeff McMillan extends the same logic to the business case on the podcast. This is the version that will get an executive's attention: efficiency, he argues, only exists if the capacity you created got applied to something value-added. If everyone uses their freed-up 30% to play golf, no value has been created at all.

So "hours saved × loaded rate," the model underwriting nearly every AI business case in circulation, is measuring one side of a two-sided equation. You need to know where the capacity came from and where it went. And, as McMillan notes, knowing you created capacity implies you had a baseline for what people were doing before—which most organizations simply don't have.

BONUS: A person will wink, but a model will not

Obvious: of course you have to specify the service. Not obvious: the specification is no longer a slide. It is the service. Feed the granite mission statement to an agent and it will execute the granite. Service design used to describe how a system should behave so humans could compensate. Now it has to describe how the system should actually behave, because nothing in the loop will politely ignore a lie.

On his return visit to Invisible Machines, Seth Godin presses designers to ask: What is it for? Who is it for? To use the vernacular of his newest book The Knot, the pin in most AI knots is a service you have not actually agreed to.

People already know when you’re lying. They hear “we’re here for patients” and translate it to pure profit. AI just believes you. The correction isn’t a better demo, it’s saying the real service out loud—the one with a constituent, a constraint, and a test.

Seth’s question: “If we adopt this constraint, is it going to help our customers get to where they want to go?”

What these truths have in common

Read together, they're less a list than a single argument arriving from five directions: the service you designed and the service you operate are different objects, and most of your instruments are pointed at the first one.

The friction sorts against your intent. The org chart hides the end-to-end path. The budget can't see the integration work. The workflow encodes a constraint that has expired. The dashboard scores your best outcome as a loss. The mission statement lies to an LLM.

None of this requires new technology to identify. It requires being willing to lose a few things you were sure of, which is the entire cost of an obvious but not so obvious truth, and the reason they're worth hunting.

Quotations from Age of Invisible Machines, second edition (Wiley, 2025), and from season seven of the Invisible Machines podcast: Jennifer Pahlka (S7E5), Marina Nitze (S7E7), Avi Goldfarb (S7E4), Joshua Gans (S7E3), and Jeff McMillan (S7E12). Seth Godin’s return visit is S7E18; his first appearance is S1E14.