Some of what you know should be built, not published

There is a diagnostic on this site. There is a workbook, a brief generator and an agent that turns customer interviews into reusable evidence.

None of them are content. They came out of the same research that produced the articles around them, and I filed them under “experiments” because that was the honest word at the time. Looking at them together now, they have something in common that the label misses. They are all things somebody uses, built out of things I knew.

I didn’t set out to create a category. It only became visible in hindsight, which is usually the sign that something structural has been happening while you were busy with the work.

Editorial work has a default endpoint, and the default is content.

That isn’t a failure of imagination. It’s what editorial teams have been asked for, more or less continuously, for as long as the job has existed. Knowledge goes in, an argument gets formed, and something readable comes out. Article, report, campaign, deck. The chain is so well established that the last link stops looking like a choice.

The chain usually runs:

knowledge → judgement → narrative → content

Most of that is load-bearing. Developing the knowledge is real work. Deciding what matters is real work. Forming the argument is real work. But the final step is a convention, and conventions are worth examining when the conditions that produced them change.

A wider version of the same chain would be:

knowledge → judgement → useful output

The question shifts with it. Not what content can we create from what we know but what could we build from what we know — which is a different question with a different set of answers, most of which never get raised in an editorial planning meeting.

The Hidden Hours research is the clearest example I have, because it went both ways.

It began as research into the operational pressures facing accounting and bookkeeping firms — where unbilled work accumulates, why it stays invisible, what it costs. That produced a narrative and a cluster of articles, which is exactly what you would expect. Research goes in, argument comes out, publishing follows.

But the same research also produced a diagnostic: a tool that asks a firm about its own situation and tells it where its hidden hours are likely sitting. The article explains the pattern. The diagnostic tells you whether the pattern is yours.

Those two outputs share everything upstream. The same interviews, the same evidence, the same judgement about what the evidence meant. They only diverge at the point where the form gets chosen, which is much later than editorial planning usually assumes. In practice the format is picked at the brief, long before anyone knows what the evidence will support.

Two routes out of the same work, then:

knowledge → narrative → communication

knowledge → interaction → utility

The first is the one editorial teams are staffed and budgeted for. The second was, until recently, a different department’s problem.

What changed is the cost of the second route.

I’ve written before that AI didn’t create Editorial Intelligence so much as make it economically viable — it lowered the cost of connecting evidence into a coherent argument, which changed who the work was worth doing for. The same thing has now happened one step further downstream. Someone who understands the knowledge, the user and the editorial logic can get to a working prototype without commissioning a build.

That is a genuine change and I don’t want to undersell it. The gap between I think this research should be a tool and here is the tool, try it used to be a budget conversation. Now it can be an afternoon.

I also don’t want to oversell it, because there’s a version of this argument that ends somewhere silly. Prototyping is not engineering. A prototype that survives contact with real users needs the things prototypes don’t have — reliability, security, sensible data handling, accessibility, someone to maintain it. The failure I’d watch for is a prototype quietly accruing real users and real obligations because nobody drew the line between the thing that proved the idea and the thing people now depend on. Cheap to build is not the same as free to own.

Here’s the part I think actually matters.

When building was expensive, expense did the filtering. You couldn’t build a diagnostic on a whim, so the ones that got built had usually survived somebody’s business case. The constraint was doing a job nobody had to think about.

Remove the constraint and the filtering has to come from somewhere else. Otherwise you get what cheap production always gives you — more things, most of them not worth having. We have watched this happen to content over the last three years. There’s no reason to expect tools to be different, and some reason to expect worse, because a bad tool wastes its user’s time rather than just failing to hold their attention.

So the interesting capability isn’t building. Building is getting handled. The interesting capability is judgement about what deserves to be built:

which knowledge is solid enough to put weight on
which audience problem is worth solving
what can be simplified without becoming untrue
what form would make the knowledge most useful — and whether that form is a tool at all

Those are editorial judgements. They are the same ones editorial work already makes about articles, pointed at a different output. A diagnostic with arbitrary scoring, a knowledge base with nothing in it worth finding, an assistant reasoning from general knowledge rather than the organisation’s own evidence — these fail for editorial reasons, not technical ones. The build was fine. The thinking underneath it wasn’t there.

Which brings me to what I can’t yet demonstrate.

I can show that this route produces things. The diagnostic exists, the workbook exists, the agent exists, and they came out of editorial work rather than a product roadmap. That much is on the site and you can go and look at it.

What I can’t show yet is the harder claim: that the editorial judgement made them better than what would have been built by starting from the format and working backwards. That comparison hasn’t been run. It’s the difference between “this got built” and “this was the right thing to build,” and only the first has evidence behind it.

There’s a sharper test, and I’d rather name it than leave it implied. If this is a discipline, it has to be able to say no. It has to look at a body of knowledge, consider whether it should become a tool, and conclude that it shouldn’t — that it’s an article, and an article is the right answer. A method that finds product opportunities everywhere it looks isn’t exercising judgement. It’s just enthusiasm with a framework attached.

I don’t have that case documented yet. Until I do, this is a working hypothesis and I’ll keep describing it as one:

Organisations may be sitting on knowledge that shouldn’t only become content. Some of it should become products. The useful discipline is knowing which is which.

That’s the bit I’m testing. Not whether knowledge can be built into something useful — the site already answers that. Whether editorial judgement is reliably good at telling which knowledge deserves it.