Anleitung zum Schreiben eines Produktspezifikationsdokuments (PRD) – Vollständige Anleitung

Was ist ein Produktspezifikationsdokument?

Ein gutes Produktspezifikationsdokument identifiziert die Ziele jedes neuen Produkts, jeder neuen Dienstleistung oder Funktion; es beschreibt genau das Produkt, das Ihr Team entwickeln wird.

‍Ein schlankes, effizientes Produktspezifikationsdokument sollte Produktziele, Zielbenutzer und die erwartete Nutzung klar umreißen.
‍
It is the foundation that any agile product team needs to ensure all stakeholders involved are aligned and the roadmap for the product team is clear. The PRD will be the most referenced resource throughout your product build.

Was macht ein effektives Produktspezifikationsdokument aus?

Produktspezifikationsdokumente müssen nicht seitenlang sein. Seien wir ehrlich, die Leute überfliegen, suchen sich Schlüsselwörter heraus und bekommen das Wesentliche mit. Um ein schmerzloses Produktspezifikationsdokument zu erstellen, ist es wichtig, dass Sie die Dinge so kurz wie möglich, prägnant und augenfreundlich halten – scheuen Sie sich nicht, zur Unterstützung visuelle Elemente zu verwenden.‍

‍→ Zum Beispiel verwenden wir bei Slite Skizzen, um Funktionen und Interaktionen zu definieren.

‍
Even if you manage to create an outstanding product requirements document, it doesn’t guarantee that your product build will be a success, but it will certainly give it the best possible starting blocks.

Eine vollständige Anleitung zum Produktspezifikationsdokument

Wie ein PRD einem Produktentwicklungsteam helfen kann

Produktentwicklungsteams sind mit Abstand das am stärksten von einem Produktspezifikationsdokument betroffene Team. Sie sind diejenigen, die sich am häufigsten auf die Projektpläne beziehen und das Dokument wie ihre Westentasche kennen müssen, um sicherzustellen, dass sie kollaborativ und effizient arbeiten.

Das PRD spielt eine kleinere Rolle in der breiteren Produktstrategie, Vision und Produkt-Roadmap. Es ist eine der wichtigsten Ressourcen, abgesehen von Talenten, die ein großartiges Produktmanagement ermöglicht.

Es hört jedoch nicht beim Entwicklungsteam auf. Marketing, Vertrieb, Business Development, Support und weitere Teams müssen sich auf die Vorlage beziehen, um vollständig zu verstehen, was kommt und wie der Zeitplan aussieht. Wenn alle Teams mit dem Dokument einverstanden sind, planen sie besser in ihren Bereichen, damit sie das neue Produkt bestmöglich unterstützen können, wenn es fertig ist.

Was das PRD für einen Produktmanager bedeutet

Als Produktmanager (PM) sollten Sie der Hauptbeitragende zu jeder technischen Dokumentation wie einer Vorlage für Produktspezifikationen oder einem PRD sein, aber das bedeutet nicht, dass Sie es alleine tun müssen. Es liegt an Ihnen – als PM –, die besten Ressourcen in Ihrem Team zu finden, die Ihnen bei der Erstellung verschiedener Teile des PRD helfen:

- Verwenden Sie einen Designer für Wireframes und Mockups

- Stellen Sie einen Vermarkter für Personas und User Stories ein

- Der Produktmanager ist für die Verwaltung des gesamten Prozesses zur Definition der Produktanforderungen verantwortlich.

Wenn dieser Prozess gut verwaltet wird, sollten die Produktmanager dieses Dokument als Ressource für sich selbst während des gesamten Prozesses und als Ressource für andere Stakeholder verwenden, auf die sie sich kontinuierlich beziehen können.

Was ist der Unterschied zwischen einem PRD und einem MRD?

Die Leute verwechseln oft, was ein PRD ist und was ein MRD ist. Sie sind unterschiedlich, gehen aber oft Hand in Hand. Ein Marktanforderungsdokument sollte vor dem Produktspezifikationsdokument erstellt werden.
‍

