Earlier this week, I posted a LinkedIn recap of three articles I’d written, each one circling the same conclusion from a different angle. Search Was the Detour argued that search engines were never the destination — just one way of connecting people to information, and AI is simply another interface doing the same job. One Home, Many Windows made the case that every AI system views your organization differently, so no single optimization works everywhere. The Friction Is the Code, Not the Feeling tied it together: the real barrier to AI visibility usually isn’t content quality; it’s structural friction — disconnected data, inconsistent entities, fragmented ownership, governance gaps.
I closed the post with a question:
Any ideas on how we can accelerate awareness and implement change?
That question wasn’t about getting an organization to adopt anything from the three articles, and it definitely wasn’t about picking a standard. It was my shorthand for something I’d been chewing on for weeks: should organizations even be building for machines at all — investing in knowledge graphs, entity models, the infrastructure behind AI understanding — or is that solving the wrong half of the problem? Because whatever the answer, an organization still has to design for two audiences with genuinely different requirements: the human, who needs motivation and emotion to make a decision, and the AI, which needs logic and machine-readable structure to make a recommendation. Those two audiences don’t share a design process or an owner inside most companies today, and I don’t think a one-line LinkedIn question was ever going to carry that.
My friend Warren Lee answered it anyway, and sharpened it in the process. He took what I’d asked and paraphrased it down to the cleanest version of the question I’d been circling: “Should my organization invest in building one at all?” That’s a better sentence than the one I wrote, and it’s exactly the right question — for the moment someone is actually in the room deciding whether to fund the thing. He answered it with what he calls a Capability Lens — four questions he runs any emerging technology through before taking it to leadership:
- What capability does this create,
- Why does it matter,
- What’s the evidence, and
- Can I explain this to an executive without using the word “ontology.” I don’t have much to add to that framework.
I don’t have much to add to that amazing framework. However, what I kept coming back to is that his question, as clean as it is, assumes an organization is already at the table, ready to ask it. In practice, most aren’t. They spin their wheels on semantics before they get anywhere near a funding decision: what do we even call this, whose job is it, is this an SEO thing or an engineering thing, do we wait for a standard to win first. That’s why the piece I actually set out to write isn’t “should we invest.” It’s the one before Warren’s: how do we get unstuck enough to even have that conversation?
How Do We Get Unstuck Enough to Even Have That Conversation?
Before “is this room ready,” there’s a smaller, more embarrassing question: does the room exist at all, and would anyone know to walk into it? Most organizations spin their wheels on semantics before they get anywhere near a needs decision: what do we even call this, whose job is it, is this an SEO thing or an engineering thing, do we wait for a standard to win first. That’s why the article I ment to write isn’t “should we invest or which one to invest in but how do we get organizationally unstuck enough to even have either or those convrsations?
This problem doesn’t sit cleanly on an org chart. It isn’t fully SEO’s, not fully engineering’s, not fully product’s — which means in most companies nobody’s job description includes “notice this and convene the people who’d need to weigh in.” Warren’s four questions, and any readiness check you could run, both quietly assume someone already called the meeting. That assumption is usually the first thing that’s wrong.
So the actual starting move isn’t a readiness test. It’s an inventory of who holds a piece of the answer, whether or not they know it yet — and an honest check on whether they’ve ever actually sat in a room together about it.
Product owns the logic inside things like a selector tool — the reasoning that decides what gets recommended. Engineering owns whether the underlying data can be normalized into anything structured at all. Marketing or SEO usually owns visibility, and is typically the first function to notice the gap — which is exactly why this keeps arriving in meetings framed as “an SEO thing” even when it isn’t only that. Legal or brand owns what the company is actually allowed to publicly claim and substantiate — which matters directly here, because you can’t close “nothing public proves we’re the best at this” without the function that decides what counts as provable.
List out who holds a piece. Then check who’s actually been in the same room about it. The gap between those two lists is the real diagnostic — more useful than anything Warren’s four questions would tell you, because you can’t answer his questions with half the room missing.
Whose job was it to have noticed this in the first place? If the honest answer is “nobody’s — it landed on my desk because I happened to keep writing about it,” that’s worth saying out loud once the room is assembled, because it means there’s no standing mechanism for surfacing a cross-functional question like this one. It only happens when someone crosses a lane on their own initiative. That’s fragile, and it’s worth naming as fragile rather than treating as normal.
And the hardest, most telling test: can you get these people in the same room without a fight over whose problem it is. A functional group can disagree about ownership and still sit down together. A dysfunctional one uses the ownership question as a reason never to meet at all. “Is this an SEO thing or an engineering thing?” stops being the semantics-spinning I described above and becomes the actual test of whether the organization is capable of having this conversation.
Once They’re Actually in the Room
Getting the right people to the table doesn’t guarantee they’re ready to sit with an open question instead of grabbing the nearest concrete task to make the discomfort go away — which is exactly what I watched a dev team do on a call recently, reaching for “let’s just build EntityMap” the moment nobody could hand them a clean answer. So once the room exists, a few blunt checks are worth running before anyone opens Warren’s four questions:
Does anyone in the room actually feel the pain, or does everyone just have the data? A stat about an AI visibility gap moves nobody. A specific, named deal lost because a competitor’s answer showed up and yours didn’t — that moves a room. If nobody can point to a moment like that, the framework gets nodded at and quietly shelved, the same way “AI is the future” got nodded at in every RDFa-era meeting I sat through twenty years ago.
Can this group agree on what to call the problem before anyone proposes a fix? Engineering may call it a delivery-mechanism problem. Marketing may call it a content problem. I called it a data problem. If three functions are quietly solving three different problems under one label, that’s not friction to push through — that’s the actual diagnosis.
Is there an owner, or just interest? Everyone nodding in a meeting is not the same as one person accountable if the answer turns out to be wrong in six months.
Has this organization ever said no to a technology bet before it was fully built, based on evidence instead of sunk cost? I have a story like that — I made RDFa an OKR once, on the strength of a promise that never paid off. The version of that question worth asking your own room isn’t about me. It’s whether your organization has ever killed one of these before it finished. If the honest answer is never, that’s a maturity gap Warren’s framework can’t fix on its own, because his framework assumes someone in the room is actually willing to act on what it finds.
Where This Leaves the Human and the Machine
This is where the human/machine split from the start of this piece actually resolves, and it isn’t where I expected it to land. I’ve spent this whole series arguing that a business has to design for two audiences — a human who needs motivation and emotion to decide, and an AI that needs logic and structure to recommend. What I hadn’t fully clocked until working through this is that the organization deciding whether to build any of it is itself a room full of humans, and it won’t move on Warren’s logic alone either. It needs its own version of the emotional case — someone in the room who’s actually felt the cost of being invisible, not just seen a chart about it.
So the real answer to “how do we get unstuck enough to even have the conversation” isn’t a framework, and it isn’t a test. It’s smaller and more uncomfortable than either: find out who isn’t in the room yet, get them there, and see whether the group that results can sit with “we don’t know yet” instead of picking a task just to feel like it’s moving. Only once that’s true does it make sense to ask Warren’s four questions — or to run the audits I’d use to answer them.
Next: once the right room exists and is willing to sit with the hard question, how do you actually find out what’s broken — the prompts to run, the difference between “we don’t have content” and “we’re not eligible to be cited,” and what it really takes to know whether you could build the thing you’re being pitched. That’s the next piece.
