In vielen Inhalte-getriebenen Medienorganisationen herrscht der Glaubenssatz: unser Produkt = unser Content. Die Wahrheit ist, dass euer Produkt viel mehr ist als euer Content. Baut Produktkompetenz auf!
- Wie du nutzer*innenzentrierte Produktentwicklung praktizierst
- Wie du deine Wettbewerber und Zielgruppen identifizierst und verstehst
- Wie du ein Produkt entwickelst und verbesserst, indem du Hypothesen testest und Feedback-Kanäle einrichtest
- Input
- Das eigene Angebot vom Produkt her denken
- Dein Produkt ist nicht (nur) dein Content!
- Umsetzung
- Bring Klarheit in dein Produkt
- Mini-Wettbewerbs-Analyse: Lerne deine Konkurrenz kennen
- In die Nutzer*innen-Rolle schlüpfen: Lerne deine Zielgruppe kennen!
- Bau dein Produkt: Was ist die nächste Iteration?
- Phase 1: Backlog
- Phase 2: Review & Refinement
- Phase 3: Umsetzung
- Phase 4: Resonanz [optional]
- Phase 5: Test
Input
Das eigene Angebot vom Produkt her denken
Produktkompetenz kann einen wirklichen Unterschied machen. Gerade in vielen stark Inhalte-getriebenen Medienorganisationen herrscht häufig der Glaubenssatz: unser Produkt = unser Content. Chefredakteur*innen treffen häufig Produktentscheidungen, einfach weil sie diese oder jene neue Funktion cool fänden. (Das ist zugegebenermaßen etwas gemein, aber nicht sehr weit von der Realität entfernt.) Dadurch entstehen Produkte, die vor allem die eigene Redaktion glücklich machen, nicht aber die Nutzer*innen.
Wir glauben: Eines der ganz großen Potenziale für Medienorganisationen liegt darin, Produktkompetenz aufzubauen und das eigene Angebot vom Produkt her zu denken. Die Inhalte sind zwar ein ganz wichtiger Teil des Produkts, aber eben nur ein Teil. Stattdessen geht es darum, die Nutzer*innen in den Mittelpunkt zu stellen und ein gutes Produkterlebnis zu designen.
Dein Produkt ist nicht (nur) dein Content!
5 wichtige Prinzipien, die dir dabei helfen, eine Produkt-Perspektive aufzubauen.
Nicht falsch verstehen: Es ist auf jeden Fall gut, wenn du große Nähe zu deinem Produkt hast und selbst zu deiner Nutzer*innenschaft gehörst. Bei der Produktentwicklung ist es aber wichtig, einen gesunden Abstand zu deinen eigenen Annahmen zu gewinnen. Frag deine Nutzer*innen! (Übrigens: Genauso wenig wie für dich baust du dein Produkt für andere Journalist*innen oder Medienschaffende. Nicht denen muss dein Produkt gefallen, sondern deinen Nutzer*innen.)
Es schmerzt: Dein Produkt wird niemals fertig werden. Und in der Regel wird es auch nicht da ankommen, wo du es gerne hättest, wenn du alles umsetzen könntet, was du dir ausmalst. Produktentwicklung geschieht in kleinen Schritten. Brich deine Produktwünsche in kleine, durchführbare Schritte herunter – und sei geduldig.
Dieser Punkt ist eine Ergänzung zum vorherigen Punkt. Sei bereit, in kleinen, unfertigen Versionen zu denken. Identifiziere bei jeder Produktanpassung den eigentlichen Kern und schneide alles Überflüssige ab. Die Wahrheit ist: Mehr als 50 Prozent dessen, was du willst, sind überflüssig.
Gleichzeitig gilt: Dein MVP sollte wirklich eine kleine Version deines Produkts oder Features sein, also ein Grundniveau an Funktionalität, Verlässlichkeit, Nutzer*innenfreundlichkeit und Design mitbringen. Sonst hat das MVP nichts mit deinem eigentlichen Vorhaben zu tun und entsprechend wenig Aussagekraft.
Deine Intuition ist wichtig. Trainiere sie und verlasse dich in schwierigen Situationen darauf, vor allem bei inhaltlichen Entscheidungen. Gleichzeitig finden wir: (Journalistische) Medienunternehmen haben in der Regel genug Raum für Intuition und brauchen Unterstützung mit Fakten. Dein Produkt kann ein wenig kühle Distanz gut vertragen.
Frage dich bei jeder Annahme: Was sagen mir die Daten? Welche konkreten Beobachtungen habe ich, die meine Annahme stützen?
In Inhalte-getriebenen Unternehmen haben diejenigen, die die Inhalte verantworten, eine wichtige Position. Das ist verständlich, schließlich galt im Printbereich für eine sehr lange Zeit: Die Inhalte waren das komplette Produkt. Das Problem heute: Ins Internet gestellte Artikel sind kein (gutes) Produkt. Die Anforderungen an und Möglichkeiten mit digitalen Produkten sind riesig.
Umsetzung
Auf in die Umsetzungsphase! Wir gehen davon aus, dass du auf dieser Seite bist, weil du schon ein Konzept oder sogar eine erste Version deines Produktes hast. Das ist gut so. Unsere Erfahrung ist: Produkte, die echte Probleme lösen, entstehen nicht in Design-Thinking-Workshops.
Bring Klarheit in dein Produkt
Es gibt unzählige Schaubilder und Frameworks, die dir dabei helfen, dein Vorhaben zu strukturieren und mehr Klarheit in dein Produkt zu bekommen. Unten findest du eine Produktkarte, die deinen Fokus schnell aufs Formulieren und Testen von Hypothesen verschiebt.
Das ist meine Idee:
- xxx
- xxx
- xxx
Dieses Problem will ich lösen:
- xxx
- xxx
- xxx
Produktvision (dort stehe ich in 3–5 Jahren):
- xxx
- xxx
- xxx
Das sind die fünf wichtigsten Hypothesen, die ich untersuchen muss, um dorthin zu kommen:
Hypothesen | Daran kann ich ablesen, ob sie eingetroffen sind |
Hypothese 1 | |
Hypothese 2 | |
Hypothese 3 | |
Hypothese 4 | |
Hypothese 5 |
Mini-Wettbewerbs-Analyse: Lerne deine Konkurrenz kennen
Du solltest wissen, welche anderen Unternehmen in deinem oder einem unmittelbar benachbarten Bereich unterwegs sind. Deine Wettbewerber zu kennen, kann dir dabei helfen, dein eigenes Profil zu schärfen.
Schau nicht nur auf deine komplett offensichtlichen Wettbewerber! Ein Produkt, das wir bei Neue Narrative entwickelt haben, ist die Tool-Plattform 9 Spaces. Dort veröffentlichen wir Tools und Methoden, die Teams dabei helfen sollen, ihre Organisation zu transformieren (z.B. als PDF und als Whiteboard-Vorlage).
Natürlich gibt es Produkte wie den Trainerkoffer von managerSeminare, die einen ähnlichen Ansatz verfolgen und zu denen wir uns positionieren müssen. Zwei Wettbewerber, die wir lange nicht präsent hatten, sind die Whiteboard-Plattformen Miro und Mural. Die entwickeln sich in den vergangenen Jahren immer stärker zu Content-Plattformen und bieten eigene sowie Nutzer*innen-generierte Whiteboard-Templates an.
Diese Beobachtung hat bei uns dazu geführt, dass wir uns mittlerweile weniger als möglichst vollständige Datenbank mit New-Work-Methoden verstehen – das lässt sich sehr leicht kopieren –, sondern mehr Fokus auf gute inhaltliche Kuratierung sowie NN Originals legen.
In die Nutzer*innen-Rolle schlüpfen: Lerne deine Zielgruppe kennen!
Ganz sicher hast du schon einmal von Personas gehört. Das sind Personenprofile, die typisch für dein Produkt sind und eine größere Nutzer*innengruppe repräsentieren sollen. Wir sind keine Riesenfans von klassischen Personas mit Vornamen, Hobbys etc., weil sie dazu einladen, in Schubladen zu denken.
Was du aber tun solltest: Halte deine wichtigsten Zielgruppen fest und konzentriere dich auf ihre Bedürfnisse, Motivationen und potenziellen Tagesabläufe. Die Karten unten helfen dabei, deine Nutzer*innenschaft im Blick zu behalten:
Geschätzter Anteil an Gesamtnutzer*innen: 40 Prozent
Bedürfnisse, die Produkt erfüllt
- Neues Methodenwissen und Inspiration für eigene Arbeit
- …
- …
- Sucht Formatideen zum Thema Meetings für einen Workshop nächste Woche
- Scannt die Inhaltsverzeichnisse aller Ausgaben nach dem Stichwort „Meeting“
- Überfliegt alle entsprechenden Artikel
- Baut zwei Schaubilder aus den Artikeln für eine Power-Point-Präsentation nach
- Kopiert einen Artikel und bringt ihn Teilnehmer*innen mit
Geschätzter Anteil an Gesamtnutzer*innen: X Prozent
Bedürfnisse, die Produkt erfüllt
- Hier steht ein Bedürfnis, das du identifiziert hast
- …
- …
- …
- …
- …
Geschätzter Anteil an Gesamtnutzer*innen: X Prozent
Bedürfnisse, die Produkt erfüllt
- Hier steht ein Bedürfnis, das du identifiziert hast
- …
- …
- …
- …
- …
Geschätzter Anteil an Gesamtnutzer*innen: X Prozent
Bedürfnisse, die Produkt erfüllt
- Hier steht ein Bedürfnis, das du identifiziert hast
- …
- …
- …
- …
- …
Gerade wenn du mit deinem Produkt noch ziemlich am Anfang stehst, kennen deine Nutzer*innen dein Produkt häufig besser als du selbst. Was wir damit meinen: Du hast Annahmen und Vorstellungen darüber, wie deine Nutzer*innen dein Produkt nutzen. Wenn du lediglich diesen Annahmen nachgehst und sehr spitze Interviews führst, verpasst du die Chance, Seiten deines Produkts kennenzulernen, an die du bis dahin gar nicht gedacht hast.
Fragen, die dir dabei helfen, dein Produkt besser kennenzulernen, sind zum Beispiel:
- Nimm mich in einen ganz normalen Tag mit, an dem du [Produktname] nutzt. Wie läuft so ein Tag genau ab?
- Welche typischen Situationen fallen dir ein, in denen du [Produktname] nutzt?
- Ich würde gerne mehr über die Situation [X, Situation von oben aufgreifen] erfahren.
- Was hast du unmittelbar davor gemacht?
- Weißt du noch, warum genau du entschieden hast, [Produktname] in der Situation zu nutzen?
- Du hast dann also zu [Produktname] gegriffen. Erzähl mir chronologisch, was du mit [Produktname] gemacht hast …
- Was war deine allererste Aktion?
- Was hast du danach gemacht?
- Wie ging es weiter?
- …
- Erinnerst du dich daran, wie du dich gefühlt hast, als du zu [Produktname] gegriffen hast?
- Was hast du gemacht, nachdem du aufgehört hast, [Produktname] zu nutzen?
Bau dein Produkt: Was ist die nächste Iteration?
Im kleinen Team sieht eure Produktentwicklung vermutlich so aus: Jemand hat eine Idee und irgendwer setzt sie um. Je größer euer Produkt-Team und je komplexer euer Produkt wird, desto dringender braucht ihr aber einen klaren Prozess, den jeder Vorschlag für eine Produktveränderung Schritt für Schritt durchläuft.
- Möglichst viele Organisationsmitglieder sind Sensoren für Veränderung und bringen ihre Ideen und Spannungen bzgl. unserer Produkte ein.
- Die Priorisierung der Vorschläge erfolgt transparent. Wird ein Vorschlag abgelehnt, begründen wir das in den Kommentaren.
- Alle Menschen in der Organisation haben eine Idee davon, welche Features als nächstes bearbeitet, welche gerade umgesetzt werden und welche zuletzt live gegangen sind.
Der folgende Prozess ist für die Entwicklung von digitalen Produkten konzipiert. Ihr solltet für diesen Prozess ein digitales Projektmanagement-Tool mit Ticketsystem verwenden, wie z.B. Notion oder Asana. Solltet ihr ein Produkt wie z.B. ein Printmagazin entwickeln, springt jetzt nicht ab. Wir sind ziemlich sicher, dass ihr viele Bausteine des Prozesses auf euer Produkt anwenden könnt. Es braucht nur ein bisschen Transferarbeit.
Wir schlagen folgende fünf Phasen für einen funktionierenden Produktentwicklungsprozess vor:
Phase 1: Backlog
Einer der allerwichtigsten Orte für eure Produktentwicklung ist der Product Backlog. Das ist in der Regel eine lange Liste, die jedes Mitglied eurer Organisation einsehen und befüllen kann. Ziel eines offenen Backlogs ist es, alle Menschen bei euch zu Sensoren und Treibern der Veränderung zu machen. Häufig wissen nämlich gar nicht diejenigen, die unmittelbar am Produkt arbeiten, am besten darüber Bescheid, welche Anforderungen die Nutzer*innen an das Produkt haben. Meistens sind es eher Personen, die viel direkten Nutzer*innenkontakt haben – beispielsweise, weil sie im Customer Support oder Sales arbeiten.
Wer etwas an eurem Produkt verändern möchte, legt ein neues Ticket an. Ihr könnt zwei Ticket-Typen unterscheiden:
Bug-Tickets dienen dem Melden von Fehlern oder Auffälligkeiten in eurem Produkt. Das kann beispielsweise ein kaputter Link sein oder ein Abstand zwischen zwei Elementen, der nicht stimmt. Bug-Tickets sollten neben einer kurzen Beschreibung auch ein Bild von der entsprechenden Auffälligkeit enthalten.
Feature-Tickets sind dafür da, dass etwas Neues entsteht. Diese Tickets beschreiben Wünsche für neue Funktionen, die euer Produkt in Zukunft bekommen soll. Wichtig ist, dass jedes Feature-Ticket vier Informationen enthält:
- Name der einreichenden Person
- Anwender*innentyp: Aus welcher Rolle heraus wird das Ticket geschrieben (z.B. CMS-Redakteur*in, Sales-Rolle)
- Ziel / Wunsch / Funktion: Was möchte ich genau erreichen? Was ist mein Ziel?
- Nutzen: Was sind die Gründe, warum ich den Feature-Wunsch einreiche? Welches Problem löst das?
Um eure Tickets schnell erfassbar zu machen, könnt ihr mit einer Textvorlage arbeiten, die alle Personen ausfüllen müssen, wenn sie ein neues Ticket einreichen:
Als <Anwendertyp>
möchte ich Ziel / Wunsch / Funktion
erreichen, aus folgenden Gründen:
Nutzen
Nutzen
Nutzen
Phase 2: Review & Refinement
In dieser Phase reviewt und priorisiert das Produkt-Team gemeinsam die Tickets. Zunächst geht es dabei darum, ein gemeinsames Verständnis zu schaffen:
- Was ist der Nutzen?
- Was ist der Aufwand?
- Welche Risiken gibt es?
- Gibt es Verständnisfragen an die Person, die das Ticket eingereicht hat?
Die Priorisierung erfolgt in der Regel in einem gemeinsamen Aushandlungsprozess. Dieser kann bei Bedarf von einer Product-Owner-Rolle moderiert werden:
In derselben Phase wird das Ticket zudem aufpoliert und vervollständigt. Das Ticket ist bereit für die nächste Phase, wenn es folgende Kriterien erfüllt:
Phase 3: Umsetzung
Diese Phase ist schnell erklärt. Die Personen, in deren Rolle das jeweilige Ticket fällt, setzen es um.
Phase 4: Resonanz [optional]
Diese Phase ist vor allem für komplexere Features sinnvoll. Sie ist ein Zwischenschritt im Umsetzungsprozess und soll das Risiko der neuen Produktversion gering halten. Das hat folgenden Hintergrund. Es gibt Produktentwicklungen, da dauert die Umsetzung mehrere Wochen oder Monate und beschäftigt gleich ein ganzes Team. Mit einer solchen Größe geht auch eine große Fallhöhe einher:
- Es kann passieren, dass ihr etwas entwickelt, von dem ihr zwar glaubt, dass es ein Problem für eure Nutzer*innen löst, es aber gar nicht tut.
- Zudem lässt sich der Aufwand einer Produktverbesserung zwar im Vorfeld schätzen, in der Umsetzung entstehen aber manchmal unvorhergesehene Folgeprobleme, die den Aufwand explodieren lassen.
Um die Risiken möglichst gering zu halten, könnt ihr einen schnellen Prototypen eures Features entwickeln und diesen in einer internen Resonanzrunde und / oder Nutzer*inneninterviews zwischentesten. So verhindert ihr, dass ihr zu lange in eine möglicherweise falsche Richtung lauft.
Phase 5: Test
Mit dieser Phase schließt sich der Kreislauf. Damit die Neuerung auch reibungslos funktioniert, sollte eine Person, die nicht direkt an der Umsetzung beteiligt war, einen strukturierten Test durchführen.
Im ersten Schritt erstellt die Person, die die neue Funktion umgesetzt hat, eine Liste mit Testfällen. Worauf muss der die Tester*in achten?
⤵️
- Bitte ZY testen ✅ ⚠️ ❌
- ...
Im zweiten Schritt bearbeitet die testende Person Punkt für Punkt die Liste mit den Testfällen. Mögliche Auffälligkeiten meldet sie der umsetzenden Person zurück. Sollte die Entwicklung noch größere Anpassungen brauchen, geht das Ticket zurück in Phase 3.
Im Folgenden findest du eine Rollenbeschreibung für die Rolle Ticket-Tester*in.
<Anwendertyp>
möchte ich Ziel / Wunsch / Funktion
erreichen, aus folgenden Gründen: Nutzen
<Anwendertyp>
möchte ich Ziel / Wunsch / Funktion
erreichen, aus folgenden Gründen: Nutzen
<Anwendertyp>
möchte ich Ziel / Wunsch / Funktion
erreichen, aus folgenden Gründen: Nutzen
<Anwendertyp>
möchte ich Ziel / Wunsch / Funktion
erreichen, aus folgenden Gründen: Nutzen