7Viele Produktmanager und UX Designer nennen, wenn man sie nach ihren Lieblingsprodukten fragt, die Produkte von Apple als ihre Favoriten. Hauptgrund für diesen Zuspruch ist meist die Einfachheit und die intuitive Bedienung, die nach wie vor herausragenden Merkmale der Produkte aus Cupertino.
Einfachheit ist uns (und natürlich auch unseren Kunden und Nutzern) wichtig – warum aber fällt es uns so schwer, selber einfache Produkte zu gestalten bzw. unsere Produkte schlank zu halten?
Ein Grund hierfür mag sein, dass es eine große Herausforderung ist, auch anfänglich einfache Produkte fokussiert und einfach zu belassen. Denn die meisten Produkte tendieren leider dazu, mit der Zeit immer mehr Features “anzusetzen” und damit komplexer und schwieriger bedienbar zu werden. Stakeholder kommen mit immer neuen Anforderungen um die Ecke, Nutzer wünschen sich zusätzliche Möglichkeiten (die häufig unreflektiert aufgenommen und ins Produkt integriert werden) und auch wir Produktmanager sind ja schließlich dafür da, unser Produkt zu verbessern, erweitern und neue Funktionen zu bauen. Oder etwa nicht?
Das Problem hierbei ist, dass jedes zusätzliche Feature in einem Produkt auch unweigerlich zu mehr Komplexität führt, Platz im User Interface benötigt und somit das Produkt schwerer zu bedienen macht. Aber auch auf technischer Seite bringt ein neues Feature Nachteile mit sich: es gibt mehr Code der geschrieben, verstanden und gewartet werden muss und die technischen Abhängigkeiten bei der Weiterentwicklung eines Produktes sind größer.
Kurzum: Nutzer bevorzugen einfache Produkte, wir Produktmanager und UX Designer sowieso und auch die Entwickler tun dies und schmeißen daher gerne auch wieder Features raus (ok, gute Entwickler wollen das… nur die Schlechten hängen an jeder Zeile Code, die ja nicht umsonst geschrieben wurde).
Was also kann man tun, um einer Featuritis vorzubeugen und ein Produkt schlank zu halten? Hierzu gibt es verschiedene Ansätze und Möglichkeiten, die ich im Folgenden beschreiben werde.
Mit einem MVP starten
Wenn man mit einem neuen Produkt startet, hat man einen unschlagbaren Vorteil: es gibt noch keine Funktionen und damit kein komplexes Produkt. Wenn man wirklich auf der grünen Wiese beginnen kann, sollte man nicht allzu lange warten und viele Funktionen umsetzen, sondern so früh wie möglich mit einem MVP (Minimum Viable Produkt) starten. Wie das geht habe ich bereits in einem älteren Artikel umfassend beschrieben.
Wichtig hierbei ist, dass das MVP nur die wirklich relevanten Funktionen beinhalten sollte – die Funktionen, die dazu dienen, den Kernwert des Produktes zu transportieren und für den Nutzer erfahrbar zu machen.
Neue Features schon vor der Implementierung auf Sinnhaftigkeit und Nutzwert prüfen
Möchte man seinem bestehenden Produkt (oder MVP) weitere Funktionen hinzufügen, sollte man dies mit Bedacht tun. Hierzu gehört, dass man
- zunächst überlegt, welche (Nutzer)-Ziele man mit den neuen Funktionen erfüllen möchte.
- entsprechende Hypothesen aufstellt, warum die Funktion benötigt wird.
- festlegt, wann die Funktion erfolgreich ist.
- Metriken definiert, mit denen man den Erfolg messen kann.
Anschließend sollte man eine Product Discovery durchführen, in der man versucht herauszufinden, ob die Hypothesen richtig sind und wie die Nutzer-Ziele optimal durch das Produkt (oder ein Feature) bedient werden können.
Erst wenn die Hypothesen belegt wurden und eine zufriedenstellende Lösung identifiziert wurde, sollte das Feature in die Entwicklung gehen.
Feature-Erfolg nach der Implementierung validieren
Wird eine Funktion, die sich in der Product Discovery als sinnvoll und vielversprechend herausgestellt hat, umgesetzt, so ist Eines essentiell: die Messbarkeit des Erfolgs muss auf jeden Fall gewährleistet werden!
Dies bedeutet in der Regel, dass für die Funktion ein entsprechendes Tracking und Analysemöglichkeiten implementiert werden müssen. Meine Erfahrung zeigt, dass es sich hierfür lohnt, für jede User Story, die durch die Entwickler umgesetzt wird, auch eine entsprechende Trackingmöglichkeit (z.B. als Teil der Definition of Done der jeweiligen Story) mit aufzunehmen.
Auch ist es in der Regel wichtig, die Funktion nicht gleich für alle Nutzer live zu stellen, sondern zunächst einen AB- oder Split-Test durchzuführen, in dem nur eine (repräsentative) Teilgruppe die Funktion sehen und nutzen kann. Dies ist daher wichtig, da ein Vergleich von Daten im zeitlichen Verlauf nur bedingt aussagekräftig ist, da hierbei andere Effekte (z.B. Jahreszeiten oder andere saisonale Effekte) die Daten verfälschen können – was letztlich dazu führt, dass man den Erfolg des Produktes nicht mehr richtig bewerten kann.
Wurde die Funktion implementiert und erfolgreich live geschaltet (für die Testgruppe), dann fließen endlich echte Nutzerdaten. Nur diese können uns zeigen, ob das Feature tatsächlich seinen Zweck erfüllt und erfolgreich ist! Die Daten sollten regelmäßig von allen Beteiligten kontrolliert werden – aber Vorsicht vor voreiligen Schlüssen! Denn eine Signifikanz der Ergebnisse ergibt sich häufig und je nach Menge der Nutzer erst nach einiger Zeit. Vorher sind bestenfalls Tendenzen zu erkennen.
Mut zum Abschalten einer Funktion
Daher lohnt es sich, nach einem hinreichend langen Zeitraum (z.B. eine Woche oder ein Monat nach Livegang) ein Entscheidungsmeeting einzuberufen. In diesem Meeting sollten alle Beteiligten, also Produktmanager, Designer, Entwickler und alle relevanten Stakeholder – darunter insbesondere auch der Ideengeber oder Anforderer – teilnehmen. Nun werden die Daten und Analysen betrachtet, bewertet und es wird entschieden, wie es mit der Funktion weitergehen soll.
Prinzipiell gibt es dazu drei Möglichkeiten:
- Die Funktion hat die definierten Ziele erreicht, die Hypothese wurde bestätigt und die Funktion wird daher Teil des Produkts für alle Nutzer.
- Die Funktion hat die Ziele nur in Teilen erreicht, die Hypothese nur zu Teilen bestätigt. Dann muss geklärt werden, ob es Ideen zur Abwandlung gibt. Hier lohnt sich auf jeden Fall auch eine genauere Analyse der Daten oder auch ein User-Test, der Klarheit bringt. Die Funktion sollte ggf. temporär abgeschaltet, weiterentwickelt und dann erneut getestet werden.
- Die Funktion hat die Ziele gar nicht erreicht, keine anderen erkennbaren Mehrwerte gebracht oder die anfängliche Hypothese sogar ganz widerlegt. Schade um die Zeit und Ressourcen, die für die Implementierung investiert wurden. Aber keine Scheu und raus mit der Funktion! Eventuell lohnt es sich aber nochmal, die Ergebnisse der Discovery erneut zu analysieren und zu hinterfragen, denn vielleicht kann man trotzdem etwas für die Weiterentwicklung lernen.
Die letzte Möglichkeit mag schwer fallen oder anfänglich sogar weh tun. Falls an dieser Stelle Bedenken auftreten so haltet euch und dem Team vor Augen, dass ihr nicht dafür da seid, irgendwelche Funktionen zu bauen und damit das Produkt komplexer zu machen. Nein, ihr seid dafür da herauszufinden, welche Funktionen wirklich einen Mehrwert für den Nutzer bieten und auf die übergreifenden Ziele eures Unternehmens einzahlen!
Funktionen testweise ausbauen
Was aber nun, wenn die oben genannten Empfehlungen zu spät kommen und euer bestehendes Produkt schon unter Featuritis leidet, zu komplex geworden ist oder nicht mehr wartbar ist? Dann gibt es immer noch die Möglichkeit, Split-Tests durchzuführen – allerdings anders herum. Baut einzelne Funktionen für eine repräsentative Testgruppe und für einen begrenzten Zeitraum wieder aus und messt, welche Effekte dies hat. Gehen die relevanten KPIs nach unten, oder tritt gar kein Effekt auf? Im ersten Fall scheint die Funktion einen Mehrwert zu bieten. Im zweiten Fall scheint sie eher überflüssig zu sein.
Wichtig ist hierbei auf jeden Fall auch, dass man sich vorher überlegen sollte, welchen Zweck eine Funktion erfüllen soll und wie sich dieser Zweck messen lässt. Denn einfach nur alle Daten im Nachhinein zu betrachten, kann alles und nichts erklären. Bildet vorher wieder Hypothesen, die ihr be- oder widerlegen könnt!
Einen Relaunch nutzen
Manchmal ergibt sich auch eine ganz andere Möglichkeit zu testen, welchen Wert bestimmte Funktionen für die Nutzer bieten: ein Relaunch. Im Prinzip bin ich kein großer Fan von Big-Bang Relaunches, da diese immer mit vielen Problemen behaftet sind. Aber in manchen Fällen macht ein Relaunch oder ein kompletter Rebuild eines Produktes einfach Sinn (z.B. wenn das alte System auf einer veralteten technischen Architektur oder Infrastruktur basiert).
Diese Gelegenheit kann man dann prima dafür nutzen, die Sinnhaftigkeit gewisser Funktionen zu hinterfragen. Denn in der Regel können bei einem Relaunch oder Rebuild nicht alle Funktionen von Anfang an wieder integriert werden, da dies den Scope und damit das Timing sprengen würde. Daher wird in dieser Situation automatisch mit einer Art MVP gearbeitet: ein neu aufgesetztes Produkt, das nicht alle Funktionen (aber in der Regel die notwendigsten) enthält.
Meist gibt es bei einem Relaunch dann eine lange Liste von Funktionen, die nachgezogen und in das neue Produkt integriert werden sollen. Eine perfekte Gelegenheit also, die Funktionen zu validieren. Dies kann entweder wie bereits oben beschrieben vor der Implementierung geschehen (durch eine Discovery) oder nach der Implementierung durch eine Analyse der zuvor definierten Metriken (mittels Split-Test). Wichtig ist hierbei jedoch genauso, dass entsprechende Tracking- und Analysemöglichkeiten gleich mit in das neue gelaunchte Produkt integriert werden.
Ich persönlich hatte schon zwei Mal die Gelegenheit, bei entsprechenden Relaunches dabei zu sein: einmal bei XING im Juni 2011 und im letzten Jahr bei OTTO. Beide Male ist die jeweilige Seite mit reduziertem Funktionsumfang neu live gegangen und beide Male haben sich viele Gelegenheiten ergeben herauszufinden, welche Funktionen wirklich relevant sind und welche weniger.
Wichtig ist jedoch, dass man sich zur Validierung der Funktionen nicht ausschließlich auf qualitatives Nutzerfeedback verlässt, sondern auch in die quantitativen Verhaltensdaten schaut. Denn erfahrungsgemäß beschweren sich bei einem Relaunch die Heavy-User am lautesten über das Fehlen einer Funktion – diese müssen aber nicht zwangsläufig maßgeblich für die Integration (oder das Weglassen) einer Funktion sein.
Daten-getriebene Produktentwicklung
Die oben beschriebenen Vorgehensweisen sollen euch Ideen aufzeigen, wie man sein Produkt schlank halten kann. Eine Sache ist dabei von besonderer Relevanz: das ganze Team und auch die Stakeholder müssen die Macht der Daten verstanden haben!
Jeder einzelne, der an der Produktentwicklung mitarbeitet (sei es der Ideengeber oder aber der Entwickler und QAler) sollte immer wieder hinterfragen, ob eine Funktion relevant ist und in die Daten schauen können, wie die Funktion performt. Jede einzelne Funktion sollte validiert werden, bevor sie endgültig in das Produkt integriert wird.
Hat man diese Daten-getriebene Denkweise im Unternehmen integriert, sprechen künftig (hoffentlich) die Fakten dafür, welche Funktion wichtig ist und welche nicht… und nicht mehr die Meinung eines HIPPO (Highest Paid Person’s Opinion).
Vielleicht müssen wir zum Eindämmen der Featuritis ein „Maximum Viable Product“ definieren: Sobald ein definiertes Maximum an Features bzw. Komplexität erreicht ist, müssen erst alte Features ausgebaut werden, damit neue genehmigt werden.
Als anderen Ansatz hätte ich noch folgende Idee: Bei der Kosten-Nutzen-Bewertung für ein neues Feature werden nicht nur die Entwicklungskosten veranschlagt, sondern zusätzlich ein monatlicher Posten, der die gestiegene Komplexität des Gesamtprodukts repräsentiert. Dieser Posten stellt indirekte Kosten durch ein komplexeres User Interface, erschwerte Wartbarkeit, Performance-Einbußen usw. dar. Je nach Umfang des Features und nach Feature-Anzahl des Gesamtprodukts wird dieser Posten teurer. Erst wenn der zu erwartende Ertrag die Entwicklungskosten und die monatlichen Kosten dauerhaft übersteigt, wird es entwickelt. (Und wenn der monatliche Ertrag irgendwann die monatlichen Kosten sogar unterschreitet, wäre das ein Indikator, dieses Feature wieder auszubauen.)
Natürlich ist es erstrebenswert, dass Fakten statt HIPPOs Entscheidungen begründen. Man sollte aber nicht vergessen, dass diese Fakten häufig Interpretationen sind bzw. auch Testergebnisse nicht immer direkt Wissen darstellen, sondern auf Interpretationen angewiesen sind. Ganz zu schweigen davon, dass auch beim Erheben von Kennzahlen, Testergebnissen etc. Fehler auftreten können. Die klassische Analyse des Wissens z.B. sagt, dass Wissen immer auch Glauben erfordert. Bei aller Liebe zu datengetriebenen Ansätzen sollten wir also aufpassen, dass wir uns dabei nicht selber etwas vormachen und einfach nur nach den Zahlen suchen, die unseren eigenen Glauben bestätigen.
Mit Bezug auf die Featuritis ist manchmal gar nicht so einfach, Produkte wirklich schlank zu halten. Hier denke ich vor allem an eine psychologische Komponente bei Entscheidungen. Jemand muss seine Entscheidung rechtfertigen oder später bei Fehlentscheidungen seinen Kopf dafür hinhalten. Aus meiner Sicht spricht das für die Tendenz, möglichst viele Features im Produkt zu lassen. Etwas zu haben, was am Ende keiner braucht, ist weniger schlimm, als etwas Wesentliches vergessen zu haben. Damit bedarf es einer Unternehmenskultur, Fehler zuzulassen, und eines Umfeldes, Ergänzungen später leicht hinzu zu fügen.
Solange ich mit meiner Anwendung auf die UX einer Browser-Applikation abziele, habe ich ein Umfeld, wo ich mich dem wahren Soll experimentell und iterativ leichter nähern kann. Blicke ich auf die Hardware von Anwendungen, so ist es aus meiner Erfahrung stets so gewesen, dass die nach 6-12 Monaten stehen musste und dann unverändert blieb. Das war und ist notwendig, um alle nachfolgenden Integrationsschritte mit der Softwareanwendung darauf durchführen zu können, um überhaupt ein konstantes Umfeld für die weiteren Entwicklungsschritte zu haben. Mit Bezug auf Hardware fällt es Menschen daher noch viel schwerer, auf Features zu verzichten. Meine Erfahrung war hier jedoch, dass es auch bei Hardware besser ist, sich von den Features einzugrenzen. Denn Features, die am Ende keiner benötigt, aber doch implementiert werden, kosten einfach Zeit und verzögern den Fertigstellungstermin. Im Großkonzern hatte damals nur keiner den Mut, sich zum schlanken Produkt zu entscheiden. Ich denke, das dies eine Erwähnung wert ist, weil ein Produkt aus Hardware und Software genauso zu einer UX führt und beides dann das Erlebnis mit dem Produkt kennzeichnet.
Jemand wie Steve Jobs hatte die Kultur der Vereinfachung und einer guten Produktphilosophie im Blut. Ihm war nicht nur das Verkaufen wichtig, sondern auch das kleinste Detail und der Herstellungsprozess. So ließ er laut Autobiographie selbst die Fertigungsstraßen seiner Produkte in einer bestimmten Farbe streichen und achtete auch auf die Details, die Normalkunden meist nie sehen. Für ihn war auch das Unsichtbare Teil des Produkts, wo Menschen meist dazu neigen, nur auf die äußere Fassade zu schielen. Für jemanden an oberster Stelle und oben in der Hierarchie im Unternehmen ist es weitaus einfacher Ziele verbindlich vorzugeben als an den Positionen darunter. Nicht alles kann durch eine Art Revolution von unten getrieben werden, wenn es an höheren Stellen nicht gewollt oder blockiert wird. Um ein Produkt schlank zu halten, müssen alle Stellen im Unternehmen hierzu mitziehen, damit die gute Idee dahinter nicht irgendwo auf halber Strecke stecken bleibt.
Hallo Detlev, ich stimme dir zu: um ein Produkt schlank zu halten, hilft es, wenn es eine grundlegenden Übereinkunft im Unternehmen gibt, dass Einfachheit eine wichtige Produkteigenschaft ist. Wenn dies vom Management getragen oder sogar (siehe Apple / Steve Jobs) forciert wird, dann macht es die Arbeit des Produktmanagers umso einfacher.
Leider ist dem aber ja nicht immer so und in vielen Unternehmen herrscht die von dir beschriebene Angst, etwas weg zu lassen – oder alternativ die Tendenz, dass jeder seine Feature-Wünsche unterbringen will und muss, ohne sie zu hinterfragen. Häufig ist es dann ja leider sogar so, dass niemand den Kopf hinhalten muss, selbst wenn das Feature den gewünschten Effekt nicht bringt.
Hier sehe ich es dann als Aufgabe des Produktmanagers, auch bei fehlendem Bewusstsein im Management oder anderen Bereichen, dafür zu sorgen, dass Feature-Ideen hinterfragt werden, getestet werden und beim Verfehlen der erwünschten Ziele auch wieder ausgebaut werden. Arbeitet man Daten-getrieben, hat man dann auch die passenden Argumente an der Hand, dies den entsprechenden Stakeholdern auch zu erklären… und vielleicht schafft man es dann ja sogar, die Kollegen dahingehend zu erziehen, dass sie auch nicht gleich mit jeder (Feature)-Idee ankommen und auf Umsetzung drängen, sondern diese selbst er einmal zu hinterfragen, klare Ziele zu definieren und eine Bereitschaft zu zeigen, sich von Ideen auch wieder zu trennen.
Hallo Rainer,
ich sehe das so, dass bei aktuell bei Otto oder Xing oder aus meiner Erinnerung bei Blaupunkt damals oder gewissen Zulieferern von CPU-Produkten und damit bereits bei größeren Unternehmen durchaus die Stelle eines Produktmanagers bereits geschaffen ist. Damit existiert dort ein Umfeld, wo ein Produktmanager in seiner Funktion gewollt als auch fürs Unternehmen als notwendig in seiner besonderen Rolle angesehen wird. Zudem ist das Geld vorhanden, sich so eine Stelle zu leisten. Somit hat der Produktmanager eine Chance, sich im Unternehmen für weniger Features stark zu machen.
Nun kenne ich jedoch viel kleinere Unternehmen im Gegensatz dazu. Wir reden hier über Firmen mit 30-100 Mitarbeiter. Dort ist es eher so, dass die Rolle des Produktmanagers durch einen anderen Funktionsträger nebenbei oder verteilt auf viele Schultern irgendwie miterledigt wird. Der Hauptaktionsbereich dieser Personen ist jedoch eine andere Rolle als die des Produktmanagers. Speziell in Großkonzernen gibt es eine Vorentwicklung, wo zwar künftige Produkte entwickelt und ausgedacht werden, aber ein Produktmanager noch nie ein Thema war. Dennoch werden auch dort Vorprodukte entwickelt. Aus diesen Vorentwicklungen entstehen dann Spin-Offs und die nehmen dann ihr Nichtwissen über die Rolle eines Produktmanagers erstmal mit.
Damit sehe ich fern von den Aufgaben und Möglichkeiten des Produktmanagers eine große Baustelle darin, das Wissen und Bewusstsein bei vielen erst zu schaffen, dass eine solche Position notwendig ist, um gute Produkte entwickeln zu können. Weiterhin bedarf es der Beschreibung eines Wegs, wie kleine und weniger finanziell gut aufgestellte Firmen vorgehen sollen, die sich einen extra Posten für einen Produktmanager nicht leisten können. Es heißt, wenn viele verantwortlich sind, ist keiner verantwortlich. Gibt es also eine Alternative, einen Produktmanager zu ersetzen oder ist der Produktmanager stets alternativlos bzw. womit überzeuge ich ein Management und einen Gesellschafter, sich einen Produktmanager zu leisten? Die Realität ist auch, dass es im Unternehmen durchaus mehrere Personen gibt, die einen Produktmanager als notwendig ansehen, aber diese Stelle eines Produktmanagers damit noch lange nicht existiert. Oft ist es so, dass Entscheidungsträger in den Ebenen über einen, gar nicht selbst das Wissen haben oder die Erfahrung gemacht haben, einen Produktmanager einsetzen zu müssen, um bestimmte Ziele auf bestimmte Weise zu erreichen. Da gibt es durchaus gewisse Beratungsresistenz.
Eine Frage ist, ob es Beispiele gibt, woran sich die Wirksamkeit eines Produktmanagers auch in Zahlen nachweisen lässt. Lohnt sich das Investment oder ist es nur eine gute Idee oder schaffe ich eine Produktmanagerstelle nur, weil mich das Modell und Ansinnen dahinter überzeugt hat bzw. weil ich daran glaube? In einer Firma lasse ich nicht zwei Experimente gleichzeitig laufen, um hinterher sagen zu können, dass das Experiment ohne Produktmanager eindeutig schlechter lief. Oft habe ich ja nur den Vergleich zwischen vorher und nachher oder zwischen unterschiedlichen Firmen und Bereichen. Das schafft eine Kluft, es für sich als nicht relevant einzustufen.
Ich denke, es gibt eine Hürde, von der Idee eines Produktmanagers auch zu einem wirkenden Produktmanager in einer Firma zu kommen, selbst wenn die Rolle nur in Personalunion ausgefüllt wird. Wenn ich dann diese bessere Ebene erreicht habe, dann kann sich der Produktmanager gegen eine unnötige Featuritis stark machen. Ohne Produktmanager sehe ich ein Problem, sich wirksam der Featuritis entgegen zu stemmen.
Viele Grüße
Detlev
Hallo Detlev,
ich sehe was du meinst. Es wäre schön und sinnvoll, wenn es eine dezidierte Rolle und Position für Produktmanager im Unternehmen gibt, aber dies ist in der Realität natürlich nicht immer möglich. Gerade kleinere Unternehmen und Startups haben häufig nicht die Ressourcen, einen eigenen Produktmanager einzustellen.
Aber meiner Meinung nach ist es auch nicht unbedingt nötig, eine Person mit der Rolle “Produktmanager” zu haben. Viel wichtiger ist es, dass es jemanden gibt, der die Funktionen und Aufgaben eines Produktmanagers übernimmt. Irgend jemand muss sich verantwortlich zeichnen für:
– Produktvision und Produktstrategie
– Kontakt zum Kunden / Nutzer
– Identifizieren von Nutzerbedürfnissen und -Problemen
– Durchführung von Discoveries zur Identifikation von Lösungen
– Erstellung einer Produkt-Roadmap
– Priorisierung von Ideen und Features (-> inkl. Vermeidung von Featuritis)
– Spezifikation von Anforderungen und Features
– Stakeholder-Management
– etc.
Dies muss nicht eine spezielle Person sein, sondern es können sich auch mehrere Personen diese Aufgaben teilen. Wichtig ist nur, dass alle Aufgaben und Verantwortlichkeiten abgedeckt sind.
In Startups übernimmt beispielsweise häufig der Gründer, CEO oder CTO die Aufgaben des Produktmanagers. Oder es kann ein UX-Designer sein, der einen Teil davon verantwortet.
Unser Blog und die Beiträge darin richten sich nicht ausschließlich an Produktmanager und UX-Designer, die diese Rollen auch inne haben, sondern an jeden, der ein erfolgreiches Produkt entwickeln will. Wenn es keinen dezidierten Produktmanager in einem Unternehmen gibt, dann sind unsere Anregungen für denjenigen bzw. diejenige gedacht, der die Verantwortung für den Erfolg eines Produktes hat.
Hallo Rainer,
ja, das sehe ich auch so. Es muss nicht zwangsweise eine extra Person sein, die den Job des Produktmanagers macht. So können auch kleinere Firmen, die Aufgaben eines Produktmanagers umsetzen. Allerdings wird das sicher viel Disziplin, Wissen und eine gute Organisation erfordern, dies in einem Team aus mehreren umzusetzen.
Viele Grüße
Detlev