Kurz gesagt, ein MRD ist eine Recherche, die die Marktbedürfnisse und -chancen mit einem Produkt Ihres Unternehmens identifiziert. Das PRD identifiziert das Produkt, das gebaut werden kann, um die Chance zu nutzen.

Was sollte in einem PRD enthalten sein?

Eine gute PRD-Startvorlage ist je nach Unternehmen und Team unterschiedlich. Die meisten Produktspezifikationsdokumente sollten jedoch Folgendes enthalten:

• Ziele und Zielsetzungen
• Wichtige Stakeholder
• ‍Benutzer-Personas & Stories
• Release-Details
• Design & Wireframes
• Risiken
• Zukünftige Roadmap & Interaktionen

Auch dies ist nur ein grober Überblick darüber, wie ein PRD aussehen kann. Möglicherweise ist es erforderlich, alle oben genannten Punkte in Ihr Dokument aufzunehmen, oder Sie müssen nur diejenigen Punkte berücksichtigen, die Sie für Ihren Produktentwicklungsprozess als relevant erachten.

1. Ziele und Zielsetzungen

Dieser Teil ist das „Warum“ für die Erstellung dieses Produktdokuments. Es bietet den Kontext für den Lebenszyklus des Produkts und wie es mit der umfassenderen Mission und Vision Ihres Unternehmens/Produkts übereinstimmt.

Versuchen Sie, die Probleme zu klären, die dieses Produkt lösen soll. Dadurch wird sichergestellt, dass Ihr Entwicklungsteam ein Produkt erstellt, das seinen Zweck erfüllt und dies auf eine Weise tut, die für den Endbenutzer angenehm ist.

2. Wichtige Stakeholder

Ein einfacher, aber oft übersehener Teil des PRD ist die Identifizierung der wichtigsten Stakeholder im Produkt-Roadmap-Prozess. Dies sollte den Produktmanager, interne oder externe Designer, Produktentwickler, den Dokumentinhaber und alle direkten Mitarbeiter oder Führungspositionen umfassen, die beteiligt sind.

Jeder, der auf Ihr Projekt hofft, muss wissen, an wen er sich wenden kann und wofür. Klare Verantwortlichkeit ist entscheidend.

3. Benutzer-Personas & Stories

Diese Personas sind so wichtig im Entwicklungsprozess und Ergebnis eines Produkts. Jede Persona, die Sie erstellen, sollte als Input für die Produkterfahrung dienen und einen bestimmten Zweck oder eine bestimmte Herausforderung haben, um Ihrem Produkt zu helfen, sein Endziel zu erreichen. Sie helfen, die Anwendungsfälle des Produkts bereitzustellen.

Viele neue Produktprojekte gehen hier schief; sie drehen sich um Personas, die zu ähnlich aufgebaut sind und lediglich Geschlecht oder Alter ändern. Konzentrieren Sie sich auf Ihre Benutzer-Personas. Wer sind sie? Wie alt sind sie? Mit welchem Geschlecht identifizieren sie sich? Was ist ihr Beruf? Woher kommen sie? Wie heißen sie? Und vor allem, welches spezifische Bedürfnis löst Ihr Produkt?

‍Stellen Sie sicher, dass alle diese Faktoren unterschiedlich, aber genau zu den verfügbaren Daten sind. Verwenden Sie Google Analytics, soziale Medien und andere Publikumsdaten, um diese zu erstellen.

Was ist ein PRD-Persona-Beispiel?

Das Benennen von Personas hilft einem Produktentwicklungsteam, für jemanden und nicht für etwas zu entwerfen. Bauen Sie genug von einer Persona auf, damit das Team nachvollziehbar ist und sie versteht, indem es dies tut, erstellen sie ein Endprodukt, das zu den identifizierten Bedürfnissen von jemandem – und damit des Marktes – passt.

