---
title: "Workbench: Follow the Product"
description: "Follow Workbench through the complete PM lifecycle . from discovery to pivot decision."
generated: true
source: scripts/generate-showcase.py
tags:
  - Showcase
  - Workbench
---

> Series B, ~200 employees, ~500 enterprise customers. Building **Blueprints** . document templates with approval gates.
>
> **Prompt style:** Enterprise . full stakeholder lists, quantified baselines, explicit metrics.

## Phase: Foundation

### Persona (Marketing Brief)

*Workbench Blueprints marketing persona for enterprise champion sales playbook and pilot-to-expansion messaging*

:::note[Prompt]
```text
/persona marketing brief

Sandra V. to PM Skills agent:

> I need a brief marketing persona for the Workbench Blueprints enterprise
> sales playbook. This should represent the internal champion who drives
> the purchasing conversation.
>
> Context:
> - 3 pilot customers have requested formal proposals after Blueprint trials
> - Common stall point: champion can't answer IT security and legal questions
>   without vendor-supplied materials
> - Need: concise persona for messaging alignment, objection prep, and
>   pilot-to-expansion proof points
> - Sales cycle: 60-90 day evaluations with 3-5 stakeholder sign-offs
>
> Keep it brief but decision-usable for the sales team.
```

---
:::

<details>
<summary>Full output: Persona (Marketing Brief)</summary>

# Persona Dossier: Sandra Vo, The Champion Who Cannot Arm Her Committee (Marketing, Brief)

</details>

---

### Persona (Marketing Detailed)

*Workbench Blueprints marketing persona for enterprise economic buyer evaluation and ROI justification*

:::note[Prompt]
```text
/persona marketing detailed

Rachel V. to PM Skills agent:

> I need a detailed marketing persona for the Workbench Blueprints economic
> buyer. This is the VP who approves budget and signs contracts, distinct
> from Sandra (our internal champion persona).
>
> Context:
> - 3 active pilot-to-enterprise conversations, all stalled at economic review
> - VP asks: ROI vs. Confluence, total cost of ownership, data residency,
>   migration timeline, contract flexibility
> - Need this persona for: pricing page messaging, enterprise proposal
>   templates, sales coaching on executive objection handling
> - Typical profile: VP of Operations or VP of IT, $500K-2M departmental
>   budget authority [fictional], 200-1000 employee companies
>
> Full detail please. This is the persona that determines whether deals
> close or die in procurement limbo.
```

---
:::

<details>
<summary>Full output: Persona (Marketing Detailed)</summary>

# Persona Dossier: Catherine Hsu, The Executive Who Approves What She Cannot Undo (Marketing)

</details>

---

### Persona (Product Brief)

*Workbench Blueprints product persona for document author submission experience and required-section compliance*

:::note[Prompt]
```text
/persona product brief

Rachel V. to PM Skills agent:

> I need a brief product persona for the Blueprints author experience.
> This is the person who creates documents from templates and submits
> them for approval. Distinct from Rhea (our approval-governance persona).
>
> Context:
> - 38% of first submissions are rejected for incomplete required sections [fictional]
> - Average 2.3 revision cycles before approval [fictional]
> - Scoping: guided authoring with completion indicators and inline validation
> - Target: user stories and edge cases for the authoring flow
>
> Keep it brief and focused on the submission experience.
```

---
:::

<details>
<summary>Full output: Persona (Product Brief)</summary>

# Persona Dossier: Marco Alves, The Author Who Submits Before He Is Ready (Product, Brief)

</details>

---

### Persona (Product Detailed)

*Workbench Blueprints approval governance persona for enterprise operations workflows*

:::note[Prompt]
```text
/persona product detailed

Create a story-first persona for Workbench Blueprints approval governance.

Context:
- Product: Workbench (enterprise collaboration platform)
- Feature lane: Blueprints required sections + approval gates
- Current pain: pilot teams can submit quickly but quality reviewers reopen too many packages late
- Baseline: re-open-after-approval rate 18% [fictional]
- Target artifact usage: PRD finalization, edge-case planning, launch checklist hardening

Output requirements:
- Narrative-first, not sterile template fill
- Explicit tradeoffs and decision moments
- Clear includes/excludes boundaries
- Scenario tailoring for problem statement, PRD, user stories, edge-cases, launch checklist
- Explicit assumptions/confidence/evidence trail
```

---
:::

<details>
<summary>Full output: Persona (Product Detailed)</summary>

# Persona Dossier: Rhea Patel, Keeper of the Approval Chain (Product)

</details>

---

## Phase: Discover

### Competitive Analysis

*"Workbench enterprise collaboration platform: Blueprints competitive landscape"*

:::note[Prompt]
```
/competitive-analysis

Scope: Enterprise documentation and knowledge management -- template governance and approval workflow capabilities. Informing Blueprints GA positioning.

Our product: Workbench -- enterprise collaboration platform, Series B, ~500 enterprise customers [fictional]. Blueprints: reusable doc templates with required sections, role-based approval gates, and version tracking.

Competitors: Atlassian Confluence, Notion, Coda, Monday.com

Segment: Enterprise (500 - 10,000 employees). Buyers: ops, compliance, and product team leads.

Feature matrix dimensions needed:
- Document templates
- Required/enforced section validation
- Native approval workflows
- Version control
- SSO/SAML
- Audit logs
- Real-time co-editing
- AI-assisted drafting

Also need: pricing comparison, positioning map (Governance Rigor vs. Ease of Adoption), deep dives per competitor, gaps and opportunities, and strategic recommendations.

Audience: Head of Product, Head of Marketing, Enterprise Sales Lead.
```

---
:::

<details>
<summary>Full output: Competitive Analysis</summary>

# Competitive Analysis: Enterprise Documentation and Template Governance

</details>

---

### Interview Synthesis

*"Workbench enterprise collaboration platform: Blueprints discovery interviews on documentation consistency and Confluence fatigue"*

