Hauptgedanke

„Einen Vorfall qualifizieren“, „Kontext wiederfinden, bevor man handelt“, „mehrere Einheiten vergleichen“, „mehrere Personen koordinieren“: So formuliert, benennt ein Kundenbedarf eine Arbeitshandlung und sonst nichts. Er sagt nicht, mit welchem Bildschirm, welchem Feature oder welchem Mechanismus das Produkt darauf antworten soll.

Genau das macht ihn lange nutzbar. Ein Bedarf, der als „einen Vergleichs-Button hinzufügen“ erfasst wird, hat die Lösung schon beim Sammeln festgelegt, und die Spur dessen, was der Kunde eigentlich tun wollte, ist verschwunden — man kann sie nicht mehr aufgreifen, um sich etwas anderes auszudenken. Auf der Ebene der Handlung formuliert, bleibt dieselbe Rückmeldung offen für mehrere Antworten des Produkts, und sie bleibt vergleichbar mit anderen Rückmeldungen, die über andere Anfragen auf dieselbe Handlung zielten.

Diese Ebene übersteht die Zeit auch am besten: Bildschirme ändern sich, Features werden ersetzt, aber einen Vorfall qualifizieren bleibt das, was ein Techniker tut.

Warum das wichtig ist

Das schützt die Discovery vor einer Entscheidung, die zu früh und von der falschen Person getroffen wird. Ein Kunde, der einen Button verlangt, schlägt eine Lösung vor; wer das unverändert erfasst, nimmt seinen Vorschlag in die Feedback-Datenbank auf, als wäre er der Bedarf.

Es schafft außerdem einen Sammelpunkt. Drei scheinbar unzusammenhängende Feature-Anfragen, auf denselben Job zurückgeführt, zeigen eine einzige Handlung, die schlecht unterstützt wird — ein Zusammenhang, der unsichtbar bleibt, solange jede Anfrage unter ihrer Lösung abgelegt ist.

Nuancen und Grenzen

Der Schritt zurück zum Job darf nicht zur systematischen Flucht ins Abstrakte werden: Ein konkretes Ärgernis, das in eine allgemeine fachliche Handlung umformuliert wird, verliert das Detail, mit dem man es hätte beheben können. Die Ebene der Handlung ist eine zusätzliche Ebene, keine, die die anderen schluckt.

Und die Formulierung als Job sagt nichts über Häufigkeit oder Wert aus: Sie sagt, was der Kunde tun will, nicht, wie viele Kunden das wollen.

Offene Fragen

• Wie prüft man, ob ein vom Produktteam formulierter Job dem entspricht, was der Kunde tatsächlich tut, und nicht dem, was man aus seiner Erzählung herausgehört hat?