Zero

The number of people who have chosen this product over the thing already in their hand is zero. How to read your own log honestly, and the difference between failure and absence.

Date

/

Category

Culture

Culture

/

Writer

Keon Hwui Kim

Keon Hwui Kim

The number of people who have chosen this product over the thing already in their hand, even once, is zero.

I have been building it for most of a year. It is deployed. It is, I think, good. And that number has not moved, and I have decided to write it in the same size type as everything else on this site.

Reading your own log honestly

My own world, at the point I last measured it: 715 events. 63 arrivals. 63 lines. 456 touches of the cat. The longest gap between any two arrivals in the product's entire history: 10.4 hours.

There are two ways to write that up.

The deck version

What it actually is

63 sessions

63 times I opened a build to check it

63 items captured

40 of them five characters or fewer. Typing tests

456 interactions with the ambient layer

I was building the ambient layer that week

Daily active use

Never went a full day without opening it, because I was working on it every day

Strong engagement

A build log with a friendly interface

Table 1. Every cell on the left is true. Every cell on the left is misleading.

The left column is not a lie. That is what makes it dangerous. Each of those statements would survive a fact check, and assembled together they describe a product with traction that does not exist.

The distinction that matters most

The temptation is to call this failure. It is not, and the difference is the most useful thing in this piece.

Failure would be: a capture-worthy moment occurred, I thought of the product, and I chose something else. That is evidence against the product. It is the useful negative, because it tells you the incumbent won a fair fight and you can go and ask why.

Absence is: no such moment has been observed to occur and be lost. Which tells you nothing about the product at all.

They look identical in the data. Both are zero. And collapsing them is how a project either kills itself early over nothing, or, far more commonly, reassures itself that the silence means something other than what it means.

So negative evidence has to stay decomposed

Category

What happened

What it means

No moments

Nothing capture-worthy occurred

No evidence either way

Not recalled

A moment happened, the product never came to mind

An access problem

Recalled, not chosen

It came to mind and lost

The useful negative

Chosen, capture failed

Tried to use it, could not

A UX problem

Captured, never useful

Kept it, nothing came of it

A product value problem

Table 2. Five completely different diagnoses. One number.

Each row implies a different action, and three of the five imply doing nothing to the product at all. A team that merges these into "low engagement" will reliably take the wrong action, and will take it energetically, because "low engagement" sounds like something you fix with features.

Why I am not measuring the hinge

The decisive event, whether a moment occurred and whether the product came to mind, leaves no trace anywhere. It exists only inside my head.

No instrument can capture it. I have decided none should be built, because every instrument that could would be a user action created in order to measure a user action, which is the one category of thing this product does not do.

So the honest position is that the most important variable in the project is unmeasurable, and the only available record is a person writing four lines by hand when something real happens: what it was, why, where it would otherwise have gone, and whether it was ever useful afterwards.

That is unsatisfying. I think it is also correct, and I would rather have an unsatisfying true method than a satisfying false one. The satisfying false one is available, cheap, and would produce a chart.

THE ONLY INSTRUMENT

  When a real capture moment happens,
  four lines, by hand, in a notebook:

    1. What was it?
    2. Why did I keep it?
    3. Where would it otherwise have gone?
    4. Was it ever useful afterwards?

  Cost to the product:      nothing
  Effect on the behaviour:  nothing
  Dashboard produced:       none
THE ONLY INSTRUMENT

  When a real capture moment happens,
  four lines, by hand, in a notebook:

    1. What was it?
    2. Why did I keep it?
    3. Where would it otherwise have gone?
    4. Was it ever useful afterwards?

  Cost to the product:      nothing
  Effect on the behaviour:  nothing
  Dashboard produced:       none
THE ONLY INSTRUMENT

  When a real capture moment happens,
  four lines, by hand, in a notebook:

    1. What was it?
    2. Why did I keep it?
    3. Where would it otherwise have gone?
    4. Was it ever useful afterwards?

  Cost to the product:      nothing
  Effect on the behaviour:  nothing
  Dashboard produced:       none

The kill conditions, written before I need them

Kill conditions written after the fact are not kill conditions. They are rationalisations with a timestamp. So these go on the record now, while I still like the product.

K1. With the product on the home screen and in the share sheet, both of which are now genuinely true and were not for most of this year, if nothing is dropped into it for two weeks, that is the strongest evidence this project can produce. The door was open and nobody walked through it.

K2. If a real corpus accumulates through real use and I never once retrieve something I could not have found faster elsewhere, then the central hypothesis is falsified and the product has no job.

Neither is a metric. Each is one honest observation, and its absence over a real interval.

I should note that K1 only became a legitimate condition recently. For most of this year the product could not be installed on a phone at all, which means the door was closed, which means any silence during that period was meaningless. A kill condition evaluated against a broken instrument is worse than no kill condition, because it kills the right thing for the wrong reason.

What the number has actually bought

Holding at zero for this long has had one clear benefit, and it is worth naming because it is the only argument for doing it this way.

Every design decision in the product had to be justified on its own terms rather than by appeal to usage. There was no usage to appeal to. You cannot say "people love this feature" when nobody has used any feature, so every argument had to be about mechanism, evidence, or principle.

That is a slower and much better way to build, and it is only available before you have users. Once there is data, the data becomes the argument, and the data is mostly about the version of the product that happens to exist.

Why publish this

Because the version of this piece that does not exist is the one written eighteen months from now, after the numbers are good, about the journey.

Everyone writes that one. It is retrospectively coherent, every difficulty is resolved by the end, and it teaches almost nothing, because the interesting decisions are all made while the outcome is still unknown and the narrative version has that uncertainty edited out.

The number is zero. I know exactly what would change my mind in either direction, and I have written both down before knowing which way it goes.

If it goes the other way, this post stays up.

Related reading

More from the Moc Mallen Studio journal