Process Stage Playbooks and Artifacts

Lifecycle at a Glance

Detailed Playbooks by Stage

Capture and Triage

This initial stage is designed to ensure that every idea, market signal, or user request has a single, lightweight entry point. The process begins by logging the signal into an Insight / Idea Note within Productboard. As a Product Manager, your goal is frictionless logging; focus on capturing the core of the user's problem, ideally framed as a "Job To Be Done" (JTBD).

During the weekly Product Ops sweep, a note is considered complete and ready for review when it contains a concise problem statement, is tagged to a strategic objective, and has initial "gut-feel" scores for metrics like Reach and MRR₁₂. This quality check also ensures the note has been reviewed within seven days and that any duplicates have been merged or linked.

Minimum Info:

• A user quote, review, pain point, or idea description

• Related Company and/or user recorded

Quality Gate:

• The note has been reviewed within 7 days

• Tags added and features added (New Idea) or linked

• Note marked as “Processed”

Discover

The purpose of discovery is to validate that a problem is real, urgent, and valuable enough to solve. This begins by formalizing an idea into a Feature or Component artifact in Productboard, where a clear problem statement, link to an OKR, and initial sizing estimates are recorded.

From there, the core work of this stage is creating the Discovery Brief. A successful brief begins with a "North Star" vision—a brief, aspirational statement that focuses on the long-term purpose and customer value. This is followed by the most critical section: the problem statement, which must clearly define the pain for the customer and the impact on the business, supported by evidence like user quotes and performance metrics.

The v1 Discovery Brief must prove the problem is real and compelling enough to secure stakeholder buy-in with a presentation at the Internal Product Forum (IPF). To pass this gate and move forward, you must demonstrate a deep understanding of the user and the problem, based on insights from at least five user interviews and preliminary research. Success at the IPF validates the opportunity and is also when you begin communicating externally by creating a public-facing Productboard Portal Card, setting its status to "Under Consideration"

Quality Gate:

• All sections of the Discovery Brief v1 template are complete

  • A clear Problem Statement is documented

  • Existing solutions are discovered

• Rapid Market Scan and Research

• The feature is linked to a strategic Objective/OKR

• Initial MRR₁₂, Risk Reduction, Reach, and Time Criticality are recorded

• Confidence score = 1 (representing a gut-feel assessment) or 2 (came in directly from multiple customers or stakeholders)

• A T-Shirt Size & Effort estimate is provided

• Internal Product Forum Review and Sign-off

Define

After securing buy-in at the IPF, the Define stage is where you analyze the validated problem, size the prize, and select the winning approach. This is captured in a more detailed Discovery Brief v2. Here, a key practice is to make your bet explicit by framing it as an opportunity hypothesis: "By providing [an automated tool], we can [reduce manual effort], which will unlock [cost savings and scalability]".

It’s crucial to surface landmines early by identifying the top adoption, technical, or commercial risks and proposing one-line mitigations. The artifact must be robust, containing market sizing (TAM/SAM/SOM), a mid-case ROI projection, and the leading KPIs that will define success. Additionally, it should feature lo-fidelity wireframes and user flows, that demonstrate proposed solutions, so that a winning approach can be better identified.

Quality Gate:

• All sections of the Discovery Brief v2 template are complete

  • Multiple hypotheses and associated wireframes for potential solutions

  • Market sizing (TAM/SAM/SOM) and a mid-case ROI projection

  • Leading success KPIs to measure outcomes

  • A clear articulation of risks and defined guard-rails

• The portal card has been launched with an "Under Consideration" status

• Interview notes are linked (from Dovetail or Confluence)

• PM, UX, and Eng/Tech Lead have provided e-signatures in Confluence (add @Eng Name and get a 👍 or a comment on the document)

• Confidence score is 3

Develop

This stage is where the chosen approach is translated into a build-ready blueprint. It involves two key artifacts. First, the Design Brief helps designers convert the business opportunity into a validated interaction model through user flows, wireframes, and prototypes. Crucially, it is at this point that a formal Timeline is applied to the project during the scoring update. This is a significant step, as this update is often reflected on public-facing roadmaps, signaling a formal commitment to the schedule. The design process culminates in testing the prototype with users to ensure high task success and securing approval from engineering leads.

