Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 3 Min.

Building Features is easy – echten Wert liefern nicht

Eva Feigl erklärt im DWX-Interview, warum Teams oft am falschen Problem arbeiten – und wie Annahmen, Vanity Metriken und fehlendes Nutzer-Feedback echten Produkterfolg verhindern.

Features zu bauen ist keine Kunst mehr – jedes Team kann liefern. Die eigentliche Herausforderung liegt woanders, sagt Eva Feigl, Product Owner bei Forterro/Abas, im Gespräch auf der DWX: "Es geht darum, dass Features auch wirklich einen Wert liefern, der messbar und nachweisbar ist und den Produkterfolg steigert." Genau daran scheitert es in der Praxis erschreckend häufig.

Der Grund liegt fast immer an derselben Stelle: unausgesprochene Annahmen. Sobald ein Team eine Lösung für ein Nutzerproblem vorschlägt, steckt implizit eine Annahme dahinter – meist unbewusst und selten überprüft. Evas Rat: Zu jedem Problem mindestens zwei Lösungsideen entwickeln, die jeweilige Annahme explizit aufschreiben und dann versuchen, sie zu widerlegen statt zu bestätigen. Der Hintergrund sind kognitive Verzerrungen (Cognitive Biases), die uns dazu verleiten, nach Bestätigung statt nach Gegenbeweisen zu suchen. Die entscheidende Frage lautet deshalb: Was ist das kleinste Experiment, mit dem ich diese Annahme widerlegen kann?

Ein zweiter blinder Fleck vieler Teams: Vanity Metriken. Kennzahlen wie Active Users oder Session Length werden oft nur gemessen, weil sie sich leicht erheben lassen – nicht, weil sie etwas über echten Produkterfolg aussagen. Erfolgsmetriken dagegen hängen laut Feigl immer am konkreten Produkt und Feature und sind eng mit einer Verhaltensänderung der Nutzer:innen verknüpft. Wer wirklich wissen will, ob ein Feature funktioniert, muss vorher festlegen, welche Verhaltensänderung Erfolg bedeutet – und das nicht erst am Ende messen.

Um dorthin zu kommen, plädiert Feigl für kontinuierlichen Nutzeraustausch als Fundament statt als nachgelagerten Qualitätscheck: wöchentliche User Interviews, dazu Usability Testing, bei dem man Nutzer:innen einfach über die Schulter schaut. Denn im Nachhinein gefragt, vergessen viele Menschen die eigenen Stolperstellen – live beobachtet werden sie sichtbar. Ihre Anekdote dazu: Als ein Softwarehersteller einst den Speichern-Button entfernte, weil im Hintergrund ohnehin automatisch gespeichert wurde, verwirrte das die Nutzer:innen so sehr, dass der Button – wirkungslos, aber beruhigend – wieder eingeführt wurde.

Auch beim Abwägen verschiedener Lösungswege gilt: mehrere Optionen offen halten, dahinterliegende Annahmen einzeln prüfen – von Klickdummys bis zu echten A/B-Experimenten. Interessant dabei: Die eigentlichen Gamechanger werden in A/B-Tests oft gar nicht getestet, weil sie vorab schon verworfen werden. KI kann laut Feigl helfen, den Lösungsraum bewusst zu erweitern und Optionen jenseits des eigenen Denkrahmens aufzuzeigen.

Ihr Fazit zum häufigsten Scheitergrund von Features: Sie entstehen zu oft aus internen Ideen von Entwicklung oder Produktmanagement – nicht aus echten Kundenproblemen. Ihr Rat an Teams: sich gemeinsam verpflichten, zu jeder Entscheidung eine Annahme zu formulieren und diese aktiv zu hinterfragen.

Zur Person:
Eva Feigl ist Product Owner bei Forterro/Abas mit einer Leidenschaft für datenbasierte Entscheidungen und nutzerzentrierte Produktentwicklung. Mit praktischer Erfahrung im Aufbau browserbasierter ERP-Oberflächen schlägt sie die Brücke zwischen User Experience und Produktstrategie – und verwandelt komplexes Nutzerverhalten in konkrete Handlungsimpulse für bessere Produkte.

 


Produktion: Event Wave, Patrizio De Mitri

Neueste Beiträge

Outlook und Mailintegration mit Microsoft Graph - Connected Apps mit .NET, Teil 2
Eine .NET-App meldet Benutzer an, liest Outlook-Nachrichten aus dem Posteingang und bereitet E-Mails für Anzeige und weitere Verarbeitung auf.
8 Minuten
Tests gezielt verteilen - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 1
Lange Testsuiten verzögern das Feedback im Pull Request. Meziantou.ShardedTest verteilt die Testfälle auf mehrere CI-Jobs und verspricht dadurch mehr Geschwindigkeit. Dieser Einstieg zeigt, wie die Aufteilung funktioniert und welche Voraussetzungen nötig sind.
6 Minuten
CLAUDE.md richtig aufbauen - Projektanforderungen an Entwickler in Zeiten von KI, Teil 1
Gleicher Prompt, gleiches Projekt, einmal mit leerer CLAUDE.md, einmal mit gepflegter. Die Ergebnisse sind nicht vergleichbar. Wie eine Markdown-Datei zum wichtigsten Interface zwischen Entwickler und KI-Agent wird.
6 Minuten

Das könnte Dich auch interessieren

Vier Tage .NET, KI und Community - Konferenz
Community-Feeling auf der .NET Developer Conference 2026: Vier Tage KI und Microsoft .NET in einem Konferenzprogramm, das sich gewaschen hat.
3 Minuten
10. Sep 2026
AIOps: Wie KI Softwaresysteme am Leben hält - Interview
AIOps verspricht proaktives statt reaktives Monitoring. Harald Binkle (Xebia) erklärt im DWX-Interview, wie Azure Smart Detection Anomalien erkennt und Copilot automatisch Patches vorschlägt.
16. Sep 2026
Wenn aus jeder Cloud-Ressource nur ein weiteres Kubernetes-Objekt wird - Interview
STACKIT baut eine europäische Cloud-Alternative zu AWS, GCP und Azure. Tech Lead Patrick Koss erklärt, warum Crossplane statt klassischem Cloud-API der Schlüssel zur Selbstverwaltung ist.
9. Sep 2026
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige