Main idea

A customer interview doesn't become usable by becoming a card. It becomes usable when it is transcribed, broken down into themes, linked to the pains expressed, to the customer's stakes, to the product's stakes, to existing features and to missing ones, cross-referenced with other interviews, then verified against the product data. All of that work bears on relations; a list, by construction, knows only items and their order.

That is why the phrase "discovery backlog" names a bad container rather than a bad practice. Discovery handles rich material that has to be compared, connected, cross-referenced, rephrased and synthesized. What discovery produces can obviously end up as a card — but only at the end, once a result is mature enough for structured collaboration.

Why it matters

This gives a criterion for choosing a container: before asking whether the tool has the right fields, look at whether the material's value lies in its items or in their links. That answer alone decides the form.

It also explains why an interview poured straight into tickets gets lost: each card survives, but the structure that connected them was never written down anywhere.

Nuances and limits

A list can approximate relations through tags, links between cards, or epics. The cost of maintaining those links grows faster than their number, and they are the first to give way.

And not all material is relational: an execution queue — fix, ship, verify — is correctly described by an ordered list.

Open questions

• At what point is a discovery result stable enough to lose its relations without losing its meaning?