Product (engineering)
Requirements written for an engineering team to build: PRDs, user stories, acceptance criteria, specs.
Download all 13
- Product manager
Acts as a product manager who starts from the user problem and evidence, writes requirements engineers can build and test, and cuts scope to the smallest valuable release.
- Write acceptance criteria
Writes testable acceptance criteria for a user story or ticket, covering the main path, alternatives, validation, boundaries, permissions and empty states. Use before a story enters development.
- Write a PRD
Writes a product requirements document that an engineering team can build from, with the problem, goals, success metrics, testable requirements, edge cases and open questions.
- Write user stories
Turns a feature description into small, independent user stories for specific users, each with acceptance criteria, and splits stories that are too big. Use when preparing a backlog.
- Define non-functional requirements
Writes measurable non-functional requirements for a feature, covering availability, latency, throughput, security, privacy, accessibility and operability, each with a target, verification and cost.
- List a feature's edge cases
Lists the edge cases of a feature before build by boundaries, time zones, concurrency, permissions, money and rounding, languages, scale and failure, each with the decision a product owner must make.
- Refine a backlog ticket
Turns a vague ticket into a ready-for-development one with the user problem, scope and non-scope, open questions, acceptance criteria and a definition-of-ready check. Use in backlog refinement.
- Specify an in-app reporting feature
Specifies a report or export feature in a B2B product, with filters, columns, permissions, row limits, async export, formats, time zones, scheduled delivery and how numbers reconcile with the screens.
- Specify an internal tool request
Interviews a non-technical colleague about the internal tool they want, one question at a time, and writes a spec developers can estimate, with problem, users, workaround, data and value.
- Specify mobile screen states
Specifies every state of a mobile screen before build, from loading, empty, error, offline and denied permissions to long text and dark mode, plus deep link entry, back behaviour and analytics.
- Turn a game design into a tech spec
Turns a game design section such as a mechanic, economy or progression system into an engineering spec with data definitions, state, designer tunables, edge cases, save impact and test hooks.
- Write an actionable bug report
Turns a messy complaint, screenshot note or support chat into a bug report engineers can act on, with environment, numbered steps, expected versus actual, frequency, impact and open unknowns.
- Write firmware requirements
Writes testable firmware requirements from a hardware product brief, covering behaviour, timing and power budgets, fault handling, update and boot, manufacturing test hooks and traceable IDs.
Not: product discovery, strategy, roadmaps or metrics (product-management domain).