Reverse engineering a Business Requirements Document (BRD) and a Product Requirements Document (PRD) from a live website is a classic exercise for Product Managers and Business Analysts. Because you are working backward from the final output, you have to separate the "Why" (BRD) from the "What and How" (PRD).
Here is the best, most structured methodology to reverse engineer these documents from a URL.
The BRD focuses on business objectives, target audience, and the overarching value proposition. You cannot see the company’s internal metrics, but you can infer their goals based on how the site is positioned.
1. Identify the Core Value Proposition & Problem Statement
- Action: Analyze the homepage above the fold, the "About Us" page, and SEO meta-descriptions.
- Questions to answer: What exact problem does this website solve? Why would someone use this instead of an alternative?
- Drafting the BRD: Write down the inferred Business Goal (e.g., "To provide a frictionless e-commerce platform for buying organic pet food").
2. Define the Target Audience & User Personas
- Action: Look at the marketing copy, the imagery, and the pricing page. Are they targeting enterprise B2B (formal language, "Contact Sales") or everyday consumers B2C (casual language, "Sign Up for Free")?
- Drafting the BRD: Create 2-3 primary user personas based on who the site is speaking to.
3. Analyze the Business Model & Success Metrics (KPIs)
- Action: How does the site make money? (Ads, subscriptions, one-time purchases, lead generation). Look at their primary Call-to-Action (CTA) buttons.
- Drafting the BRD: Deduce what metrics matter to them. If the main CTA is "Subscribe," their primary KPI is likely Monthly Recurring Revenue (MRR) and Churn Rate. If it's a media site, it's Time-on-Page and Ad Click-Through Rate.
The PRD is much more granular. It details the exact features, user flows, and system behaviors required to build the product.
1. Map the Information Architecture (Sitemap)
- Action: Click through the main navigation menu, footer links, and user dashboards.
- Drafting the PRD: Create a visual sitemap or a bulleted list of the platform's hierarchy (e.g., Home > Categories > Product Page > Checkout).
2. Identify User Roles & Permissions
- Action: Try to use the site as an unauthenticated (guest) user, then create an account. Look for "Admin," "Seller," or "Creator" login portals.
- Drafting the PRD: Document the Access Control List (ACL). What can a guest see vs. a logged-in user vs. a premium user?
3. Document User Flows and Epic/Feature Breakdown
- Action: Perform the core tasks of the website. If it’s an e-commerce site, go from searching for an item to adding it to a cart to checking out.
- Drafting the PRD: Break the site down into "Epics" (e.g., User Management, Search & Discovery, Checkout) and "User Stories" (e.g., As a user, I want to filter search results by price so I can stay within budget).
4. Deduce Acceptance Criteria & Edge Cases
- Action: Intentionally try to break the site. Leave mandatory form fields blank, enter letters into phone number fields, or try to access restricted pages.
- Drafting the PRD: Write down the validation rules. (e.g., "Password must contain 8 characters," "If payment fails, show X error message").
To make this process faster and more accurate, use these specific tools and tactics:
- Browser DevTools (F12):
- Network Tab: Watch the API calls when you click a button. The JSON payloads in the Request/Response will literally tell you the Data Model required for the PRD.
- Elements Tab: Inspecting the DOM can reveal hidden features, A/B testing flags, or upcoming features commented out in the code.
- Traffic & Competitor Tools (SimilarWeb / Ahrefs): Plug the URL into these tools to discover their demographic data and traffic sources. This provides hard data to back up the "Target Market" section of your BRD.
- Wayback Machine (Archive.org): Look at the website from 2 years ago. Seeing how the site evolved helps you understand what features they prioritized or killed, giving you insight into their true business requirements.
You do not have to write everything from scratch. You can use Large Language Models (LLMs) to do the heavy lifting:
- Take Full-Page Screenshots: Use a browser extension (like GoFullPage) to capture entire pages (Homepage, Dashboard, Settings).
- Prompt an AI (like Claude 3.5 Sonnet or ChatGPT-4o): Upload the screenshots and use a prompt like:
"Act as an expert Product Manager. I have attached a screenshot of a web application's dashboard. Based on this UI, reverse-engineer a detailed PRD. Include: 1. Assumed User Personas. 2. A list of Features/Epics. 3. Detailed User Stories with Acceptance Criteria. 4. Inferred data inputs/outputs."
- Feed the DOM/Text: Scrape the text of their "Features" or "Pricing" page and feed it to the AI to instantly generate the BRD's Value Proposition and Feature Scope.
When reverse engineering, keep in mind that a live URL only shows the survivors of the product process. You will not be able to see:
- Features that were in the original PRD but were descoped due to budget/time.
- Internal backend constraints (e.g., "Must integrate with legacy AS400 system").
- The original budget, timeline, and internal stakeholder disputes.
By combining business inference (BRD), systematic clicking and edge-case testing (PRD), and technical inspection via DevTools, you can recreate highly accurate requirements documents for any live platform.