:::note[Prompt]
```
/interview-synthesis

Research project: Blueprints discovery interviews -- documentation consistency and governance in enterprise teams
Product: Workbench (enterprise collaboration platform, Series B, ~500 enterprise customers [fictional])
Feature under exploration: Blueprints -- reusable document templates with required sections and role-based approval gates

Participants: 6 enterprise team leads interviewed over 3 weeks (Oct 6 - 24, 2025)
- P1: VP Ops, financial services, 8,000 employees, Confluence customer
- P2: Director of Compliance, healthcare SaaS, 2,200 employees, Confluence customer
- P3: Head of Product, logistics platform, 1,500 employees, Notion customer
- P4: Engineering Manager, insurance carrier, 4,000 employees, Confluence + SharePoint
- P5: Program Director, government contractor, 6,500 employees, SharePoint
- P6: Operations Lead, manufacturing SaaS, 900 employees, Coda customer

Format: 45-minute video calls, semi-structured
Interviewer: Rachel V. (Technical PM, Blueprints)
Observer: Tomás G. (Design Lead) on 4 of 6 sessions

Key areas explored:
1. How teams currently enforce documentation standards
2. What happens when docs reach approval incomplete
3. Pain points with current tools (Confluence, Notion, SharePoint, Coda)
4. Appetite for required-section enforcement vs. flexibility concerns
5. Who approves docs and how long it takes

Raw notes and recordings are in the Workbench research repository.
Stakeholders: Sandra C. (Head of Product), Derek H. (Head of Marketing), Mei-Lin T. (Enterprise Sales Lead)
```

---
:::

<details>
<summary>Full output: Interview Synthesis</summary>

# Interview Synthesis: Enterprise Documentation Consistency and Governance

</details>

---

### Stakeholder Summary

*"Workbench enterprise collaboration platform: Blueprints launch stakeholder map"*

:::note[Prompt]
```
/stakeholder-summary

Project: Workbench Blueprints -- reusable document templates with required sections and role-based approval gates
Product: Workbench (enterprise collaboration platform, Series B, ~200 employees, ~500 enterprise customers [fictional])
Stage: Pre-development. Discovery interviews complete. About to enter Define phase.
PM: Rachel V. (Technical PM, Blueprints)

Stakeholders to map:

Internal:
1. Sandra C. -- Head of Product. Blueprints sponsor. Approves scope and timeline. Wants Blueprints to drive enterprise expansion and reduce churn in the compliance segment.
2. James W. -- VP Engineering. Owns engineering allocation. Concerned about CRDT complexity and timeline risk. Supportive but cautious.
3. Karen L. -- Engineering Lead, Blueprints squad. Day-to-day engineering owner. Excited about the technical challenge. Needs clear requirements early.
4. Derek H. -- Head of Marketing. Owns GA positioning and messaging. Needs competitive differentiation story for enterprise sales enablement.
5. Mei-Lin T. -- Enterprise Sales Lead. Manages the top 50 enterprise accounts. Wants Blueprints to close pipeline deals stalled on governance gaps. Resistant to phased rollout -- wants everything at once.

External:
6. IT Security leads at enterprise customer accounts. Gate SSO and data residency requirements. Will block deployment if security posture is insufficient.
7. Confluence-migrant accounts (estimated 15 of 80 closed-beta customers [fictional]). High-value, high-risk -- switching cost makes them sticky if onboarding goes well, churnable if it doesn't.

Format: Full stakeholder summary with influence/interest map, detailed profiles, communication plan, and risk mitigation.
```

---
:::

<details>
<summary>Full output: Stakeholder Summary</summary>

# Stakeholder Summary: Workbench Blueprints

</details>

---

## Phase: Define

### Problem Statement

*"Workbench enterprise collaboration platform: enterprise documentation completeness gap"*

:::note[Prompt]
```
/problem-statement

Product: Workbench (enterprise collaboration platform, Series B, ~500 enterprise customers [fictional])
Feature area: Document templates and approval workflows (Blueprints)

The problem: Enterprise teams create documents using templates but no tool enforces template completion before a document enters the approval workflow. Result: approvers receive incomplete documents, send them back, and the approval cycle inflates from what should be a same-day decision to a multi-day back-and-forth.

Who is affected: Primarily two personas -- (1) document authors (project leads, ops managers) who use templates but don't complete every section; (2) approvers (department heads, compliance leads) who receive incomplete documents and must either reject and wait or approve and accept compliance risk.

Scale:
- 38% of Blueprints in closed beta reach approval with ≥1 empty required section [fictional]
- 60% of enterprise projects in our customer base lack an approved kickoff document at the time of project handoff [fictional]
- Median time to first approval: 4.0 days [fictional]; estimated 3 of those days are queue time while the doc is bounced back for completion
- Approvers review ~15 docs/month on average; at least half are incomplete [fictional]

Strategic context:
- H1 2026 OKR: expand enterprise customer base from 500 to 650 [fictional]
- Enterprise churn in compliance-heavy segments (healthcare, financial services, government) is 18% annual [fictional]; governance tooling is the most-requested feature in churn exit surveys
- Series C fundraise planned for late 2026; enterprise traction is the anchor narrative
- Competitive gap: no doc-first tool (Confluence, Notion, Coda) enforces template section completion; Monday.com has approval workflows but is not a document tool

Stakeholders: Sandra C. (Head of Product), Mei-Lin T. (Enterprise Sales Lead)
```

---
:::

<details>
<summary>Full output: Problem Statement</summary>

# Problem Statement: Enterprise Document Approval Inefficiency Due to Incomplete Template Submissions

</details>

---

### Hypothesis

*"Workbench enterprise collaboration platform: required-section enforcement hypothesis"*

