Es gibt unterschiedliche Techniken, die einem dabei helfen, tolle Produkte zu entwerfen. Um eine dieser Techniken geht es heute, nämlich die Technik ein Problem umzuformulieren, um es genau zu verstehen.
Wer schon einmal eine Kundenbefragung durchgeführt hat, um ein neues Produkt zu entwickeln, weiß sehr gut, dass es nicht einfach ist, zu verstehen, welche Produktmerkmale Kunden konkret benötigen. Hierbei hilft diese Technik.
Erst zusammen mit anderen Techniken und Arbeitsphasen wird hieraus ein Vorgehensmodell. Daher werde ich in Zukunft noch auf weitere Arbeitsschritte eingehen.
Ohne konkrete, und „gute“ Anforderungen ist es selbst für das beste Entwicklungsteam nicht möglich, das richtige Produkt zu entwickeln (zumindest ist dann die Gefahr sehr groß, dass man am Markt vorbei entwickelt). Gute Anforderungen fallen aber nicht vom Himmel, sondern müssen normalerweise erst erarbeitet werden.
Bei genauerem Hinsehen zeigt sich in der Anforderungsphase oft das folgende Problem: In den frühen Phrasen der Produktentwicklung wissen Kunden, Nutzer oder Stakeholders zwar oft sehr genau, welche Ziele sie mit einem neuen Produkt erreichen wollen. Normalerweise sind sie aber nicht in der Lage, das Problem sauber zu definieren, das diesen Zielen zugrundeliegt. Auch können Nutzer oft nicht sagen, welche Produktmerkmale sie konkret benötigen.
Im ersten Schritt der Produktdefinition geht es darum, herauszufinden, welches konkrete Problem gelöst werden soll, und warum. Diese Information dient dann als Arbeitsgrundlage für die weiteren Entwicklungsschritte.
Die wichtigste Aufgabe des Entwicklungsteams ist es, Konsens mit den Kunden herzustellen, an welcher konkreten Aufgabenstellung man nun arbeiten soll. Der einfachste Weg, dies herauszufinden, ist das man Kunden eben fragt – und dies so methodisch, wie möglich.
In der Anfangsphase eines Produktentwicklungsprojekts legt man fest, was konkret entwickelt werden soll. Hierfür sind die unten detaillierten Schritte notwendig, und herauskommen soll eine konkrete Problembeschreibung, die man im gesamten weiteren Projekt verwenden kann, um sich zu orientieren.
Beherzigen sie hierbei die folgenden Tipps, um eine gute Problembeschreibung zu erarbeiten:
Fassen Sie zunächst die Bereiche und Informationen zusammen, die wichtig sind, um die Aufgabenstellung zu verstehen, vor der der Nutzer Ihrer zukünftigen Anwendung steht. Hierbei können Sie sehr gut die Methode des Storytelling einsetzen (Beim Storytelling macht man mittels kurzer Zustandsbeschreibungen die einzelnen Elemente der Kundensituation deutlich).
Die im Storytelling entwickelten Zustandsbeschreibung gruppieren Sie anschließend, um so größere Handlungsbereiche zu identifizieren (Clustern). Wichtig ist, daß sie auch Kontextinformation berücksichtigen und das Kunden und Stakeholder die Problemdefinitionsphase intensiv begleiten.
Am Besten beginnen Sie den zweiten Arbeitsschritt auf der Basis einer ersten Produktvision (welche Schlüsselfragen und -probleme soll das Projekt lösen?) und verschaffen Sie sich zusammen mit Ihrem Team einen Überblick über die relevanten Ursache- und Wirkungsprinzipien (Effectmap), die der Aufgabenstellung des späteren Nutzers zugrundeliegen.
Nutzen Sie diese Information, um die Zielrichtung zu verdeutlichen, die das Projekt nehmen sollen und machen Sie die Annahmen transparent, die sie hierbei treffen. Dies hilft dabei, Annahmen später zu konkretisieren.
Formulieren Sie die erste Version Ihrer Problembeschreibung in Form einer klaren und eindeutigen Fragestellung. Anschließend formulieren Sie die Problembeschreibung so lange um, bis sie den richtigen Fokus, und den richtigen Scope für Ihre Entwicklungsvorhaben gefunden haben.
Ein Hersteller von Lesegeräten könnte zum Beispiel fragen/ die Frage als Problem herausgeben: Wie lesen wir in Zukunft?
Sobald Sie die konkrete Formulierung der Anwendungsproblematik kennen, erstellen Sie ein einseitiges Dokument, das die Problembeschreibung enthält, zusammen mit den Zielen, die dieses Produkt erreichen soll.
Normalerweise verwenden Sie hierfür dieselbe Effektmap als Input und ihre Produktvision, die sie im Schritt zwei schon einmal verwendet haben.
Da das hier erarbeitete ein-Seitendokument sehr wichtig ist, um das Projektziel nicht aus den Augen zu verlieren, sollten Sie zusammen mit dem Team während des Projektverlaufs ruhig öfters in dieses Dokument schauen, und es anpassen, falls sich Änderungen ergeben.
Neben der Problembeschreibung benötigen Sie weitere Informationen in Ihrem Projekt, wie zum Beispiel eine Architekturvision. Um solche Bausteine geht es in den nächsten Blogposts zum Thema.
Im Internet finden Sie weiterführende Artikel:
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links: