The SERP Audit → 90‑Minute Contractor‑Ready PRD: A Step‑by‑Step Workflow

A focused SERP audit compresses early discovery by revealing what users expect for a query: the dominant content type, the feature signals (tools, calculators, widgets), and obvious gaps. Look at the top 8–12 results and note content type (guide, comparison, product page, tool), UX patterns, frequency of screenshots/screens, and recurring feature names — these are signals you can convert into feature candidates.

Don’t treat intent as binary. Identify the SERP’s dominant intent (informational, navigational, commercial, transactional) and the '3 Cs' pattern — content type, format and angle — to decide the shape of your page or product. This reduces guesswork and directly maps search patterns to what contractors should build and test.

Run the audit in three focused timers: 10 minutes (SERP scan), 30 minutes (feature extraction + mapping to user intent), 40 minutes (prioritization + acceptance criteria + mockup sketch + estimate) — 90 minutes total. Use a simple shared doc: a one‑page brief header, a features table, RICE scores, acceptance tests, and one mockup per high‑priority feature.

Convert signals into feature candidates using a short taxonomy: Visibility (what users see in SERP), Utility (what they can do), Trust (proof points and pricing), and Friction (missing pieces). This taxonomy keeps the feature list actionable and prevents mixing marketing copy tasks with engineering features.

Use a lightweight RICE score (Reach, Impact, Confidence, Effort) for numerical ordering — it’s fast and defensible. For speed, predefine Reach buckets and Effort buckets (e.g., Reach: 1/10/100 users per month; Effort: 1/3/8 developer days). This keeps scoring consistent and speeds decision‑making.

When the product is small or timeboxed, overlay RICE with MoSCoW: mark a small set as Must, a few as Should, and defer Nice-to-have items. Contractors need a clear Must list to avoid scope creep and to produce reliable estimates.

Acceptance criteria must be testable and concise. Use Gherkin-style Given/When/Then examples for each feature — contractors can use those directly as QA checks and to derive unit/integration tests. Keep 2–4 scenarios per feature: happy path, one edge case, and one failure path if relevant.

Attach a low‑fidelity mockup for each Must feature plus a short UI checklist (states, form validation, error messages, data persistence). The mockup doesn’t need pixel perfection: an annotated screenshot or Figma frame with notes is enough for a contractor to estimate and implement.

Provide a per-feature estimate in developer days plus assumptions. Use standard rate buckets (contractor, senior contractor, specialist) and present estimates as 'best case / likely / worst case' to set expectations. Include a clear definition of done: acceptance tests passed, demo deployed to staging, and handover notes.

Hand off a single brief containing: PRD header (goal, KPI), prioritized feature table with RICE and MoSCoW labels, acceptance tests (Gherkin), mockups, data/API notes, and a one‑paragraph rollout plan. This is what contractors need to give a firm time/cost estimate and start work immediately.