:::note[Prompt]
```
/hypothesis

Product: Workbench Blueprints (enterprise doc templates with required sections and approval gates)
Stage: Define phase, post-discovery interviews and problem statement

Hypothesis: Requiring all Blueprint sections to be completed before an author can submit for approval will reduce median time to first approved Blueprint.

Context:
- 38% of Blueprints in closed beta reach approval with ≥1 empty required section [fictional]
- Median time to first approval: 4.0 days [fictional]
- Most rejections are for missing content, not quality [fictional]
- Approvers (dept heads, compliance leads) are the bottleneck -- they reject and wait, or approve with risk
- Target: reduce median approval time to ≤1 day [fictional] (aspirational)
- MDE for experiment: 1.0 day reduction (to ≤3.0 days) [fictional]

Target users: Project leads and document authors at enterprise Workbench accounts
Validation: A/B test in closed beta (80 accounts, ~300 Blueprints/week [fictional])
Primary metric: median time-to-first-approval (days)
Guardrails: author abandonment, author NPS

Stakeholders: Sandra C. (Head of Product), Karen L. (Eng Lead), Leo M. (Data Analyst)
```

---
:::

<details>
<summary>Full output: Hypothesis</summary>

# Hypothesis: Required Blueprint Sections Reduce Time-to-Approval

</details>

---

### Opportunity Tree

*"Workbench enterprise collaboration platform: enterprise expansion via governance, SSO, and Confluence migration"*

:::note[Prompt]
```
/opportunity-tree

Product: Workbench Blueprints (enterprise doc templates with required sections and approval gates)
Stage: Define phase, post-discovery and problem statement

Desired outcome: Expand Workbench enterprise customer base from 500 to 650 accounts within 12 months [fictional]
Current state: 500 enterprise customers [fictional]; enterprise churn in compliance segments is 18% annual [fictional]; 8 pipeline deals ($1.8M ARR) stalled on governance gaps [fictional]
Timeframe: 12 months from GA launch
Owner: Sandra C. (Head of Product)

Opportunities identified from discovery research:
1. Documentation governance gap -- no enterprise doc tool enforces template completion; 38% of docs reach approval incomplete [fictional]; enterprise teams need "templates with teeth"
2. SSO and security parity gap -- enterprise IT blocks deployment of tools without SSO/SAML, audit logs, and SOC 2; this is a pre-qualification filter, not a differentiator, but it is a hard gate
3. Confluence migration friction -- 4 of 6 interview participants had Confluence experience; all described migration as expensive and risky; Blueprints must offer a capability Confluence cannot provide to justify the migration cost

Solutions to explore per opportunity:
- Governance: required-section enforcement, native approval gates, template admin controls
- SSO/security: SAML integration, audit log export, SOC 2 Type II, data residency options
- Migration: Confluence template import, guided manual migration, migration support program

Prioritization: Governance is highest impact and highest confidence. SSO is table stakes (must-have, not differentiator). Migration is medium confidence (we believe it drives adoption but have not tested).

Stakeholders: Sandra C. (Head of Product), Karen L. (Eng Lead), Mei-Lin T. (Enterprise Sales Lead)
```

---
:::

<details>
<summary>Full output: Opportunity Tree</summary>

# Opportunity Solution Tree: Enterprise Customer Expansion via Blueprints

</details>

---

### JTBD Canvas

*"Workbench enterprise collaboration platform: Blueprints JTBD for ops managers enforcing documentation standards"*

:::note[Prompt]
```
/jtbd-canvas

Product: Workbench Blueprints (enterprise doc templates with required sections and approval gates)
Stage: Define phase, post-discovery interviews

Job performer: Operations managers and team leads at enterprise companies (500-10,000 employees) who are responsible for ensuring documentation standards are followed across their teams. They are not the approvers (those are department heads) -- they are the middle layer who currently enforce standards manually.

Circumstance: When a new project kicks off, a compliance review is due, or a vendor onboarding begins, these managers need to ensure the team produces a complete, approved document before work proceeds. Currently they manually review documents for completeness -- a shadow approval role that takes ~3 hours/week [fictional].

Core job: Enforce documentation standards across the team without becoming the "docs police" -- without spending their time checking whether other people filled in every section.

Current solutions they "hire":
- Confluence templates (direct competitor) -- has templates but no enforcement; "docs graveyard" problem
- Notion (direct competitor) -- beautiful UX, zero governance; "flexibility over standards" philosophy
- SharePoint + email approval chains (indirect) -- separate tools stitched together; works but is slow and fragile
- Manual review by the manager themselves (non-consumption) -- the current workaround; reliable but time-consuming and resented

Key interview quotes to incorporate:
- P6: "I don't want to be the docs police. I want the tool to be the docs police." [fictional]
- P1: "Templates without enforcement are just suggestions with formatting." [fictional]
- P4: "If one tool did both -- the doc and the approval -- we'd move tomorrow." [fictional]

Stakeholders: Sandra C. (Head of Product), Tomás G. (Design Lead)
```

---
:::

<details>
<summary>Full output: JTBD Canvas</summary>

# Jobs to be Done Canvas: Enforce Documentation Standards Without Manual Policing

</details>

---

## Phase: Develop

### Solution Brief

*"Workbench enterprise collaboration platform: Blueprints solution brief (one-pager)"*

