Product Artifacts

Product Artifacts are the building blocks of your product documentation in Product Graph. They provide a structured way to capture requirements, decisions, and context in a format that’s both human-readable and AI-agent ready.

​

What are Product Artifacts?

Product Artifacts are structured documents that capture the essential elements of your product, from high-level strategy to detailed acceptance criteria. Unlike traditional documents, artifacts are designed to be:

• Structured: Consistent format that makes information easy to find and parse
• Connected: Clear relationships provide context and let you drill deeper
• AI-Ready: AI agents can read and use your requirements directly
• Versioned: Track changes and maintain history of your product decisions

​

The Artifact Hierarchy

Product Graph follows a clear hierarchy that flows from strategy to implementation: Product → Capability → Feature → Requirement → Acceptance Criterion This hierarchy ensures traceability from high-level product goals down to testable conditions, making it easy for teams and AI agents to understand how each piece connects to the whole.

​

Core Artifacts

These artifacts form the primary hierarchy of your product model. They’re long-lived and represent the stable structure of what you’re building.

​

Product

The top-level artifact that defines the boundaries, vision, and scope of what you’re building. A Product represents your entire offering and serves as the root of the product specification hierarchy. It contains all the Capabilities, User Types, and Core Entities for that product. The Product document captures the strategic overview: the “why” and “what” at the highest level. It includes an overview, vision, guiding principles, problem statement, and value proposition. Products serve as the foundational anchor for all product specifications:

• Define the overall vision, purpose, and value proposition
• Establish boundaries for what is and isn’t part of the product
• Provide strategic context that all child artifacts inherit
• Serve as the entry point for stakeholders to understand the offering

​

Capability

A high-level ability that the product provides, expressed in problem or outcome terms rather than implementation details. Capabilities represent the stable, enduring pillars of what the product can do, focusing on what ability users gain rather than which specific features exist. Capabilities remain relatively constant across many releases while the Features beneath them evolve. Think of Capabilities as answering “What can users accomplish?” while Features answer “What can users do specifically?” Capabilities provide the strategic structure for organizing product functionality:

• Frame product abilities in terms of user outcomes and problems solved
• Create stable organizational pillars that persist across releases
• Group related features under a common theme or goal
• Communicate product value at a level executives and stakeholders understand

Parent: Product (one Product has many Capabilities) Example: “Inbox Organization & Categorization”: the ability to automatically organize and categorize incoming emails

​

Feature

A concrete, user-facing behavior or functionality that realizes part of a Capability. Features represent specific, releasable units of work that users can interact with and that deliver tangible value. Unlike Capabilities, which describe high-level abilities in outcome terms, Features describe the specific behaviors and interactions that make those abilities possible. Features serve as the primary unit of product development, bridging the gap between strategic Capabilities and detailed Requirements:

• Break down abstract Capabilities into concrete, deliverable functionality
• Define clear scope for development teams
• Describe what the product does from a user’s perspective
• Enable release planning and roadmap management
• Track progress within Capabilities as they deepen

When writing Feature documents, focus on user-facing behavior and experience, not implementation details. Parent: Capability (one Capability has many Features) Example: “Thread Summaries Panel”: a specific feature that shows AI-generated summaries of email threads

​

Capability vs Feature

​

Requirement

A formal statement of a single, atomic system behavior or constraint that must be satisfied. Requirements bridge the gap between user-facing Features and testable Acceptance Criteria by specifying exactly what the system must do, or how it must perform, without describing implementation details. Each Requirement describes one behavior and is validated by multiple Acceptance Criteria. Requirements translate Features into precise, testable specifications:

• Define exactly what the system must do to deliver a Feature
• Create unambiguous specifications that development can implement
• Establish clear boundaries between different behaviors
• Link to Projects for execution tracking

Apply atomicity: one requirement equals one behavior. Avoid “and” across distinct behaviors.

​

Requirement Types

Parent: Feature (one Feature has many Requirements) Example: “The system must authenticate with Gmail using Google OAuth with read-only and labeling scopes.”