Unterstützen Sie diese Personas mit User Stories. Hier ist ein Beispiel für ein Persona-Anforderungsdokument: „Als Cindy, jemand, der XYZ tut, benötige ich dieses Produkt, um XYZ zu tun.“ Indem Ihr Designteam diese Kundenbedürfnisse als Unterstützung bei der Entwicklung eines neuen Produkts verwendet, wird es etwas schaffen, das seinem Zweck und seiner Markttauglichkeit treu bleibt.

Diese Stories sollten sich hauptsächlich auf eine bestimmte Funktion des Produkts konzentrieren. Anstatt wie ein Projektvorschlag auszusehen, sollte die Persona einen im MRD identifizierten Schmerzpunkt beantworten und den Wert, den die Funktion bietet.

4. Release Notes

Diese sind so wichtig, nicht nur um einem Produktteam zu helfen, sicherzustellen, dass die Produkt-Roadmap auf Kurs bleibt, sondern auch für andere beteiligte Teams. Es wird den Leuten helfen, ihre Arbeitsbelastung zu verwalten, damit sie das Produkt bei Bedarf unterstützen können.

‍Produkt-Release Notes sollten Meilensteinnamen, Funktionen, Fehlerbehebungen und kommende Verbesserungen enthalten.

5. Design & Wireframes

Visuelle Designs und Wireframes sind ein Muss für jedes erfolgreiche Produktspezifikationsdokument. Sie helfen Ingenieuren, die Designvision zu verstehen und die Schmerzpunkte von Benutzer-Personas zu beantworten.

Durch die Einführung von Wireframes in diesem Stadium können Sie Probleme identifizieren und Lösungen finden, die ohne visuelle Hilfe nicht offensichtlich gewesen wären. Betrachten Sie Design in diesem Stadium nicht als Grafikdesign. Ihr Wireframe sollte als Blaupause oder grundlegende Karte dafür dienen, wo Ihre Kernfunktionen auf einer Seite platziert werden und welche Seiten überhaupt benötigt werden.

Wireframes müssen nichts Schönes sein, aber sie müssen Ihren Ingenieuren und anderen Stakeholdern eine klare Vorstellung davon vermitteln, wie das Produkt verwendet wird und wie ein Benutzer durch das Produkt fließt.

6. Risiken

Die Gabe der Nachsicht ist so etwas Mächtiges. Wir wissen nicht, ob ein Produkt erfolgreich sein wird oder scheitern wird, noch jede Hürde, auf die wir im Laufe des Entwicklungsprozesses stoßen werden. Was wir tun können, ist zu versuchen, so viele Risiken wie möglich zu identifizieren, denen wir auf dem Weg begegnen könnten.

Ein Risiko kann alles sein, von einem wackeligen Zeitplan über neuen Code oder Talente, eine bestimmte Integration oder eine benötigte externe Ressource. Durch die frühzeitige Identifizierung von Risiken im Produktdokument kann das Produktteam alle größeren Herausforderungen so früh wie möglich bewältigen und einen Plan B für jede Situation vorbereiten.

7. Zukünftige Roadmap & Iterationen

Ein Produkt ist nie wirklich ein fertiges Werk. Es sollte sich in einem ständigen Zustand des Wandels befinden, aus seiner Verwendung lernen, sich anpassen und zu neuen Technologien oder Verbraucherbedürfnissen heranwachsen. Die erste Iteration Ihres Produkts sollte genau das sein, ein erster Entwurf.

Fragen Sie sich als Produktinhaber oder -manager, welche funktionalen Anforderungen für das MVP unerlässlich sind und was auf die zweite oder dritte Iteration warten kann. Erwägen Sie vielleicht sogar, was am besten bis zu einer zweiten oder dritten Iteration zurückgehalten wird und mit einigen Benutzerdaten unter dem Gürtel unterstützt werden könnte.

