A lot of us product managers have struggled with the craft of creating “complete” Product Specs/PRDs. This  leads to engineers having a lack of clarity on what needs to be built, sales and business not being aligned in terms of what is being built vs what is being sold as well as executives and other stakeholders having a lack of clarity in terms of what exactly the vision and strategy of the product are in the product manager’s mind.

There’s a quote from “System Engineering Fundamentals” for Product Requirements:

“Determine the needs or conditions to meet for a new or altered product, taking into account the possibly conflicting requirements of the various stakeholders”.

For the definition of a product specification, they promote proper documentation for a precise idea of the problem to be solved so that the designing would be efficient and the cost of design alternatives can be estimated. 

A spec should be crystal clear and technically concise that doesn’t cater to any ambiguity which makes it the engineers easy to understand what they are actually going to work on. When we go deep down into the spec, it is much like a game plan which is made to act strategically with our product or service to achieve our goals.

The spec should clearly answer the What, Why, How, and When something needs to be solved. It should be the single source of truth for the particular feature/product which the engineering team can refer to and clearly begin on the solution with full clarity. 

There are some amazing companies out there that do excellent documentation for Product Specifications/PRDs like Google, Facebook, Uber, and Microsoft. What are they doing right?

There are so many elements in a product spec that are specific to the type of industry you are working in, whether you are working in a B2C or a B2B company, an early-stage company, or a company with a mature product line, etc.  

Let’s go over some of the elements that make these specs really “complete” :

1. Goals should be SMART: Specific, Measurable, Attainable, Relevant, and Timebound. An example of a bad goal would be- “Make system XYZ faster”; since what defines “fast” or “faster” and when do we know whether the goal is met or not?

2. Assumptions: Don’t assume that the assumptions made are known by the engineers, leadership, or any other stakeholders, convey all the assumptions clearly before that have been made as a baseline before starting a particular spec.

3. Non Goals: We tend to keep our focus on ‘do this to win’ but it’s also important to figure out what ‘not to do’ as well. This prevents scope creep and helps us focus on the right things. So clearly call out things that you are NOT chasing.

4. Target Audience & User Personas: Discover your target group of people with different personas who will be affected by your feature. Before writing individual feature specs, it’s good to know the product’s relevancy for the particular audience you are targeting and how it will affect them.

5. Data Analysis/Complete Analysis: Publish the data analysis your team has done to give an insight into the problem statements or the solutions which you’ve chosen to build. This gives a clear metric-driven insight into the product strategy.

6. Hypothesis: Companies like Facebook and Uber run hundreds of tests/hypotheses every single week. For a B2C product, clearly call out any hypothesis that you are going to test with this particular feature release.

7. Feature List Table: The feature list table is a short summary of the whole spec which lists down all the sub-features with priorities, owners as well as calls out any other cross-team dependencies. This helps the engineering team plan out the feature efficiently and carve out individual sub-tasks and tickets.

8. Features in Detail: Document the complete description of the feature in detail.  Based on the type of feature  it should include wireframes/flowcharts/pseudocode for functional and business understanding. Wherever applicable, link to the UX design which lets all the stakeholders understand how the design should be.

Clearly call out the internal/external dependencies.

9. Deployment Plan (GTM Strategy): Define how you would want to launch your feature. Is the feature being launched in a phased manner as per user groups/geographies or as per some other pivot?

10.  Metrics: List out all the success metrics to be tracked. Depending on the type of the feature, you can use metrics frameworks like AARRR (Acquisition, Activation, Retention, Referral, Revenue) or RED (Requests, Errors, Duration) or CSAT/NPS.

11.  Anti-Metrics / Counter Metrics: Document the risks posed thanks to your feature. What are the metrics to be tracked to manage the risk? What’s the risk mitigation plan?

12.  In concluding, here are some of the specific domain-related features you should be cognitive of, starting from Security Sign-off/Audit Sign-off/Privacy Sign-off for your privacy concerns, Localisation for international features that deliver support for different languages, Future Enhancements involves future vision with the plan and phases for the product, Appendix in which any kind of stuff you want to add, epic/ticket links, etc.   

Thank you.

Credits

Speaker- Anand Kulkarni

Blogged by – Nupur Chandra & Phani Marpaka

Video Edited by Nupur Chandra