Choosing Template for Product Documentation

This article will come in handy for a Product Owner who:

• Wants to choose a template for a product documentation
• Looks for the most efficient ways to organize it

Below you will find 3 patterns to organize product documentation as well as directions which type to choose based on the project type, size, complexity and project management framework.

Type 1 — Extended Product Documentation

This is classic and the most deliberate way to structure and maintain product documentation
Every feature would be described in detail at the dedicated space.

Use cases:

• Beginning of the project — in order to align stakeholders vision
• Complicated project with a high value of mistake (e g software for a self-driving car)
• Waterfall project management approach
• More than 3 teams involved in the development. Documentation helps to understand product scope of other teams

The most common sections of the Extended feature PRD are:

• The team cast
• Hypothesis and argumentation
• Short feature overview
• Glossary
• Competitors overview
• Functional requirements
• Stories breakdown
• Mockups

Other sections could be:

• User personas
• Flow diagrams
• Nonfunctional requirements
• Feature performance metrics
• Configuration tables (for A/B tests)
• Dependencies
• Risks and Constraints

Type 2 — Light version of Product Documentation

This would be a tree-structured cheat-sheet with short overview of each product feature.

You will normally create it once the active development phase is over to have a summary-guide of what was developed.

Use cases:

• External audit
• End of the project that was outsourced. Product knowledge transfer to the client
• Product onboarding of a new team member

Building blocks:

1. User story
2. User scenarios
3. UI screenshots
4. UML diagrams

Type 3 — Jira stories grouped by epics

Sometimes due to the changing Agile environment, creating and maintaining the detailed product documentation for every feature simply doesn’t make sense.

In the startups while the product value is still being established after every cycle of testing with real users — product requirements can drastically change over a few month period.

Maintaining the extended product documentation during this phase will just eat resources and bring 0 value.

Use cases:

• Establishing startup with constantly changing product requirements
• Small simple product with only 1 development team involved

Tips to organize your product documentation in jira:

• All tickets in jira should be related to a specific epic. It will help to track history of all product changes and create wiki-version of documentation once a product is established.
• When requirements are refined during the development process — don’t forget to update the jira stories
• If scenarios of several jira stories are strongly related — make sure the stories are linked

Jira story building blocks:

• User/Job story
• Gherkin scenarios
• Acceptance criteria (Here you can list all info that was not covered by in the scenario section)
• Screenshots (Saves time of the team members who want to quickly grasp which UI part is related to the story)
• Link to design

Summary

Following diagram gives a quick summary of the use cases for each product documentation type.

Choosing product documentation type

I hope this article helped you to choose the best way to organize the product documentation. It’s highly important to create extended PRD only when it helps the team to achieve better results.

Let your work with product documentation be joyful and highly efficient!