📝

Guide to Writing Product Requirements

Description
Enable consistent understanding across your team with this core PM tool
Tags
Product Management
Created
Jan 29, 2023 2:52 AM
Updated
Jan 29, 2023 7:29 AM

Any product development endeavor involves synchronizing a significant number of people: from engineers and designers, to sales and marketing teams, to C-level decision-makers. Product managers need a tool to quickly bring everyone up to a consistent baseline of understanding while preventing mistakes of misalignment.

Writing product requirements is the preferred way for PMs to succinctly communicate their insights and plans while enabling a 2-way conversation with stakeholders. In this article, I’ll show you how to start using product requirements in your own development efforts.

What are Product Requirements?

Product requirements are an evolving, collaborative document that helps guide the product development process from ideation to launch and beyond. They are a single source of truth that centralize key information, visuals, insights, and learnings in one place to ensure team and leadership alignment. They also help pressure-test thinking and expose blind spots.

Product requirements start out as a short memo and gradually mature into a more detailed document:

  1. Product brief:
    • A 1-pager written in the early stages of scoping or development
    • Clarifies the problem space and creates early alignment
    • Not too detailed to facilitate inquiry and dialogue
  2. Product spec:
    • 2-3 pages written when the team moves from the problem space to the solution space
    • High-level vision and product ideation broken down into medium-scope components
    • Enough detail to enable conversation around the solution without being too prescriptive
  3. Full product requirements document (PRD):
    • 5+ pages of execution and launch details written throughout the development phase
    • Allows the team to outline a plan with milestones, but is not prescriptive at the day-to-day task level

Great product requirements should provide enough constraints to get started and know where you’re headed, yet allow enough flexibility to enable new approaches or solutions as exploration gets underway. To reiterate: this is a collaborative document that should be regularly socialized, not a task list defined solely by the PM.

Writing Product Requirements

Product requirements are meant to be a team effort, but owned by the PM. It is advisable to write them using collaborative software such as Google Docs, Notion (Affiliate Link*), or Confluence.

There is no set standard for product requirements, but you can use the following section guidelines to start crafting your own document:

How Strong Are Your Product Requirements?

As you write and socialize your product requirements, you will inevitably get pushback or be asked for clarification. Here are some questions to consider to ensure your product requirements enable progress and minimize blind spots:

  • Can you clearly articulate what you want to do and why? Can you explain it to a non-technical audience?
  • Do the product requirements clearly portray what success looks like?
  • Have you socialized your document with and gotten feedback from everyone critical to the project, such as analysts, marketers, data engineers, etc.?
  • Are you able to have meaningful conversations about risks and tradeoffs and still move forward with a decision?
  • Have you outlined meaningful steps that enable engineers, designers, and marketers to start building?

Are Product Requirements Dying?

Product requirements are not without their critics. At many companies, there is a tendency for PRDs to become overly long, out of date, and read by few. Some argue that product requirements were designed in the age of waterfall development and are too bloated for agile approaches.

I see things differently. The more people you add to a project, the easier it is to end up with people swimming in different directions. It is the PM’s job to constantly edit and keep the document up to date. It should never be more than ~6-7 pages, but it can link out to supporting material. The document then becomes the source of truth for constant socialization (such as making decks), and anyone can access it to quickly get a download of the product’s current state.

There is a reason that Amazon starts staff meetings by having everyone silently read 6-page narrative memos. Information asymmetry is reduced, and meetings become a two-way discussion and debate.

Also, product requirements are not supposed to be prescriptive. If someone thinks the PRD is inconsistent with agile approaches, that is either a sign that either:

  • the PRD is too explicit and inflexible about tasks
  • the company has only become reactive to customer requests and is rudderless

It is the PM’s role to empower the team to build something great, not to micromanage.

Your Turn to Adopt Product Requirements

Strong product managers stay on top of their product requirements because they enable clear thinking across the organization. No matter the stage in the development lifecycle, it’s not too late to augment your existing documentation with a single source of truth.

References

*Notion affiliate link: If you click this link, I may make a commission for upgrades to paid Notion plans. At the time of writing, Notion compensates me for 50% of the first year fees for new Plus and Business plan upgrades within 90 days of clicking my link.