PRDs evoke images of gray-haired product managers shaking their fists at today’s developers yelling “get off my lawn!” and praying for the return of waterfall methodologies. But PRDs live on strongly in the cultures of large organizations such as Google, Amazon, Meta, and other big tech companies. Despite the near-universal embrace of document-light methodologies like design thinking and agile, the benefits of the idea of a PRD - a single artifact tracing through most requirements, use cases, user stories, test scenarios, and architectural considerations - can be realized through the shift to the AI-driven software development lifecycle without sacrificing the speed and flexibility of modern approaches.
Historically the PRD is a largely static document after project kick-off, which has many uses depending on the organization, team, or project. PRDs (and its close cousin the MRD) can make a business case for a new product or feature, define who the users are in personas and target markets, what they will be able to do in user stores, and how the product will benefit the organization financially. Some touch on system requirements, testing requirements, acceptance criteria, and even risk analyses. They can be a business plan, marketing plan, detailed system requirements plan, and a test plan all in one.
Startups use them far more rarely. The reasons are multifold: stakeholder alignment is easier with small teams, there are no budget approval meetings, resource constraints prevent thorough documentation, or a complementing desire to be ultra-lean makes it culturally incompatible. Also, startups might be more acutely aware that they don’t know where they’ll find PMF, which is essentially the “what” (as opposed to the “how”) a PRD is tasked to define.
What’s notable is that some of Big Tech’s internal incubator units have completely discarded the concept of a PRD in place of fast, iterative, documentless product development that they were founded on. Stripped down teams work to ship products and find PMF sometimes with engineers leading without designers, PMs, or testing units.
However, our research shows large tech companies continue to use PRDs or similar constructs. These companies have struggled to diversify their revenue streams outside their core businesses. The reasons for this are multifold. It’s hard to create new businesses that matter when your core business generates billions, so even $100M businesses may not get the attention they need to grow. Innovation tends to die in large companies even when it’s purchased once the acquiring organization’s finance and ops departments start regulating the decision making, let alone when it's internally incubated and forced to demonstrate results. Perhaps the PRD, with its lack of flexibility and adaptability, is part of this equation or a reflection of waterfall type thinking in the main organization.
At Intelligenic, we believe the PRD is a container to reflect thinking that needs to remain dynamic throughout the software lifecycle. The power of an AI-backed software development process is that it has the promise of allowing even large companies to get back to the document-light style agile development processes that made them great while maintaining the financial, resource, and market discipline needed to succeed at scale.
At the end of the day, all organizations building software products need some form of a PRD to determine what, why, and how they intend to build a product. The key here is to support the needs of the organization allowing them to present this PRD with as much or as little detail as needed. All the while supporting its dynamic creation and maintenance creating a living document of the product that can be adapted to what actually gets built.
Regardless of the form or change in process, the concepts a PRD brings together can be streamlined, summarized, dynamic, and effective when AI is incorporated into the SDLC. And maybe even it reemerges as a key artifact in your team’s ongoing processes.
Long live the PRD.
‍