Jobs-to-be-done Outcome Expectations

JTBD Metriken

Jobs-to-be-done_Outcome-Expectations (Bild: Muhammad Ghafari via Flickr)

Die Essenz von Jobs-to-be-done (JTBD) ist die Erkenntnis, dass Kunden (und Nutzer) kein Produkt (oder Service) um seiner selbst Willen kaufen. Kunden haben ein Problem oder befinden sich in einer Situation die sie ändern möchten und beschaffen sich Dinge um ihre Lage zu verbessern.

Jobs-to-be-done mit Peter Drucker

Ein bedeutender Teil des Jobs-to-be-done (JTBD) Frameworks sind Jobs-to-be-done Outcome Expectations. Eine Problembeschreibung (Situation, Ängste und Hindernisse, Motivation) ist ja nur die halbe Miete. Jobs-to-be-done Outcome Expectations ergänzen das Gesamtverständnis für eine Situation und erlauben es allen Beteiligten bessere und umfassender Lösungsansätze zu entwickeln.

Jobs-to-be-done Outcome Expectations

Ein wichtiger Abschnitt der Produktentwicklung ist bekanntlich die Kenntnis von Customer Needs. Diese Kundenanforderungen werden aber sehr oft falsch dokumentiert. Das liegt daran, dass Marktforscher beispielsweise nicht wissen was sie Kunden fragen sollen um Customer Needs zu erfahren. So werden Wünsche und Lösungen notiert und gesammelt und später im Prozess als vermeintliche Nutzeranforderungen umgesetzt.

Tatsächlich sind Kundenanforderungen aber als desired outcome zu verstehen. Kunden haben ein Ziel vor Augen und sehr wohl auch interne Metriken mit deren Hilfe sie den Grad der Zielerreichung messen. Diese nachprüfbaren Leistungen eines Produktes sind Jobs-to-be-done Outcome Expectations.

Nehmen wir als Beispiel den Job der asynchronen Kommunikation mit Freunden. Aus Gesprächen mit Nutzern haben wir möglicherweise gelernt, dass das ein wichtiger Job-to-be-done ist (es ist eine Situation in welcher sich Nutzer befinden und die sie im Sinne einer positiven Veränderung verlassen wollen). Wir dokumentieren unsere Interview-Erkentnisse zum Beispiel in dieser Job Story (Situation, Motivation, Ergebnis): Wenn ich jemandem etwas mitteilen möchte und ein persönliches Gespräch vermeiden will weil ich befürchte dass mich das zu viel Zeit kostet, dann will ich meine Nachricht zuverlässig aber von mir unabhängig zustellen lassen.

Interne Metriken welche Nutzer für die erfolgreiche Abarbeitung dieses Jobs haben sind beispielsweise Zuverlässigkeit (z. B. Null Fehler unter 1000 Versuchen) und Unabhängigkeit (möglichst Null den Empfang unterstützende Interaktionen auf Seiten des Absenders).

Gegen solche Metriken lassen sich potentielle Lösungen validieren. Aber es gibt noch weitere Jobs-to-be-done Outcome Expectations:

  1. Vom Nutzer gewünschte Ergebnisse
  2. Vom Nutzer unerwünschte Ergebnisse
  3. Vom Hersteller (Lösungsanbieter) gewünschte Ergebnisse
  4. Vom Hersteller (Lösungsanbieter) unerwünschte Ergebnisse

Weil wir von (mit kommerzieller Absicht hergestellten) Produkten sprechen (und nicht von Kunst) müssen auch die Anbieter-seitigen Jobs-to-be-done Outcome Expectations berücksichtigt werden, sonst kann das Produkt nicht gewinnbringend am Markt angeboten werden.

Jobs-to-be-done Outcome Expectations sind keine speziellen Eigenschaften einer Lösung. Sie sind viel mehr auf einer höheren (abstrakteren) Ebene Problem-spezifische Merkmale.

Produkte müssen mehr als nur nützlich sein um am Markt bestehen zu können. Man spricht von Desirability, Viability und Feasibility. Um die Sinnhaftigkeit, Machbarkeit und Wirtschaftlichkeit einer Lösung besser beurteilen zu können hilft es sicherlich sich im Vorfeld umfassend mit Jobs-to-be-done Outcome Expectations zu befassen.

About Jan (490 Articles)
Informationsarchitekt und Konferenz-Veranstalter (IA Konferenz, die Konzepter-Konferenz: http://iakonferenz.org, MOBX Mobile UX Konferenz: http://mobxcon.com), Podcaster und Twitter Addict. Geboren in Prag, sesshaft in Berlin.

Leave a comment

Your email address will not be published.


*


css.php