Who asked for this AI feature — a customer, you, or the board?

The question that sorts AI features is not "does anyone need this". It is "who asked for it".

There are three honest answers. A customer is pushing on the door. You are pushing from the inside. Or the board asked — sometimes because the money behind the board asked first. The version of that question in circulation has only the first two branches: is the customer demanding agents, or are you pushing this internally, where the honest answer is usually the second. The third branch predicts a specific ending: the thing ships, the board sees it, nobody opens it again.

Then two numbers, both set before the release rather than after it: how many people saw the feature, and how many used it. Our read is that those two counts say more about the fate of a feature than any brief does — and they cost almost nothing to instrument while the brief is still being written.

The number that says this is common

An enterprise survey reports that 97% of executives deployed AI agents in the past year and 52% of employees actively use them. The adoption playbook that collects those figures calls the 45-point gap a product problem rather than a training-budget problem.

The same playbook breaks down one feature at launch: 127 people saw the new tab, 4 used it — 3% on launch day.

Its tell is the part worth memorizing: when it goes wrong, nobody says "the model is wrong". They say "nobody uses it", and then they ask for more model quality — the one lever that will not move that number.

What the third branch does to a brief

The logical core of a founder's account in a video that has been going around, in our words: investors tell a founder they will write a check immediately if that founder starts an AI company, and say plainly that what the AI actually does is not the point — investors who, eighteen months earlier, did not invest in AI at all. The result has a name: a governance vacuum — no named owner, no success metric, no kill criteria.

In our experience that is not a moral failure, and treating it as one is how you lose the conversation. Our position: if the real deliverable is a defensible board narrative, then the measurement is the deliverable, and the cheapest honest version of the feature is the right one to build.

The same qualifying question carries a second distinction, and it changes the size of the job more than any estimate does. Improving a feature inside work the customer has already bought has an existing success metric to move. Changing what you sell is a new product with new buyers — and that one tends to get ordered by accident.

We ran the question on ourselves

No customer asked for it. In Kindling, our writing product, the feed of writing prompts was the queue itself — one line of code:

feed = visible.slice(0, refillTo)

skip -> 7 -> 6 -> 5 -> crosses the refill floor -> buys new material
                                                   from a paid search API

So the gesture the author repeats most — skipping a card — was quietly buying inventory. That is the "who asked" answer. Here is the "who used it" answer, read off the live rows:

prompts skipped      67
prompts expired      59
still pending        11   <- cleared a refill floor of 10
newest of those      three weeks old
genuinely fresh       1

Eleven pending prompts cleared a floor of ten, so the system believed it was stocked. One of them was worth showing. The feature was not being rejected and it was not broken — it was being skipped, and every skip added cost.

Then we rewrote it:

before                            after
-----------------------------     --------------------------------------------
feed = the queue                  feed = a window onto a pool
7 on screen                       7 on screen, 3 anchors that never rotate
pool = whatever is left           pool target 24
floor of 10, any item counts      floor of 10, counted in FRESH items only
no staleness rule                 staleDays = 14
paid refills: hourly ceiling 30   paid refills: 3 a day
                                  (30/hour allowed 120 searches from one
                                   day of swiping)

38 new tests. 1,648 green at dc5f30c, 1,656 at d30e94a.

When the daily cap is spent, the feed now rotates the pool it has and says so, instead of being quietly shorter than it was an hour ago.

When the decision actually happens

The adoption playbook is blunt about timing: the decisions that most affect adoption are made 6 to 8 weeks before launch. Not at launch, and not in the retro. By the time usage is disappointing, the levers that move it have already been pulled.

What we put in that window is ours rather than a finding — six lines at the top of a brief:

1. Who asked?            customer / us / the board
2. Which job is this?    an improvement inside work already bought (metric exists)
                         or a change of positioning (new product, new buyers)
3. Owner after delivery: ____________________
4. Success metric:       ____________________
5. Kill criteria:        ____________________
6. Instrumented before release:  how many saw it  /  how many used it

Lines 3 to 5 are the governance vacuum, written as blanks. If you cannot fill them in, the answer to line 1 was probably the board.

FAQ

Is "the board asked for it" a bad reason to build? No, and this is our opinion rather than a finding: it is a real constraint with a real deadline. It is only dangerous unsaid, because an unsaid reason arrives without an owner, a metric or a stopping rule. Said out loud, it usually shrinks the scope to something defensible.

We already launched. Is it too late to get the two numbers? No. They are counts, not analytics infrastructure — the 127-saw / 4-used breakdown in that playbook is one launch day and two numbers. What you lose by measuring late is the 6-to-8-week window where the decisions that move adoption are still open.

Isn't low usage a training problem? The playbook reading the 97%/52% split calls the 45-point gap a product problem, not a training-budget problem. Its tell, again: the request that follows "nobody uses it" is almost always for more model quality, and that lever does not move usage.

What would change our mind? A board-ordered feature whose seen/used ratio looks like a customer-pulled one. If origin does not predict the ratio, the question is the wrong question and the two numbers are the only thing worth keeping.

Why measure skips at all — isn't a skip just a no? In our case a skip was a purchase. Trace what your most repeated gesture triggers before you decide it is free.

A related case

Kindling is the product the rewrite above shipped in: two polarized takes as a nudge, you react in your own language, it carries your intonation into English — and it now refuses to charge you for looking. It is live at kindling.iloblique.com.

The short version of this argument, for a founder with one minute rather than ten: {{anchor_url}}

If you have something worth building, we'd like to hear about it.