KI-generierte Funktionen auf ein stimmiges Produkt prüfen

Bei der Produktprüfung KI-generierter Funktionen geht es um vier Fragen: Löst die Änderung ein echtes Kundenproblem? Ist ihr Umfang klar begrenzt? Funktioniert der gesamte Ablauf für die Kunden? Und ist jemand dafür verantwortlich, das Ergebnis zu überprüfen? Die technische Prüfung bleibt notwendig. Diese Fragen helfen Ihnen, vor der Veröffentlichung zu entscheiden, ob die Änderung in Ihr Produkt passt.

Ein Agent kann eine überzeugende Demo erstellen, bevor Sie diese Entscheidung getroffen haben. Sie können die neue Schaltfläche anklicken, die Implementierung prüfen und die Tests abnehmen. Trotzdem fügen Sie womöglich nur einen zweiten Weg für eine vorhandene Aufgabe hinzu, eine unverständliche Einstellung oder eine Übergabe, die jemand anderem zusätzliche Arbeit macht.

In seinem am 15. Oktober veröffentlichten Beitrag Someone behind the software beschreibt Linear-Mitgründer Karri Saarinen seine Sorge, dass einzeln betrachtet sinnvolle Änderungen eine gemeinsame Produktvorstellung schwächen. Der Text löste eine rege Diskussion auf Hacker News aus. Er ist die Einschätzung eines Praktikers, kein Beleg dafür, dass Agenten Produkte grundsätzlich verschlechtern.

Die praktische Frage lautet: Was sollten Sie prüfen, wenn die Implementierung schneller vorliegt als eine fundierte Produktentscheidung? Wir schlagen dafür vier Prüfschritte vor. Sie greifen Empfehlungen von YC zur Kundenbefragung und Vorgehensweisen aus Basecamps Shape Up auf. Die Kombination ist unsere Empfehlung; für sie gibt es weder eine gemessene Erfolgsquote noch den Anspruch wissenschaftlicher Validierung.

Warum kann eine technisch funktionierende Neuerung ein Produkt schwächen?

Eine Funktion kann ihre Spezifikation erfüllen und dennoch die übergeordnete Aufgabe erschweren. Ein stimmiges Produkt hilft Menschen mit seinen einzelnen Bestandteilen dabei, eine Aufgabe auf nachvollziehbare Weise zu erledigen. Dazu gehört auch, was vor und nach der neuen Interaktion geschieht.

Stellen Sie sich vor, Sie ergänzen einen direkten Zugang zur Änderung eines Interviewtermins. Dieser Zugang funktioniert. Doch die Kandidatin erhält eine andere Nachricht als der Recruiter, und ein alter Link verweist weiterhin auf den vorherigen Termin. Jede Ansicht kann für sich plausibel wirken, während im Gesamtprozess unklar bleibt, welche Vereinbarung gilt.

Saarinen verbindet gutes Produkturteil mit Erfahrung, Kundengesprächen und dem Blick dafür, wie die Teile zusammenpassen. Das bietet eine konkretere Diskussionsgrundlage als das bloße Gefühl, eine Funktion passe schon. Fragen Sie, welche bestehenden Erwartungen sich ändern und ob die betroffenen Personen ihre Aufgabe weiterhin erledigen können.

Diese Frage gilt für Arbeit von Menschen, Agenten oder beiden gemeinsam. Anlass ist eine vorgeschlagene Produktänderung. Ob die Änderung in das Produkt gehört, hängt nicht davon ab, wer den Code geschrieben hat.

Halten Sie den Prüfaufwand angemessen. Für eine korrigierte Beschriftung reichen möglicherweise eine kurze Erklärung und ein Screenshot. Ein neuer Weg zur Terminvereinbarung braucht Nachweise zu den betroffenen Interaktionen. Die folgenden vier Prüfschritte unterstützen diese Entscheidung. Sie verlangen kein neues Freigabegremium für jede Bearbeitung.

Welches Kundenproblem löst diese Änderung?

