Der Produktlebenszyklus: Reise einer Produktfunktion

Dies ist der vierte Beitrag einer fünfteiligen Serie, die ich mit dem Ziel schreibe, einem Produktanwärter beim Einstieg in die Welt des Produktmanagements zu helfen.

In meinem letzten Beitrag habe ich die Disziplin des Produktmanagements in vier Teile unterteilt, mit dem Ziel, Aspiranten des Produktmanagements dabei zu helfen, ihren Karriereweg innerhalb eines Unternehmens oder im Allgemeinen zu verstehen. In diesem Beitrag werde ich über den Lebensweg eines Produktfeatures sprechen, von der Idee bis zur Aufgabe, um einem Produktmanagement-Anwärter zu helfen, eine 360-Grad-Perspektive darüber zu erhalten, was die Rolle eines Produktmanagers beinhaltet.

T – 30 Tage

Not macht erfinderisch, sagt man. Das ist buchstäblich der Fall, wenn es um die Geburt eines Produktfeatures geht. Alles beginnt mit einem gewissen Maß an Unbehagen.
Mancher Mitarbeiter im Unternehmen fühlt sich beim Erfüllen einer seiner täglichen Aufgaben unwohl – vielleicht hat sich die Benutzerbasis vergrößert und er kann sie nicht mit den alten Prozessen verwalten. Einige Führungskräfte im Unternehmen sehen sich eine Excel-Tabelle an und denken, dass das Unternehmen zu viel Geld verliert, beispielsweise aufgrund einer hohen Anzahl von Produktstornierungen. Oder vielleicht hat ein Konkurrent eine Produktfunktion auf den Markt gebracht, die dazu führt, dass die Kunden das Produkt des besagten Unternehmens verlassen. Jemand, der sich den Marketing-Conversion-Trichter ansah, bemerkte zu einem bestimmten Zeitpunkt hohe Drop-offs und war der Meinung, dass eine Optimierung ihm dabei helfen könnte, sein Quartalsziel zu erreichen. Oder es könnten 100 verschiedene Gründe sein, von einer hohen Anzahl von Kundenbeschwerden für ein häufiges Problem bis hin zu einer neuen Funktion, die von einer Mehrheit der in der Vorwoche befragten Benutzer gefordert wurde. Der Punkt ist – alles beginnt mit einem gewissen Maß an Unbehagen.

Nun wird dieses Unbehagen dem Produktmanager zur Kenntnis gebracht; oder vielleicht ist es der Produktmanager, der es zuerst bemerkt. Dies ist der Punkt, an dem eine Kette von Ereignissen beginnt, die zur Geburt eines neuen Features führen können.

T – 25 Tage

Es ist an der Zeit, dass der Produktmanager über die Problemstellung nachdenkt. Er geht und spricht mit Kunden oder internen Stakeholdern, die das Unbehagen gemeldet haben, und dann mit denen, die es tatsächlich erleben; alles mit einem einzigen Ziel – um sicherzustellen, dass er die „Wurzel“-Problemaussage identifiziert hat. Wenn diese Phase auf die leichte Schulter genommen wird oder der Produktmanager nicht genug Zeit dafür aufwendet, dann werden die entstehenden Produkteigenschaften brüchig, verzerrt und finden ziemlich schnell ihr Ende.
Sobald der Produktmanager die Kernproblemstellung identifiziert hat, entscheidet er, ob es sich lohnt, sie zu lösen. Ist das Unbehagen wirklich groß oder ist es irgendwie übertrieben oder schlimmer noch, nur erfunden? Würde die Lösung tatsächlich einen erheblichen Mehrwert für den Kunden und/oder das Unternehmen schaffen? Würde die Lösung dem Kunden und/oder Unternehmen nicht eine erhebliche Strafe auferlegen? Gibt es eine Möglichkeit, dieses Problem durch eine geringfügige Optimierung der Prozesse oder durch Aktivitäten zu lösen, die keine Produktänderungen erfordern – z. B. einen Anbieter wechseln, einen besseren Preis mit einem bestehenden Anbieter aushandeln, eine Drittanbietersoftware zur Lösung des Problems beschaffen, einstellen ein zusätzlicher Mitarbeiter, Änderungen an Inhalten, Grafiken, Call-to-Action-Button usw.?

Wenn es eine Möglichkeit gibt, mit einer Methode, die keine Produktänderungen beinhaltet, einen ähnlichen Mehrwert zu erzielen, dann würden wir uns dafür entscheiden, irgendetwas am Produkt zu ändern – egal ob das bedeutet, etwas hinzuzufügen oder zu entfernen. Sobald der Produktmanager davon überzeugt ist, dass die Lösung der Problemstellung einen erheblichen Mehrwert bietet und eine Änderung der Produktebene einen viel höheren ROI (unter Berücksichtigung von Zeit, Geld und Aufwand im Vergleich zum Wert) bringt als eine Änderung ohne Produktebene, ist die Saat für eine neue Produktmerkmal gepflanzt werden.

