Die Größe des Backlogs ist umgekehrt proportional zur Häufigkeit von Gesprächen mit Kund:innen

• Je häufiger man mit Kund:innen spricht, desto kleiner wird das Backlog
• Es ist wichtig, Planungszeit durch Gespräche mit Kund:innen zu ersetzen
• Je mehr Vermittler es zwischen Entwickler:innen und Kund:innen gibt, desto eher erfüllt das Produkt die Anforderungen der Kund:innen nicht
• Ein großes Backlog bedeutet, dass es viele unvalidierte Annahmen gibt und die Wahrscheinlichkeit gering ist, Kundennutzen zu schaffen

Auf das Design technischer Komponenten statt auf UI-Design fokussieren

• Nicht zu viel Zeit in UI-Design investieren, sondern eine grundlegende UI schnell veröffentlichen und sie anhand von Kundenfeedback verbessern
• Die technische Schuld niedrig halten, damit Änderungen, die Kund:innen benötigen, schnell umgesetzt werden können

Die Art, wie Menschen eine App zu nutzen glauben, unterscheidet sich von der tatsächlichen Nutzung

• Es ist wichtig zu beobachten, wie Kund:innen die App tatsächlich verwenden
• Wenn man das Verhalten der Nutzer:innen direkt beobachtet, lassen sich Erkenntnisse gewinnen, die mit rein quantitativen Kennzahlen nicht sichtbar werden

Account-Spoofing implementieren

• Um zu verstehen, welche Bildschirme ein bestimmter Kunde tatsächlich sieht, ist es wichtig, in eine Account-Spoofing-Funktion zu investieren
  • Account Spoofing: eine Funktion, mit der Administrator:innen die App wie ein bestimmter Produktionsnutzer verwenden können
• Dadurch lassen sich Probleme effektiv diagnostizieren und die Abhängigkeit von Testdaten verringern

Die Bedeutung der ersten Seite

• Kund:innen, die die App zum ersten Mal öffnen, sollten die relevantesten Informationen prägnant präsentiert bekommen
• Wenn man versucht, zu viele Informationen auf der ersten Seite unterzubringen, erhöht das die kognitive Belastung der Nutzer:innen

Kund:innen sind die wichtigsten Marketer

• Der NPS (Net Promoter Score) ist ein guter Indikator dafür, ob Kund:innen das Produkt so sehr mögen, dass sie es weiterempfehlen würden
• Man kann Werbebudget ausgeben, aber als Marketingstrategie ist es effektiver, bei zufriedenen Kund:innen anzusetzen

Ein MVP ist ohne iterative Verbesserungen bedeutungslos

• Ein MVP sollte nicht einfach als Vorwand dienen, wegen Termindruck eine minderwertige Customer Experience zu liefern
• Ein MVP hilft zu entscheiden, ob weitere Iterationen nötig sind und, falls ja, was verbessert werden sollte

Meinung von GN⁺

• Das Wichtigste an diesem Artikel ist die Bedeutung der Produktentwicklung, die durch kontinuierliche Gespräche mit Kund:innen die tatsächlichen Bedürfnisse realer Nutzer:innen widerspiegelt
• Er betont die Bedeutung einer flexiblen UI und technischer Komponenten, mit denen sich Kundenfeedback schnell umsetzen lässt
• Er zeigt, dass langfristiger Erfolg daraus entstehen kann, das Produkt über das MVP hinaus kontinuierlich zu verbessern und die Kundenzufriedenheit zu steigern
• Der Artikel teilt Lehren aus dem Startup-Alltag und bietet Gründer:innen sowie Entwickler:innen praktische Einblicke

[GN⁺]

Hacker-News-Kommentare