Beginnen Sie mit einer konkreten Situation, in der eine Person Schwierigkeiten hatte. Halten Sie fest, was sie tun wollte, an welcher Stelle sie nicht weiterkam und wie sie sich mit dem bestehenden Produkt beholfen hat.

In YCs Startup-School-Rückblick mit Transkript empfiehlt Eric Migicovsky, nach einer früheren Problemsituation und bereits versuchten Lösungen zu fragen. Diese Antworten liefern mehr als die bloße Reaktion auf Ihren Lösungsvorschlag.

Fügen Sie der Produktprüfung ein Supportgespräch, eine beobachtete Nutzung oder ein klar beschriebenes Kundenbeispiel bei. Trennen Sie Beobachtung und Deutung. „Der Recruiter hat die neue Uhrzeit in zwei Nachrichten kopiert“ beschreibt ein Verhalten. „Wir brauchen einen KI-Terminassistenten“ schlägt eine wesentlich umfangreichere Lösung vor.

Benennen Sie die betroffene Person so genau, wie es die Aufgabe erfordert. Kandidatinnen und Kandidaten, die ihre eigene Buchung ändern, haben andere Bedürfnisse als Recruiter, die ein Interview mit mehreren Beteiligten koordinieren. Wenn Sie beide nur als „Nutzer“ bezeichnen, verdecken Sie möglicherweise die Übergabe, die Sie verstehen müssen.

Ihre Beobachtungen können eine kleine Verbesserung rechtfertigen, während die größere Geschäftschance noch unklar bleibt. Eine einzelne Kundensituation kann eine unverständliche Interaktion sichtbar machen. Sie belegt nicht, wie häufig das Problem im gesamten Markt vorkommt. Sagen Sie, was Sie wissen, was Sie daraus schließen und welche Fragen offen sind.

Auch wenn eine Demo den Anstoß gegeben hat, können Sie das Problem noch untersuchen. Beobachten Sie zunächst, wie jemand die bestehende Aufgabe angeht, bevor Sie die vorgeschlagene Änderung zeigen. Vielleicht reichen eine klarere Formulierung oder ein vorhandener Link. Vielleicht entdecken Sie auch einen tieferliegenden Bedarf, den die Demo übergangen hat.

Die Prüffrage: Können Sie die Schwierigkeit des Kunden beschreiben, ohne die Funktion zu erwähnen? Wenn Sie dafür ausschließlich erklären müssen, was der Agent gebaut hat, untersuchen Sie zuerst das Problem, bevor Sie die Implementierung erweitern.

Welche Abwägung begrenzt den Funktionsumfang?

Definieren Sie das nützliche Ergebnis und die Komplexität, die Sie dafür akzeptieren. Benennen Sie ausdrücklich, was ausgeschlossen bleibt. So erhält die Prüfung eine klare Grenze.

Das Shape-Up-Kapitel Set Boundaries beschreibt, wie ein Team den vertretbaren Aufwand festlegt und das Problem entsprechend eingrenzt. Im Kalenderbeispiel unterscheidet es zwischen dem Bedarf, freie Zeiten zu sehen, und der wesentlich größeren Aufgabe, sämtliche denkbaren Kalenderfunktionen zu bauen.

Nutzen Sie diese Unterscheidung bei der Produktprüfung. „Kandidaten helfen, die vorhandene Terminänderung zu finden“ ist ein begrenztes Ziel. „Terminvereinbarung mühelos machen“ lässt Raum für neue Kalender, Berechtigungen, Erinnerungen, Einstellungen und Ausnahmen, ohne zu klären, welcher Teil gerade zählt.

Halten Sie die erwogene Alternative fest. Könnten Sie den vorhandenen Weg verbessern, einen verwirrenden Schritt streichen oder die Nachricht korrigieren, die dorthin führt? Im Vergleich mit dem unveränderten Produkt hat eine neue Funktion leichtes Spiel. Erst der Vergleich mit einer kleineren, nützlichen Korrektur macht die Abwägung sichtbar.