Versuchen Sie, die zukünftige Roadmap Ihres Produkts für die Design- und Engineering-Teammitglieder zu planen, damit sie verstehen, welche Grundlagen jetzt gelegt werden müssen, um diese Versionen zu ermöglichen. Berücksichtigen Sie den Zweck all Ihrer zukünftigen Arbeit, den Zeitrahmen, in dem sie voraussichtlich geliefert wird, und ihre Priorität neben anderen Funktionen.

Beispiel für eine Vorlage für ein Produktspezifikationsdokument

Das Schreiben eines Produktspezifikationsdokuments kann eine entmutigende Aufgabe sein, und es ist schwer zu verstehen, wo man anfangen soll. Es ist eine gute Idee, mit einer Vorlage für ein Produktspezifikationsdokument zu beginnen, um Ihren Prozess in Gang zu bringen.

Nachfolgend haben wir Ihnen ein PRD-Beispiel zur Verfügung gestellt, das Sie verwenden und an Ihre eigenen Bedürfnisse anpassen können.

‍

‍

Wie schreibt man ein Produktspezifikationsdokument?

Schritt 1: Lernen Sie

Ein PRD (was „Produktspezifikationsdokument“ bedeutet) sollte sich auf das Problem konzentrieren, das Ihr Produkt löst. Recherchieren Sie Kundenbedürfnisse und -wünsche und was sie derzeit für ähnliche Produkte bezahlen.

Wie gehen Wettbewerber an das Problem heran? Wie können Sie die Kundenbedürfnisse besser erfüllen?

Sprechen Sie mit Ihren Marketing-, Vertriebs- und Technikexperten über die Vor- und Nachteile der verfügbaren Technologien. All diese Recherchen werden Ihnen helfen, Ihr Produktentwicklungsteam selbstbewusst und effektiv zu führen.

Schritt 2: Definieren Sie die Kernwerte des Produkts

Ihre Vorlage für ein Produktspezifikationsdokument sollte klar erläutern, wie das Produkt mit den übergeordneten Zielen und der Produktstrategie Ihres Unternehmens übereinstimmt. Präsentieren Sie das Wertversprechen Ihres Unternehmens als Elevator Pitch. Stellen Sie sicher, dass jeder weiß, was eine erfolgreiche Implementierung des Produkts während des Design- und Implementierungsprozesses liefern muss.

Schritt 3: Erstellen Sie eine Produktphilosophie

Die Definition von Produktprinzipien hilft Ihrem Team bei der Entwicklung. Einige PRD-Beispiele sind:

• Sicher
• Zuverlässig
• Intuitiv

Diese Übung zum Wertversprechen hilft, die Prinzipien Ihres Produkts zu verfeinern und Ihr Team bei der Definition von Benutzeraufgaben und Produktfunktionen zu unterstützen.

Schritt 4: Identifizieren Sie Benutzerprofile, Ziele und Aufgaben

Eine fokussierte Übung zu Ihrem Benutzerprofil, Ihren Zielen und Aufgaben hilft Ihnen, Ihr Produkt effektiv zu entwickeln. PRDs sollten beispielsweise angeben, für wen es ist, welche Produktziele sie haben und wie sie es verwenden werden.

Erstellen Sie ein Benutzerprofil

Ihr Produktdokument sollte den primären Produktbenutzer identifizieren, der für Ihr Unternehmen in Bezug auf den Umsatz am wichtigsten ist. Fragen Sie Ihr Team bei der Prüfung neuer Funktionen, wie dieser Benutzer auf diese Funktion reagieren und sie verwenden würde. Konzentrieren Sie sich auf die Bedürfnisse, Wünsche, Gewohnheiten und Einstellungen der Mehrheit Ihrer primären Benutzer, anstatt zu versuchen, jeden potenziellen Kunden zufrieden zu stellen.

Definieren Sie Benutzerziele

Ein Produktspezifikationsdokument sollte angeben, was Benutzer erreichen möchten. Benutzer haben oft Schwierigkeiten, genau zu erklären, was sie wollen. Identifizieren Sie die Bedürfnisse und Hindernisse des Benutzers, damit Designer und Ingenieure die beste Lösung finden können.

