Während einer Product Discovery werden alle relevanten Beteiligten zusammengebracht und so viele valide Informationen wie notwendig gesammelt, um den gesamten Problemraum durch die wichtigsten Anforderungen aller Perspektiven klar zu definieren. Nach dem Motto “fail early” werden darauf aufbauend passende Lösungsansätze erarbeitet, evaluiert und iteriert - erstmal ganz ohne Programmieraufwände. Diese Praxis ermöglicht langfristig ein effektives, ressourcenschonendes Entwickeln und trägt durch informierte Entscheidungen zur höheren Qualität einer bedarfsgerechten, nutzerzentrierten Lösung bei. Aus unserer Erfahrung müssen aber ein paar Faktoren stimmen, dass eine Discovery auch tatsächlich Lerneffekte und innovative Lösung bewirkt.

Ich bringe ein good practice Beispiel mit und möchte mit dem Publikum interaktiv analysieren, welchen Einfluss z.B. Teamzusammensetzung, Methoden der Nutzerzentrierung und Kollaboration haben und welche Knackpunkte ganz konkret problematisch sein könnten.

Zielpublikum: Product Owners, Project Leads, Agile Coaches, Developers, Designers
Voraussetzungen: Interesse und grundlegende Praxis in nutzerzentrierter Arbeit
Schwierigkeitsgrad: Advanced

Immer wieder stehen wir vor der Frage "Make or Buy?" und begegnen dabei featurereichen Platform-as-a-Service- oder Software-as-a-Service-Lösungen, die unsere Anforderungen erfüllen sollen.

Doch ist das tatsächlich so? Unsere Erfahrung zeigt, dass fertige Lösungen von der Stange in den seltensten Fällen genau die Fähigkeiten mitbringen, die unsere Anforderungen erfüllen.

Am Beispiel API-Management stellen wir unseren Ansatz des Capability Journey Mappings als Herangehensweise zur pragmatischen Diskussion von Fähigkeiten vor. Die Metapher eines Liniennetzplans erlaubt uns dabei eine geführte und strukturierte Betrachtung möglicher Capabilities auf dem Weg zu einer passgenauen Lösung. So werden potentielle Voraussetzungen oder Vorbedingungen abhängiger Fähigkeiten berücksichtigt.

Im Ergebnis entsteht ein klares Bild, welche Capabilities zur Erfüllung der Geschäftsanforderungen benötigt werden. Damit ist die Grundlage geschaffen, um eine differenzierte Make-or-Buy-Entscheidung für einzelne Capabilities zu treffen, anstatt umfangreiche, monolithische Plattformen einzuführen. Die Brücke von den Geschäftszielen zu den benötigten technischen Fähigkeiten einer Plattform ist damit geschlagen.

Zielpublikum: Architects, Product Owner, Business Analysts, Enterprise Architects
Voraussetzungen: Grundverständnis von Anforderungsanalyse, System Capabilities
Schwierigkeitsgrad: Advanced