The Product Field im Einsatz bei TiO – ein Erfahrungsbericht

The Product Field im Einsatz bei TiO

Auf der diesjährigen Mind The Product Engage in Hamburg haben wir von dem Product Field erfahren und an einem Workshop zur Methodik teilgenommen. Nun wollten wir unser Wissen in die Praxis umsetzen und anhand unseres neuen Produkts TiO – der Sprachcoach unsere ersten realen Erfahrungen mit dem Product Field sammeln.

Um was geht’s beim Product Field?

Das Product Field zielt darauf ab, die Komplexität der Produktentwicklung aufzudecken und zu veranschaulichen. Dabei wird das Augenmerk nicht nur auf Lösungsansätze und Funktionen gesetzt, sondern auch ein Blick auf die strategischen Ziele, die benötigten Ressourcen und das Rahmengerüst der Entwicklungsarbeit geworfen.

Die Vorteile liegen somit auf der Hand:

  • Im Team ein geteiltes Verständnis für Product Thinking schaffen
  • Den Gesamtkontext der Produktentwicklung überblicken und die Bemühungen auf Kurs halten
  • Die Value Proposition finden, klären und stärken
  • Blinde Flecken finden und sich auf das Wichtigste fokussieren

Wie sind wir vorgegangen?

Im Surf Office in Cadiz haben wir uns einen Nachmittag Zeit und eine freie Wand geschnappt. Mit Hilfe der Anleitung konnten wir die Methode für TiO – der Sprachcoach anwenden. Die Methode gliedert sich in vier Schritte: Frame – Map – Check – Find. Hier berichten wir von unseren Erfahrungen:

1. Frame: die visuelle Struktur erstellen

Hinsichtlich des „Frames“ haben wir uns stark an die Struktur des Product Fields gehalten: Im „Center“ steht das Produkt selbst. Das Produkt ist umgeben vom „Core“: Welches Problem wird wie gelöst und was sind die Vorteile für die Nutzer gegenüber den Konkurrenten? Um das Core zieht sich der „Context“: Die Rahmenbedingungen und Motivation um das Produkt zu entwickeln und erfolgreich auf dem Markt zu etablieren. Zu guter Letzt umgibt ein „Charakter“ das Produkt: Die Idee, der Wert, der Markt und die Ressourcen, die das Produkt zum Leben erwecken.

The Product Field

2. Map: das große Brainstorming

Weiter ging es mit Schritt 2: „Map“. Gemeinsam haben wir zu den einzelnen Aspekten des Produkts gebrainstormt und unsere Ideen auf Post-Its festgehalten. Obwohl wir alle mehr oder weniger die gleichen Ansichten hatten und die gleiche Sprache sprechen, trafen wir beim Mappen bereits auf die ersten Fallstricke der Methode, aber dazu später mehr. Da wir den Lean Canvas bereits ausgefüllt hatten und uns einen sportlichen Zeitrahmen gesetzt hatten, konnten wir alle Aspekte in rund 2,5 Stunden abarbeiten und an die Wand bringen. Ohne die Vorarbeit und mit Stakeholdern aus mehreren Bereichen würden wir aber dazu raten, hier mehr Zeit darauf zu verwenden (z.B. einen vollen Tag).

Eine gute Vorgehensweise ist es, zunächst den Spielraum zu öffnen und möglichst alle Aspekte anhand von Post-Its im Canvas zu platzieren. Dann sollte man sich aber zum Zwecke der Übersichtlichkeit und Erfassbarkeit, auf die wichtigsten Punkte einigen und diese Post-Its jeweils näher am Produkt platzieren. Die Wichtigkeit von Post-Its haben wir am Stadium definiert: Ein Post-It, das den Status Quo beschreibt hat für uns also eine höhere Wichtigkeit als ein Post-It, dass ein Zielbild beschreibt.

3. Check: die Validität überprüfen

Im nächsten Schritt „Check“ geht es darum, die Verbindungen zwischen den Aspekten zu überprüfen. Wir bildeten also vier Validierungssätze, in denen alle Felder einmal zur Sprache kamen. Dazu bildeten wir Sätze anhand einer festen Struktur. Wenn man z.B. oben links beginnt, fügt man die Produkteigenschaften in folgendes Satzkonstrukt ein: Die Goals leiten die Drivers die Uniqueness zu formen (oder konkreter: „Das Streben, das digitale Sprachenlernen zu revolutionieren, leitet DieProduktMacher dazu an, ein Sprachlernprodukt zu formen, mit dem Lernende aus ihren Fehlern lernen können“). Lassen sich nicht mindestens vier Sätze formen, die alle Aspekte mindestens einmal aufgreifen, sollte man auf die Probleme dabei eingehen und überlegen, wie sich die Lücken mit ergänzenden Eigenschaften schließen lassen. Treffen die Sätze wiederum nicht den Status Quo, sondern schildern das Zielbild, dann weiß man, worauf man sich schleunigst fokussieren sollte.

4. Find: Stärken und Schwächen bestimmen

