The Phantom Stakeholder: Why You’re Building for Someone Who Doesn’t Exist

Somchai’s face had already settled into that particular expression — the one where someone has stopped listening but their body hasn’t caught up yet. It was 2 PM on a Wednesday, and across the table a junior engineer was explaining, with the weary patience of someone who’d given this speech before, why their deployment process required a printed form signed by two separate teams. The air conditioning hummed. Someone’s Teams notification chimed three rooms away. “It’s because of Security,” the engineer said, in the same tone you’d use to describe gravity or the weather — not as something anyone decided, but as something that simply was.

That sentence — “It’s because of Security” — had been doing the heavy lifting for an entire department. And nobody had thought to check whether Security had ever actually asked for any of it.

The Unquestionable Authority

As John F. Kennedy once observed, “The great enemy of the truth is very often not the lie — deliberate, contrived, and dishonest — but the myth, persistent, persuasive, and unrealistic.” He was talking about politics, but he could have been describing your average requirements discussion.

Here’s the pattern. You’re in a refinement session. Someone proposes a simpler approach. Someone else shuts it down with three magic words: “Legal needs this.” Or “Compliance requires that.” Or the perennial favourite, “The enterprise customers expect it.” The conversation stops. Nobody pushes back. Because who’s going to argue with Legal? Who’s going to risk being the person who said we don’t need to be compliant?

These are what I call phantom stakeholders — requirements attributed to people who never actually asked for them, invoked as argument-enders by people who may genuinely believe what they’re saying. The phantom stakeholder isn’t a person. It’s a label. A shield. A way of making a requirement unfalsifiable by attaching it to an authority nobody wants to question.

And it’s costing you more than you think.

The Sam Story

When I first arrived at this company, I walked into a wall of red tape. I don’t handle red tape well — it makes my blood pressure do things my doctor wouldn’t approve of. I’m wired to get things done, and being blocked without a clear reason is the professional equivalent of someone standing in a doorway and refusing to move.

This particular wall involved deployment. My engineers had to print out a form — an actual physical form — and get it signed by two different teams before they could deploy code to production. With actual paper. It’s not 1999. Vanilla Ice hasn’t had a hit in years. We’ve mapped the human genome. And yet here we were, physically printing deployment approvals like we were running a fax-based startup.

Every time I asked why, I got the same answer: “Security.” Not a person. Not a team with a name and a Slack channel. Just… “Security.” This faceless, all-powerful entity that had apparently decreed that trees must die so that our code could reach production.

So I started asking: who is Security? Where do they sit? Can I talk to them? People looked at me like I’d suggested we go question the weather. But I kept pushing, because that’s what you do when something doesn’t make sense — you trace it back to the source.

Turns out “Security” was a team of two people. I found them. I found Sam.

I’ll be honest — I walked up to Sam with my verbal sleeves rolled up, ready for a fight. But I kept it polite. I explained the situation: we have Pull Request history, we have deployment tooling with full audit trails, we don’t need paper forms. Sam listened. He asked a few sharp questions about data immutability and audit trail integrity. I answered them. And then he said something that nearly knocked me over:

“Yeah, that sounds fine. Let’s stop using the paper forms. I never liked them anyway — I always thought it was backwards.”

Sam wasn’t the villain. Sam was a reasonable person who’d never been consulted about the process that bore his team’s name. Our engineers had built this entire painful workflow because of “Security” — this phantom in the background who turned out to be a friendly bloke named Sam who agreed with us the moment someone actually bothered to talk to him.

The Folklore Machine

Here’s the critical insight: this almost never starts as a lie. Nobody sat in a room and decided to fabricate a requirement and pin it on Legal. What actually happens is more like a game of telephone played over months and years.

Someone from Security, at some point in the past, probably mentioned something about needing an audit trail. That comment got interpreted by an engineer on a different team. Their interpretation became a process. The process got documented. New joiners learned the process without questioning it. And every time someone did question it, they got the conversation-stopper: “It’s because of Security.”

The phantom stakeholder is more folklore than fraud.

As Field Marshal William Slim put it, “When you cannot make up your mind which of two evenly balanced courses of action you should take — choose the bolder.” But in most organisations, when someone invokes Security or Legal or Compliance, we consistently choose the more cautious path — not because we’ve evaluated it, but because the label itself makes the bolder path feel irresponsible. We’re not making a decision. We’re deferring to a ghost.

It’s Not Just PMs

Now, I want to be clear about something: this isn’t a post about catching Product Managers in lies. In my experience, PMs are actually among the least likely to invoke phantom stakeholders — at least the good ones, and I’ve been fortunate to work with a lot of good ones.

The most common source? Engineers working cross-team.

Here’s how it plays out. Team A implemented something years ago. At the time, someone from Security gave some guidance, and Team A interpreted that guidance in their own way — reasonably, given what they knew. That interpretation became baked into their architecture. Fast forward two years: Team B questions a decision in Team A’s service. Rather than explaining the full history and opening themselves up to debate, someone on Team A says, “It’s because of Security.” Conversation over.

It’s not malicious. It’s efficient. But “efficient” and “correct” aren’t the same thing, and that shorthand has a cost. The original interpretation might have been reasonable then but outdated now. Security’s actual requirements might have evolved. The technology landscape might have changed enough to make the constraint irrelevant.

