Navigate Ways of Working
Artefact Requirements
What's required at each tier, who owns each artefact, and what good looks like — including the artefact matrix, ticket structure, PRD structure, and one-pager structure.
Artefact Requirements
What’s required at each tier, who owns it, and what it should contain. Proportionate rigour — not every item needs a PRD.
Artefact Matrix
| Artefact | Owner | Tier 1 | Tier 2 | Tier 3 | What Good Looks Like |
|---|---|---|---|---|---|
| Discovery | |||||
| User research | PM | conversation | ✓ several users | ✓ structured | Documented findings, not just impressions. Different contexts and perspectives. |
| Competitor scan | PM | — | ✓ | ✓ detailed | Who, what they do, strengths/weaknesses, positioning. Not just a list of names. |
| Market analysis | PM | — | — | ✓ | Market size, trends, white space, commercial viability. |
| Tech feasibility | Lead Dev | at refinement | conversation | ✓ spike + written | Approach, risks, rough effort. Tier 3: time-boxed spike proving key risk. |
| Business/commercial case | PM + stakeholders | — | — | if revenue impact | Investment required, payback period, success commercially. |
| Specification | |||||
| Ticket | PM | ✓ | ✓ from PRD | ✓ from PRD | Problem, solution direction, success criteria, constraints. 2 paragraphs for Tier 1. |
| PRD | PM | — | ✓ | ✓ detailed | Problem, goals, user stories, scope, solution, risks, phasing. 15-min read. |
| One-pager | PM | — | — | ✓ | Executive audience. Problem, opportunity, assumptions, decisions needed, investment, metrics. |
| Acceptance criteria | PM + QA | ✓ | ✓ | ✓ | Happy path, edge cases, error scenarios. Produced at refinement. |
| Framing document | PM + HoP | — | — | ✓ | Hypothesis, discovery questions, investment boundary for discovery phase. |
| Design | |||||
| Wireframes | PM or Designer | if UI work | ✓ | ✓ hi-fi | Layout, hierarchy, interaction. Primary build handoff artefact. |
| Interactive prototype | PM or Designer | — | for validation | for validation | User testing of complex flows. Not a build artefact — engineers build from wireframes. |
| Technical | |||||
| ADRs | Dev / Staff Eng | if significant | if significant | ✓ | Context, decision, consequences, alternatives. In repo. |
| Increment review notes | PM | — | — | ✓ | Progress vs goals, metric validation, scope adjustments, go/no-go for next increment. |
Ticket — What Goes In
| Field | Tier 1 | Tier 2/3 |
|---|---|---|
| Problem | 2–3 sentences | Reference PRD section |
| Solution direction | 2–3 sentences | Reference PRD section |
| Success criteria | 1–3 outcomes | Reference PRD metrics |
| Constraints | Timeline, technical, deps | Reference PRD scope |
| Acceptance criteria | From refinement | From refinement |
| Design | Reference/sketch if needed | Link to wireframes |
Tier 1 test: If the ticket takes more than 15 minutes to write, the work is probably Tier 2.
PRD — What Goes In
| Section | Purpose |
|---|---|
| Problem statement | User/business problem + evidence |
| Goals & metrics | Measurable outcomes, time-bound |
| User stories / JTBD | Who, what, workflow |
| Scope | In / out / deferred |
| Solution overview | Shape, not implementation |
| Design | Wireframes / mockups |
| Dependencies & risks | What could go wrong |
| Phasing | Sprint-level increments |
One-Pager — What Goes In
| Section | Purpose |
|---|---|
| Title + one sentence | What is this, plain language |
| Problem | Evidence-backed user/market need |
| Opportunity | Size of prize, cost of inaction |
| Proposed solution | Non-technical description |
| Key assumptions | What must be true to succeed |
| Key decisions | What leadership must decide |
| Risks + mitigation | What could go wrong |
| Investment | Sprints, people, cost, timeline |
| Success metrics | How we know it worked |
Different from the PRD. Written for leadership, not the squad. Answers “should we commit?” not “how do we build it?”
Prototypes are for validation, not build. Interactive prototypes are powerful for user testing but counterproductive as build specs. Engineers build from wireframes and the design system. Giving a dev a polished prototype risks them spending time recreating it pixel-for-pixel instead of building the right solution.
AI accelerates all of this. AI drafts tickets, PRDs, one-pagers, acceptance criteria, wireframes, and competitor analysis. Humans review, refine, and own the output. AI raises the floor; humans add judgment.
For the full tier definitions, see the Product Process guide.