The Ten-Year Test
Four questions I run before taking a technology trend seriously. Most things pass the first one and fail the second.
Every year some technology becomes mandatory to have an opinion about. I sell technology for a living, so I can’t opt out — but I can be slow on purpose. Before I take a trend seriously I run four questions: is the problem it solves real today; does the problem grow over ten years; who owns it when it breaks; and if it fully succeeds, what happens to the people who adopted it. Almost everything passes the first. The second quietly kills most of the rest — a lot of trends solve a real problem that is already shrinking.
I have a professional obligation to trends. When something new gets loud, my clients ask about it within the month, and “I haven’t looked into it” is not an answer I’m allowed to give. So I’ve had to build a filter — something faster than expertise, but sturdier than a hot take.
The filter is four questions, asked in order, and the order matters. Each one is cheaper to answer than the next, and each failure is a full stop. Most things never make it past the second question, which saves me a remarkable amount of reading.
A trend is a claim about the future. A technology is a claim about a problem.
Question one: is the problem real today?
Not “could this matter” — does somebody, right now, have this problem badly enough that they’ve built an ugly workaround for it? Workarounds are the tell. A spreadsheet doing a database’s job, a person doing a system’s job, a weekly meeting doing an API’s job. If nobody has bothered to build a workaround, the pain isn’t real yet, whatever the conference keynotes say. Almost everything passes this one. Serious teams don’t usually build products around imaginary problems; they build them around small ones.
Question two: does the problem grow for ten years?
This is the killer, and it’s where most trends die in my notebook. A real problem that is already shrinking is a trap: you can build a working product, win real customers, produce genuine case studies — all while the ground shrinks underneath everyone involved.1
The question to ask is what the problem depends on. If it depends on a limitation — of hardware, of bandwidth, of some other technology’s immaturity — then the problem has an expiry date, because limitations attract engineers the way honey attracts everything. If it depends on something durable — human attention, coordination between organizations, regulation, trust — it tends to grow. Ten years is the honest horizon: long enough that the current hype cycle can’t carry a bad answer, short enough that “everything changes eventually” doesn’t excuse one.
Question three: who owns it when it breaks?
By now the trend has a real, growing problem behind it. This question asks whether it can survive contact with an actual organization. When the thing fails at 2 a.m. — and it will — is there a named human whose job is to fix it, or does the failure fall into the gap between a vendor’s SLA, an integrator’s contract, and an internal team that never asked for it? Technologies that create unowned failure don’t get adopted; they get piloted forever. This is the question executives are secretly asking in every meeting, whatever words they use, and it’s the one most pitches can’t answer.
Question four: what does total success cost the adopter?
The last question is the strangest, and I only ask it of things that pass the first three: imagine the technology wins completely. Everyone has it. Now what did the early adopters actually buy? If the answer is a durable capability — their people understand something, their data is somewhere useful, their processes got simpler — the adoption was real. If the answer is that they paid to be a beta tester for a capability everyone now gets by default, they bought a subscription to being early, which is a hobby, not a strategy. Some trends fail this question even in their best case. Those I recommend watching from a comfortable distance.
The test, compact
Look for the ugly workaround. No workaround, no problem — not yet.
Problems built on limitations expire. Problems built on people don’t. This kills most trends.
Unowned failure means permanent pilot. Someone specific must hold the 2 a.m. pager.
If winning leaves adopters with nothing durable, being early was the product.
Being slow about trends isn’t the same as being skeptical of technology. It’s the opposite: taking a technology seriously means asking it serious questions, and serious questions take longer than a news cycle.
The test has made me late to a few real things — I’ll admit that when it happens, in a revision, on this page. So far it has mostly made me early to saying no, which is its own kind of useful.