Blog

Macht KI Ihr Team zur Feature-Fabrik?

KIEntwicklungProdukt
Illustration verschiedener Entwicklungsprozesse, die zeigt, dass KI das Produkt verkompliziert

Das Muster, das wir immer wieder sehen

Ihr Team liefert mehr aus als noch vor zwei Jahren. Steigt Ihr Umsatz auch?

Seit KI-Coding-Tools durchgestartet sind, hören wir von Kunden am häufigsten eine Variante von „Können Sie noch <hier 5 neue, beliebige Features einsetzen> hinzufügen?“ Wir können sie schneller bauen als je zuvor, aber die meisten werden keine einzige Kennzahl bewegen, weil niemand vorher geprüft hat, ob die Nutzer sie überhaupt wollen.

Das KI-Produktivitätsparadox: beschäftigter, nicht schneller

GitHub verzeichnet Tag für Tag mehr Pull Requests, doch wie Sie sich vorstellen können, werden die meisten davon nie gemergt und erblicken nie das Licht der Produktion. Diese Lücke hat einen Namen: das KI-Produktivitätsparadox.

KI verändert auch, wie schnell sich Menschen fühlen. In einer randomisierten Studie von METR brauchten erfahrene Entwickler, die in ihnen bereits bekannten Codebasen arbeiteten, mit KI-Tools rund 19 % länger für ihre Aufgaben. Trotzdem glaubten sie, schneller zu sein.

Diagramm, das zeigt, wie KI die Entwicklung in Open-Source-Projekten bei Entwicklern verlangsamt hat, die die Codebasis sehr gut kennen
Quelle: metr.org, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/#motivation

Wie diese Zahlen zeigen, wurde gute Software selten durch Tippgeschwindigkeit ausgebremst. Der langsame und mühsame Teil war schon immer die Entscheidung, was gebaut werden soll – was neue Kunden bringt und bestehende länger hält.

Wenn Bauen also so billig wird, wird auch das Bauen des Falschen billig. So landen Teams in einer Feature-Fabrik.

Feature-Fabrik (Subst.) – kritischer Begriff für ein Produkt- und Entwicklungsteam, das seinen Erfolg daran misst, wie viele Features es ausliefert (Output), statt am tatsächlichen Wert oder am gelösten Problem für die Nutzer (Outcome)

Warum sich die meisten dieser Features nie verkaufen

Wenn die Entwicklung so schnell läuft, verliert man sich leicht in Retro-Meetings und in Listen mit Feature-Ideen, die jemandem beim Kochen oder im Fitnessstudio eingefallen sind. Kreativität ist nicht das Problem. Ein Kunde ohne sie hätte nie ein Produkt gebaut – die Probleme beginnen, wenn Ideen auf Optimismus statt auf Daten gebaut werden.

Erinnern Sie sich, als die ersten KI-APIs herauskamen? Plötzlich war das nächste Feature jedes Produkts „KI“. Es gab keinen klaren Grund, warum das Produkt KI brauchte, welche Daten es nutzen könnte, um etwas Wertvolles zu schaffen, was es kosten würde oder wie es in den Workflow der Kunden passen sollte … Ich könnte weitermachen, aber Sie verstehen, worauf ich hinauswill.

Früher war das anders. Als ein komplexes Feature ein bis zwei Monate Wartezeit bedeutete, nahmen sich Kunden Zeit: Sie durchdachten den Ansatz, prüften ihre Annahmen anhand echter Nutzerdaten und entschieden erst dann, ob das Feature den Aufwand wert war.

KI hat diese Wartezeit abgeschafft – und das „Nachdenken“ gleich mit. Übrig bleibt eine geringe Feature-Nutzung, und für den Kunden heißt das: Geld in die Entwicklung gesteckt und 0 € zurückbekommen.

Wie wir bei Morplo Features auswählen

KI hat auch uns schneller gemacht: KI-Agenten programmieren neue Features → unsere Engineers reviewen sie. So fließt weniger ihrer Zeit ins Code-Schreiben und mehr in Architektur, Abwägungen, Reviews und Produktentscheidungen. Den Großteil der gesparten Zeit investieren wir in die Feature-Priorisierung: die Entscheidung, was sich zu bauen lohnt, bevor wir mit dem Code beginnen.

Diagramm, das zeigt, wie man die Priorisierung von Features optimiert
Quelle: App Solutions, https://theappsolutions.com/blog/development/mvp-feature-prioritization/

So funktioniert das in einem Kundenprojekt:

  1. Ein Product Manager hinterfragt das Briefing. Jedes Projekt wird von einem PM geleitet, der das Geschäft des Kunden versteht. Wenn eine Liste mit fünf neuen Features auf unserem Tisch landet, lautet die erste Frage, welches Kundenproblem jedes davon löst und ob es das Produkt dorthin bringt, wo es in zwei Jahren stehen sollte.
  2. Wir schauen uns die Daten an, die das Produkt bereits hat. Bevor wir etwas Neues planen, prüfen wir, wie die bestehenden Features genutzt werden: zu welchen die Nutzer zurückkehren, welche sie ignorieren und wo sie abspringen.
  3. Jedes Feature bekommt eine klare Spezifikation. Wir schreiben strukturierte Spezifikationen, die festhalten, was das Feature tut, für wen es ist und woran wir erkennen, dass es funktioniert hat. Oft scheitert eine schwache Idee schon beim Aufschreiben – und das ist weitaus günstiger, als es nach dem Launch herauszufinden.
  4. Wir bauen Prototypen, bevor wir entwickeln. Wir gestalten Features in Figma, verwandeln sie mithilfe von KI in klickbare Prototypen und präsentieren die Idee damit unserem Kunden – und idealerweise einigen seiner Kunden.
  5. Wir liefern in Sprints und prüfen die Ergebnisse. Die Arbeit geht in Sprints raus. Wenn wir sehen, dass ein Feature bei den Nutzern nicht ankommt, merken wir das früh und passen den nächsten Sprint an, statt noch mehr Features obendrauf zu packen.

Mit genau diesem Workflow haben wir Reggy von der Idee zu einem MVP gebracht, das ihre Finanzierung gesichert hat, und anschließend zu einer Plattform, die ihre ersten Kunden gewonnen hat.

Fazit

Entwicklungsteams können mit KI jetzt mehr ausliefern, und das wird sich nicht ändern – aber mehr Entwicklung ≠ mehr Kunden. Teams, die echten Mehrwert aus KI ziehen, nutzen die gewonnene Zeit, um Nutzungsdaten auszuwerten, mit ihren Kunden zu sprechen und zu den meisten Ideen auf der Liste Nein zu sagen.

Wenn also das nächste Mal „Können Sie diese fünf Features hinzufügen?“ aufkommt, beginnen Sie mit einer Frage: Welche davon werden Ihre Nutzer tatsächlich verwenden?

Wenn Ihr Backlog immer weiter wächst, neue Features Ihnen aber keine neuen Kunden bringen, lernen Sie das Team hinter unserem Prozess kennen und besprechen Sie Ihre Idee mit uns.

Bereit, Ihr Unternehmen zu transformieren?