Quality Gate

• All sections of the Design Brief template are completed

  • User flows and a journey map that reframe the problem

  • Established design principles and constraints

  • Wireframes and low-fidelity prototypes (as needed)

  • Success criteria defined as user test tasks

• Scores for Confidence, Effort, and the project Timeline have been updated.

After successful user testing, the design iterations are complete and the UX is included in the Product Requirements Document (PRD), which serves as the final blueprint for engineering. A strong PRD begins with the primary objective, defines core system concepts, and breaks down requirements into thematic user stories. This will become an Epic in Jira and include a story map for MVP and future phases (slices).

Once the PRD is complete, the feature in Productboard is re-estimated, its timeline is updated, and the public-facing Portal Card is changed to "Planned".

Quality Gate

• All sections of Product Requirements Documentation are complete

  • Goals and outcome KPIs

  • Scope boundaries, including what is explicitly out-of-scope ⁷²

  • Detailed Acceptance Criteria, written in Gherkin format ("Given/When/Then")

  • A list of telemetry events to be tracked

  • The roll-out and feature flag strategy

• Effort and Timeline scores have been updated

• The portal card has been updated to "Planned"

Deliver

The Deliver stage focuses on slicing work for a continuous engineering flow while simultaneously preparing for a successful market launch. Engineering Epics and Stories are structured to be "Definition of Ready," meaning each story expresses user value, adheres to the INVEST model, and is linked to its corresponding PRD and Figma designs.

Concurrently, the PM prepares the Release Package, which bundles all go-to-market materials. You should treat launch readiness as a formal requirement, creating user stories for your own tasks like writing customer-facing documentation or designing a migration playbook. The final quality gate before release is a thorough check to ensure all acceptance criteria have passed QA, telemetry is firing correctly, and help documentation is live. Upon release, the Portal Card status is updated to "Beta".

Quality Gate

• All Acceptance Criteria pass QA

• A release version has been assigned

• Release Package

  • User-facing descriptions and screenshots are complete

  • A "How to turn on" guide is available

  • Knowledge Base article is written (or updated)

  • In-Product Communication Created (Pendo Guide)

  • ROI 1-Pager for Sales & Account Management

• Known limitations are documented

• Analytics and telemetry are confirmed to be firing correctly

• Help-Center and Docs pages are live

• The portal card has been updated to "Beta"

• A final demo sign-off has been provided by the PM

Measure & Learn

This final stage is about closing the loop to determine the project's ultimate success and decide what to do next. Using an Outcome Review artifact, you will analyze performance at 30 and 90 days post-launch. This review must directly reference the success metrics and objectives you defined at the start of the project. The goal is to use performance data, technical health metrics, and qualitative feedback to make a clear, data-informed decision: iterate, scale, or sunset the feature. This decision is logged, and to finalize the process, the Portal Card is updated one last time to "Launched".

Purpose: To analyze performance data and user feedback to make a clear decision on the future of the feature: iterate, scale, or sunset.

• Artifact: 14-30-90-Day Outcome Review (Dashboard + Narrative in Pendo/Confluence)

• Status: Released

• Description: Outcome reviews are conducted at T+30 and T+90 days post-launch. The artifact is a 1-pager containing a dashboard screenshot and a narrative explaining the results.

• Quality Gate:

  • The portal card has been updated to "Launched"

    • This D14 when the feature moves from First Adopters to General Cloud

  • 14-30-90-Day Outcome Review

    • KPI deltas versus initial targets are recorded in Confluence

    • Qualitative feedback and NPS scores have been collected and analyzed

    • Tech-ops health (errors, latency) has been reviewed

    • An iterate/scale/sunset decision is logged (D30+)

  • A fast-follow backlog has been created

  • Retrospective actions are assigned and documented

Quick Links

• Template directory → /Processes & Continuous Improvement/Templates

• Figma project → CXT Design System

• Confluence space shortcuts → Discovery, Strategy, UX Specs, PRDs, Release Docs, Outcomes

Remember : If you can’t see an artifact in its space, the work isn’t ready.