Was ist ein Produktanforderungsdokument?

Stellen Sie sich vor, Sie sind Küchenchef in einem High-End-Restaurant. Eines Abends kommt ein sehr wichtiger Kunde herein (sagen wir Meryl Streep) und bittet um Pasta – macht aber keine weiteren Angaben. Sie geraten in Panik. Der Schweiß beginnt sich unter Ihrer Kochmütze zu sammeln. Wenn Sie Meryl Streep enttäuschen, sind Sie Ihren Job los. Aber niemand wird Ihnen sagen, welche Art von Pasta sie wünscht.

Dieses imaginäre Szenario verdeutlicht, warum ein Produktanforderungsdokument so wichtig ist: Es wird vom Produktmanager geschrieben und beschreibt detailliert, was gebaut werden muss, für wen es gedacht ist und welchen Nutzen es dem Endbenutzer bringt. Es ist der Unterschied zwischen der Anweisung, Nudeln zu kochen, und der Anweisung, Spaghetti Bolognese zu machen.

Erfahren Sie, welche weiteren Vorteile Sie aus der Erstellung eines Produktanforderungsdokuments ziehen können und wie Sie loslegen können.

Was ist ein PRD?

Ein Produktanforderungsdokument definiert vollständig den Zweck eines Produkts oder einer Funktion und erklärt, was das Produkt beinhalten soll. Ohne dieses sehr wichtige Dokument wird Ihr Team mit ziemlicher Sicherheit scheitern, weil es keine Ahnung hat, was als erfolgreicher Build angesehen wird.

Ein PRD hält alle auf der gleichen Seite: Niemand sollte Fragen darüber haben, was das Produkt ist oder was es erreichen soll, nachdem er das PRD gelesen hat. Es setzt sehr klare Ziele und Richtlinien für ein Produkt und zeigt, wie die Funktionen eines Produkts die Bedürfnisse des Benutzers erfüllen.

Was ist kein PRD?

Es ist keine Schande, ein PRD mit einem BRD zu verwechseln – es gibt viel zu viele Akronyme auf der Welt. Aber ein PRD ist definitiv anders als andere Dokumente, mit denen Sie vielleicht vertrauter sind.

Business Requirements Document (BRD)

Ein Business Requirements Document stellt das Produkt in den Kontext Ihrer Organisation als Ganzes. Es beschreibt, was ein neues Produkt leisten soll, und beschreibt die Bedürfnisse und Erwartungen der Anwender, den Grund, warum diese Lösung notwendig ist, und alle Einschränkungen, die eine erfolgreiche Einführung beeinträchtigen könnten.

Software-Anforderungsdokument (SRD)

Ein Software-Anforderungsdokument geht auf die Details der Software ein, die Ihr Produkt antreibt. Es enthält Details zu Schnittstellen, Sicherheitsanforderungen, Funktionsfähigkeiten, Leistungsstufen und verwandte Informationen. Diese Dokumente sind für Entwickler, Tester, Ingenieure und Kunden gedacht.

Warum Sie ein Produktanforderungsdokument brauchen

Das PRD ist die Vision für das Produkt. Was gibt es ohne eine Vision, auf die man hinarbeiten kann?

Produktanforderungsdokumente zeigen auch, wie die Ziele des Produkts mit verschiedenen Aspekten des Produkts erreicht werden sollen. Dieses Dokument wird von verschiedenen Teams in Ihrem Unternehmen verwendet, um den Stakeholdern das Produkt zu beschreiben, Ihrem Vertriebsteam zu helfen, das Produkt überzeugend zu präsentieren, damit sie es verkaufen und reich werden können, und Ihre Designer wissen, wie es aussehen und funktionieren soll. Es ist im Wesentlichen eine Blaupause für Ihr Produkt.

Brauchen Sie also ein PRD? Auf jeden Fall. Genauso wie ein Autohersteller eine Blaupause für ein Auto braucht, bevor er mit dem Bau beginnt.

Was sollte in Ihrem PRD enthalten sein

Da dieses Dokument Design-, Support-, Vertriebs-, Marketing- und Entwicklungsteams berühren wird, gibt es ein paar Punkte, die standardmäßig enthalten sein sollten.

Hauptziel

Das Hauptziel sollte erklären, für wen Sie das Produkt bauen, welche Kundenprobleme Sie zu lösen hoffen und wie das Produkt in Ihre Ziele und Vision als Unternehmen passt. Dieser Abschnitt könnte auch potenzielle Anwendungsfälle enthalten.

Bevor Sie mit der Erstellung Ihres PRD-Dokuments beginnen, ist es wichtig, dass Sie die Stimme des Kunden erfassen. Stellen Sie sich vor, Sie machen sich daran, ein Produkt zu bauen, ohne Kundenforschung zu betreiben, und es stellt sich heraus, dass Ihre Kunden wollen, dass es sich nicht wie eine Social-Media-App anfühlt. Sie machen sich daran, ein Produkt zu bauen, das ein Bedürfnis befriedigt, also müssen Sie wissen, was diese Bedürfnisse sind. Sobald Sie verstehen, was Ihre Kunden wollen, können Sie erklären, wie Ihr Hauptziel für das Produkt diese Wünsche erfüllt.

Gewünschtes Veröffentlichungsdatum

Sie werden wahrscheinlich mehrere Veröffentlichungsdaten für verschiedene Komponenten oder Iterationen des Produkts haben, besonders wenn Sie die agile Methodik verwenden. In Ihrem PRD legen Sie die Termine für die wichtigsten Komponenten des Projekts fest. Sobald dies definiert ist, können Projektmanager damit beginnen, Scopes und Timelines zu erstellen und diese dann in Sprints zu platzieren.