:::note[Prompt]
```
/solution-brief

Product: Workbench Blueprints -- reusable document templates with required sections and role-based approval gates
Stage: Pre-PRD; consolidating decisions from discovery, define, and develop phases into a one-pager

Problem recap:
- 38% of enterprise documents reach approval with >=1 empty required section [fictional]
- Median time to first approval: 4.0 days [fictional]; most of that is rejection-revision cycles
- 60% of enterprise projects lack an approved kickoff doc at handoff [fictional]
- No doc-first competitor enforces template section completion

Proposed solution:
- Blueprint templates with required and optional sections, designated by template admins
- Required-section enforcement at submission (Submit button disabled until all required sections complete)
- Native role-based approval gates (single-stage approval in v1; multi-stage in v1.1)
- Real-time co-editing via Yjs CRDTs (offline-first, 20+ concurrent editors [fictional])
- Hybrid creation flow: guided wizard for first-time authors, blank canvas for returning authors
- SAML SSO, audit logs, and SCIM provisioning for enterprise deployment

Key features (5):
1. Required-section enforcement
2. Native approval gates
3. Yjs-powered co-editing
4. Hybrid wizard/canvas creation flow
5. Enterprise security (SAML, audit logs, SCIM)

Success metrics:
- Median time to first approval: 4.0 days -> <=2.5 days [fictional]
- Approval rejection rate: 38% -> <=15% [fictional]
- Enterprise accounts with active Blueprints: 200 of 500 within 6 months of GA [fictional]
- Enterprise churn (compliance segment): 18% -> <=12% within 12 months [fictional]

Trade-offs: No AI-assisted drafting in v1 (Partial per competitive analysis); no multi-stage approval in v1; no Confluence template import in v1 (guided manual migration only)

Risks: CRDT complexity (mitigated by spike); author abandonment from enforcement (mitigated by A/B test); Atlassian Rovo response (monitor)

Stakeholders: Sandra C. (Head of Product), Derek H. (Head of Marketing), Mei-Lin T. (Enterprise Sales Lead)
```

---
:::

<details>
<summary>Full output: Solution Brief</summary>

# Solution Brief: Workbench Blueprints

</details>

---

### Spike Summary

*"Workbench enterprise collaboration platform: CRDT library evaluation for Blueprint co-editing"*

:::note[Prompt]
```
/spike-summary

Spike: CRDT library evaluation for Blueprints real-time co-editing
Product: Workbench (enterprise collaboration platform)
Engineer: Nate P. (Backend Engineer)
Duration: 5 days (Dec 1-5, 2025)

Background:
- Blueprints requires real-time co-editing (20+ concurrent editors per document [fictional])
- Our editor is ProseMirror-based; no current collaboration layer
- Enterprise requirements: offline-first, conflict resolution, per-user audit trail
- Target: 20+ concurrent editors, <100ms merge latency [fictional]

Libraries evaluated:
1. Yjs (CRDT, MIT) -- y-prosemirror binding; offline-first; sub-document support
2. Automerge (CRDT, MIT) -- Rust/WASM; strong offline; no ProseMirror binding
3. ShareDB (OT, MIT) -- central server model; mature; no offline support

Findings from prototype:
- Yjs: integrated in 2 days; 45ms merge latency at 20 users [fictional]; +38KB gzipped [fictional]; offline works out of box
- Automerge: no ProseMirror binding (3-4 week custom build [fictional]); +120KB gzipped [fictional]; excellent offline
- ShareDB: integrated in 1.5 days; 62ms merge latency [fictional]; +22KB gzipped [fictional]; NO offline (disqualified)

Stakeholders: Karen L. (Eng Lead), James W. (VP Engineering)
```

---
:::

<details>
<summary>Full output: Spike Summary</summary>

# Spike Summary: CRDT Library Evaluation for Blueprints Co-Editing

</details>

---

### Architecture Decision Record

*"Workbench enterprise collaboration platform: ADR for Yjs CRDTs for Blueprint co-editing"*

:::note[Prompt]
```
/adr

ADR: Use Yjs CRDTs for Blueprints real-time co-editing
Product: Workbench Blueprints
Stage: Post-CRDT spike; recording architecture decision

Context:
- Blueprints requires real-time co-editing (20+ concurrent editors [fictional])
- ProseMirror-based editor; no current collaboration layer
- Enterprise requirements: offline-first, conflict resolution, per-user audit trail
- Spike evaluated Yjs, Automerge, ShareDB

Decision: Yjs
- 2-day integration via y-prosemirror; 45ms merge latency at 20 users [fictional]; +38KB gzipped [fictional]; offline-first
- Automerge rejected: no ProseMirror binding (3-4 week custom build [fictional]); +120KB [fictional]
- ShareDB rejected: no offline support (disqualified)

Consequences:
- Positive: fast integration, offline-first, active community, sub-document support
- Negative: WebSocket provider TBD, audit trail requires custom middleware, binary document format
- Neutral: bundle size acceptable for enterprise

Stakeholders: James W. (VP Engineering), Karen L. (Eng Lead), Nate P. (Backend Engineer)
```

---
:::

<details>
<summary>Full output: Architecture Decision Record</summary>

# ADR-012: Use Yjs CRDTs for Blueprints Real-Time Co-Editing

</details>

---

### Design Rationale

*"Workbench enterprise collaboration platform: guided wizard vs. blank canvas for Blueprint creation flow"*

:::note[Prompt]
```
/design-rationale

Decision: Blueprint creation flow -- guided wizard vs. blank canvas
Product: Workbench Blueprints (enterprise doc templates with required sections and approval gates)
Stage: Develop phase, pre-PRD

Problem: How should a new Blueprint be created? Two options:
- Option A: Guided wizard -- step-by-step flow, one section per screen, progress indicator, validation per step
- Option B: Blank canvas -- full template opens in the editor, all sections visible, fill in any order (Confluence model)
- Option C (hybrid): Wizard for first-time creation, canvas for returning authors who have completed a Blueprint before

Context:
- Enterprise users are not power users of Workbench yet -- Blueprints is a new feature
- Required sections are the core differentiator; the creation flow must make enforcement feel helpful, not punitive
- Discovery interviews: middle managers act as "docs police"; the creation flow should reduce, not increase, that burden
- Closed-beta preference test (8 users [fictional]): 6 preferred wizard on first use, 5 preferred canvas after their second Blueprint
- Karen L. (Eng Lead): wizard adds 1 sprint of effort vs. canvas [fictional]
- Tomas G. (Design Lead): wizard produces cleaner first submissions but risks feeling patronizing for experienced authors

Evaluation criteria: first-submission completeness rate, author time-to-submit, author satisfaction (NPS), engineering effort, scalability to custom templates

Stakeholders: Sandra C. (Head of Product), Karen L. (Eng Lead), Tomas G. (Design Lead)
```

---
:::

<details>
<summary>Full output: Design Rationale</summary>

