Engineering Spec With Acceptance Criteria for Apple's Online Apple Watch Shopping Page

You are a product manager at Apple. Write the product requirements and acceptance criteria that the engineering team will build from for the page on Apple's online store where shoppers browse the current Apple Watch lineup and pick a model to buy. The global site header and footer are out of scope. Treat this as a take-home exercise that should take no more than two hours. The live page changes with every product generation, so work from this assumed layout and say explicitly if you change any part of it: - a product navigation bar that names the current generation and links to its overview page and to a model comparison page; - a special-offers module whose call to action opens a full-screen overlay; - a filter panel with facets such as case material, band type and collection; - a grid of product tiles, each with an image, the model name, the price and a "New" label where it applies; - entry points to Apple Watch Studio, the configurator where shoppers pair a case with a band, which opens in a full-screen overlay; - sections for special collections such as the Nike and Hermès editions, each with its own tiles and Studio entry point; - promotional modules for watch bands and for the lower-priced Apple Watch SE; - a comparison module that summarizes each model in the lineup, with links to shop for it or learn more about it. ```hint Write criteria a tester can check Go module by module. For each one, pin down what it shows, what every interaction does and which states it can be in, then turn each behavior into a pass-or-fail check. Spend the most precision on the filters, because that is where two engineers are most likely to build different things from the same loose sentence. ``` ### Clarifying Questions - Is this a rebuild that must match today's behavior, or may the spec change it, for example by keeping a collection's Studio entry point visible when that collection is selected as a filter? - Will design supply mockups and breakpoints, or must the spec define how each module behaves on mobile versus desktop? - Do analytics events, SEO metadata and localization (currencies, regional availability, right-to-left languages) belong in this document or in separate specs? - What format does the engineering team expect for acceptance criteria, such as Given/When/Then scenarios attached to tickets? ### What a Strong Answer Covers - The page's job in the purchase funnel, how success is measured, and an explicit scope with stated assumptions and exclusions. - Module-by-module functional requirements covering content, interactions, navigation targets and responsive behavior on mobile and desktop. - Unambiguous, testable acceptance criteria, with precise filter logic (how selections combine within and across facets, active counts, reset) and empty, loading and error states. - Non-functional requirements: performance, accessibility, localized prices and availability, SEO metadata and analytics instrumentation. - Prioritization that fits the two-hour limit and a list of open questions for design and engineering. ### Follow-up Questions - A shopper selects aluminum and titanium under case material, then selects one band type. Exactly which tiles should remain, and how would you phrase that as an acceptance criterion? - After launch, which events would you ask engineering to instrument, and which numbers would tell you the page is doing its job? - Engineering says the filters will miss the launch date. What ships first, and what do you tell stakeholders?