Definieren Sie Benutzeraufgaben

Erstellen Sie bei der Zusammenstellung Ihres PRD mit Ihrem Team benutzerfreundliche Aufgaben. Untersuchen Sie, wie Sie die Ziele des Benutzers schnell und einfach erreichen können. Bewerten Sie dann die besten Alternativen.

Schritt 5: Listen Sie Ihre Produktfunktionen auf

Der Großteil Ihres PRD beschreibt die Funktionalität und die Einschränkungen, die dem Produktdesign auferlegt werden. Die Produktfunktionalität wird in funktionalen Anforderungen beschrieben. Nichtfunktionale Anforderungen beschreiben Einschränkungen des Produktdesigns.

Schritt 6: Testen Sie Ihr Konzept

Produktmanager und Entwickler nehmen ihren PRD-Entwurf oft zu ernst. Es ist zu spät, größere Änderungen vorzunehmen, wenn Beta-Feedback eintrifft. Moderne Prototyping-Tools machen das Testen der Prototyp-Produktvalidierung für Feedback einfach. Die drei Arten des Testens der Produktvalidierung sind:

• Machbarkeit
• Benutzerfreundlichkeit
• Konzeptprüfung

Schritt 7: Freigabekriterien

Ihr Anforderungsdokument sollte Anforderungen und Freigabeziele als "Muss", "Hohe Wünsche" und "Schön zu haben" priorisieren und einstufen. Dies hilft Ihnen, das Produkt auf den Markt zu bringen und sich entwickelnde Anforderungen zu verfolgen.

Legen Sie quantifizierbare Erfolgsmetriken fest wie:

• Leistung
• Zuverlässigkeit
• Benutzerfreundlichkeit
• Sicherheit
• Supportfähigkeit
• Skalierbarkeit
• Lokalisierbarkeit
• Andere relevante Produktfaktoren

Schritt 8: Überarbeiten Sie Ihren PRD-Entwurf

Stellen Sie sicher, dass der Entwickler das PRD-Problem versteht und die Qualitätssicherung genügend Informationen hat, um einen Testplan zu erstellen. Beheben Sie alle Probleme, die Ihre Stakeholder beim Erstellen Ihres PRD ansprechen.

Schritt 9: Verwalten Sie die Produktentwicklung

Wenn ein Problem mit den Anforderungen auftritt, beziehen Sie sich auf das PRD. Wenn es keine Antwort gibt, lösen Sie das Problem und protokollieren Sie die Entscheidung. Während der gesamten Entwicklung und Produkteinführung vermittelt Ihr PRD Ihrem gesamten Team ein klares Verständnis dafür, was Sie anstreben.

Die Fallstricke beim Erstellen eines Produktspezifikationsdokuments

Der Testprozess

In Ihrem ersten Usability-Test werden Sie sehen, welche Probleme sie haben und wie Sie sie beheben können. Für effektive Usability-Tests:

• Testen Sie die Benutzerfreundlichkeit vor der Implementierung, nicht danach
• Machen Sie mehrere Iterationen
• Beziehen Sie andere Stakeholder ein
• Konzentrieren Sie sich auf Benutzeraktionen, nicht auf Wörter
• Beobachten Sie die Interaktionen der Benutzer mit dem Produkt

Wenn Sie keine Usability-Ingenieure im Haus haben, beauftragen Sie eine Firma, die sich auf Usability-Tests spezialisiert hat, und fügen Sie deren Input zu Ihrem Anforderungsdokument hinzu.

Den Kunden im Fokus behalten

Kunden sind selten so technisch versiert wie Produkthersteller. Beispielsweise können Produktspezifikationsdokumente, die Ihren Designern intuitiv erscheinen, für potenzielle Benutzer unverständlich sein. Ein schlechter erster Eindruck kann Ihr Produkt beim Kunden sauer machen. Aus diesem Grund ist Kundenfeedback während der Entwicklung ein unschätzbarer Teil des Prozesses.

