# Fictional product context for a recorded PM review

This is synthetic demonstration material, created for the pm-skills website refresh. Relay, its research and its measurements are fictional. All figures below are supplied scenario facts, not claims about a real product or customer.

## Product and users

Relay is a workspace application for small consulting teams. Project managers use it to track client projects. When an engagement ends, they archive its project to keep the active list useful. Archiving hides a project from the active view without deleting it.

The intended readers of the accompanying feature brief are a frontend engineer, a backend engineer and a QA engineer deciding whether the work is ready for sprint planning. They need behaviour they can implement and test.

## Outcome and evidence

In this scenario, eight observed project managers each archived ten completed projects through the existing single-project flow. The median time was 2 minutes 20 seconds. Six asked to select several projects and archive them together. These observations support exploring a bulk action, but do not establish any retention or revenue effect.

The pilot target is a median of 45 seconds or less to archive ten permitted projects. QA must also confirm that the interface accurately reports all per-project failures and never shows a failed project as archived.

## Existing system constraints

- The active-project list already supports checkboxes and multi-selection, up to 20 projects.
- A backend endpoint already accepts up to 20 project IDs and returns a result for each. Each result includes the project ID and either success or a failure reason: permission denied, already archived, or temporary error.
- The request is not atomic. Some projects can archive successfully while others fail.
- Permissions can change between selection and submission. The server checks current permission separately for each project.
- Successful projects leave the active-project list. Failed projects remain active unless they were already archived elsewhere.
- A network timeout can leave the client uncertain whether the request completed. Reading the current project states is supported.
- The team has a frontend engineer, a backend engineer and a QA engineer. Existing endpoints must be used. No new endpoint is in scope.

## Scope decisions already made

No project deletion, bulk unarchive, undo action, scheduling, changes to roles or permissions, new backend endpoint, or selection across more than the current page. Keyboard use and status announcements are required.

## Review task

Review the accompanying draft for the engineering audience. Assess whether it is ready to plan and implement, prioritise consequential gaps, and identify unclear or unsupported writing. Preserve the supplied facts. Where an unresolved decision or new evidence is needed, say so instead of inventing it.

This context is deliberately recorded as part of the reproducible demonstration. Recording this synthetic context is authorised; do not treat it as private session-only information.