# Design Rationale: Blueprint Creation Flow

</details>

---

## Phase: Deliver

### PRD

*Workbench enterprise collaboration platform - Blueprints v1 PRD for required-section enforcement and approval gates*

:::note[Prompt]
```
/prd

Here is the structured brief for the Blueprints v1 PRD.

**Product context:**
- Workbench collaboration platform, ~500 enterprise customers [fictional], Series B
- Blueprints = reusable document templates with required sections and approval gates
- Core problem: 38% of Blueprints reach approval with ≥1 empty section [fictional]; median time to first approval is 4.0 days [fictional]; 60% of enterprise projects lack an approved kickoff doc at handoff [fictional]

**Prior decisions to incorporate:**
- ADR-012: Yjs CRDTs selected for real-time co-editing (45ms merge latency at 20 concurrent editors [fictional], +38KB gzipped [fictional])
- Design rationale: Hybrid wizard/canvas -- guided wizard for first-time authors, blank canvas for returning authors
- Opportunity tree: Priority path is documentation governance gap → required-section enforcement
- Hypothesis: Required sections reduce time-to-approved from 4.0 days to ≤2.5 days [fictional]; validation via A/B test (Mar 9 -- Apr 5, 2026)

**Target users:** Enterprise ops managers (creators), department heads (approvers), IT security leads (admin/provisioning)

**Key features for v1:**
1. Required-section enforcement (submit button disabled until all required sections complete)
2. Native approval gates (role-based routing, sequential and parallel approval)
3. Yjs real-time co-editing (offline-first, sub-document-level sync)
4. Hybrid wizard/canvas creation flow
5. Enterprise security suite (SAML SSO, audit logs, role-based access)

**Timeline:** Closed beta running now with 80 accounts [fictional]; A/B test Mar 9 -- Apr 5; GA target April 2026

**Success metrics:** Time-to-approved ≤2.5 days [fictional], empty-section rate ≤10% [fictional], enterprise account growth from 500 to 650 in 12 months [fictional]

Please generate a complete PRD following the standard template.
```
:::

<details>
<summary>Full output: PRD</summary>

# PRD: Workbench Blueprints v1

</details>

---

### User Stories

*Workbench enterprise collaboration platform - Blueprints v1 sprint stories for required sections and approval gates*

:::note[Prompt]
```
/user-stories

I need two user stories for the Blueprints v1 sprint backlog. These are the two highest-priority stories for the first sprint.

**Story 1 -- Required-section enforcement (author perspective):**
- Persona: Ops manager creating a Blueprint from a template with required sections
- Core need: Cannot submit an incomplete document for approval
- Key behaviors: Required sections show a visual indicator; submit button disabled until all required sections have content; if content is deleted, submit re-disables
- Context: Part of the hybrid wizard/canvas flow; applies to both wizard and canvas modes
- Relates to: A/B test hypothesis (required vs. optional sections, Mar 9 -- Apr 5)

**Story 2 -- Approval gate (approver perspective):**
- Persona: Department head reviewing a submitted Blueprint
- Core need: Review complete documents efficiently with clear approve/reject actions
- Key behaviors: Notification on submission; inline section review; approve, reject with required comment, or request changes; Blueprint marked approved when all required approvers complete
- Context: Sequential and parallel approval chains configured per template by admin

For each story, include full acceptance criteria, design notes, technical notes, dependencies, out of scope, and open questions.
```
:::

<details>
<summary>Full output: User Stories</summary>

# User Story: Required-Section Enforcement for Blueprint Authors

</details>

---

### Edge Cases

*Workbench enterprise collaboration platform - Blueprints edge-case analysis for approval workflows and co-editing*

:::note[Prompt]
```
/edge-cases

I need a comprehensive edge-case analysis for Blueprints v1 covering the three highest-risk areas: required-section enforcement boundaries, approval-gate state transitions, and real-time co-editing conflicts.

**Context:**
- Required sections use a content-presence check (non-whitespace); submit is disabled until all required sections have content
- Approval gates support sequential and parallel chains; state stored in relational DB, not in the Yjs document
- Co-editing uses Yjs CRDTs with sub-document-level sync; offline edits cache locally and merge on reconnect
- 80 closed-beta accounts [fictional], target ~20 concurrent editors per Blueprint [fictional]

**What I need:**
- Edge cases organized by category
- Error messages for each failure state
- Recovery paths so QA and engineering know the expected behavior
- Prioritized test scenarios (P1 must-test, P2 should-test, P3 nice-to-test)

Please be thorough -- Karen's team will use this directly for test planning.
```
:::

<details>
<summary>Full output: Edge Cases</summary>

# Edge Cases: Workbench Blueprints v1

</details>

---

### Launch Checklist

*Workbench enterprise collaboration platform - Blueprints v1 GA launch readiness checklist*

:::note[Prompt]
```
/launch-checklist

I need a comprehensive launch checklist for Blueprints v1 GA. Here's the context:

**Launch details:**
- Launch name: Blueprints GA
- Target date: April 28, 2026
- Rollout: From 80 closed-beta accounts to all ~500 enterprise customers [fictional]
- Ship decision confirmed by Sandra C. on April 14, 2026

**Key stakeholders:**
- Rachel V. (PM), Karen L. (Eng Lead), Tomás G. (Design Lead), Derek H. (Head of Marketing), Mei-Lin T. (Enterprise Sales Lead), James W. (VP Eng)

**Critical items I'm tracking:**
- SAML SSO certification -- must be complete before GA (enterprise blocker)
- IT admin provisioning guide -- enterprise security teams need this before they'll onboard
- Confluence migration communication plan -- many prospects are switching from Confluence
- A/B test code cleanup -- remove experiment flags, ship required-sections as default
- WebSocket provider scaling -- validated at 80 accounts, need to load test for 500

**Rollback concern:** If a critical bug surfaces in the first 48 hours, we need a clean rollback to the pre-Blueprints state without data loss for accounts that already created Blueprints during GA.

Please generate the full launch checklist with go/no-go criteria and a rollback plan.
```
:::