Im letzten Schritt – „Find“ – haben wir anhand eines Dot-Votings die Stärken und Probleme unseres Produktes herausgearbeitet. Dabei fühlte sich das Dot-Voting ein bisschen an wie Schiffe versenken, so konnten wir für die wichtigste Stärke drei Punkte vergeben, für die zweitwichtigsten Stärken zweimal je zwei Punkte etc. Spätestens hier zeigt sich die Wichtigkeit die Eigenschaften vorab in der Mapping Phase nach Relevanz bzw. Status Quo geclustert zu haben. Votet man nämlich auf ein Zielbild, malt man sich hier Luftschlösser und die Ergebnisse sind wenig realistisch, geschweige denn relevant.

DieProduktMacher beim Workshop zum Product Field

Was haben wir beim Anwenden gelernt?

Da es uns nicht nur um unser Produkt ging, sondern auch um das Erlernen und Ausprobieren der Methode, haben wir im Anschluss eine kleine Retro gemacht. Wie ziemlich jedes Tool, hat auch das Product Field Vor- und Nachteile.

Was hat uns gefallen?

Zu den Vorteilen gehört definitiv die Ausführlichkeit der Aspekte, die aufgezeigt und bewertet werden. Ist man z.B. ein Startup und bereitet einen Investor Pitch vor, dann zeigt das Product Field viele relevante Themengebiete und Bewertungen auf und lässt Lücken und somit Arbeitspakete erkennen. Zudem zeigt es durch seine Ausführlichkeit den Diskussionsbedarf bei vielen Punkten auf, der sonst – auch mit dem Lean Canvas – eher versteckt bleiben würde.

Gut fanden wir auch die Unterscheidung zwischen Usern und Customern, die nochmal verdeutlicht, dass die Nutzer nicht immer identisch mit den Käufern des Produkts sind. So sind bei TiO – der Sprachcoach z.B. Deutschlernende die Zielgruppe, als Customer kommen aber z.B. auch Deutschlehrer in Betracht.

Ein weiterer großer Vorteil ergibt sich dadurch, dass man auch Eigenschaften aufschreiben kann, an denen es momentan hapert bzw. die nicht vorhanden sind. Hier bietet es sich an eine andere farbliche Markierung zu verwenden. Dadurch sind diese Themen nicht tabu und fallen – wie bei anderen Tools – leicht unter den Tisch.

Was hat uns nicht gefallen?

Dennoch trafen wir das ein oder andere Mal auf Probleme mit der Methode, vor allem beim Brainstorming der Produkteigenschaften kamen wir ins Schwimmen:

  • Validität: Hypothese oder Fakt
  • Timing: Zielbild oder Status Quo
  • Abstraktionsphase: High Level oder Low Level

So blieb uns bis zum Ende unklar, ob die Eigenschaften, die wir brainstormten, clusterten und priorisierten, eher Hypothesen sein sollten oder Fakten. Dementsprechend auch, ob wir, gerade bei der Produktneuentwicklung, uns auf unser Zielbild konzentrieren sollten oder nur mit den Errungenschaften im Status Quo. Und ob diese Eigenschaften eher auf einem High-Level (wie im allseits bekannten Security Bike Beispiel) formuliert sein sollten, oder eher auf einem für uns relevanteren konkreten Low-Level?

Aufgrund dieser Schwierigkeiten sind wir uns nicht sicher, ob das Product Field in einer frühen Produktphase, wie wir sie momentan bei TiO – der Sprachcoach haben und in der die technische Machbarkeit noch nicht validiert ist, als Tool wirklich geeignet ist. Zudem wirkte die Methode für uns ein bisschen verkopft, vor allem als es um das Formulieren der Validierungssätze ging. Da diese auf einem sehr abstrakten, hohen Level sind, zweifeln wir an der Relevanz der Validierungssätze für operativ tätige Produktmanager. Da wir gerne auf einem eher konkreteren Level arbeiten, können wir uns nicht vorstellen, wie einzelne Aspekte hier zum Aufzeigen von Lücken führen können. Durch diese „Verkopftheit“ der Methode kam uns die Arbeitszeit auch zäh und langwierig vor, wobei wir dennoch für die Methode nur knapp vier (aber sehr intensive) Stunden aufgewendet haben.

Würden wir das Product Field wieder nutzen?

Das Product Field ist sicher eine Methode, die man als solche nicht aus den Augen verlieren sollte. Dennoch würden wir sie für die Zukunft  enger auf unsere Bedürfnisse anpassen:

  1. Nächstes Mal arbeiten wir mit getrennten Farben für Zielbild und Status Quo, sodass wir immer auf einen Blick wissen, wo wir stehen und wo wir hinwollen. Gleichzeitig können wir so Hypothesen eindeutig markieren.
  2. Wir wenden das Tool auf ein bestehendes Produkt an, bzw. auf ein Produkt bei dem die technische Machbarkeit bereits bewiesen ist und das nicht so facettenreich ist wie TiO.
  3. Wir verzichten auf die High-Level Validierungssätze, sofern wir nicht an einem Produkt-Pitch arbeiten.

Wir nehmen aber auch einige Learnings aus der Methode mit und werden sie in unser eigenes Vorgehen einbinden, sodass man auch mit ihnen in einer frühen Produktphase einen Nutzen erzielen kann. Stay tuned. ;)

TAGS > , , ,

Post a comment