The same pattern plays out with “Legal” and “Compliance” and every other institutional authority. We take a secondhand interpretation, strip away its context, and present it as gospel.

Smoking Out the Phantom

So how do you build a culture where these attributions get respectfully but routinely verified? Not through suspicion — through simple good practice.

Ask for the artifact, not the summary. “Can you share the email or Slack thread where Legal requested this?” This isn’t adversarial. Frame it as wanting to understand the context so you can build the right thing, not as an accusation. Real requirements leave a paper trail. Phantom ones evaporate the moment you ask for the source.

Separate the need from the solution. Someone says “Legal needs an audit log of every field change.” Maybe what Legal actually said was “we need to be able to demonstrate compliance during an audit.” Those are wildly different requirements with wildly different engineering costs. The phantom version is almost always someone’s solution dressed up as someone else’s requirement. This is where the Five Whys earn their keep — keep asking until you get to the actual need, not the interpreted solution layered on top of it.

Invite the stakeholder into the room. This is the move that feels aggressive but is actually just good process. “This sounds important — should we get someone from Legal into the next refinement so we nail the requirements?” If the person who invoked the stakeholder resists this, that tells you something. And when the stakeholder does show up, you almost always get a simpler, more flexible requirement than what was being relayed. I’ve had countless interactions with security and compliance teams, and the overwhelming majority of the time, they’re just trying to be helpful. They’ve analysed our engineering process and come up with proposals about how they think we should change. The right move is to collaborate with the engineers — the ones who own the process — and ask how to integrate those requirements into it.

Track the pattern, not the instance. One phantom reference is nothing. Everyone shorthand occasionally. But if the same person consistently invokes unnamed authorities to shut down technical pushback, that’s a pattern worth a quiet conversation. Not “you’re making things up” — more like “I’ve noticed we’re often building based on secondhand requirements, and I want to make sure we’re not over-engineering.”

Create a requirements provenance norm. In your refinement template or spec document, add a field: “Requested by / Source.” It’s lightweight, it’s not accusatory, and it makes phantom stakeholders structurally harder to invoke. When every requirement needs a name attached, people stop attributing things to ghosts.

The Customer Wants

While we’re at it, let’s briefly touch on the other phantom that haunts engineering teams outside of product engineering: “The customer wants.”

Henry Ford reportedly said, “If I had asked people what they wanted, they would have said faster horses.” And Steve Jobs put it more bluntly: “People don’t know what they want until you show it to them… Our task is to read things that are not yet on the page.” Both were making the same point — customers don’t have solutions, they have problems.

I’ll save the full version for another post, but here’s the short version: in product engineering, we’ve largely solved this one. We believe that customers don’t always know what they want. They have problems that need solving. Our job is to understand the customer’s problem first, then come up with a solution. We drive this with data — analytics tell us about customer behaviour, and sometimes that data tells us more than the customer does, because people don’t always understand their own behaviour until they’re faced with new options.

So when someone in my teams says “the customer wants X,” people look confused. Not because we don’t care about customers — we care deeply. But because we’ve trained ourselves to hear that phrase for what it is — the same conversation-closer as “Legal needs.” Outside of product engineering, though, teams haven’t built that muscle. “The customer wants” still gets treated as gospel, shutting down the very exploration that would lead to a better solution. The question isn’t what the customer wants. The question is what problem the customer has, and whether X is actually the best way to solve it. Ford didn’t build a faster horse. Jobs didn’t build a better Walkman. They understood the problem behind the request.

The Real Cost

The phantom stakeholder doesn’t just create unnecessary work. It creates invisible unnecessary work — the kind that never shows up in retrospectives because everyone believes the work was genuinely required. You can’t optimise what you can’t see, and you can’t see a requirement that everyone believes is legitimate.

Worse, it erodes trust. When engineers discover that “Security required this” actually meant “someone on another team assumed Security would want this five years ago,” they start questioning everything. And a team that questions every requirement is almost as dysfunctional as a team that questions none of them.

The physicist Richard Feynman had a useful principle here: “The first principle is that you must not fool yourself — and you are the easiest person to fool.” The phantom stakeholder works so well precisely because we fool ourselves first. We believe that Legal needs the thing. We believe the customer wants it. The myth is more comfortable than the uncertainty of actually checking.

The Bottom Line

Phantom stakeholders aren’t villains. They’re an emergent property of organisations where people are busy, communication is imperfect, and “I don’t know why, but someone important needed it” is a faster answer than “let me trace this back to the original requirement and verify it still applies.” And in agile teams where “moving fast” is the unspoken religion, the fastest answer almost always wins — even when it’s wrong. Nobody gets praised in a stand-up for saying “I spent yesterday tracing a requirement back to its source and it turns out we don’t need it.” But they should.

The fix isn’t suspicion. It’s curiosity. It’s building a culture where “who specifically asked for this?” is a normal question, not an act of rebellion. Where tracing a requirement back to its source is as routine as writing a test. Where invoking an authority without evidence is gently, consistently challenged — not because we don’t trust each other, but because we’ve all seen what happens when we trust folklore over facts.

The next time someone tells you “Security needs this,” don’t roll your eyes. Don’t assume they’re wrong. Just ask one simple question: “Have we talked to them?”

You might find your own Sam.

Now, if you’ll excuse me, I need to go remove a three-year-old approval workflow that nobody remembers requesting. Apparently it was because of “Compliance.” I’m going to go find out if Compliance agrees.