<details>
<summary>Full output: Launch Checklist</summary>

# Launch Checklist: Blueprints v1 GA

</details>

---

### Release Notes

*Workbench enterprise collaboration platform - Workbench 3.5 release notes for Blueprints GA*

:::note[Prompt]
```
/release-notes

I need customer-facing release notes for Workbench 3.5, which ships Blueprints GA.

**Highlights (top 2 features to call out):**
1. Blueprints with required-section enforcement -- the headline feature; reduces incomplete document submissions
2. Real-time co-editing -- powered by Yjs CRDTs; multiple authors can work simultaneously, including offline

**New features to cover:**
- Required-section enforcement (submit gated on section completeness)
- Native approval gates (sequential and parallel chains, role-based routing)
- Real-time co-editing (offline-first, presence awareness)
- Hybrid wizard/canvas creation flow
- SAML SSO integration and audit logs

**Improvements:**
- Template gallery redesign (faster browsing, search)
- Notification system updated for approval events
- Document editor performance (15% faster load time [fictional] from bundle optimization)

**Bug fixes:**
- Fixed: document auto-save occasionally failed on slow connections
- Fixed: role assignment changes did not propagate until page refresh
- Fixed: exported PDFs missing footer page numbers

**Known issues:**
- Co-editing cursor labels may overlap when 10+ editors are in the same section
- Wizard auto-disable threshold (12 sections) is not configurable by admins in v1

**Coming soon (v1.1 preview):**
- Version history for Blueprints
- Approval delegation (OOO forwarding)
- Section-level commenting
- Jira two-way sync

Tone: professional, clear, no hype. Enterprise audience.
```
:::

<details>
<summary>Full output: Release Notes</summary>

# Workbench 3.5

</details>

---

## Phase: Measure

### Experiment Design

*"Workbench enterprise collaboration platform: Blueprints required vs. optional sections A/B test"*

:::note[Prompt]
```
/experiment-design

Experiment: Required vs. optional Blueprint sections
Product: Workbench Blueprints (enterprise doc templates with approval gates)
Stage: Closed beta shipped; need to A/B test before expanding to full 500-customer base [fictional]

Context:
- Blueprints allows admins to create doc templates with sections
- Currently all sections are optional -- authors can submit incomplete Blueprints for approval
- Data: 38% of Blueprints reach approval with ≥1 empty section [fictional]; most rejections are for missing content, not quality
- Hypothesis from Define phase: making sections required (must complete before submitting) reduces time to first approval
- Baseline: median time to first approved Blueprint = 4.0 days [fictional]
- Goal: reduce to ≤2.5 days [fictional]

Treatment: Required sections -- authoring UI blocks submission if any required section is empty. Show inline validation message, highlight empty sections.
Control: Current optional sections -- authors can submit with empty sections as today.

Primary metric: median time-to-first-approval (days)
Secondary: approval rejection rate, Blueprint completion rate
Guardrail: don't tank author-side NPS or increase abandonment

Audience: Project leads at enterprise customers in closed beta (excludes IT admins and approvers).
Stakeholders: Head of Product, Data Science, Engineering Lead (Blueprints)
```

---
:::

<details>
<summary>Full output: Experiment Design</summary>

# Experiment Design: Blueprints Required vs. Optional Sections

</details>

---

### Instrumentation Spec

*"Workbench enterprise collaboration platform: Blueprints v1 GA instrumentation spec"*

:::note[Prompt]
```
/instrumentation-spec

I need the instrumentation spec for Blueprints v1 GA. Here are the events I've identified from the PRD and experiment results:

**Core lifecycle events:**
1. `blueprint_created` -- when an author creates a new Blueprint from a template
2. `section_completed` -- when a required section transitions from empty to non-empty
3. `section_cleared` -- when a required section transitions from non-empty to empty
4. `approval_requested` -- when an author submits a Blueprint for approval
5. `approval_granted` -- when an approver approves a Blueprint
6. `approval_rejected` -- when an approver rejects a Blueprint
7. `blueprint_published` -- when an approved Blueprint is published to the team workspace

**Key properties I need on each event:**
- Standard: account_id, user_id, blueprint_id, template_id, timestamp
- blueprint_created: creation_method (wizard/canvas), template_name, required_section_count, optional_section_count
- section_completed/cleared: section_id, section_name, is_required, word_count
- approval events: approval_chain_type (sequential/parallel), approver_position, approval_cycle_number
- blueprint_published: time_to_approved_hours, total_approval_cycles, co_editor_count

**PII concerns:**
- user_id is internal (UUID), not PII
- We must NOT capture section content in events -- only metadata
- Account names should not appear in event properties; use account_id only

**SDK:** Workbench Analytics SDK (server-side collector, JavaScript client)

Please generate the full instrumentation spec with testing checklist.
```
:::

<details>
<summary>Full output: Instrumentation Spec</summary>

# Instrumentation Spec: Workbench Blueprints v1

</details>

---

### Dashboard Requirements

*"Workbench enterprise collaboration platform: Blueprints post-launch monitoring dashboard requirements"*

:::note[Prompt]
```
/dashboard-requirements

I need dashboard requirements for the Blueprints post-launch monitoring dashboard. Here's the context:

**Audiences:**
1. Rachel V. (PM) -- daily check: adoption trends, approval bottlenecks, template usage
2. Sandra C. (Head of Product) -- weekly review: executive summary, account growth, key health metrics
3. Karen L. (Engineering) -- real-time: system health, merge latency, error rates

**Key metrics from the PRD and experiment results:**
- Median time-to-approved (target: ≤2.5 days [fictional])
- Empty-section submission rate (target: ≤10% [fictional])
- Approval cycle count (target: ≤1.5 cycles [fictional])
- Blueprint adoption: monthly active Blueprint creators (target: 2,000 [fictional])
- Enterprise account growth (target: 500 → 650 in 12 months [fictional])

**Data sources:**
- Workbench analytics pipeline (event data from instrumentation spec)
- WebSocket provider telemetry (merge latency, connection count, error rate)
- CRM pipeline (account growth, enterprise tier)
- Support ticketing system (Blueprint-related ticket volume)

**Visualization preferences:**
- Time-to-approved: trend line over time (weekly median)
- Adoption: stacked area chart by department/template type
- Approval funnel: horizontal funnel chart
- System health: real-time gauges with alert thresholds

Please generate the full dashboard requirements including layout, filters, alerts, and acceptance criteria.
```
:::

