What is Documentation?
For a software company, documentation refers to information either embedded in the product or published documentation. It describes what the app does, how it works, and other essential details. Product documentation is a broad term and describes information for internal use and the product’s customer.
What Are Common Types of Product Documentation?
Product documentation can include many documents, such as the roadmap to documentation explaining how to use the app’s APIs).
Here are some common examples of product documentation. Remember that this is not a complete list and that not every product team will use every type of documentation on the list.
- Product vision statement
- Product strategy
- SWOT analysis
- User/buyer personas
- User research
- Product roadmap
- Competitive analysis
- Go-to-market strategy
- Market-requirements document (MRD)
- Product-requirements document (PRD)
- User tutorials and walkthroughs
- Product backlog
- Sprint backlogs
- Release notes
- Code documentation
- API and SDK documentation
- QA/testing documentation
- Help file
Note: Many of the items on this list fall outside the product manager’s responsibility. Creating the code documentation and the release notes, for example, will be the development team’s job. In many organizations, the go-to-market plan falls under marketing.
What Documents Does a Product Manager Create?
Depending on the size of an organization and how the company divides its responsibilities, a product manager’s job might include creating several of the documentation examples above.
But at a minimum, product managers should expect to be responsible for developing the following documents. We believe these are five of the most important strategic documents for a product’s success.
The 5 most important documents for product managers to prepare
1. User/buyer personas
We’re listing persona creation first because products exist to solve problems for people and businesses. Until you know who or what your product will help, you should not begin devising plans for the development.
A user and buyer persona is a short, composite biography describing the people who will buy and use your product. Learning enough about the target persona for your product will require research. The research can include speaking directly with your personas, sending out surveys, studying competitive products, and reading the industry chat forums where your personas post their thoughts and complaints about these products.
Your persona narrative should also describe the problem or goal these people are experiencing, the obstacles they face overcoming them, and how your solution will fix these problems for them.
2. Product vision
When you have a strong understanding of your persona, you’re ready to draft a product vision statement. The draft is a short, high-level statement describing the long-term objective for your product.
Don’t skip this exercise. Articulating your product vision is a key step to developing a product roadmap to help you accomplish your goals. It will also help you align your team around a shared understanding of the big-picture plans.
LinkedIn, for example, went to market with this product vision statement:
“To connect the world’s professionals and make them more productive and successful.”
That’s an inspirational message, not only for LinkedIn’s customers but also for its employees. If you draft it well, your product vision can help motivate your team. They’ll be able to remind themselves that their day-to-day work is contributing to a more significant cause.
3. Product strategy
Now that you’ve established a vision for your product, it’s time to begin drafting your product strategy. The strategy should take the form of a broad outline of how you plan to build and release the product.
Your product strategy will include plans for how you’ll work with other teams, assign resources to develop the product, and prioritize the functionality you will build first. Your strategy can also include your plans for pricing the product, positioning it against competitors, and high-level goals for sales and marketing.
4. Product roadmap
We believe this will be the most critical documentation you oversee as a product manager.
The product roadmap acts as a bridge, connecting the high-level strategic planning you’ve done so far with your cross-functional team’s plans to carry out their tactical work on the product.
The roadmap also serves another purpose: It acts as a reference point, a set of guardrails, that your team can refer to anytime to ensure they are still moving in the right strategic direction.
We’ll walk you through how to document a roadmap in the next section.
5. Go-to-market plan
In many companies, the marketing or product marketing team will take responsibility for the product’s go-to-market plan. But product managers need to take an active role in shaping this strategy.
After all, product management—not marketing—owns responsibility for the product’s success or failure with customers. The go-to-market strategy will affect how the product performs when the company releases it to the market.
How Do You Document a Product Roadmap?
If you are building your first roadmap from scratch, here is an overview to get you started.
Step 1: Find the right roadmapping tool.
Your product roadmap needs to tell a strategic story about your plans and goals. Spreadsheets and presentation software won’t do the job.
You need a purpose-built roadmap app, one designed by product managers for product managers. The tool should accommodate your needs, such as moving themes epics around quickly as your priorities or constraints change.
The software you use should also make it easy to share your product roadmap with everyone on your team and integrate the roadmap with apps like Slack and Jira to update other departments when you change the roadmap.
Step 2: Use a scoring system to decide what goes on the roadmap.
Once you’ve found the proper roadmap app, you’re ready to begin populating a new roadmap with the big strategic themes and epics for your product. But you will be working with limited limitations and time pressure to complete the first version of your product. The question is, which initiatives will you include on your roadmap first?
For this step, you will want to gather and review the research you’ve done—interviews with personas, competitive analyses, industry surveys, etc. You and your team can pull together all the features and ideas you’ve jotted down to this point, check them against the research you’ve compiled, and begin weighing your feature ideas against each other.
The key here is to use a common rating or scoring system for all items on your list to ensure you’re weighing each idea using the same criteria. Those criteria can include upside metrics, such as revenue, market share, and customer delight. They can also have risk metrics, including development effort and opportunity cost.
One great framework you can use for this exercise is weighted scoring. You can use the prioritization board built into ProductPlan’s roadmap app to manage your team’s scoring. When you’ve determined the items you want to include on the roadmap, you can do so with a click. You can even shelve the remaining items for later in the “Parked” area of the app.
Step 3: Include a strategic justification for every item you add.
When you add a theme or epic to your roadmap, you’ll want to include your reasoning. You will use this roadmap for many strategic purposes. When you present the roadmap to other stakeholders, such as development, sales, and your executive staff, you want them to understand not only what you plan to build but why doing so will benefit your company.
When you use the right roadmapping app, you can drop in a short note under the item’s description—and you can make it visible by default or keep it hidden until you click on it.
You can also create a link to supporting data—a file, a page on your intranet, etc.—and connect that link to the epic. Maybe your roadmap will include an initiative to build support for a new browser. You can link to your data showing that a significant percentage of new buyers of your app use this browser.
Step 4: Revisit and review your roadmap regularly.
Your product roadmap represents a high-level overview of your plans and goals for the product, not a step-by-step tactical plan. During development, things will change. Because your cross-functional team will also be using the roadmap as their strategic reference point, you need to make sure it always reflects your current thinking and priorities.
Review your roadmap regularly, review it for accuracy, and make relevant changes to it immediately. Suppose you’ve integrated your roadmap with your team’s other workflow apps, such as Slack or MS Teams. In that case, you will also want to make sure your changes automatically trigger notices to the relevant people working on your product.