Release Package: Process & Artifacts

Audience: Product Managers (PMs), UX Designers, Engineering Leads, Product Marketing, Client Success, Support, and QA

Objective: Provide a single, unambiguous playbook for assembling, approving, and communicating every production release so that customers experience a polished, self‑service upgrade while internal teams can support, enable, and sell with confidence.

Why We Have a Release Package

A release that ships without clear enablement material is just half‑done software. The Release Package bundles all go‑to‑market and support assets so that:

Customers know what changed and how to turn it on.
Sales/AM teams have the collateral to sell or upsell.
Support can answer questions without scrambling.
PMs close the loop on the Deliver stage quality gate defined in our PDLC.

The package is a formal artifact—failure to meet its checklist means the feature is not release‑ready.

Where It Fits in the PDLC

PDLC Stage	Trigger	Outcome
Develop → Deliver	PRD approved & Engineering stories ready	PM begins drafting the Release Package alongside engineering & UX
Deliver (In Progress)	All Acceptance Criteria pass QA	Final content reviews; internal preview sent
Release Day	Version tagged & deployed to First Adopters	Public communications published, portal card set to Beta
T+14/30/90 Days	Outcome Reviews	Metrics & feedback inform next iteration

Timing Guidance

Start drafting ≥ 2 weeks before target go‑live.

Lock copy & screenshots 3 days before release freeze.

Send internal preview (Sales, Support) 24 hrs before customer comms.

Required Artifacts (Definition of Done)

Each artifact lives in its designated "single source of truth". Use the provided templates under /Processes & Continuous Improvement/Templates.

Artifact	Owner (RACI)	Location
Release Notes (what’s new, why it matters, limitations)	PM (R), Eng. Lead (C), Product Marketing (C), Support (I)	Confluence → `/Release Notes/YYYY-MM-DD`
Knowledge‑Base Article (step‑by‑step usage & FAQs)	PM (R), Product Marketing (C), Support (I)	Confluence → `/Products and Initiatives/Product_Name/Feature_Name/Release Package/Knowledge Base Article`
“How to Turn On” Guide – (enablement steps or feature flag path)	PM (R), Eng. Lead (C), Product Marketing (C), Support (I)	Confluence → `/Products and Initiatives/Product_Name/Feature_Name/Release Package/Sign Up Instructions`
In‑Product Guide / Tooltip (Pendo walkthrough)	PM (R), UX (C), Product Marketing (C)	Pendo
Screenshots & Short Loom Demo or Interactive Prototype	UX (R), PM (A)	Confluence → `/Design & UX/Prototype Showcase`
ROI One‑Pager for Sales & AM	PM (A), Product Marketing (R)	Confluence → `/Products and Initiatives/Product_Name/Feature_Name/Release Package/ROI One Pager`
Known Limitations List	PM (R), Eng. Lead (A)	Confluence → `/Products and Initiatives/Product_Name/Feature_Name` → Known Limitations
Portal Card Status Update (Beta → Launched)	PM (R)	Productboard Portal

Quality Gate: All items above are completed, reviewed, and linked in Productboard and Confluence before "Ready for Release" can be set.

Scaling Guidelines — Which Artifacts Are Required?

Not every change warrants the full Release Package. Use the impact‑effort tiering below to determine which artifacts are mandatory.

Tier	Typical Example	Must‑Have Artifacts	Optional / Conditional
Patch (≤ 4 dev hrs, no UX change, hotfix)	Null‑pointer bug in background job	Release Notes (single‑line entry in the next monthly roll‑up)• Known Limitations (update if defect removed)• Internal Slack heads‑up	KB article (only if end‑user workflow changes)• Portal card update (if customer‑visible)
Minor (≤ 1 sprint story, small UI/QoL tweak, toggle default off)	Add sortable column to report	Release Notes (stand‑alone)• KB Article update• UI Screenshots (if visual change)• Internal preview to Support	Pendo guide (if discoverability needed)• ROI one‑pager (if monetizable)
Major (multi‑story feature, new workflow, or revenue driver)	New Dispatch Board module	Full Release Package (all artifacts listed in §3)	–

