Spec‑First Feature Pages: A 7‑Field PRD That Publishes Copy, JSON‑LD, a 60s Demo, and Acceptance Tests

Marketing copy and engineering specs are different animals. When you write copy first you recreate product meaning in another pass; when you write specs first, you capture intent once and derive artifacts from it. That reduces handoffs and prevents the product and page from drifting apart as engineers ship changes.

A spec‑first approach treats the PRD as the single source of truth: content writers and search markup generators read the same seven fields engineers use to build the feature. This enables consistent messaging, accurate structured data (JSON‑LD), and acceptance tests that are traceable to the same sentences on the page.

Keep the PRD deliberately small. Each field maps to a publishing artifact and must be short enough to be consumed programmatically. The seven fields are: Title, One‑line Promise, Problem, How it Works (3 steps), Key Benefits (3 bullets), Target Persona & Context, Acceptance Criteria (Given/When/Then).

Write each field as a single atomic unit: Title becomes the page H1 and the JSON‑LD name; One‑line Promise becomes meta description and the first paragraph; How it Works becomes the demo script steps and the 'featureList' in JSON‑LD; Acceptance Criteria become the source for automated tests.

Map fields to outputs with simple templates. Use the Title, One‑line Promise, Problem, and Key Benefits to assemble the page copy. For JSON‑LD, use schema.org's SoftwareApplication or Product structure and populate fields like name, description, featureList, datePublished, and offers when relevant. Google’s developer docs show practical SoftwareApplication and Product examples you can model.

For a 60‑second demo script, convert How it Works (3 steps) into a three‑act script: 10s setup (persona + problem), 35s walkthrough (each step 10–12s with one benefit), 15s close (result + CTA). Keep language executable: 'Show login → click Create Template → show generated JSON‑LD preview'.

Write acceptance criteria in Given/When/Then (GWT) format. Each GWT scenario in the PRD becomes one acceptance test that QA or your CI framework can run or validate. Keep scenarios specific: include the persona, preconditions, the action, and the measurable outcome.

Use the same examples on the page as the fixtures in tests. When tools (Cucumber, SpecFlow, Robot Framework) parse Gherkin‑style scenarios, your engineering team can implement step definitions that call production code or run against a staging environment. That keeps behavior, documentation, and tests aligned.

Below are compact export templates you can implement as small scripts in your CMS or product tooling. The idea: paste the 7 fields and the system emits three outputs. Use whatever templating system your stack supports (Liquid, Handlebars, or a small Node/Python script).

Export snippet patterns: JSON‑LD using SoftwareApplication/Product, demo script assembly rule, and Gherkin acceptance test generation. These are intentionally short so you can paste them into a generator or a CMS field that performs the transformation.