<details>
<summary>Full output: Dashboard Requirements</summary>

# Dashboard Requirements: Blueprints Post-Launch Monitor

</details>

---

### Experiment Results

*"Workbench enterprise collaboration platform: Blueprints required-section enforcement A/B test results"*

:::note[Prompt]
```
/experiment-results

Leo M. just finished the A/B test analysis. I need a full experiment-results document for the April 14 ship-decision meeting. Here are the results:

**Experiment details:**
- Name: Required-Section Enforcement A/B Test
- Duration: Mar 9 -- Apr 5, 2026 (28 days)
- Accounts: 80 closed-beta enterprise accounts [fictional]; 40 treatment, 40 control
- Randomization: Account-level (all users within an account see the same variant)
- Total Blueprints created during test: 612 (298 treatment, 314 control) [fictional]

**Primary metric:**
- Median time-to-approved: Treatment 2.4 days [fictional] vs. Control 4.0 days [fictional]
- Relative change: -40% [fictional]
- Mann-Whitney U test: p = 0.001
- 95% CI for median difference: 1.2 -- 2.0 days [fictional]

**Secondary metrics:**
- Empty-section submission rate: Treatment 6% [fictional] vs. Control 37% [fictional]
- Approval cycle count: Treatment 1.4 [fictional] vs. Control 2.3 [fictional]
- Blueprint completion rate (% of started Blueprints that reach approval): Treatment 78% [fictional] vs. Control 71% [fictional]

**Guardrail metrics:**
- Author satisfaction (in-app survey, 1-5 scale): Treatment 3.8 [fictional] vs. Control 3.9 [fictional] (not significant, p=0.42)
- Blueprint creation rate (Blueprints started per account per week): Treatment 3.7 [fictional] vs. Control 3.9 [fictional] (not significant, p=0.31)
- Average section word count: Treatment 142 words [fictional] vs. Control 128 words [fictional] (significant, p=0.03)

**Segment analysis:**
- By company size: Large (200+ employees): -44% time-to-approved [fictional]; Mid (50-199): -38% [fictional]; Small (10-49): -31% [fictional]
- By template type: Project kickoff templates: -45% [fictional]; Process documentation: -35% [fictional]; Meeting notes: -22% [fictional]

**Surprising finding:** Authors in the treatment group wrote 11% more words per section on average [fictional]. We think the required-section badges acted as a psychological prompt to write more thoroughly.

**Recommendation:** Ship. Required-section enforcement exceeded our MDE of 1.0 day with high confidence.

Please generate the full experiment-results document for the ship-decision meeting.
```
:::

<details>
<summary>Full output: Experiment Results</summary>

# Experiment Results: Required-Section Enforcement A/B Test

</details>

---

## Phase: Iterate

### Retrospective

*"Workbench enterprise collaboration platform: Blueprints v1 GA post-launch retrospective"*

:::note[Prompt]
```
/retrospective

I'm facilitating the Blueprints post-GA retrospective. Here's the context:

**Session details:**
- Date: May 12, 2026
- Duration: 90 minutes
- Format: Virtual (Zoom), structured facilitation

**Attendees:** Rachel V. (PM, facilitator), Karen L. (Eng Lead), Tomás G. (Design Lead), Nate P. (Backend Eng), Aisha K. (Frontend Eng), Leo M. (Data Analyst), Sandra C. (Head of Product, observer)

**Context:**
- Blueprints v1 GA launched April 28, progressive rollout completed May 5
- 320/500 accounts active on Blueprints [fictional]; remaining 180 in onboarding pipeline
- Time-to-approved holding at 2.4 days [fictional] (target: ≤2.5)
- 3 launch-week incidents: (1) approval UX confusion -- 23 support tickets from first-time approvers who couldn't find the reject button, (2) SSO incident day 2 -- misconfigured SAML attribute mapping blocked 12 accounts for 3 hours, (3) wizard threshold rigidity -- 8 enterprise templates with 15+ sections couldn't use the wizard at all

**What went well:**
- A/B test methodology was solid; ship decision was data-driven and confident
- Progressive rollout caught the SSO issue at 10% before it hit all accounts
- Yjs co-editing performance exceeded targets (32ms p95 merge latency vs. 50ms target [fictional])
- Cross-functional coordination between eng, design, and marketing was the best it's been

**What to improve:**
- Approval UX needed more usability testing before launch
- SSO configuration was manual and error-prone; need automated validation
- Wizard threshold should be configurable, not hardcoded
- Edge-case doc was excellent but QA didn't have time to test all P2 scenarios

**Action items I want to formalize:** 5 items for v1.1 sprint planning

Please generate the full retrospective document.
```
:::

<details>
<summary>Full output: Retrospective</summary>

# Retrospective: Blueprints v1 GA Launch

</details>

---

### Lessons Log

*"Workbench enterprise collaboration platform: Blueprints skip-and-submit enforcement lesson"*