Rule of Thumb

If customers will see or interact with the change → at least a Minor tier.
If the change requires config, migration, or training → Minor or Major tier.
If it simply fixes something that was broken without altering user behavior → Patch tier.
When in doubt, default up a tier; never ship undocumented breaking changes.

Exception Handling: A PM may downgrade a planned Major to Minor only with sign‑off from the Head of Product.

Responsibilities (RACI‑Lite)

Role	Key Responsibilities
Product Manager (A)	Owns the package; coordinates timelines; drafts Release Notes, KB, How‑to guide; updates portal card; leads internal preview & Go/No‑Go.
Engineering Lead (C/R)	Confirms technical accuracy, limitations, rollout / migration scripts; tags release version; ensures telemetry firing.
UX Designer (C)	Provides final UI screenshots, validates in‑product copy, builds Pendo guide.
Product Marketing (C)	Edits messaging for consistency, updates website / newsletter if applicable.
Client Success & Support (I)	Attend preview call; prepare macro responses; surface training needs.
QA (C)	Verifies that Success Criteria & telemetry events in PRD are met; signs off on "All ACs Pass" checklist.
Head of Product (I)	Receives Go/No‑Go summary; intervenes only on blocker/escalation.

Communication Plan

Day	Audience	Channel	Message
T‑5	PM, Eng Lead, UX	Confluence comment	"Draft Release Package ready for review"
T‑3	Sales, AM, Support	Loom + Confluence	Internal preview, ROI sheet, KB link
T‑1	Leadership	Email digest	High‑level release summary & Go/No‑Go checklist
T 0 (09:00 CT)	First Adopters	In‑app banner (Pendo) + Email	"New feature available—here’s how to turn it on"
T +7	All customers (if GA)	Release Notes page + newsletter	Public announcement
T +14/30/90	Internal stakeholders	Confluence Outcome Review	KPI deltas vs targets; iterate/scale/sunset decision

All times are in America/Chicago (CT) unless otherwise stated.

Tier‑Based Checklists

Copy the appropriate checklist (Patch, Minor, or Major) into the JIRA Epic’s description. Larger tiers inherit everything from the smaller ones.

Patch Checklist (≤ 4 dev hrs, no UX change)

Fix merged and release branch/tag updated
Ticket closed with Fix Version set
Single‑line entry added to Release Notes
Known Limitations updated or cleared
Internal Google Chat heads‑up posted to #Operations

Minor Checklist (≤ 40 hour story, UX changes)

All Patch checklist items
KB article created/updated with new screenshots
UI screenshots stored in Figma → Release Assets
Loom preview recorded and shared with Sales & Support
Portal card status updated (e.g., Beta)

Major Checklist (Full Release Package)

All Minor checklist items
ROI One‑Pager completed and uploaded to /Sales Enablement
Pendo in‑app guide scheduled for launch
Outcome Review doc created in Confluence
Go/No‑Go meeting held; decision logged in Confluence

When every bullet in the relevant tier is addressed, move the Epic to Ready for Prod and proceed with the Communication Plan.

7. Templates & Resources Templates & Resources Templates & Resources

Release Notes Template – /Templates/Release Notes
Knowledge‑Base Article Template – /Templates/KB Article
ROI One‑Pager Template – /Templates/Sales Enablement
In‑Product Guide Checklist – /Templates/Pendo Guide
Outcome Review Template – /Templates/Outcome Review

8. FAQ & Best Practices

“My feature is behind a flag—do I still need a KB article?”
Yes. Even private‑beta customers need documentation. Mark it Internal‑Beta.
“What if engineering finds a last‑minute blocker?”
PM updates Release Notes with "Delayed" status, sends a quick Slack to Sales/Support, and shifts comms by the agreed buffer.
“Who owns translations?”
PM raises a JIRA ticket for Localization once English copy is final; Localization team targets T‑2 days.

Remember

“If it isn’t documented in the Release Package, it isn’t done.”

Following this process guarantees consistent, high‑quality launches that delight users and equip every team to succeed.