Product (engineering)
Requirements written for an engineering team to build: PRDs, user stories, acceptance criteria, specs.
Download all 47
- 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.
- Document an existing feature's behaviour
Writes a behaviour spec of an existing feature from code, tickets and observations before a rewrite or migration, marking each rule as confirmed, inferred or unknown, with quirks users rely on.
- Extract requirements from meeting notes
Extracts draft requirements from stakeholder meeting notes or transcripts, tying each to who said it, separating decisions from wishes, and listing conflicts and open questions.
- 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.
- Review a spec for gaps before kickoff
Reviews a PRD or feature spec before engineering kickoff for ambiguous wording, untestable requirements, missing states and roles, contradictions and unstated dependencies, with a fix for each.
- Turn an app idea into a spec developers can quote
Interviews a non-technical founder about an app idea, then writes a spec developers or agencies can estimate from, with users, core flows, an MVP cut, integrations, unknowns and open questions.
- Specify an approval workflow
Specifies a multi-step approval process in a product, with approval rules and thresholds, approver selection, delegation and absence, escalation, rejection and resubmission, and edits after approval.
- Specify a bulk import feature
Specifies a user-facing CSV or spreadsheet import before build, with template, column mapping, duplicate policy, validation messages, partial success, size limits and undo.
- Specify business calculation rules
Writes the calculation rules for a feature such as fees, commissions, discounts or scores as ordered formulas with rounding and currency rules and worked examples QA can test against.
- Specify a change for existing users
Specifies how a behaviour or data model change reaches users and records that already exist, with defaults, backfill, grandfathering, opt-outs, communication and what happens to work in progress.
- Specify comments and mentions
Specifies comments on items, with threading, mentions and who can be mentioned, edit and delete rules, notifications, access on private items, moderation and what happens on item deletion.
- Specify concurrent editing rules
Specifies what happens when two people or a person and an automation change the same record at once, with conflict detection, lock or merge rules per field, user messages and edge cases.
- Specify content reporting and moderation tools
Specifies how users report content or accounts and how moderators review them, with reasons, queues and priority, enforcement actions, notices, appeals, repeat-offender rules and audit.
- Specify delete and restore behaviour
Specifies what delete means for a type of record, covering archive versus soft and hard delete, trash and restore windows, cascades to related items, shared copies and permanent erasure.
- Specify form fields and validation
Specifies a form field by field with type, required rules, formats, limits, defaults, dependencies between fields, error message wording and when validation runs, for design, build and QA.
- Specify direct messaging between users
Specifies private messaging between users of a product, covering who can message whom, conversation model, attachments, read receipts, blocking and reporting, notifications, retention and deletion.
- 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.
- Specify order cancellation, returns and refunds
Specifies order cancellation, returns and refunds for engineers, with time windows, partial refunds and fees, discount allocation, payment reversal, restocking, notifications and records.
- Specify plan limits and entitlements
Specifies what each pricing plan unlocks and limits, how usage is counted, what happens near and over a limit, and how upgrades, downgrades and trials change access to existing data.
- Specify promo and discount code rules
Specifies promo and discount codes for a store or subscription, with code types, eligibility, stacking order, usage limits, expiry, currency and tax handling, refunds and abuse prevention.
- Specify a record's status lifecycle
Specifies the statuses of a business record such as an order, claim or request, with allowed transitions, who or what triggers each, side effects, what each role sees and how mistakes are reversed.
- Specify recurring schedule rules
Specifies recurring events, bookings or reminders with repeat patterns, time zone ownership, daylight saving, month-end dates, edits to one or all future occurrences and end conditions.
- Specify user reviews and ratings
Specifies a reviews and star ratings feature, covering who may review, content and editing rules, aggregation and display, sorting, business replies, fake-review signals, moderation and disclosure.
- Specify roles and permissions for a feature
Specifies who can see and do what in a feature as a role-by-action matrix, with ownership rules, inherited access, what denied users see and how access changes mid-session.
- Specify in-product search behaviour
Specifies in-product search for engineers, covering what is indexed, matching and typo rules, ranking, permission filtering, freshness, empty results and how quality is checked.
- Specify a share link feature
Specifies shareable links to items, with who can create them, access levels, sign-in requirements, expiry and passwords, revocation, link previews, search engine exposure and audit of access.
- Specify sign-in and session rules
Specifies sign-in and session rules for a product, covering sign-in methods, multi-factor, session length and idle timeout, lockout, remembered devices, account recovery and sign-out everywhere.
- Specify subscription billing rules
Specifies subscription billing behaviour, covering renewals, proration on upgrades and downgrades, failed payment retries, grace periods, cancellation timing, refunds, taxes and notices.
- Specify support and admin tools for a feature
Specifies the internal admin and support tools a new feature needs to be operated, such as lookups, safe overrides, impersonation rules, bulk fixes and audit, so support never needs database access.
- Specify a team invitation flow
Specifies how people join a team or workspace, covering who may invite, seats and billing, invite expiry, existing accounts, domain rules, resends, revocation and removing members.
- Specify a third-party integration
Specifies a product integration with an outside service, covering connect and disconnect, access requested, field mapping, sync direction and timing, conflicts and what users see when it breaks.
- 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.
- Write a requirement change request
Writes a change request for a requirement that changes mid-build, with what changes and why, impact on finished work, tests, estimate and date, the options and the decision needed.
- Write a requirements traceability matrix
Builds a traceability matrix linking each requirement to its source, design, tests and status, flagging requirements without tests and tests without requirements, for audits or regulated releases.
- Write a software requirements specification
Writes a software requirements specification along ISO/IEC/IEEE 29148 lines, with scope, context, numbered testable functional and non-functional requirements, interfaces and verification.
- Write a feature spec for a coding agent
Writes a spec-driven development package for a coding agent, with requirements in EARS form, a design grounded in the existing codebase, and an ordered task list with tests and checkpoints.
- Write use case specifications
Writes fully dressed use cases for a system, with actors, goals, preconditions, main success scenario, alternate and exception flows, postconditions and business rules, numbered for traceability.
- Write requirements for a website build
Writes requirements for a website project to brief agencies or freelancers, with goals, sitemap, content and CMS needs, integrations, hosting, accessibility, SEO, ownership and acceptance.
Not: product discovery, strategy, roadmaps or metrics (product-management domain).