Eine der größten Herausforderungen für Produktentwicklungsteams ist die Entscheidung, welches Produkt gebaut werden soll. Bei Teams, die auf der Grundlage einer Produktspezifikation arbeiten, insbesondere bei der Hardware-Entwicklung, dürfen die Ingenieure in der Regel erst dann mit der Arbeit beginnen, wenn die Spezifikation fertiggestellt und genehmigt ist. Und da die meisten Entwicklungszeitpläne unglaublich kurz sind, bleibt oft nicht genug Zeit, um alternative Lösungen in Betracht zu ziehen, sobald neue Informationen auftauchen.
Eine Möglichkeit, diese Herausforderung zu betrachten, ist hier dargestellt. Sie können sich vorstellen, dass der Kreis alle Möglichkeiten darstellt, wie das Team das Produkt bauen könnte. Und dieser kleine blaue Punkt ist die Spezifikation für ein bestimmtes Produkt. Diese Produktspezifikation legt genau fest, auf welches Produkt sich die Entwickler konzentrieren und es entwickeln sollen.
In diesem Beitrag beschreibe ich zunächst einige der gängigen Methoden, die zur Vereinbarung einer Produktspezifikation verwendet werden. Dann gehe ich auf die Probleme ein, die mit diesen Methoden verbunden sind, und zeige auf, wie sie dazu führen können, dass Produkte auf der Grundlage einer Spezifikation entwickelt werden, die die Probleme des Kunden nicht wirklich löst.
Ich sollte erwähnen, dass meine Sichtweise aus 10 Jahren Erfahrung in der analogen und Mixed-Signal-Halbleiterindustrie stammt, zunächst als Anwendungsingenieur und später als Produktdefinierer. Jetzt bin ich als Berater bei Jama tätig.
Worst Ways to Create a Product Specification:
Ask Your Customer What They Want You To Build
Eine Möglichkeit, damit zu beginnen, ist, Ihre Kunden zu fragen, was sie brauchen. Dies kann durch das Warten auf eine Angebotsanfrage des Kunden geschehen oder weniger formell durch Treffen und Diskussionen. In der Regel erfahren Sie auf diese Weise, welche Lösung oder welches Produkt der Kunde heute verwendet und was er in naher Zukunft gerne ändern würde. In gewisser Weise agieren Sie als Auftragnehmer, und Ihr Kunde ist für alle Details der Spezifikation verantwortlich.
Da es in diesem Szenario darum geht, ein bestehendes Produkt zu iterieren, ist die Wahrscheinlichkeit groß, dass Sie am Ende eine sehr spezifische Idee haben, die Sie definitiv umsetzen können.
Es gibt jedoch mehrere Probleme mit diesem Ansatz:
- Was Ihr Kunde Ihnen über seine Produktstrategie erzählt, erzählt er wahrscheinlich auch Ihrer Konkurrenz, und ein Hauptziel des Projekts ist es wahrscheinlich, etwas billiger zu machen als die bestehende Lösung. Sie werden sich in einem Preiskrieg wiederfinden.
- Ihr Kunde hat sich bereits auf eine Art von Lösung festgelegt, die auf dem basiert, was er zuvor gekauft hat, was es schwierig macht, etwas vorzuschlagen, das seinen Bedürfnissen besser entspricht.
- Der Zeitplan ist wahrscheinlich extrem aggressiv, so dass wenig Gelegenheit bleibt, etwas Neues zu entwickeln oder echte Innovation zuzulassen.
- Ihr Kunde kennt vielleicht keine neuen Technologien, oder er weiß einfach nicht, was er braucht.
In diesem Fall verlassen Sie sich darauf, dass Ihr Kunde seine internen Anforderungen in eine Spezifikation für Sie übersetzt, anstatt dass Sie Anforderungen für ein Produkt schreiben, das der breite Markt braucht und kaufen wird.
Während der Entwicklung des Produkts wird Ihr Team aus verschiedenen Gründen unweigerlich Kompromisse eingehen müssen. Der einzige Weg, um sicher zu sein, dass die beste Wahl getroffen wird, ist, die Änderungen an der resultierenden Produktspezifikation mit Ihrem Kunden zu besprechen. Wenn Sie das nicht tun, laufen Sie Gefahr, ein Produkt zu bauen, das der Kunde nicht akzeptieren wird. Da das Konstruktionsteam unter extremem Zeitdruck steht, ist die Wahrscheinlichkeit groß, dass es ohne die besten Informationen Kompromisse bei der Produktauswahl eingeht. Dadurch erhöht sich das Risiko, das falsche Produkt zu bauen.
Dieser Ansatz funktioniert, weil ein Produkt geliefert wird. Wenn Sie in der Lage sind, Standardkomponenten zu liefern, dann ist das in Ordnung. Wenn Sie nach einer einzigartigen Lösung suchen, die die Bruttomarge verteidigt, dann ist dies nicht der beste Ansatz.
VERWANDTER POST: Wie man eine bessere Auswirkungsanalyse für vor- und nachgelagerte Beziehungen durchführt
2. Ein Ingenieur soll die gesamte Spezifikation schreiben
Ein anderes häufiges Szenario ist, dass ein Ingenieur oder ein anderes Teammitglied mit Kundenkontakt eine Lösung auf der Grundlage von Gesprächen mit einem oder mehreren Kunden vorstellt. Das Team schart sich um diese Idee, und mit einem Ansturm an internem Schwung werden die Anforderungen schnell dokumentiert, und die Bemühungen des Teams wenden sich schnell dem Schreiben der Produktspezifikationen und der Entwicklung der Lösung zu.
Wenn eine Lösung fertig ist und auf den Markt gebracht werden kann, validieren einige Teams ihre Idee mit den Kunden, aber da das Team eine Lösung vorstellt – und nicht einen Bedarf erforscht – dreht sich die Diskussion in der Regel um Details in der Produktspezifikation. Diese Teams haben keine Gelegenheit herauszufinden, ob die Lösung ein Problem löst.
Typischerweise kommen in diesem Szenario die Produktanforderungen direkt aus dem Kopf einer Person und werden dann in einem langen Lastenheft festgehalten, und der Rest des Teams arbeitet anhand der dokumentierten Spezifikation. Jedes Mal, wenn das Team auf einen Konflikt stößt, bei dem ein Kompromiss gefunden werden muss, muss die Person, die die Anforderungen verfasst hat, unabhängig und mit wenig oder gar keinen neuen Informationen über die richtigen Kompromisse entscheiden. Und wenn diese Person die Anforderungen weder recherchiert noch validiert hat, dann wird das Team das falsche Produkt bauen.
Warum diese Ansätze nicht zum Erfolg führen
Beiden bisherigen Ansätzen ist gemeinsam, dass der Schwerpunkt darauf liegt, so schnell wie möglich zu einer fertigen Produktspezifikation zu gelangen. Die Teams haben es so eilig, etwas zu bauen und den Termin des Kunden einzuhalten, dass sie nicht zuerst sicherstellen, dass das „Etwas“ auch das richtige „Etwas“ ist.
Darüber hinaus ist das Wissen über die Anforderungen nur bei einer Person im Team vorhanden. Diese Person ist entweder der Ansprechpartner für den Kunden oder derjenige, der die Produktidee entwickelt hat. In beiden Fällen fehlt dem Rest des Teams jeglicher Kontext für die Lösung, der Grund, warum sie dieses Produkt bauen, und sie können daher keine Empfehlungen aussprechen.
Das Ergebnis ist oft, dass Produkte später als geplant eingestellt werden, nachdem viel Zeit und Geld verschwendet wurde, oder dass Teams Produkte schaffen, die nicht erfolgreich sind, oder „Me-too“-Produkte, die hauptsächlich über den Preis konkurrieren. Nichts von alledem ist gut für das Geschäft.
VERBUNDENE POST: 8 Do’s and Don’ts für das Schreiben von Anforderungen
Die besten Wege zur Erstellung einer Produktspezifikation:
Der beste Weg, Produkte zu entwickeln, die Ihre Kunden kaufen werden, besteht darin, mit Ihrem Zielmarkt zu sprechen, lange bevor Sie mit dem Schreiben Ihrer Spezifikation beginnen. Zunächst müssen Sie Ihre Problemstellung formulieren.
Eine Produktproblemstellung besteht aus ein paar Sätzen oder Absätzen, die einen Marktbedarf beschreiben. Sie werden aus der Perspektive der Persona geschrieben, die das Problem hat, und – das ist entscheidend – sie sagen nichts darüber aus, wie das Problem tatsächlich zu lösen ist. Das Ziel dieser Phase der Untersuchung ist es, ein Verständnis für das Problem und ein Gefühl für den Wert zu vermitteln, der mit der Lösung des Problems verbunden ist.
Eine Problemstellung besteht im Allgemeinen aus drei Teilen:
- Der erste Teil ist die Persona oder eine Beschreibung der Person, die das Problem hat. Es ist hilfreich, die Persona sehr detailliert zu beschreiben und dann in der Problembeschreibung auf eine bestimmte Persona zu verweisen, um zu vermeiden, dass dieselbe Persona-Beschreibung wiederholt wird.
- Als nächstes folgt eine Beschreibung des Problems. Je mehr Details, desto besser. Stellen Sie sicher, dass der Bedarf kristallklar ist. Geben Sie dem Problem auch einen Namen. Dies erleichtert es den Teams, während des Projekts darauf zurückzugreifen.
- Schließen Sie mit einer Beschreibung, wie häufig das Problem auftritt. Wenn das Problem selten auftritt und nur geringe Auswirkungen hat, dann ist die Lösung des Problems von geringem Wert. Wenn das Problem häufig auftritt und große Auswirkungen hat, dann ist der Wert seiner Lösung hoch.
Sie können damit beginnen, Kunden zu fragen, welche Probleme sie haben, von denen sie glauben, dass Sie sie lösen können, aber Sie müssen tiefer graben, um zu den wirklich wertvollen Problemaussagen oder Golden Nuggets zu gelangen. Diese „goldenen Nuggets“ ergeben sich im Allgemeinen aus der Entwicklung eines tiefen Verständnisses des Marktes und der Zusammenstellung von Informationen aus einer Vielzahl von Quellen.
Wenn Sie dies erfolgreich tun, werden Sie am Ende ein Problem identifizieren, das Sie lösen können und für das Ihr Kunde bezahlen wird.
Achten Sie während des Prozesses darauf, dass Sie nicht auf falsch positive oder negative Ergebnisse stoßen. Wenn Sie zu sehr auf Leute innerhalb Ihres Unternehmens oder nur auf eine kleine Anzahl von Kunden hören, kann das dazu führen, dass Sie ein Problem fälschlicherweise bestätigen oder verwerfen. Sprechen Sie mit so vielen Kunden wie möglich und sammeln Sie so viele Daten wie möglich.
Kehren wir zurück zu unserem Diagramm aller möglichen Produkte, die wir bauen können.
Diesmal haben wir Schnittlinien hinzugefügt, die Einschränkungen darstellen. Wenn wir uns die Problemstellung als Linien vorstellen, die den Kreis kreuzen, dann wird eine gute Problemstellung, die auf dem Verständnis des Marktes beruht, einen Bereich im Kreis begrenzen, der alle akzeptablen Lösungen darstellt. Alles, was in diesem Bereich liegt, löst das Problem und wäre für den Kunden akzeptabel.
Sie werden feststellen, dass dieser Bereich viel größer ist als die vorherigen Kreise für Anfragen und Produktideen. Das liegt daran, dass diese Problemstellung und der Kontext die Lösung absichtlich so locker wie möglich halten, um neue Ideen zuzulassen.
Die Idee ist, dem Designteam maximale Flexibilität zu geben, um die innovativste Lösung zu schaffen, die innerhalb der Einschränkungen möglich ist.
VERWANDTER POST: Checkliste: Auswahl eines Anforderungsmanagement-Tools
Wie kommt man zu einer endgültigen Problemstellung?
Hier sind meine Empfehlungen:
- Bestimmen Sie zunächst für jedes Projekt eine Person, die die Verantwortung hat, die Stimme des Kunden zu sein.
- Als Nächstes beauftragen Sie diese Person damit, die Marktprobleme ausschließlich auf der Grundlage der vom Markt gesammelten Informationen zu ermitteln.
- Stellen Sie sicher, dass diese Marktprobleme dokumentiert und an einem Ort weitergegeben werden, auf den das gesamte Team Zugriff hat.
- Schreiben Sie eine Begründung für jedes Marktproblem auf, die erklärt, warum es ein Problem ist und wie wichtig es zu lösen ist
- Fügen Sie einen Meilenstein in den Projektplan ein, bei dem die Problemstellungen vom Team zusammen mit einem Business Case überprüft und genehmigt werden müssen.
- Wenn das Team mit der Entwicklung einer Lösung beginnt, kehren Sie regelmäßig zur Liste der Problemstellungen zurück, um alle daran zu erinnern, was das Ziel ist.
- Erfassen Sie für jedes Problem eine Liste der Produktmerkmale, die das Problem lösen werden.
- Wenn ein Problem nicht vollständig gelöst werden kann, überprüfen Sie den Business Case, um sicherzustellen, dass das Produkt immer noch lebensfähig ist.
Von der Problemstellung zur Spezifikation
Nun, da Sie Ihre Problemstellungen haben und das Team mit ihnen vertraut ist, beginnen Sie mit der gemeinsamen Entwicklung einer Produktspezifikation. Da jeder im Team das zu lösende Problem versteht, kann jeder zur Spezifikation beitragen.
Da Sie im Vorfeld das zu lösende Problem im Rahmen der festgelegten Einschränkungen identifiziert haben und Ihr Team mehrere Möglichkeiten zur Bereitstellung der Lösung in Betracht gezogen hat, verfügen Sie über genügend Informationen, um die Produktspezifikation zu schreiben.
Freigeben Sie die Produktspezifikation in kleinen Stücken
Am besten geben Sie kleine Teile der Spezifikation so früh wie möglich an das Team weiter, um schnelles Feedback zu erhalten. Auf diese Weise wird vermieden, dass Zeit auf dem falschen Weg verschwendet wird, und es wird dem Team viel leichter gemacht, qualitativ hochwertiges Feedback zu geben.
Nicht überzeugt? Überlegen Sie doch mal: Was passiert, wenn Sie ein 200-seitiges Datenblatt zur Prüfung erhalten? Wahrscheinlich schauen Sie sich die ersten paar Seiten an und überfliegen dann den Rest.
Was passiert nun, wenn Sie ein einseitiges Dokument erhalten? Wahrscheinlich lesen Sie das ganze Dokument. Zweihundert einseitige Dokumente führen zu einem viel besseren Feedback als ein einziges 200-seitiges Dokument.
Beziehen Sie sich auf die Problemstellung, um sicherzustellen, dass Sie auf dem richtigen Weg sind
Auch während der Entwicklung der Spezifikation sollten Sie immer wieder überprüfen, ob das Produkt immer noch eine gültige Lösung für das Problem darstellt. Es kann leicht passieren, dass man sich in den Kompromissen verstrickt, die mit der Entwicklung eines Produkts einhergehen, und vergisst, zu überprüfen, ob man noch auf dem richtigen Weg ist.
Dieser Ansatz steuert auch die Erwartungen der Beteiligten. Da der Prozess kontrolliert wird, gibt es einen Rahmen und eine Transparenz, die verhindert, dass jemand Entscheidungen außer Kraft setzt. Zu jedem Zeitpunkt des Projekts sind Sie in der Lage, genau zu erklären, welchen Wert Ihr Produkt bietet und warum es die Funktionen haben muss, die das Team festgelegt hat.
Die Entwicklung von Produkten nach den Bedürfnissen des Marktes ist entscheidend für den Erfolg
Ich bin mir bewusst, dass dies in einigen Branchen eine große Veränderung gegenüber der Art und Weise darstellt, wie Produkte bisher entwickelt und hergestellt wurden. Aber da die Märkte immer stärker umkämpft sind und die Produkte immer komplexer werden, reicht es nicht aus, einfach nur eine weitere Iteration von etwas zu liefern, das man schon einmal gebaut hat, um lange im Geschäft zu bleiben.
Um mehr darüber zu erfahren, wie man Anforderungen so schreibt, dass alle Beteiligten ein klares Verständnis der Entwicklungsbedürfnisse haben, laden Sie unser eBook, Best Practices for Writing Requirements, herunter.
Lesen Sie das EBOOK