• Meinungen zur Organisation von Funktionen/Verbesserungen

  • Erfahrungsgemäß ist die Strategie, aus jeder Idee ein Ticket zu machen, ineffizient. So entsteht eine „Icebox“, die voller Ideen ist, die nie genutzt werden.
  • Selbst wenn für einen wichtigen Deal eine Idee aus der Icebox benötigt wird, erinnert man sich oft nicht daran, dass sie existiert, und erstellt stattdessen ein neues Ticket.
  • Bevorzugt werden Tickets, die kurz- oder mittelfristig realistisch umsetzbar sind; andere Ideen werden separat gespeichert.
  • Das Engineering-Team pflegt eine Liste technischer Schulden, die es beheben möchte, und PMs pflegen je Projekt eine Liste möglicher Verbesserungen.
  • Für neue Funktionen/Produkte werden PRDs geschrieben, aber nicht sofort in Tickets umgewandelt.
  • Ein riesiger Backlog, der größtenteils nie bearbeitet wird, ist ein Zeichen für schwache PMs, die Angst haben, „Nein“ zu sagen.

• Zusammenhang zwischen Backlog-Größe und PM-Fluktuation

  • Die Größe des Backlogs ist umgekehrt proportional zur Fluktuation bei PMs.
  • Für langjährige PMs ist der Backlog eine Gedächtnisstütze für frühere Produktgespräche.
  • Neue PMs schauen auf den Backlog, sind verwirrt und versuchen Dinge aufzuräumen, die sie nicht verstehen.

• Gegenargumente zur Pflege eines kundenbasierten Backlogs

  • Teams, die einen Backlog pflegen, beziehen ihn meist von Kunden.
  • „Finde Funktionen, die das Leben der Kunden verbessern, und mache daraus die nächsten Features“ ist nicht so einfach.
  • Was macht man, wenn es viele Kunden gibt und die Funktionen, die ihr Leben verbessern würden, nichts miteinander zu tun haben und komplex sind?
  • Auf Kundenanfragen sollte man immer hören, aber man sollte fast nie genau das bauen, was sie verlangen.
  • Kunden fordern Funktionen an, die nicht nur eine UX-Umsetzung enthalten, sondern auch auf das zugrunde liegende Problem und den aktuell genutzten Arbeitsablauf hindeuten.
  • Man muss das Geschäftsproblem herausarbeiten und die UX-Umsetzungsidee sowie prozessspezifische Details verwerfen.
  • Dann sollte man die minimale Funktion, die das Geschäftsproblem löst, wirtschaftlich und mit gutem, konsistentem UX-Design umsetzen.

• Warum PMs einen Ort zum Erfassen von Kundenanforderungen brauchen

  • PMs brauchen einen Ort, an dem sie Kundenanforderungen erfassen können.
  • Ohne ein spezielles Tool enden diese Anforderungen meist als Jira-Tickets.
  • Es gibt zwei Ansätze: ProductBoard und Jira Product Discovery.
  • ProductBoard verfolgt einen CRM-Ansatz, bei dem alle Kundeninteraktionen erfasst und später in Anforderungen und Wünsche zerlegt werden.
  • Jira Product Discovery beginnt mit Ideen und verlangt, alles, was man von Kunden hört, sofort in eine lange Liste von Anforderungen und Wünschen zu zerlegen.
  • Der Vorteil von Jira Product Discovery ist, dass die Ideenliste vom Entwickler-Backlog getrennt wird, aber es entsteht erneut eine weitere lange Liste.
  • Wenn man Produktprioritäten auf Basis von Kundengesprächen analysieren will, ist ProductBoard das bessere Tool für Product Discovery.

• Die Bedeutung eines durch Kundenfeedback verfeinerten Backlogs

  • Wenn man fast täglich mit Kunden spricht, enthält der Backlog Funktionen und Verbesserungen, die direkt durch Kundenfeedback informiert und verfeinert wurden.
  • Es gibt immer viel zu tun, aber der Unterschied liegt darin, ob der Backlog durch Kundenfeedback informiert und verfeinert wurde.