Schreiben Sie anschließend auf, worauf Sie verzichten. Im Terminbeispiel könnten Änderungen an der Zuweisung der Interviewer oder an den Benachrichtigungsregeln ausgeschlossen bleiben. Das hilft, wenn während der Implementierung eine attraktive angrenzende Idee auftaucht: Sie können entscheiden, ob die neuen Erkenntnisse eine Erweiterung des Umfangs rechtfertigen.

Berücksichtigen Sie auch den laufenden Aufwand. Jemand muss die Funktion erklären, ihre Zustände pflegen, ihre Nachrichten übersetzen und Fehler behandeln. Nicht jede Schaltfläche braucht ein spekulatives Finanzmodell. Sie sollten aber erkennen, wenn ein direkter Zugang eine zusätzliche Interaktion schafft, die Ihr Team dauerhaft mit dem Rest des Produkts abstimmen muss.

Die Prüffrage: Können Sie erklären, warum es sich lohnt, diese Variante statt der kleineren Alternative dauerhaft zu pflegen? Falls nicht, grenzen Sie den Vorschlag ein oder überarbeiten Sie ihn. Auch eine funktionierende Implementierung, die Sie nicht veröffentlichen, kann Erkenntnisse liefern.

Ist der vollständige Ablauf weiterhin verständlich?

Probieren Sie die Änderung als Teil einer echten Aufgabe aus. Prüfen Sie dabei die gespeicherten Daten und die Sicht der nächsten beteiligten Person. Eine ausgefeilte Ansicht oder eine isolierte Komponente zeigt nicht die gesamte Interaktion.

Das Shape-Up-Kapitel Get One Piece Done empfiehlt, einen kleinen nutzbaren Teil vollständig zu integrieren, damit Menschen ihn ausprobieren können. Übertragen Sie diesen Gedanken auf die Prüfung: Verfolgen Sie die Aufgabe vom Anlass bis zur anschließenden Übergabe.

Beginnen Sie bei einer Terminänderung dort, wo Kandidatinnen und Kandidaten die Einladung tatsächlich erhalten. Folgen Sie dem Link, wählen Sie eine Uhrzeit, speichern Sie die Änderung und rufen Sie die Buchung erneut auf. Prüfen Sie anschließend die Ansicht des Recruiters und die Nachrichten an alle Beteiligten. Vergewissern Sie sich, dass das Ergebnis auch nach dem Verlassen der Seite gespeichert bleibt.

Wählen Sie schwierige Fälle passend zur Änderung aus. Ein Termin kann vor der Bestätigung nicht mehr verfügbar sein. Ein Kandidat kann einen alten Link erneut öffnen. Eine Interviewerin kann absagen, während jemand anderes die Seite geöffnet hat. Ein solcher Durchlauf deckt nicht jede Möglichkeit ab. Er kann aber Annahmen sichtbar machen, die eine technische Prüfung verdienen.

Betrachten Sie auch das Umfeld. Verwendet der neue Weg vertraute Bezeichnungen? Kann jemand nach einem Fehler weitermachen? Kann die betroffene Person die Aktion auf einem kleinen Bildschirm ausführen? Hängt der Zugriff weiterhin vom richtigen Konto oder von der passenden Buchungsberechtigung ab?

Beschreiben Sie die Nachweise präzise. Eine Aufzeichnung belegt, was auf dem aufgezeichneten Weg passiert ist. Automatisierte Tests belegen Verhalten innerhalb ihrer Prüfungen und Testbedingungen. Beides rechtfertigt keine pauschale Aussage, das gesamte Produkt sei korrekt.

Das ähnelt dem Vorgehen, die Anleitung einer Code-Aufgabe mit einer Person zu testen, die sie zum ersten Mal liest: Wer jemanden beim tatsächlichen Ablauf beobachtet, kann Lücken erkennen, die den Verfassern nicht mehr auffallen. Hier geht die Entscheidung weiter. Sie betrifft auch die Frage, ob die Funktion überhaupt in das bestehende Produkt passt.