Beginnen Sie nicht mit Lösungen

Ihr Produktspezifikationsdokument sollte das zu lösende Problem angeben, nicht wie das Produkt es lösen wird. Ein lösungsbasierter Ansatz kann dazu führen, dass Ihre Ingenieure falsche Annahmen treffen und Ihr Entwicklungsteam verwirrt und frustriert zurücklassen.

Nicht genügend Details

Ihr Produktdokument sollte Ingenieuren und Designern viel Spielraum lassen. Teammitglieder werden PRD-Lücken füllen. Planen Sie Probleme ein, die während der Entwicklung auftreten, planen Sie Zeit ein, um sie schnell zu beheben, und aktualisieren Sie das PRD nach Bedarf.

Übermäßig detailliert

Zu viele Details können dazu führen, dass Teammitglieder das PRD nicht lesen. Komplexe Produkte benötigen möglicherweise Dokumente auf niedrigerer Ebene für jedes Subsystem. Die PRD-Vorlage von Slite berücksichtigt komplizierte Projekte.

Zu viele Funktionen

Obwohl es verlockend ist, alle Kundenbedürfnisse zu erfüllen, kann dies bei High-Tech-Produkten kontraproduktiv sein. Hinzugefügte Funktionen blähen das Produkt auf, was zu Benutzerverwirrung und erhöhten Wartungskosten führt. Seien Sie diszipliniert, wenn Sie Ihrem Produktspezifikationsdokument Funktionen hinzufügen.

Engineering-getrieben

Sie können den Produktmanager überlasten, wenn Ihr Engineering-Team von einer neuen Technologie begeistert ist. Projektmanagement-Regeln erfordern, dass Sie den Ingenieuren zuhören, sich aber auf den Wert konzentrieren und Beispiele für Anforderungen geben, die Kunden kaufen und Ihr Unternehmen erstellen kann.

Marketing-getrieben

Ein Marketing-getriebenes Beispiel für ein Problem mit einem Anforderungsdokument sind "Specials", spezielle Funktionen oder zusätzliche Käufe im Austausch für zusätzliche Zahlungen. Sonderangebote können zu Verwirrung und Frustration bei den Kunden führen. Sie erfordern auch das Erstellen, Testen, Warten und Unterstützen mehrerer Produktversionen. Und Kunden stellen möglicherweise fest, dass neue Funktionen ihre Bedürfnisse nicht erfüllen. Bewerten Sie jede vorgeschlagene Funktion und wissen Sie, wann Sie sich abwenden müssen.

Anforderungstransparenz

Ihr PRD muss die Anforderungstransparenz unterstützen und Probleme, Testfälle, Fehler und Problemlösungen für jede Anforderung verfolgen. Ein integriertes Anforderungsmanagement-Tool wie SLITE kann Ihre PRD-Bedeutung verdeutlichen und die Anforderungstransparenz erheblich vereinfachen.

Einfache Handhabung von PRD- und Produktprozessen mit Slite

Nur weil Sie es geschafft haben, ein effizientes Produktspezifikationsdokument zu erstellen, bedeutet das nicht unbedingt, dass Ihr Team es als Bezugspunkt verwendet oder überhaupt weiß, wo es zu finden ist. Slite ist hier, um Ihnen bei der Handhabung neuer Produktprozesse zu helfen, indem es Ihr Team mit den großartigen Ressourcen verbindet, die Sie erstellen:

• Teilen Sie Ihr PRD und andere Softwaredokumentation in Echtzeit mit denjenigen in Ihrem Team, die sie benötigen.
• Zentralisieren Sie das Wissen Ihres Teams, kein Springen mehr von Person zu Person, um Informationen zu erhalten.
• Erhalten Sie sofortigen Zugriff auf eine Fülle von Vorlagen, die Ihren Produktprozessen zum Erfolg verhelfen können.

‍