How we decide a product doesn't deserve to exist.
We publish professional digital products. The question we get — and asked ourselves first — is simple: why buy a kit when you can ask an AI? Our answer lies less in what we produce than in what we refuse to produce. Internal case: our own catalogue, not a client engagement.
The problem
A catalogue of files becomes interchangeable.
A generic guide loses its value in one query. Producing fast creates duplicates, vague promises and incomplete files. And without governance, sources go stale: a product that works for six months and then misleads. We audited our own range and made the call: stop building a catalogue of files, and start building a system of living products — sharing a common architecture of evidence, decision, data and updates.
Our doctrine
What an AI query doesn't hand you.
We set out value criteria. A product only deserves to exist if it delivers what generated text doesn't. This isn't product versus AI — we use AI ourselves, and this page doesn't pretend otherwise — it's designing what AI doesn't cover.
- Structured data — not prose: filled-in grids, matrices and reference frameworks.
- Deterministic calculations — rules, thresholds and scores that produce a testable result, kept separate from any generative output.
- Evidence — dated sources, an owner, a stated scope, a validity period.
- Controls — built-in checks, and human validation with defined roles and exceptions.
- Maintenance — the product follows regulation and practice. A query doesn't.
The method
Gates, before the first line of code.
Every product passes a series of checks before it gets built — quality and economics come before development. Some of the most discriminating:
- Is the problem critical? Converging interviews and a cost of inaction, or we stop.
- Is there a buyer and a budget? An enthusiastic user without a sponsor isn't enough.
- Does it lead to a decision? If it only produces content or a checklist, it doesn't deserve to exist.
- Does it hold up against AI? A measured gap against a generic answer. Below the threshold, we rework it or drop it.
- Does it reuse what exists? Isolated creation is refused: a product must build on components already proven.
- Is maintenance funded? Sources, owner, cadence, service commitment. A vague promise to update is grounds to stop.
- Are there two paying pilots? Verbal interest isn't market evidence.
- When do we kill it? Every product has a stop date and criterion agreed upfront.
Deliverables: value criteria, packaging architecture, product structure (a ZIP with README, the tool, a usage guide and a sample report), QA checklist, maintenance policy (monitoring, versioning, criticality, cycles, retirement) and changelog.
What it proves
The capability is transferable.
You probably don't publish a digital catalogue. But the question is yours: what in your offering holds up against automation — and what doesn't deserve to? We apply to our own range the method we bring in the Business Solutions Studio: arbitrate, structure, control, maintain, and know when to stop. It's the same work.
Scope and honesty
What this case is — and isn't
This case describes our own catalogue, not a client engagement — we say so rather than dress it up. It carries no sales figures, no pricing, no projections, no detailed roadmap. The distribution channel is being built: we don't present it as operational until it is.
An offering to protect from automation?
It takes one short conversation to frame: what holds up in your offering — and what doesn't deserve to.