PRD Example — Team Collaboration Feature Set
Example document for Product Requirements Document. Use this as a reference when creating your own.
For Informational Purposes
This document template is provided for informational purposes. Customize it for your specific needs.
Document: Product Requirements Document
Example Document
Last updated 6/4/2026
Product Requirements Document: Team Collaboration Feature Set
Author: Priya Venkatesan Status: Approved Date: 5 June 2026 Target release: v4.0 Stakeholders: Product (Priya), Design (Theo Lind), Engineering (Sam Okoye), Customer Success (Mara Diaz)
1. Overview and problem
Northwind is a project-tracking app used mostly by individuals managing their own work. As accounts have grown, teams have started sharing a single login or copying details between apps to coordinate, because Northwind has no real way for several people to work in the same project. This feature set adds the collaboration basics — shared projects, assignment, comments, and notifications — so a team can plan and run work together inside Northwind instead of around it.
2. Goals and success metrics
Goals
- Let teams work together in a shared project without leaving Northwind.
- Reduce the coordination that today happens in chat tools and spreadsheets.
Success metrics
| Metric | Baseline today | Target | How it's measured |
|---|---|---|---|
| Multi-member projects | 0% of active projects | 35% within 90 days | Project membership data |
| Weekly active collaborators | n/a | 3+ members in 25% of team projects | Activity events |
| Seat expansion in team accounts | 1.0 seats / account | 2.4 seats / account | Billing data |
3. Target users and personas
- Lena, the team lead — runs a 6-person marketing team. She wants to see who is doing what and unblock people without chasing them in chat. Today she keeps a private spreadsheet because Northwind cannot show her the whole team's work.
- Raj, the team member — an individual contributor who wants to know what is assigned to him and discuss a task without switching to email. Today he gets task details forwarded to him second-hand.
4. User stories and requirements
User stories
- As a team lead, I want to invite teammates to a project so that we can plan and track work in one place.
- As a team lead, I want to assign a task to a teammate so that ownership is clear.
- As a team member, I want to comment on a task so that the discussion lives with the work.
- As a team member, I want to be notified when something is assigned to me or mentions me so that nothing slips.
Functional requirements
- (Must) A project owner can invite people by email to a shared project and assign them a role of editor or viewer.
- (Must) Any editor can assign a task to a member of the project; the assignee is shown on the task and in list views.
- (Must) Members can post threaded comments on a task, and can @mention another project member.
- (Must) A member receives an in-app and email notification when a task is assigned to them or they are @mentioned.
- (Should) Members can see a per-project activity feed of assignments and comments.
- (Could) Members can react to a comment with a small set of emoji.
5. Scope and non-goals
In scope for this release
- Shared projects with editor and viewer roles, task assignment, threaded comments, @mentions, and the resulting notifications.
Non-goals
- Real-time co-editing of the same task field by two people at once — out of scope for v4.0.
- Cross-organisation guest access; collaboration is limited to members of the same account for now.
- Granular per-task permissions beyond the project-level editor/viewer roles.
6. UX considerations
The shared project should feel like the existing single-user project with people added, not a separate mode. Assignment and comments must be reachable from the task without a full-page change. Key states to design for: an empty project with only the owner, a task with no assignee, a long comment thread, and a member who has lost access. Notifications must be glanceable and must not overwhelm — assignment and @mention only in this release.
7. Dependencies and risks
| Item | Type | Impact | How we'll handle it |
|---|---|---|---|
| Account/identity service must support multi-member roles | Dependency | Blocks invites and roles | Confirm capability with platform team before build |
| Email notification service | Dependency | Blocks the notification requirement | Reuse the existing transactional email pipeline |
| Notification volume could feel like spam | Risk | Hurts adoption | Limit to assignment and @mention; add per-user controls in a fast follow |
| Teams sharing one login may resist paying per seat | Risk | Limits seat-expansion metric | Pair launch with a clear migration prompt and CS outreach |
8. Release criteria
- All Must requirements (1–4) implemented and verified against their feature specs.
- Membership, assignment, and notification events are instrumented and reporting to the metrics dashboard.
- No open critical or high defects in invite, assignment, or notification flows.
- Sign-off from Product, Engineering, and Customer Success.
Open questions
- Should viewers be able to comment, or is commenting editor-only? Owner: Priya. To resolve before build.
- What is the upper limit on members per project for this release? Owner: Sam. To confirm with the platform team.
Notes
An illustrative worked PRD that frames a product area across several features, with named personas, prioritised requirements, measurable success metrics, and explicit non-goals; the product, people, and figures are fictional.
About this Example
Part of the Product Requirements Document document collection
Document Type
Product Requirements Document
A comprehensive document defining what a product should do, its features, user stories, and acceptance criteria.