Ein Problem braucht genug Häufigkeit oder Folgen, um Aufmerksamkeit zu verdienen

Das Dashboard sieht in der Demo schön aus. In diesem Beispiel entdeckt es einen Formatfehler in einem monatlichen Export. Der Fehler braucht zwei Minuten zur Korrektur und tritt zweimal im Jahr auf. Alle mögen die Demo; nach dem Test öffnet niemand mehr das Dashboard.

Das Problem lässt sich beschreiben. Vielleicht kostet es aber weniger, damit zu leben, als ein weiteres Tool einzuführen. Eleganz erzeugt allein keine Dringlichkeit.

Ein aufgezeichnetes Produktgespräch bietet eine Prüfung mit zwei Achsen: Vorsicht vor einem Problem, das zugleich klein und selten ist. Ein großes Problem kann auch selten Aufmerksamkeit verdienen. Ein kleines, häufiges Problem kann sich zu täglicher Arbeit summieren. Entscheidend ist die Arbeit hinter dem Verkaufsgespräch.

Zähle Vorfälle und Folgen getrennt

„Wie viele Menschen haben das Problem?“ ist als erste Frage zu allgemein. Frage ein bestimmtes Team, wann es zuletzt auftrat und was danach geschah. Verbrachte jemand Minuten damit, ging ein Verkauf verloren, verzögerte sich eine Bestellung, wurden private Daten offengelegt oder war es nur lästig? Diese Folgen sind nicht gleichwertig.

Frage anschließend, wie oft dieselbe Ereignisart auftritt. Eine wöchentliche Korrektur von fünf Minuten kann in einem großen Team viel Zeit kosten. Ein Fehler einmal im Jahr kann wichtig sein, wenn er eine kritische Übertragung verhindert. Eine zweimal jährlich auftretende Zwei-Minuten-Störung lässt sich schwerer als eigenständiges Produkt verkaufen.

Ein Beispiel mit beiden Achsen:

Wie viel Aufmerksamkeit verdient das Problem?

1. Selten und gering

   Funktion oder manuelle Checkliste

   Ein neues Produkt kann mehr Aufmerksamkeit kosten als das Problem.

2. Selten, aber teuer

   Schutzmaßnahme oder Vorfallprozess

   Jeder Vorfall kann Vorbereitung rechtfertigen.

3. Häufig, aber gering

   Standardregel oder kleine Gewohnheit

   Kosten summieren sich durch Wiederholung.

4. Häufig und teuer

   Eigener Ablauf

   Wiederkehrende Folgen können laufende Investition rechtfertigen.

Die Felder sind Fragen für die Untersuchung, keine Markturteile. „Hoch“ hängt davon ab, wessen Kosten zählen. Ein Fehler, der für Administrator:innen kaum Folgen hat, kann Kund:innen schwer treffen. Ein Problem, das in einem kurzen Interview nicht vorkam, kann zur Saisonspitze zentral sein.

Ein Problem kann in der Demo klein und im System groß sein

Bei Integrationen wird die Unterscheidung konkret. Ein falscher Feldwert sieht bei einem Kontakt klein aus. Wird dieselbe Zuordnung auf Tausende Kontakte angewendet, entsteht wiederkehrende Handarbeit. Ein ausgefeilter Alarm für eine einmalige kosmetische Abweichung kann dagegen mehr Verwaltung schaffen, als er spart.

Der Leitfaden zur Integration von Business-Tools beginnt bei Ablauf und maßgeblicher Quelle, weil die echten Kosten davon abhängen, wie Datensätze wandern und genutzt werden. Ein Team, das den Wechsel von kostenlosen Tools erwägt, sollte ebenfalls Umwege und verpasste Aktionen zählen, statt nur Funktionslisten zu vergleichen.

Frage nach den letzten drei echten Vorfällen. Notiere jeweils, wer ihn bemerkte, wer ihn behob, welche Arbeit stehen blieb und was ohne Eingriff passiert wäre. Die letzte Frage trennt eine Störung von einem unsichtbaren Risiko. Sie verhindert auch, dass Gründer:innen oder Käufer:innen einen eindrucksvollen hypothetischen Fall als gemessenes Muster ausgeben.

Frage dann nach den Kosten des heutigen Umwegs. Eine Tabelle und eine Fünf-Minuten-Kontrolle können ausreichen. Ein manueller Prozess, der jeden Morgen eine Fachperson für den Abgleich bindet, vielleicht nicht. Die Alternative gehört zur Wertrechnung des Produkts; sie sollte nicht übergangen werden.

Prüfe auch die Einführungskosten

Selbst ein wichtiges Problem rechtfertigt nicht immer eine neue Anwendung. Jemand muss sie anbinden, erlernen, ihre Ausgaben prüfen und den Zugriff pflegen. Kostet das Produkt mehr Aufmerksamkeit als die Aufgabe, können Käufer:innen vernünftig beim bisherigen Weg bleiben.

Das Quellgespräch warnt außerdem: Viel Hilfe bei der Einrichtung kann frühes Interesse größer erscheinen lassen, als es ist. Ein Team wirkt wie ein Softwarekunde, nutzt aber in Wahrheit nicht eingepreiste Beratung. Ein kleines Problem mit teurer Einführung ist besonders schwer dauerhaft zu bedienen. Beratung ist deshalb nicht verboten; sie muss nur mitgezählt werden.

Es gibt Ausnahmen von der Prüfung mit zwei Achsen. Gesetzliche Pflichten können Handeln verlangen, obwohl beobachtete Vorfälle selten sind. In einem neuen Markt fehlen möglicherweise historische Daten. Eine kleine Zielgruppe kann ein ausreichend schmerzhaftes Problem haben, auch wenn die breite Masse es nicht kennt. Dann sollten Pflichten, glaubwürdige Fehlerwege oder verbindliche Budgets den Beleg liefern, nicht allein eine Häufigkeitsschätzung.

Die Achsen helfen auch zu entscheiden, ob ein Bedarf ein eigenes Produkt oder eine kleine Funktion in einem bereits genutzten Tool verdient. Ein seltener Formatfehler kann einen nützlichen Knopf im Exportablauf rechtfertigen, selbst wenn niemand dafür ein separates Abo abschließt. Ein kleines, häufiges Problem lässt sich womöglich besser durch eine andere Standardeinstellung lösen als durch ein neues Dashboard. Der Produktumfang sollte zur Aufmerksamkeit passen, die die Aufgabe ohnehin bekommt. Die Frage ist nicht, ob das Problem existiert, sondern wie viel neues Verhalten seine Lösung verlangen darf.

Die produktive Recherchefrage lautet nicht „Würdest du das nutzen?“, sondern „Wann ist das zuletzt passiert, was kostete es und was hast du stattdessen getan?“ Ein Produkt verdient seinen Platz, wenn die Antwort auf Arbeit zeigt, die Menschen bereits verändern wollen.