Documentation for Product Managers
Note: An update is long overdue. Will be making the changes soon :-)
A framework for documenting SaaS PDLC
PMs are to products in much the same way Conductors are to Orchestras. Nobody knows what you do, you never really play any instruments yourself, and everybody feels that you’re grossly overpaid for the work you do.
Gags aside, the similarities don’t end here. PMs, like conductors, work behind the scenes, bringing different components of the final product together. However, unlike developers and designers, who can cuddle their commits and mockups at night, PMs’ beds are cold and lonely.
Despite owning entire products, PM work is largely intangible.
Besides the documentation!
What a conductor’s baton is to an orchestra, documentation is to product-building.
If building products was a disease, then the documentation would be its most telling symptom.
Introduction
I drew up a framework to streamline my own documentation process after talking to a few consummate PMs about its purpose and the best practices around it.
In this write-up, you’ll find the framework I built and the resources that helped me up my documentation game.
This is not intended to be an exhaustive list, and I’m sure I’ll discover deficiencies in this write-up every time I look at it. To assuage the guilt of putting out lacking work, I’ll keep updating this piece semi-regularly.
Now, I’ll walk you through an abridged PDLC to demonstrate the framework. Here’s a visual guide to help summarize it:
Phase 1// Project Proposal or Feature Request
1. I receive a [Feature Request Doc] from a Customer Success Associate. It’s a problem faced (or feature requested) by a bunch of our customers. The [Feature Request Doc] comprises:
- the challenges faced by the customer in absence of the feature
- the impact it’s having on their business (to help determine the relative importance of the feature)
- The profile of the customers (to help determine the priority of the issue based on the revenue at stake)
- any recommendations/inputs that the team might have
Proposal/Request docs require elementary RCA on the Customer Success team’s part in order to validate the authenticity of the request. However, the goal of the doc is just to establish the existence of the problem along with its impact.
Phase 2// Analysis & Feasibility
2. I sift through the customer feedback to delineate the scope of the problem and perform some analyses to determine the extent and the root cause of the problem. Then I do some reconnaissance to explore the possible resolutions for the issue.
Quite often, I need to enlist the help of a developer to determine the technical feasibility of the solution and have to consult with other stakeholders to validate its alignment with the overarching goal of the product/business.
There’s no universal way to go through this and it varies with individuals, teams, and requirements.
3. I then begin to outline the [Product Requirements Document] (PRD). It goes by a few names, and it’s important to have a shared vocabulary within the organization.
A PRD comprises the problem statement, users’ needs, user stories, the proposed solution, its value proposition, the rollout strategy, and the success metrics for the solution.
This is not an exhaustive list and here you can find a great primer by Manas (PM Lead, Gojek): Twitter Emoji Reactions PRD.
4. The PRD is often accompanied by a [Business Requirements Document (BRD)]. It’s usually prepared by Business Executives and Analysts.
Phase 3// Execution
5. Once the scope for the v1 launch of the project is frozen, I write a detailed [Functional Requirement Document (FRD)].
The FRD is a detailed breakdown of the product/feature(s) you’re planning to build that the developer(s) refer to while building the solution. Therefore, you try to break the product down at a functional level, i.e. buttons and their respective behaviors.
Here’s the FRD template we use at SmartServ— FRD Template
6. A [Behavior Driven Document (BDD)], on the other hand, is a high-level document that describes the behavior of the product from users’ perspectives. Not only does the BDD help the developer visualize the end product, it also allows the QA to prepare high-fidelity test cases.
Here’s a BDD example I put together: BDD Template
7. Meanwhile, I also work on the [Pricing Strategy Document] for the product. Pricing is a complex process with way too many moving parts. I don’t think that I can summarise it with authority in such a short post.
I’ve linked to a great resource that helped me navigate through the many variables of pricing.
Phase 4// Roll-out
8. Done with the product-centric documentation, I move on to the internal stakeholders.
An [Adoption Document] contains all information that might be useful in driving product adoption amongst the customers. It’s used by the customer-facing teams (Sales, CS, Marketing) to understand the value proposition of the product and they use it for quick reference during demos and sales pitches.
This document also contains FAQs on setting up the product, giving a demo, pointers for pitching, future roadmap, and the metrics to track the adoption of the particular feature.
9. I then take care of the release-related documentation. Along with the Marketing team, I work on a [Press Release]. The purpose of the press release is to get eyes on the new product/feature.
A few organizations, like Amazon, work backward from the customer. They write an internal Press Release that talks about the finished product before they even begin working on the product.
Here’s a great post on the Amazon [Press Release] paradigm.
10. External [Release Notes] are often purposed similarly. However, the nature of the release note is dictated by its placement. An app-store release note serves a different purpose than one on your website.
One must imagine Sisyphus happy!
Come release date, we gather around in a huddle and set fire to all the Google docs.
I’m just kidding!
We wait until the rollback to do that.
And then we retreat from our Zoom windows back to our beds, only to get back at it the following day.