​

Acceptance Criterion

A single, testable condition that proves a Requirement is satisfied. Written in Given-When-Then format, each AC defines one specific, observable, and measurable check with a clear pass/fail outcome. ACs are the most granular level of the product specification hierarchy and serve as the bridge between Requirements and executable test cases. Acceptance Criteria transform abstract Requirements into verifiable conditions:

• Define exactly what “done” means for a Requirement
• Provide unambiguous test cases for QA and development
• Cover happy paths, edge cases, error states, and non-functional constraints
• Create a contract between product, development, and QA teams
• Eliminate subjective interpretation of Requirements

Writing testable criteria: Parent: Requirement (one Requirement has many Acceptance Criteria) Example: “Given a message classified as Priority, When the inbox list renders, Then the message row displays a ‘Priority’ label.”

​

Supporting Artifacts

These artifacts provide essential context and structure but sit outside the core hierarchy.

​

User Type

A long-lived archetype representing a category of people who use the product. User Types capture who the users are, their goals, behaviors, workflows, constraints, and pain points, without being tied to demographic details. They serve as personas that inform feature design, requirement writing, and acceptance criteria by providing a shared understanding of the humans the product serves. A User Type document includes:

• Who they are: The role and context of this user type (situation, not demographics)
• Goals and motivations: What they’re trying to accomplish and what drives their decisions
• Behaviors and workflows: How they typically interact with the product
• Constraints and limitations: Barriers they face (time, technical skill, device, accessibility needs)
• Pain points: Frustrations or problems the product should address

User Types differ from Core Entities: User Types describe who uses the system (people and their needs), while Core Entities describe what the system manages (domain concepts and objects). User Types can be attached to Features to show which users benefit, or to Requirements to clarify who the requirement serves. Examples: “Power Emailer” (high volume, values efficiency), “Occasional User” (infrequent visits, needs intuitive UI), “System Administrator” (manages settings, needs audit trails), “Mobile-first User” (needs touch-friendly UI), “Accessibility-focused User” (relies on screen reader or keyboard navigation)

​

Core Entity

A fundamental domain concept (the “nouns”) that a product manipulates, displays, stores, or reasons about. These essential conceptual objects form the shared vocabulary and structural backbone of the product’s domain model. Core Entities establish clear definitions that the entire team and system can reference consistently. Core Entities provide:

• A shared vocabulary for discussing the product domain across teams (product, engineering, design)
• Clear conceptual boundaries that inform how features are designed and built
• Domain documentation that remains stable even as features evolve
• A foundation for understanding relationships between concepts in the system
• Reference definitions that Acceptance Criteria and Requirements can point to

Core Entities are long-lived and stable. They represent enduring concepts in the domain, not implementation details. Focus on conceptual clarity over technical implementation: describe what something is, not how it is stored. Core Entities differ from User Types: entities represent things in the system; user types represent people who use the system. Examples: Email app: “Thread,” “Message,” “Label,” “Contact,” “Draft.” E-commerce: “Order,” “Cart,” “Product,” “Customer,” “Shipment.”

​

Project

A temporary execution container that tracks a bounded scope of work to be delivered. Unlike the core artifacts, Projects are time-bound initiatives that link to existing artifacts for tracking, prioritization, and delivery management. Projects do not own artifacts; they reference them to define what is in scope for a particular initiative. Projects bridge the gap between product specification and execution:

• Scope which artifacts are included in a specific release, sprint, or initiative
• Track progress against a defined set of deliverables
• Define goals, timelines, and success criteria for bounded work
• Coordinate across multiple Capabilities, Features, and Requirements
• Archive completed initiatives while preserving the underlying artifacts

Projects reference, not own: deleting a Project removes links but leaves all artifacts intact. Linked artifacts can be edited independently; the Project provides a lens for viewing and tracking scope. Example: “Q1 Mobile Launch”: a project tracking all the work needed to ship the mobile app by end of quarter