Produktmerkmale

Definieren Sie die Merkmale Ihres Produkts, damit die Leute wissen, was sie bauen sollen. Bezogen auf Ihre Hauptziele sollte dieser Abschnitt detailliert beschreiben, was der Zweck jeder Funktion ist und welches Problem sie zu lösen hofft.

Angenommen, Sie entwickeln eine Marktplatz-App für den Kauf und Verkauf von Kleidung – Sie wollen den ganzen Spaß der sozialen Medien mit der Aufregung, coole Kleidung für weniger Geld zu bekommen, verbinden. In Ihrem PRD haben Sie dann die Beschreibung, wie Ihr Home-Feed aussehen wird, und zeigen, wie er die Anforderung erfüllt, sich wie ein Social-Media-Engagement anzufühlen. Sie haben dann auch eine Beschreibung des Posts eines Artikels mit dem ursprünglichen Preis, der dem „zu verkaufen“-Preis gegenübergestellt wird, und zeigen, dass es die Anforderung erfüllt, coole Klamotten für weniger Geld zu scoren. Auf diese Weise hat jedes Feature einen kalkulierten Zweck.

Sie sollten auch detailliert beschreiben können, wie der Nutzer mit der App interagieren wird: Wird es ein unendliches Scrollen geben, wird es eine eingebettete Kamera-Funktion geben und wird es eine Möglichkeit geben, problematische Nutzer einfach zu blockieren? Dies alles sollte in Ihrem PRD definiert werden.

Ihr Produktanforderungsdokument sollte auch Freigabekriterien enthalten, Ziele, die Sie erreichen müssen, bevor Sie das Produkt freigeben. Erstellen Sie Freigabekriterien um:

Mindestfunktionalität
Benutzerfreundlichkeit, gemessen durch Benutzertests
Zuverlässigkeit
Performance und Geschwindigkeit
Support

Berücksichtigen Sie Werkzeuge wie einen Critical-to-Quality-Tree, um Kundenbedürfnisse mit Produktanforderungen zu verbinden.

Mehr erfahren

Benutzerführung und Design

Das Design ist natürlich visuell. Hier sollten Sie Wireframes von Seiten und Mockups von Designs einbinden, damit andere sehen können, was Sie sich für das Aussehen und das Gefühl der Website vorstellen.

Drahtgitter für die Anmelde- oder Registrierungsseiteup Page Wireframe (Click on image to modify online)

Bank App Wireflow Beispiel (Klicken Sie auf das Bild, um es online zu bearbeiten)

Performance-Metriken

Wenn Sie nicht festgelegt haben, wie die Leistung Ihres Produkts ermittelt wird, gibt es keine Möglichkeit zu wissen, ob es ein Erfolg oder Misserfolg ist. Ihr Produkt sollte über einen Feature-Tracker verfügen, der feststellt, welche Funktionen Ihres Produkts am häufigsten genutzt werden, um zu ermitteln, welche Komponenten Ihres Produkts am erfolgreichsten sind. Diese Art der Nachverfolgung hilft Ihnen, Ihr Produkt in der Zukunft zu verbessern. Zu den Leistungsindikatoren könnte gehören, wie oft jede Funktion verwendet wird, wie lange Ihre Benutzer mit den Funktionen interagieren, wie Benutzer durch Workflows navigieren usw.

Quantifizieren Sie den Erfolg jeder Funktion. Sie können zum Beispiel sagen: „Wir glauben, dass unsere Apple-Pay-Integration von 40 % der Nutzer genutzt wird.“ Ab diesem Zeitpunkt haben Sie eine numerische Möglichkeit, um festzustellen, ob Sie richtig lagen und ob das Feature ein Erfolg war oder nicht.

Verwenden Sie eine Hypothese für jede Ihrer Funktionen, einschließlich einer quantifizierbaren Hypothese, die nach der Einführung überprüft werden kann, um den Erfolg oder Raum für Verbesserungen zu bestimmen. Vielleicht stellen Sie fest, dass einige Funktionen ganz aufgegeben werden können.

Anticipated future work

Die obigen Analysen können helfen, Verbesserungen in der Zukunft zu bestimmen. Aber vielleicht haben Sie auch Ideen, wie Sie das Produkt im Laufe der Zeit weiterentwickeln wollen. Diese zukünftige Arbeit sollte immer noch die Bedürfnisse der Kunden im Auge haben. In diesem Abschnitt ist es wichtig, Ihre Ideen auf hohem Niveau zu halten – Sie können in der Zukunft detaillierter werden.

Glücklicherweise gibt es Vorlagen für Produktanforderungsdokumente, die das Rätselraten aus dem Prozess nehmen. Erstellen Sie eine Vorlage aus den von uns bereitgestellten Informationen und passen Sie sie an die Bedürfnisse Ihres Unternehmens an.

Lucidchart eignet sich hervorragend zur Erstellung von Wireframes, Mockups, Projektstrukturplänen, Zeitplänen und anderen visuellen Darstellungen, die Ihnen helfen, Produktanforderungen zu erklären. Und sie lassen sich mithilfe unserer Integrationen mit G Suite, Microsoft Office, Atlassian und anderen Plattformen leicht in Ihr PRD einfügen. Melden Sie sich noch heute für einen kostenlosen Account an.

Sehen Sie, warum Lucidchart ein idealer Arbeitsbereich für die Erstellung von Wireframes und die Erklärung von Produktanforderungen ist.