:::note[Prompt]
```
/lessons-log

I need to document a lesson learned from the Blueprints launch. Here's the context:

**Title:** Required-Section Enforcement Caused Skip-and-Submit Behavior

**What happened:**
- Required-section enforcement successfully reduced the empty-section submission rate from 37% to 7% [fictional]
- But post-launch analysis revealed that approximately 4% of submitted Blueprints contain placeholder text in required sections [fictional] -- authors typing "TBD," "See above," "Will update," or pasting Lorem Ipsum to clear the gate
- Combined, 11% of Blueprints reaching approval still have quality issues [fictional] (7% empty + 4% placeholder), vs. our 10% target
- This was flagged as a risk in the PRD (Risk row 1: "Required sections cause author frustration and workarounds") but we underestimated the speed of adoption
- The root cause: we enforced completeness at the wrong point. Blocking submit punishes the author but doesn't help the approver. Approvers still have to manually check for placeholder text.

**The lesson:**
- Enforce quality at the approval gate, not the authoring gate
- Shift from "block the author from submitting" to "give the approver a completeness score"
- The submit gate should remain (it catches genuine omissions) but add a visible completeness/quality signal to the approval view

**Team:** Rachel V., Karen L., Leo M.
**Timeline:** Identified May 10, 2026 (Leo M.'s 2-week post-launch analysis); documented May 14

Please generate the full lessons-log entry.
```
:::

<details>
<summary>Full output: Lessons Log</summary>

# Required-Section Enforcement Caused Skip-and-Submit: Enforce at the Approval Gate, Not the Authoring Gate

</details>

---

### Refinement Notes

*"Workbench enterprise collaboration platform: Blueprints v1.1 backlog refinement session"*

:::note[Prompt]
```
/refinement-notes

I just ran the v1.1 refinement session. Here are the details:

**Session info:**
- Date: May 26, 2026
- Duration: 60 minutes
- Attendees: Rachel V. (PM, facilitator), Karen L. (Eng Lead), Tomás G. (Design), Nate P. (Backend), Aisha K. (Frontend), Leo M. (Data)

**Stories refined (6):**

1. BLUE-201: Approval action bar redesign -- promote Reject and Request Changes to primary visibility
   - Points: 3 (was 2 from retro; increased after discussion of animation transitions)
   - Ready for sprint

2. BLUE-202: Audit trail export (CSV) -- compliance officer can export all Blueprint lifecycle events for a date range
   - Points: 8
   - Ready for sprint
   - Note: Nate P. flagged that the current audit log stores events in an append-only format optimized for writes, not reads. The export query will need a read-optimized view or materialized table.

3. BLUE-203: Audit trail export (PDF) -- formatted PDF export for regulatory submissions
   - Points: 5
   - Blocked -- depends on BLUE-202 (CSV export provides the data layer); also needs legal review of the PDF format for FDA/SOX compliance

4. BLUE-204: Configurable wizard threshold -- template admins can set the section count at which the wizard auto-disables (default: 12)
   - Points: 2
   - Ready for sprint

5. BLUE-205: Approver-visible completeness score -- display per-section quality indicators in the approval review view
   - Points: 8
   - Ready for sprint (design review scheduled for May 28)
   - Note: Tomás G. proposed a progress bar showing "% sections with 20+ words" plus yellow warning badges on sections below threshold. Karen L. asked whether the threshold should be configurable -- team decided to hardcode 20 words for v1.1 and make it configurable in v1.2 if needed.

6. BLUE-206: Compliance officer role -- new RBAC role with template-lock and audit-export permissions
   - Points: 13
   - Blocked -- depends on BLUE-202 (audit export) for the export permission; also needs Karen L. to design the RBAC extension architecture

**Questions raised:**
- Should the audit trail export include section-level edit history or just lifecycle events? (Decision: lifecycle events only for v1.1; section-level history deferred to version history feature)
- Should the completeness score be visible to authors during editing, or only to approvers? (Decision: approvers only for now; author-visible is a future consideration)
- What happens to in-flight Blueprints when a compliance officer locks a template? (Parked for BLUE-206 design)

**Decisions made:**
- Wizard threshold default stays at 12 (consistency with v1) but is now admin-configurable
- Completeness word-count threshold is hardcoded at 20 words for v1.1
- Audit trail export scope is lifecycle events only (not section edit history)

Please generate the full refinement notes.
```
:::

<details>
<summary>Full output: Refinement Notes</summary>

# Refinement Notes: May 26, 2026

</details>

---

### Pivot Decision

*"Workbench enterprise collaboration platform: Blueprints customer segment pivot decision"*

:::note[Prompt]
```
/pivot-decision

I need a formal pivot-decision document for the exec team. Here's the situation:

**Current state:**
- Blueprints GA launched April 28, 2026; 320/500 accounts active [fictional]
- Time-to-approved: 2.4 days [fictional] (on target)
- But adoption is uneven: 68% of active Blueprints come from ops/compliance teams [fictional]; 8% from engineering [fictional]; 24% from other departments [fictional]
- Sales pipeline: 6 of 8 stalled deals ($1.8M ARR [fictional]) are in regulated industries waiting for compliance-specific features (audit trail export, regulatory template library, compliance officer role)

**Options:**
1. Persevere: Continue horizontal strategy; invest equally across all department use cases
2. Customer segment pivot: Narrow focus to ops/compliance teams in regulated industries; defer engineering templates to v2
3. Hybrid: Ship the compliance features that unblock the $1.8M pipeline, but keep the horizontal template system

**My recommendation:** Option 2 (customer segment pivot). The data is clear that ops/compliance is where the product-market fit is strongest. Engineering teams need fundamentally different features (code review integration, CI/CD hooks, Jira-native workflow) that would take 6+ months to build. Narrowing focus now lets us win the compliance segment, hit the 650-account target [fictional], and return to engineering in v2 with dedicated investment.

**Key concern from Sandra C.:** She worries that narrowing the segment limits the TAM for Series C fundraising. Mei-Lin T. counters that regulated-industry compliance is a $4.2B TAM [fictional] and growing.

Please generate the full pivot-decision document.
```
:::

<details>
<summary>Full output: Pivot Decision</summary>

# Pivot Decision: Workbench Blueprints Customer Segment Focus

</details>

---

*28 artifacts generated across the full PM lifecycle.*

---

**Explore other journeys:**

- [Storevine (B2B Ecommerce Platform)](storevine.md)
- [Brainshelf (Consumer PKM App)](brainshelf.md)
