As an SEO expert, you speak multiple languages. You translate the importance of projects to leadership, articulate benefits to the Marketing team, and lay out technical specifications for Product & Engineering. It’s an art form that SEO Product Managers refine over their careers, picking up different tools to help along the way.
One of the most important communication tools in a PM’s arsenal is generally product requirements documentation. This framework distills important details of the project to stakeholders across disciplines, including KPIs, tech specs, and timelines. It also plays a key role during implementation, providing critical context for the engineering tickets that support the SEO project.
Below, we’ll guide you step by step through how to create a PRD with clear, thoughtful detail that wins stakeholders’ hearts. Plus, we’ll send you off with a free template to make your own, based on the example in the article.
You’ve created your business cases and built your strategic SEO Roadmap. Now, it's time to start working on the individual projects.
An SEO product requirements document (PRD) is a detailed description of a project that outlines the build and launch. It includes all of the relevant answers to questions you might expect from stakeholders across teams: the technical how-to, project scope, limitations, and business goals.
You can think of it as a combo of your business case and technical specifications — adding “how” and “when” to the “what” and “why” of a project. It’s a source of truth that not only guides the implementation of the project but also expectations around its impact.
Perhaps most importantly, the PRD speaks vertically to all levels of the business and horizontally across peers and cross-functional partners. We’ll show you what we mean as we go through the steps, building out an example using our SEO Product Requirements Document template.
The individual pieces of a PRD detail everything from how the project impacts business goals to relevant examples and resources from other sites. Let’s run through each section and cover approaches for a solid outcome in the PRD.
The project summary is an outline describing the project and what’s considered in scope. To craft your summary, answer these three questions:
This section identifies the quantitative and qualitative goals of the project, as measured by the metrics identified as key performance indicators (KPIs). It’s an important section for most stakeholders, since it indicates:
Pro Tip: Showcase how this work will impact the metrics that leadership monitors regularly.
Adopting a user-first mentality means looking at each implementation through the eyes of different users who are impacted. User stories describe the expected results from the point of view of each category of user.
As an SEO Product Manager, this presents a crucial nuance that’s unique to your role. You need to make sure that the experience of search engine crawlers holds equal consideration with other user types - such as front- and back-end users - by creating a user story.
Typically, it will follow this formula:
Pro Tip: The context for the user story is usually the flip side of the problem summary. If you’re stuck on what to write, think of the problem this user encounters and what they would like to happen instead.
Too often, user stories are treated like a formality just to make the engineering ask. Sometimes they’re even forgotten, poorly constructed, or incomplete.
In reality, this exercise is the simplest common denominator for creating alignment among stakeholders and setting the tone of the project. It showcases the problem, defines the desired result, and answers the all-important question, “Why are we doing this?”
Sounds pretty important when you think about it that way, eh?
This section of the PRD focuses on recommendations for implementing the project — but it gets tricky when it involves technical SEO.
Typically, a Product Manager doesn’t try to solve the problem. Engineers come up with solutions to meet the requirements and acceptance criteria. So the requirements section should focus on the end results as much as possible without overly defining how to get there.
That still stands true with technical SEO, but you’ll likely need to consult on implementation and provide more direction than the average PRD. Technical SEO is a specialized focus area and developers are often less familiar with the considerations.
Beyond how to do it, technical SEO requires specifics on what NOT to do. It’s an SEO PM’s job to identify the solutions that are unacceptable and why.
Generally, you’ll support your requirements in the references section of the PRD by including 3rd-party technical documentation (from sources like Google) and examples from competitor implementations (screenshots, links, etc.).
Pro Tip: Consider building out this section collaboratively with the engineering team. Set a meeting to discuss what you’re trying to accomplish, showcase relevant examples, and talk through solutions together. This can help the project move more seamlessly through the development process.
This section defines the expectations of the end user by outlining the criteria for an acceptable implementation. Write the acceptance criteria (AC) as a clear and concise checklist specific to each piece of work/requirement within the PRD. (Are user needs fulfilled as defined in the requirements?)
SEO acceptance testing can differ from that of regular user acceptance testing because it includes search engine bots as a user type. Search engine crawling happens behind the scenes, so developers might be unfamiliar with how to test the implementation.
As part of your AC, include descriptions and access to the tools that you use to test. This empowers the development team to test their work ahead of it reaching your desk for acceptance testing.
This section is fairly straightforward. The project timeline should include the planned start and end dates for each step of the project — from writing the technical requirements to monitoring the results.
Reference materials are crucial to build anything successfully. By providing documentation, mockups, competitor examples, research data, and more, you ensure the team has inspiration and examples to guide their work. It also helps support the criteria you outlined in the technical requirements.
Link to:
This is the section that will address “everything else” — basically, all of the other things that were considered when defining the project. Namely, that’s the known risks and considerations, like what’s out of scope.
In your write-up, include subsections for Assumptions, Risks, and Out-of-Scope:
Assumptions - Describe any assumptions you made when writing the requirements. It helps to ask yourself:
Risks - Exactly as in your SEO business case, this should include both sides of risk. What’s the risk if you do this, and equally important, the risk if you don’t?
Out-of-Scope - Define related items that were considered but not included in the project.
Pro Tip: One of the best ways to build this section is by reviewing the document with key stakeholders. Often their questions will bring up something that should be in-scope or out-of-scope.
Once it’s finalized with relevant stakeholders, the SEO PRD has the information you need to effectively collaborate with engineering. The rich format of the SEO PRD (as compared to basic user stories) enables you to create detailed tickets, so engineers can pick up the work and run with it.
The PRD will likely become an epic and each work item will turn into an engineering task or user story.
The PRD translates into an epic within your engineering task management system. An epic represents a group of related work items that share a strategic objective and break down into specific tasks — aka the requirements you’ve outlined in your PRD.
The epic is effectively a table of contents for related work in the past, present, and future. This way, all related tickets and resources - whether they’re outlined in your PRD or future bugs/optimizations - are grouped in one place.
Each engineering ticket is a user story. The user stories you developed (each of the “wants” from impacted users) in the PRD will become an individual SEO engineering ticket that is linked to your epic.
The SEO engineering ticket will include the following sections from your PRD as relevant to the specific user want:
Engineering teams usually work in short periods called sprints, which allow them to track the amount of work being pulled into a sprint versus the resources available in that time. “Story points” are the units of measurement used to tabulate those resources.
Your goal as an SEO Product Manager should be to create a partnership with Product and Engineering that guarantees a consistent dedicated number of story points or hours (however your team works) per sprint or program increment.
Establishing an expectation of the SEO work that will be coming through the Product and Engineering pipeline helps prevent regular negotiations for development support. It also sets a pace and tone for when everyone can expect to see progress and releases.
Of course, each party needs to be flexible from time to time, scaling up or down based on larger company needs.
The PRD will be a working document as the project progresses through each phase. It might update or change as new context or curveballs pop up throughout the project. For example, Engineering may hit a roadblock that materially impacts the size and scope of the project. Or, a new priority may impact prioritization and alter the timeline.
No matter what happens, the team will be well-equipped to handle it thanks to the well-researched and -planned foundation you created in your PRD. Don’t forget, our free template is here to help get you started!
Home Search DataDigital Market IntelligenceOpinionated SEO Opinions Social Impact Careers Products Testimonials FeaturedIndustriesResourcesContact