Die Prüffrage: Kann die vorgesehene Person die versprochene Aufgabe erledigen, und versteht die nächste Person das Ergebnis? Wenn eine Übergabe scheitert, reparieren Sie den Ablauf oder begrenzen Sie das Versprechen vor der Veröffentlichung.

Wer trägt nach der Veröffentlichung die Verantwortung?

Benennen Sie eine verantwortliche Person und legen Sie fest, was sie anschließend beobachten soll. Verantwortung umfasst auch die Frage, ob die Änderung tatsächlich geholfen hat.

In Hand Over Responsibility beschreibt Shape Up, wie ein Team ein vollständiges, begrenztes Projekt übernimmt und die einzelnen Aufgaben selbst ermittelt. Das unterstützt eigenständiges Arbeiten innerhalb klarer Grenzen. Die Gründerin oder der Gründer muss nicht jede Implementierungsentscheidung freigeben, damit das Produkt stimmig bleibt.

Benennen Sie die Person, die Fragen zur Entscheidung beantworten, die nötigen Beteiligten zusammenbringen und auf neue Erkenntnisse reagieren kann. Das kann jemand aus Produktmanagement, Design, Entwicklung oder dem Gründungsteam sein. Die Arbeit lässt sich im Team verteilen, während die Ansprechperson eindeutig bleibt.

Wählen Sie eine Beobachtung, die zum ursprünglichen Problem passt. Konnten Kandidaten die Möglichkeit zur Terminänderung nicht finden, prüfen Sie, ob sie diese Aufgabe nun erledigen können und ob sich entsprechende Supportgespräche verändern. Klicks auf die neue Schaltfläche allein beantworten die ursprüngliche Frage nicht.

Bei Produkten mit geringer Nutzung kann die direkte Nachfrage bei betroffenen Kunden aufschlussreicher sein als ein Dashboard. Bei stärker genutzten Abläufen können Sie zusätzlich erfolgreiche Abschlüsse und Fehler untersuchen. Verstehen Sie eine Veränderung nach der Veröffentlichung in beiden Fällen nicht als Kausalitätsbeweis, wenn sich auch andere Bedingungen geändert haben.

Legen Sie fest, wann eine weitere Änderung oder die Entfernung der Funktion nötig wäre. Vielleicht verursacht der direkte Zugang Verwirrung, verdoppelt einen vorhandenen Weg oder verlagert Abstimmungsarbeit auf Recruiter. Das sind Gründe, die Produktentscheidung zu überdenken, selbst wenn die Implementierung technisch weiterhin einwandfrei ist.

Wenn Sie auch die Wirtschaftlichkeit des Agenteneinsatzes bewerten, behandeln Sie diese Prüfung ausdrücklich gesondert. Bei den Kosten pro akzeptiertem Ergebnis geht es um die Wirtschaftlichkeit des Pilotprojekts. Die Prüfung hier fragt, ob gerade dieses Ergebnis akzeptiert werden sollte.

Die Prüffrage: Wer kommt auf das ursprüngliche Kundenproblem zurück, und was wird diese Person untersuchen? Weisen Sie diese Verantwortung vor der Veröffentlichung zu, damit die Frage nach dem Start nicht verloren geht.

Wenden Sie die vier Prüfschritte auf eine Terminänderung an

Betrachten wir einen hypothetischen Vorschlag: Ein Agent ergänzt auf der Bestätigungsseite eines Interviews eine auffällige Schaltfläche zur Terminänderung. Dies ist ein Anwendungsbeispiel, kein Bericht über einen Vorfall bei Kit und keine Ankündigung einer Funktion.

Ausgangspunkt ist ein Kundengespräch über die Schwierigkeit, den vorhandenen Weg zur Terminänderung zu finden. Der Vorschlag könnte dieses Problem lösen. Daraus ergibt sich noch kein Bedarf für einen neuen Mechanismus zur Terminplanung.

