Direkt zum Hauptbereich

Was Kunden wirklich wollen? Über das Konzept Jobs to be Done von Tony Ulwick

Innovationen werden fast mystisch betrachtet. Wir warten auf den genialen Einfall für das nächste Produkt. Und natürlich wären wir selbst gern die Person, die diesen Einfall hat. Doch allzu selten kommt es so. Zeit, unsere Vorstellung von einem innovativen Produkt zu überdenken. Dazu könnte uns das Konzept von Jobs to be Done von Anthony Ulwick helfen. Ein Leseempfehlung für Product Owner.

 

Der Flop, der zum Nachdenken führt

 

In den 1980er Jahren war Tony Ulwick bei IBM. Nach dem Flop des IBM PC jr begann er mit Kollegen darüber nachzudenken, warum Kunden ein Produkt oder Service kaufen. Das Problem machte er bei den Kundenanforderungen aus. Damals holte man sich erst nach Produkteinführung Feedback zur Benutzung. Ulwick fragte sich, ob möglich wäre, vorher herauszufinden, wie Kunden ein Produkt bewerten würden /1, Pos. 242/. So kam Ulwick auf die so genannte ergebnisorientierte Methode (eng. outcome-drive method).

Kunden haben Jobs zu erledigen 

 

Für diese Methode formuliert Ulwick drei Annahmen:
  • Kunden (Privatpersonen oder Organisationen) haben regelmäßig Aufgaben oder Jobs zu erledigen. Dazu nehmen sie Produkte oder Services zu Hilfe. 
  • Kunden nutzen immer (bewusst oder unbewusst) eine Reihe von Kriterien, um einzuschätzen, wie gut das Produkt sie beim Abarbeiten des Jobs unterstützt.
  • Diese Kriterien können im Voraus erfasst und genutzt werden, um ein innovatives Produkt zu entwickeln.
Diese Herangehensweise unterscheidet sich fundamental von der Suche nach der besten technischen Lösung.

Was passiert, wenn man nicht in Jobs denkt?

 

Für ein gutes Produkt sind zwei Fragen wichtig: Erfüllt es seinen Zweck? Und: Ist es seinen Preis wert? Produkte, die nicht ihren Zweck erfüllen, lassen sich nicht verkaufen. Produkte, die zu teuer sind, werden ebenfalls zum Ladenhüter.

Wenn wir keine klare Vorstellung davon haben, warum ein Kunde unser Produkt kauft, fokussieren wir zu sehr auf seine Funktionen und Eigenschaften. Wenn Produkte veralten, suchen wir verzweifelt nach eine neuen Lösung, also vielleicht nach einer neuen Funktion hier oder einer neuen Eigenschaft dort. Oder hilft eine neue Architektur? Ein neues Design? Das verhängnisvolle Ergebnis einer solchen Vorgehensweise: Es werden zu viele Projekte gestartet, von welchen keines die nötige Aufmerksamkeit bekommt und also auch keines schnell genug fertig gestellt wird. Und weiter geht es in der Spirale: Weil man jetzt noch dringender ein neues Produkt braucht, werden weitere Projekte gestartet. Und so weiter. Und irgendwann wird die tolle, geniale, innovative Produktidee schon kommen.

In seinem zweiten Buch beschreibt Ulwick, warum Innovationsprojekte so häufig scheitern /2, Abschnitt 1).

Bei welchem Job soll unser Produkt also unterstützen?

Was ist ein Job?

 

Unter Job versteht Ulwick, etwas, das es zu erledigen gilt. Beispiele:
  • Unterwegs Musik hören.
  • Holz sägen.
Wenn wir einen Job erledigen, bewerten wir immer etwas, z.B.: Wie schnell finden wir die passende Musik? Wie viele Klicks muss ich machen, um ein bestimmtes Album zu finden? Wie gerade sägt eine Kreissäge? Wie stark reißt das Holz am Ende des Schnitts aus?

Ulwick beschreibt Merkmale dieser Art in einer bestimmten Sprache, was seine Methode so praktisch anwendbar macht.

Wie kommt man an die Bewertungskriterien?

 

Durch Befragen und Beobachten kann man eine Liste von Kriterien erstellen. Anders als beim typischen Anforderungsmanagement wird der Benutzer dann immer direkt und konkret gefragt: Wollen Sie diese Kriterien minimieren oder maximieren?

Im Jahr 2008 hat Ulwick einen Artikel im Harvard Business Review dazu veröffentlicht, wie man den Job eines Kunden beschreibt./3/ In einem weiteren Artikel beim MIT Sloan Management Review beschreibt er, welche Art von Kriterien immer wieder auftauchen./4/

Dabei geht Ulwick davon aus, dass es 50 bis 150 Kriterien sind, mit welchen wir ein Produkt bewerten. Das sind ganz schön viele. Deshalb bietet er mit dem Opportunity Algorithm gleich auch noch eine Auswertungsmöglichkeit bereit, der die Kriterien in eine Reihenfolge bringen hilft. /5, 6/

Und? Hilft diese Vorgehensweise?

 

Ulwick vertritt die Ansicht, dass der Erfolg bei klassischen Innovationsmethoden im einstelligen Prozentbereich liegt. Projekte, die nach seiner Methode angegangen werden, versprächen dagegen eine Erfolgsquote von 86%. Die Daten habe ich mir nicht selbst angesehen, die Argumentation erscheint mir jedoch plausibel.

Besonders gefällt mir, dass diese Methode die Möglichkeit bietet, empirisch zu arbeiten. Somit lassen sich bestimmte Diskussionen im Team objektivieren. Bei jeder Funktion lässt sich prüfen, ob und wie stark sie dazu beiträgt, ein bestimmtes Kriterium zu minimieren oder zu maximieren.

Bsonders wichtig ist dabei natürlich, dass man die entsprechenden Kundengruppen beobachtet und befragt. (Womit Ulwicks Beratungsfirma Strategyn natürlich auch ihr Geld verdient.) Bei wichtigen Produkten ist das sicher auch gut angelegt Zeit und Energie. Allerdings bezweifle ich, dass ein Product Owner diesen Aufwand für jedes Produkt auf sich nimmt oder auch auf sich nehmen muss. Trotzdem: Das Konzept "Jobs to be done" hilft auf jeden Fall beim Verständnis über das zu erstellende Produkt. Denn es hilft dabei, Annahmen zu formulieren und Ideen zu testen.

Der Marketing-Guru Philip Kotler bezeichnet Ulwick als den Deming der Innovation. Und der Harvard Business School Professor Clayton Christensen hat seine Idee aufgenommen und in seiner Forschung weiter getestet (/5, Pos. 2478/ und /7/). Ulwick stellt sein Wissen in Form von zwei Büchern und mehreren Artikeln gut lesbar und für wenig Geld zur Verfügung. Für Product Owner sind sie gutes Lesefutter in den kommenden Sommerferien.

Anmerkungen

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?