• Backlog-Management durch tägliche Gespräche mit Kunden

  • Als technisch orientierte Person spricht man täglich mit Kunden; die Theorie ist attraktiv, hat aber einige Probleme.
  • Recency Bias und Opportunitätskosten: Man muss weiterhin Feedback zu Problembereichen sammeln, an denen man wegen höherer Prioritäten bewusst nicht arbeitet.
  • Reaktive Entwicklung: Wenn man das Erfassen von Feedback überspringt, konzentriert man sich auf die zuletzt am leichtesten zugänglichen Aufgaben und übersieht ältere Probleme.
  • Wissensbasis des Teams: Wenn es eine einzige verantwortliche Person gibt, die Feedback sammelt und Lösungen liefert, könnte die These des OP zutreffen.
  • Wenn das Team beteiligt ist, braucht es eine gemeinsame Datenbank, in der Datenpunkte asynchron erfasst und wiedergefunden werden können.
  • Ein Backlog kann schnell wachsen, aber der Umgang mit komplexen Systemen und Menschen bringt zwangsläufig Schwierigkeiten mit sich.
  • Für ein gut organisiertes Team braucht es gutes Backlog-Management: irrelevante Aufgaben archivieren, Duplikate entfernen, regelmäßig priorisieren und die Tools optimal nutzen.
  • Wichtiger als das Tool selbst ist die Verwaltung des Backlogs; möglicherweise braucht es eine „Fassade“ über dem Backlog, die relevante Informationen sichtbar macht und bei Bedarf tieferes Nachforschen erlaubt.

• Warum es wichtig ist, App-Nutzer zu beobachten

  • Es ist wichtig zu beobachten, wie Kunden eine App verwenden.
  • Man kann alle Metriken tracken, aber zu sehen, wie Nutzer scrollen, um etwas zu finden, den Zurück-Button drücken oder auf etwas klicken wollen, das nicht anklickbar ist, ist eine sehr unmittelbare Erfahrung.
  • Es wäre wünschenswert, wenn alle Unternehmen wie Apple und Google mehrmals täglich Nutzer beobachten würden.

• Die Nutzlosigkeit großer Backlogs

  • Große Backlogs enthalten viele unsichere Annahmen und haben eine geringe Wahrscheinlichkeit, echten Kundennutzen zu schaffen.
  • Es wurden oft Fehler gemacht, etwas für wertvoll zu halten, obwohl es in Wirklichkeit niemanden interessiert.
  • Ein großer Backlog spiegelt wider, dass zu selten mit Kunden gesprochen wird, und sollte daher sehr skeptisch betrachtet werden.

• Warnung zur Implementierung von Account-Spoofing

  • Account-Spoofing ist eine einfache Methode, Probleme in der Produktionsumgebung zu testen, aber Support- und Entwicklungsteams müssen den Produktionsdaten vertrauen können.
  • In manchen Branchen kann das für Kunden zu einem großen Problem werden.
  • In dem letzten Startup, in dem gearbeitet wurde, hatten Entwickler überhaupt keinen Zugriff auf Produktionsdaten.
  • Aus Sicherheitssicht sollte das als letztes Mittel gelten; besser ist es, unter der Annahme zu arbeiten, dass kein Zugriff auf Kundendaten möglich ist.

• Die Baumstruktur der Produktplanung

  • Produktplanung sollte immer als Baumstruktur aufgebaut sein.
  • Der oberste Knoten sind Geschäftsziele, darunter das Produkt, darunter Kundenprobleme und darunter die Backlog-Einträge.
  • Zu viele Backlog-Einträge können bedeuten, dass keine geeignete Struktur eingerichtet wurde und keine priorisierte Liste von Geschäftszielen existiert.
  • „Mit Kunden sprechen“ ist nützlich, um Kundenprobleme zu verstehen, aber zuerst muss man die Geschäftsziele kennen. Sonst verschwendet man Zeit damit, Feedback zu Bereichen zu sammeln, an denen ohnehin nicht gearbeitet wird.