On PRDs
Regarding the philosophy of effective PRD design.
TruckSmarter builds product with no PMs. Instead, we expect operators and builders to directly define the specifications of products they work on and with everyday. Below I “open source” an internal piece I wrote to discuss the “skill” of defining product requirements.
At TruckSmarter, we plan product development with a number of documents: we use product proposals to light the first spark of product ideas, we use engineering requirement documents to discuss the appropriate technical approach for executing on a particular feature, we use Figma designs to detail exactly how a user flow will progress once a particular feature is incorporated in any of our user-facing applications. Most critical amongst these documents is the “product requirement document” (PRD), which details the precise requirements of a particular product or feature. Building a successful software product is a collaborative effort between a wide range of functions: legal, marketing, operations, sales, etc. Product requirement documents are crucial for ensuring every individual involved in this effort is aligned on the what and why of any product development initiative.
Why should you read this?
At TruckSmarter, we don’t have a typical “product manager” role. We entrust operators and builders to directly define the specifications of products they work on and with everyday. This unique operational style has empowered individual contributors to quickly ship high impact product updates and maintain an execution advantage, relative to competitors. This organizational structure only works if all individual contributors can confidently define product requirements for the initiatives they accomplish.
What is a product requirement document?
The simplest definition of a product requirement document perhaps lives within its name: A product requirement document is a document that should detail all product requirements of a feature. This definition is straightforward, but is perhaps not complete enough to be particularly useful. Ambiguity in its individual words minimizes its utility.
“all” doesn’t clarify the scope of the document. Surely this document doesn’t need to include a pixel by pixel specification of every sub-component of the feature?
“product requirements” doesn’t clarify the concerns of the document. How do I know which requirements are properties of the “product” as opposed to the “design” or the “engineering architecture”?
“detail” doesn’t clarify the form of the document. What if I want to include wireframes or flow charts when communicating requirements?
A more technical definition, borrowing from established standards on the practice of project management provides more informative guardrails of what should and shouldn’t be in a product requirement document.
A product requirement document details all functional requirements of stakeholders for a particular feature.
Like any good definition, this motivates a few more sub-definitions.
Functional requirements refer to the expected behaviors of the feature once it is completed from the perspective of project stakeholders.
Project stakeholders are the set of persons or entities who may affect or be affected by the outcomes of a project. Stakeholders are often, but not exclusively, team members at a software development company. At TruckSmarter these persons or entities can be carriers, brokers, fuel merchants, the finance team, TruckSmarter’s business, or engineers on a particular on-call rotation.
A feature is a distinct capability or functionality within a product that provides value to project stakeholders.
With a thorough understanding of the “What?” for product requirement documents, the next question to answer is “who?”.
Who participates in a PRD process?
In order to talk productively about the PRD process, we’ll need to specify its 3 major participants. Each participant plays a different role in crafting a PRD to achieve its goals.
Project owner: This is the person(s) who is accountable for the writing the PRD, sharing it with reviewers, and for the overall execution of project priorities. This person is distinctly responsible for the success or failure of the project. They “captain” the PRD process; working with other participants to ensure the document achieves its main objectives.
Stakeholder representatives: These are representatives of PRD project stakeholders that are internal members of the project owner’s organization. While these individuals typically work alongside the project owner, they can represent project stakeholders outside of the project owner’s organization, such as business partners or end-customers.
Product development team: These are team members at a company (designers, engineers, data analysts) who will be responsible for implementing a feature described in an ERD.
Often times, the same person(s) can take on multiple of these roles (for example, at TruckSmarter a member of the product development team is often a project owner). The project owner authors a PRD, while stakeholder representatives and the product development team are reviewers of the document. Reviewers are expected to review every detail in the “final draft” of the document before beginning significant development, as well as any iterations upon this draft generated throughout the course of product development.
Why do we write PRDs?
Why is it so crucial to write functional requirements down? A product requirement document typically has the following core objectives in descending order of priority.
Aligning stakeholder representatives and project owners on the minimal set of functional requirements necessary to achieve a major goal for project stakeholders (which should be spelled out within the document).
To give a feature’s development team a source of truth for functional requirements as they bring the feature into existence.
To give stakeholder representatives (oftentimes coworkers of a project owner) an artifact describing exactly what the impending effects of the feature might be in order to coordinate any other organization-wide changes associated with a feature (updates to legal documentation, sales materials, or operational processes, etc.).
This list of goals is deceptively brief, but well-written PRDs contain a surprising amount of detail to achieve all three of these objectives. For any sufficiently complex product initiative, project owners must align project stakeholders on a solution that achieves their various goals, track down all details required to inform design and engineering implementation, and define all functional details of a feature that might directly or indirectly affect any individuals (often kicking off a vicious cycle to re-align on product details missed with their first solution). At smaller companies this challenge is heightened with quickly shifting priorities, underdefined product direction, and a rapid execution cadence.
What should I include in a product requirement document?
After “what?”, “who?”, and “why?”, the next question we must answer with regard to a product requirement document is “how?”. Unfortunately, “detail all functional requirements” is not sufficiently descriptive instruction. Below is a non-exhaustive list of “do’s” and “don’t’s” which guide what should be included in a well-defined product requirement document.
Do center a PRD around the goal of a feature. The first objective of a PRD is to ensure a feature achieves a particular goal for project stakeholders. All discussion between reviewers and authors will revolve around whether or not each functional requirement furthers the documents stated goal. Clearly defining a goal is crucial for a successful PRD process, as it prevents unwanted requirement creep beyond the intended scope of a project owner. Any functional requirements deemed unrelated (or actively harmful) to the goal of a feature should be excluded in the final iteration of the document.
Do describe functional requirements with enough detail to be useful. The perfect PRD includes all information necessary to achieve the document’s core objectives and not a word more. Project owner must be deliberate in their description of functional requirements, including every detail relevant for aligning team members, specifying development work, and documenting feature functionality. They must establish a ubiquitous language of entities, individuals, and concepts related to the feature, to empower clear discussion of a features efficacy. It’s all too common for authors to include too few details, rather than too many (the absence of relevant details is much harder to spot than the presence of irrelevant ones). An approach that starts with abundance is often preferable to one of scarcity.
Handwavy fluff in lieu of feature specifications can greatly diminish the utility of the document. It leaves reviewers quarrelling over definitions or ill-described stakeholder concerns instead of discussing a feature’s core functional requirements.
Some examples of useful functional requirements, for the booking feature of an appointment scheduling application would be:
Visitors should be able to select a time on an account owner’s calendar by selecting an available timeslot based on the visitor’s time zone. When booking an appointment, visitors must fill out a form specifying their name, email, and any additional information required by the appointment type.
After booking, visitors should receive a confirmation email with a calendar invite. Both the user and the visitor receive reminder emails both 24 hours and 1 hour before the appointment.
Visitors can cancel or reschedule appointments through links provided in the confirmation email. The system must offer the user the option to set cancellation and rescheduling policies, including deadlines and any associated fees.
Examples of requirements without enough detail to be useful are:
There's a page where users can book times.
Visitors can book appointments.
These requirements are devoid of specificity, prohibiting a reader from understanding their effect on project stakeholders with any precision. The primary goal of an "appointment scheduling” feature is to help visitors book appointments. For stakeholders to evaluate if it meets that objective they must understand additional details: the workflow for appointment booking and the information used to determine available times. These requirements are meaningless to a product development team. They provide no valuable notes on which data from the account owner is necessary to support a visitor's desired flow and no information regarding the data a visitor can read and write to the application.
Do split functional requirements by their respective stakeholder. Complex features will often have multiple stakeholders, each of which are affected by a set of functional requirements. Documenting these effects from the prospective of each stakeholder can bring exceptional clarity to a completed document. One could organize the example functional requirements of the previously mentioned appointment scheduling application as follows:
Visitors
Visitors should be able to select a time on an account owner’s calendar by selecting an available time slot based on the visitor’s time zone. When booking an appointment, visitors must fill out a form specifying their name, email, and any additional information required by the appointment type.
After booking, visitors should receive a confirmation email with a calendar invite. Both the user and the visitor receive reminder emails 24 hours and 1 hour before the appointment.
Account Owners
Account owners should be able to authorize access to their google calendar, to import time slots for which they are available.
Account owners should be able to specify which days of the week are open for visitors to book appointments.
Do document operational requirements for launching the feature. Launching a feature successfully often requires much more than excelling at product development. It can involve appropriate measurement of user engagement or incurred vendor costs, broad updates to go-to-market strategies and operational processes. Effective PRDs detail what must be measured to understand a feature’s success, how the rollout will be completed, and what the process will be for educating internal and external users about the feature.
Do link to visual aids if they help communicate functional requirements. A PRD doesn’t need to solely comprise of text. Often times functional requirements are best described with visual aids (wireframes, system diagrams, flow charts, etc.). It is completely reasonable to link non-text artifacts in a PRD for team members to review. That said, to make sure that all discussion of functional requirements can be easily referenced, it is crucial for PRD authors to consolidate any comments from team members into a single document.
Don’t include functional requirements you do not expect to be supported in the final version of the feature. Sometimes, the hardest part of writing a product requirement document is deciding what not to include as every feature can branch in boundless directions. Including non-requirements in this document often hinders its capability to achieve core objective #2. If a product development team is unable to determine which functional requirements must be satisfied and which are goals for a future iteration, the document cannot effectively be referenced as a source of truth specification.
Of course, no one is clairvoyant. This “don’t” is not a directive for PRD authors to aim to be so. It instead dictates that “stale” functional requirements should be removed from a PRD before proceeding to product development work. Notes on previously proposed requirements, “P2” requirements (nice-to-have’s which stakeholders might want but are not critical to a feature’s success), or a set of features which might be developed in the future should be relegated to an “appendix” or “future work” section of the document.
Don’t describe more than 2 “milestones” for a feature. It is common for a large feature’s PRD to be broken down into milestones, or small iterations of the feature which provide iterative benefit for stakeholders. With each additional milestone in a PRD, comes additional difficulty in nailing every detail of every functional requirement. Constructing a PRD for a significantly complex feature is a herculean task, why make it harder by attempting to specify feature development work months in advance? By constraining the feature scope to a handful of milestones a PRD author can lessen their burden aligning on and defining long term requirements. Reducing any risk that a PRD needs to be revisited to accommodate newly discovered requirements months in the future.
It is very reasonable for a PRD to speculate on the functional requirements of a feature’s subsequent iterations. To ensure functional requirements make a lasting impact, it can be crucial to consider future stakeholder goals. Instead of straining to define future requirements, a project owner should document their foresight in a “future work” section of the document. This can communicate any extensions which much be supported by initial feature requirements.
Don’t include design or technical details. This “don’t” is perhaps the most socialized guidance on PRDs and doesn’t warrant as much discussion. Where lines can get blurred is that it’s perfectly reasonable to inform functional requirements with engineering or design considerations. Estimates of requirement feasibility are a core input towards discovery of any successful solution. A PRD author can thread this needle by only including high level summaries of implementation details, while routing comments on these details to a more comprehensive function specific document.
How should I interact with a PRD template?
Like many software companies, TruckSmarter provides contributors with a template defining what content they should put in a requirement document. A common critique of company-wide templates is that they are rigid and prescriptive. They define an exact set of details a PRD must include; some of which might not be relevant for
Features of varying contexts. Product requirements for an internal CRM integration vs. an update to an experience for end users
Magnitudes of scope. Product requirements for a developer tooling change vs. an entirely new subscription offering.
Number of effected stakeholders. A feature to be leveraged by a single person on an internal team vs. an update which affects stakeholders across the entire company.
In reviewing hundreds of PRDs over the past few years, I’ve come to see this rigidity as a feature, rather than a bug of a well-defined PRD template. If it even needs repeating, its extremely difficult to identify and describe the minimal set of useful functional requirements of a feature. The temptation one might have to ignore an established PRD template can often have disastrous outcomes for the resulting document. A good template is extensively battle-tested to support the communication norms, operational tenor, and shared user personas of a software development organization. It helps project owners reason about which considerations might be important. It aims to ensure that when properly used, the core objectives of a product requirement document are always met.
Perhaps despite this warning, you might still be inclined to take some artistic license when writing a PRD. Perhaps, the existing template is so mistuned to the context of your feature you’re convinced you can write a more effective PRD with a bespoke structure. Perhaps the feature you’re developing is so minor that you’d prefer to use a more paired down version of your company wide template. These objections are all reasonable, but “freestyle” with PRDs at your own risk. If your proposed bespoke PRD layout fails to achieve the core objectives of the document, you may be asked to write it again. Even worse you may not, leaving this failure unnoticed until it adversely impacts the success of your feature.
The PRD process
Thus far, we’ve covered the meat and potatoes of a PRD process, actually doing the hard work of writing the document. However, writing a product requirements document consists of much more than writing product requirements in a document. A PRD typically has an associated process, in which a project owner identifies which persons and entities are stakeholders of their product, selects the set of functional requirements which achieve an agreed upon goal, and refines their description of these requirements to maximize its utility for a feature’s development team. This process is as important to get right as the actual document. As mentioned, the number one goal of the PRD process is to empower team members to align effectively on a feature’s optimal set of functional requirements.
What are the steps of the PRD process?
A “project” is planned to begin and it is decided that the project owner will write a PRD to ensure its success. All day, everyday, members of a software development team iterate on the functionality of a company’s products; it can be unclear which iterations are worthy of initiating a process, and for which, the additional overhead is too unwieldy.
The best guidance I can give to this question is somewhat circular. One should write a PRD if they intend to achieve one of the document’s three objectives. Any time a contributor wants to align a team around a core set of functional requirements of a new individual feature, a PRD should be used. The PRD process is most useful when its the sole document used for achieving these objectives, so if you find yourself aligning on how a system should work, what a user should experience, or the details of a feature’s impact in any non-PRD setting, it’s time to start the PRD process.
A project owner aligns with stakeholder representatives on the goal of the feature. Before even considering the PRD’s functional requirements, a project owner should achieve unanimous agreement on its feature’s described goal. Without this foundation, a project owner risks complete failure in their PRD’s process as their defined functional requirements may stray severely from a goal stakeholders aim to achieve. A project owner can attain goal alignment in various ways. They can present a “draft goal” asynchronously for stakeholder representatives for review or hold a “kick off meeting” where the project owner ideates synchronously with these stakeholders to determine an appropriate feature goal.
A project owner works to uncover the functional requirements necessary for a successful launch of the feature. Functional requirements arise from understanding a problem experienced by a project stakeholder. Problem discovery can take a number of forms. For features used by end customers, less likely to communicate directly with the project owner, it could entail conducting user interviews or observing quantitative user data. For features used by stakeholder representatives, it can entail a quick discussion (synchronous or asynchronous) to determine exactly what challenges targeted users might face with their workflow today.
The feature’s stakeholder representatives and product development team are determined. This ensures smooth progression through the PRD process for the project owner. Collecting feedback from these individual participants is a required component of a successful feature launch, making it critical for project owners to identify them early.
A project owner writes a PRD, documenting the functional requirements of the feature. Perhaps I’ve discussed this at enough length.
A first draft document is shared with some reviewers, to give early feedback. Tight feedback loops are a hallmark of overperformance in so many domains, and writing product requirement documents is no different. Effective PRD authors are able to put together a “minimally useful” set of functional requirements to start a conversation on what the final set of functional requirements might actually be. Defining a complete first draft PRD empowers reviewers to directly discuss whether specific functional requirements further the goals of a feature, while an ambiguous work-in-progress forces reviewers to participate in the process as authors, clouding ownership of final document details.
The final iteration of the PRD is shared with stakeholder representatives and the product development team. Once a PRD’s authors and initial reviewers feel as though the document is stable enough for review from all relevant team members, it should be shared out more broadly for comments. PRD review is critical for achieving objective #1 of the document. This step gives stakeholder representatives the opportunity to evaluate whether or not the project will achieve its expected business goals. It also allows members of the product development team to give specific feedback about the feasibility of individual functional requirements.
At TruckSmarter, our PRD template forces an author to specify “stakeholders” and “product development team members” so that an owner can document whose reviews are necessary to validate functional requirements.
Notion properties used for members of my team to document the product development team members and stakeholder representatives held responsible to validate all functional requirements.
All outstanding discussion around the feature is resolved and the product development team can begin implementation. Project owners, stakeholder representatives, and product development team members must agree on all details of all functional requirements to ensure a PRD achieves all of its core objectives. Any unresolved discussion on the document additional risk that the implemented feature fails to achieve an agreed upon goal. A project owner can finalize alignment on the details of their feature, by confirming that every reviewers comment is resolved or documenting the resolution of “open questions” within the document.
The product development team begins to implement the feature, supporting all agreed upon functional requirements. Finally.
Changes to the PRD during development are documented to ensure reviewers remain aligned. Feature development rarely goes exactly to plan. Requirements which seemed feasible are discovered to be unmanageable as the product development team moves to implementation. Opportunities appear to ship new requirements with greater impact or to cut existing requirements deemed unnecessary. When updates are made to functional requirements, stakeholder representatives and product development team members must affirm that the update still furthers the goal of the feature, to avoid negative surprises during the reveal of finished work.
The PRD template at TruckSmarter includes a “changelog” to record re-validation from stakeholder representatives and product development team members. Any meaningful update to the functional requirements of a PRD is documented in this log, alongside the reviewers who were required to affirm this change.
Notion block used to document changes to a product requirement document made during the implementation of a feature.
Conclusion and caveats
This guide aims to serve more as a theory survey than an instruction manual, giving readers a framework to think about how they might construct a PRD process, rather than prescribing how exactly the powerful tool must be used. My hope is that it gives each reader ample direction for crafting a PRD process well-tuned to their complexity of an individual feature and the operating context of a product development team.
Thanks to Nick Faulkner and Dave Ghent for the thorough review and Mac McCann for the expressive header image for this piece. If TruckSmarter’s unique approach to building product is at all interesting to you definitely check out our available roles!