Vergleichen Sie bei der Eingrenzung des Umfangs die auffällige Schaltfläche mit einem deutlicheren vorhandenen Link. Nehmen wir an, beide führen zum selben bestehenden Ablauf für Terminänderungen. Dann können Sie die Auffindbarkeit beurteilen, ohne zugleich die Auswahl verfügbarer Zeiten oder beteiligter Personen neu zu gestalten. Halten Sie diese Entscheidung in der Beschreibung fest.

Prüfen Sie beim vollständigen Ablauf sowohl eine erfolgreiche Änderung als auch einen fehlgeschlagenen Versuch. Sehen Sie sich die gespeicherte Buchung, den erneuten Aufruf durch den Kandidaten, die Ansicht des Recruiters und die Benachrichtigungen an. Prüfen Sie, was eine alte Einladung nach der Terminänderung zeigt. Eine Schaltfläche, die auf die richtige Seite führt, erfüllt erst den ersten Teil dieser Prüfung.

Diese Abhängigkeiten sind in Kits bestehendem Code zur Terminplanung konkret erkennbar. Bei einer Terminänderung werden die zeitlichen Voraussetzungen, der Buchungsstatus sowie die Verfügbarkeit der gastgebenden und teilnehmenden Personen geprüft. Die gespeicherte Buchung und die Kalendersequenznummer werden aktualisiert und Benachrichtigungen in die Warteschlange gestellt. Das beschreibt Aufgaben der Implementierung; es garantiert nicht, dass jede externe Nachricht zugestellt wird. Es erklärt, warum eine scheinbar kleine Produktänderung den Blick auf die gesamte Aufgabe braucht.

Legen Sie beim Prüfschritt zur Verantwortung fest, wer spätere Versuche und entsprechende Rückmeldungen untersucht. Diese Person sollte wissen, ob die ursprüngliche Schwierigkeit des Kandidaten behoben wurde. Sie sollte auch erkennen, ob die auffälligere Platzierung ein neues Problem schafft, etwa die Erwartung, eine nicht mehr änderbare Buchung doch ändern zu können.

Die Prüfdokumentation kann knapp bleiben:

Als Entscheidungen eignen sich etwa Annehmen, Eingrenzen, Untersuchen oder Ablehnen. Ein Punktwert würde eine Genauigkeit suggerieren, die diese Fragen nicht bieten. Wenn Sie eine Änderung zurückstellen, nennen Sie die fehlenden Nachweise und die nächste Aufgabe. So kann das Team zu einer Entscheidung kommen.

Übertragen Sie dieses Vorgehen auf Ihren Recruiting-Ablauf

Im Recruiting wird ein stimmiger Produktablauf greifbar: Eine Aktion der Kandidatin oder des Kandidaten verändert, was das Team als Nächstes tun muss. Interviewzeiten, Fortschritt durch die Phasen, Erwartungen der Beteiligten und Nachrichten müssen zusammenpassen, damit der Prozess verständlich bleibt.

Kit bietet Recruiting- und Terminabläufe, bei denen diese Zusammenhänge zählen. Die hier vorgeschlagenen Prüfschritte gehören nicht zum Funktionsumfang von Kit. Kit validiert weder Kundenforschung noch zertifiziert es von Agenten erstellte Funktionen. Ihr Team bleibt dafür verantwortlich, passende Änderungen auszuwählen und deren Auswirkungen zu prüfen.

Halten Sie vor der Annahme Ihrer nächsten Funktion das Kundenproblem, die Abwägung zum Umfang, den vollständigen Ablauf und die verantwortliche Person fest. Bringen Sie Nachweise mit, deren Umfang zur Änderung passt, und treffen Sie dann die Entscheidung. Wenn Sie einen Recruiting-Ablauf für Ihr Startup suchen, können Sie Kit ausprobieren und prüfen, wie das Zusammenspiel zwischen Kandidaten und Team zu Ihrem Prozess passt.