T – 15 Tage

Wenn der Produktmanager über Vorerfahrung verfügt, kann er basierend auf dieser Erfahrung eine Lösung vorschlagen. Dies ist jedoch möglicherweise nicht in allen Fällen die beste Lösung.
Wenn die Problemstellung eine hochtechnische Lösung erfordert, bespricht der Produktmanager das Gleiche mit Entwicklern und technischen Managern und holt sich deren Rat bezüglich der besten Vorgehensweise. Wenn die Lösung Änderungen auf Designebene erfordert, kann der UX-Lead konsultiert werden. Es könnte sein, dass der Produktmanager und die UX-Person einen Design-Sprint organisieren und die Lösung auswählen, die von den tatsächlichen Benutzern dieser Funktion gut angenommen wird. Manchmal ist das Problem vollständig geschäftsbezogen und erfordert daher die Zustimmung der Geschäftsleitung.
Es kann also mehrere Möglichkeiten geben, wie eine Lösung finalisiert werden könnte. Sobald dies jedoch der Fall ist, ist der Produktmanager dafür verantwortlich, diese theoretische Lösung in eine aktive Produktfunktion umzuwandeln.

T = 0 (aka Geburt des Produktfeatures)

Wenn eine bestimmte Lösung identifiziert wird, erstellt der Produktmanager in Zusammenarbeit mit dem zuständigen Team einen groben Überblick über die Lösung. Es kann einen Prototyp der Lösung enthalten oder nicht. Manchmal ist es nur eine einfache Excel-Tabelle mit „Wenn-dann“-Bedingungen, die geschrieben wurden, wann einem Benutzer ein bestimmter CTA angezeigt werden soll usw.
Der Produktmanager formuliert die Lösung im entsprechenden PRD (Product Requirements Document). Wenn das Feature klein ist, könnte es sich nur um einen Absatz in einer vorhandenen PRD für ein größeres Feature handeln. Manchmal ist das Feature so groß, dass es eine vollständige PRD erfordert, nur um es richtig zu detaillieren. Das PRD wird von den zuständigen Teams betrieben und der Produktmanager stellt sicher, dass ein breiter Konsens bezüglich des Features besteht.

T + 15 Tage

Das Einfrieren kleiner Features kann weniger als einen Tag dauern. Große Features brauchen manchmal mehr als 30 Tage, um von allen grünes Licht zu bekommen.
Nehmen wir durchschnittlich 15 Tage, um zu sagen, dass dies die Zeit ist, in der das neugeborene Feature den Entwicklern vorgestellt wird. Es findet eine ordnungsgemäße Design- und PRD-Übergabe statt, bei der Entwickler, die an dem Projekt arbeiten, über die 5Ws (Was, Warum, Wann, Wo, Wer) und die Testfälle (wie sich das Feature nach der Veröffentlichung verhalten oder nicht verhalten soll) informiert werden. .
Zusammen mit dem Engineering Manager wird ein angemessener Veröffentlichungszeitplan für das Feature mit Fristen für das Ende der Entwicklung, den Beginn der Tests, die Behebung der gemeldeten Fehler und das endgültige Veröffentlichungsdatum festgelegt. Dann wird die gesamte Zeitleiste in messbare Sprints (normalerweise 15 Tage lang) unterteilt. Sobald die Entwickler zufrieden sind, beginnt die Entwicklung.

T + 30 Tage

Sprint 1 endet. Ein Teil der Produktfunktion wird ausgerollt. Es ist vielleicht noch nicht kundenorientiert, aber die meisten Teams folgen heute agilen Methoden für die Softwareentwicklung – was bedeutet, dass wir inkrementell und iterativ bauen. Anstatt also in 6 Monaten ein großes Feature zu erstellen und alles auf einmal zu veröffentlichen, teilen wir das Ganze in unabhängige Teile auf, die für sich alleine funktionieren können (eine Reihe von User Stories) und schnell bereit sind, überprüft und iteriert zu werden.
Der Produktmanager stellt sicher, dass der Release-Zeitplan durch tägliche Scrum-Meetings und Diskussionen mit dem zuständigen Engineering-Manager, der am Projekt arbeitet, auf dem richtigen Weg ist. Falls es zu Verzögerungen kommt, werden die Zeitpläne entsprechend angepasst oder kleine Teile der Funktionen fallen gelassen, um sicherzustellen, dass die Veröffentlichung rechtzeitig erfolgt. Nach jedem Sprint wird der erzielte Fortschritt dem Produktmanager und relevanten Stakeholdern in einem Meeting präsentiert und nach der Freigabe freigegeben.
Ein Jahr Produktmanagementprogramm von UpGrad

T + x Tage

