Research verkaufen, wenn der Kunde morgen Code will

Die meisten Kunden kommen mit einem klaren Bild zu uns. Sie wissen, was sie wollen, denken seit Monaten darüber nach und wollen nächste Woche Code sehen. Verstehe ich. Code fühlt sich nach Fortschritt an, Research nach Verzögerung.

Aber das Teuerste, was man bauen kann, ist das falsche Produkt, gut gebaut.

Das eigentliche Risiko ist das falsche Produkt

Als CB Insights gescheiterte Startups ausgewertet hat, war „kein Bedarf am Markt“ in der Analyse von 2021 der häufigste Grund, genannt von 42 % der Firmen. Die genaue Zahl schwankt zwischen den Ausgaben des Reports, und sie beruht auf dem, was Gründer selbst über ihr Scheitern sagen. Man sollte sie also nicht zu genau nehmen. Das Muster ist trotzdem schwer zu übersehen: Viele Produkte scheitern nicht an schlechtem Code, sondern daran, dass niemand sie so gebraucht hat, wie sie gebaut wurden.

Ein paar Wochen Research garantieren keinen Erfolg. Aber sie finden die großen, offensichtlichen Fehler, solange sie noch billig zu beheben sind.

Was wir vor der ersten Zeile Code machen

„Discovery“ klingt groß. In der Praxis ist es eine kurze Liste:

• Mit den späteren Nutzern reden. Nicht über unsere Idee, sondern über ihren Alltag. Wie lösen sie das Problem heute? Was haben sie schon probiert? Was hat es sie gekostet? Das Buch The Mom Test von Rob Fitzpatrick ist dafür die beste Anleitung, die ich kenne. Frag nach echtem Verhalten in der Vergangenheit, nicht nach Meinungen über die Zukunft. Leute sind höflich und sagen dir sonst einfach, dass deine Idee toll ist.
• Eine grobe Version testen. Klickbare Screens, mehr nicht. Die bekannte Faustregel von Jakob Nielsen: Schon etwa fünf Nutzer decken in einer Testrunde die meisten Usability-Probleme auf. Du brauchst keine große Studie, sondern ein paar ehrliche Sessions, dann verbessern, dann noch mal testen.
• Prüfen, was technisch geht. Gerade bei KI-Features. Kann das Modell das wirklich zuverlässig? Was kostet eine Anfrage? Was passiert, wenn es danebenliegt? Ein Tag Ausprobieren kann einen Monat Bauen auf einer falschen Annahme sparen.

Wie wir es verkaufen

Was sich bei uns geändert hat: Wir nennen es nicht mehr „Research“, sondern behandeln es als ersten Teil der Umsetzung, mit einem klaren Ergebnis:

• eine kurze Liste, was in die erste Version kommt und was nicht
• getestete Screens, nach denen die Entwickler bauen können
• eine Kosten- und Zeitschätzung, der wir selbst vertrauen

Der letzte Punkt ist Kunden am wichtigsten. Eine Schätzung nach der Discovery beruht auf dem, was wir gelernt haben, nicht auf dem, was wir im ersten Call geraten haben. Das heißt weniger Überraschungen und weniger Diskussionen mitten im Projekt.

Wann man es weglassen kann

Nicht jedes Projekt braucht eine große Discovery. Wenn der Kunde schon mit seinen Nutzern gesprochen hat, Daten hat oder etwas neu baut, das bereits funktioniert, halten wir es kurz. Research ist kein Ritual. Es soll das größte Risiko aus dem Weg räumen, und manchmal ist das schon weg.

Aber wenn jemand sagt „wir wissen genau, was die Nutzer wollen“ und noch nie einem von ihnen bei der Nutzung zugeschaut hat, dann brauchen wir sie meistens am dringendsten.