Nach 'n' Sprints ist die Entwicklung abgeschlossen und das gesamte Feature ist out. Es ist nicht erforderlich, dass die Kunden das Feature erst nutzen können, wenn es vollständig freigegeben ist. Sie könnten es seit der Veröffentlichung am Ende von Sprint 1 selbst verwenden. Jede nachfolgende Sprint-Zyklus-Veröffentlichung macht das Feature nur robuster und bringt es näher an das heran, was es sein soll.
Das Starten eines Features ist selbst eine Kunst und beinhaltet viele Schritte, die wir überspringen und einfach davon ausgehen, dass nach viel Trommeln und Brustklopfen der Welt erklärt wurde, dass ein Feature veröffentlicht wurde. Dies kann so komplex sein wie eine ausgewachsene Pressemitteilung, in der der CEO selbst über den neuen Start spricht, oder es kann einfach etwas sein, bei dem eine E-Mail an eine bestimmte Abteilung gesendet wird, die das Feature verwenden wird und es wahrscheinlich angefordert hat der erste Ort. Nun, da das Feature da draußen ist, geben wir diesem Feature einen Namen – Mr. Feature.

T + y Tage

Auch nach der endgültigen Veröffentlichung geht manchmal etwas schief. Mr. Feature, der einst so glänzend und wertvoll war, ist möglicherweise nicht mehr derselbe, und dafür kann es mehrere Gründe geben. In dieser Phase im Produktzyklus geht es darum, das Produkt zu unterstützen. Eines schönen Tages wurde eine weitere Version veröffentlicht, die dazu führte, dass Mr. Feature auf unbeabsichtigte Weise funktionierte (alias fehlerhaft wurde) oder vielleicht wurde eine andere Funktion entfernt, die einige Abhängigkeiten von Mr. Feature hatte, und dies verursachte das fehlerhafte Verhalten. Es könnte auch sein, dass wir bei der Erstellung der Funktion die Anzahl der Benutzer unterschätzt haben, die sie verwenden werden, oder nicht alle Anwendungsfälle geplant haben und die Funktion jetzt nicht auf diese vielen Benutzer oder Anwendungsfälle skaliert werden kann.

Dies wird entweder vom Testteam in seiner regelmäßigen Überprüfung gemeldet oder von einem Teammitglied, das es gerade entdeckt hat, während es die Funktion selbst verwendet. Bei kundenorientierten Funktionen können diese Beschwerden von den tatsächlichen Kunden des Produkts stammen und über das Customer Experience-Team an den Produktmanager weitergeleitet werden.

Der Produktmanager versucht, die Grundursache des Fehlers zu verstehen und plant die Behebung je nach Priorität für den nächsten Release-Zyklus – es könnte im aktuellen Sprint hinzugefügt werden, wenn es sich um eine hohe Priorität handelt, oder sogar in nachfolgenden Sprints. Nachdem der Fehler behoben und veröffentlicht wurde, lebt Mr. Feature, um einen anderen Tag zu sehen, wenn auch in einer reformierten Form – Mr. Feature 2.0 – dank des Produktmanagers und des Engineering-Teams. Hut ab!

T + z Tage

Es heißt, dass alle guten Dinge ein Ende haben müssen. Leider ist das auch bei Mr. Feature der Fall, egal welche Version es ist – vielleicht Mr. Feature 9.263.75! Das bedeutet, dass Mr. Feature ein langes und glückliches Leben geführt hat, aber jetzt ist das Ende des Weges hier.
Es kann verschiedene Gründe haben. Eine neue Funktion kam hinzu, die die Notwendigkeit von Mr. Feature völlig überflüssig machte. Es könnte auch etwas Extremes sein – so wie das Unternehmen entschieden hat, dass die Funktion zwar einen Mehrwert für ihre Benutzer bringt, aber wirtschaftlich keinen Sinn mehr für sie macht.

Egal aus welchem ​​Grund, dem Produktmanager (oder er ist derjenige, der die Diskussion beginnt) wird mitgeteilt, dass die Dienste von Mr. Feature nicht mehr benötigt werden. Nun, so herzzerreißend es auch ist, hat der Produktmanager die Pflicht, Mr. Feature zur Ruhe zu legen. Obwohl er zuvor einige Dinge sicherstellen muss, wie die Benutzer zu informieren, die Mr. Feature verwendet haben, dass es ab einem bestimmten Datum nicht mehr verfügbar sein wird, funktioniert die neue Funktion gut, bevor Mr. Feature entfernt wird, keine andere Flow wird beeinträchtigt, wenn Mr. Feature weg ist, und so weiter.

Es ist also an der Zeit, Mr. Feature RIP zu sagen. In Ihrer Produktmanagementkarriere müssen Sie dies mehrmals tun. Aber denken Sie daran, das Ende eines Features ist der Beginn eines anderen und der Zyklus geht weiter. So ist das Leben im Produktmanagement!

Studieren Sie Produktmanagement-Kurse online von den besten Universitäten der Welt. Erwerben Sie Master-, Executive PGP- oder Advanced Certificate-Programme, um Ihre Karriere zu beschleunigen.

Empfohlenes Programm für Sie: Design Thinking-Zertifizierungsprogramm von Duke CE