Change logVersion control

Product Requirements Document - Quorum

Author: James
Date: 2026-04-10

Document conventions

Source file: prd.md — Markdown body plus YAML workflow frontmatter (BMAD checkpoint, visionDiscovery, pipeline, roster). Regenerate published copies after substantive edits:

Run python3 _gen_prd_exports.py in _bmad-output/planning-artifacts/. Optional: quorum-prd-executive-summary.pdf (exec summary only). In-product Quorum PRDs use the same HTML + .docx pairing from one source (pipeline step 4, FR26).

Traceability map

Executive Summary

Quorum is an AI-native product development platform where named agents are the cross-functional team—not a chat sidebar on a ticket tool. Solo founders and enterprise product groups start from a full vision, run it through a disciplined three-pillar filter (Desirability, Feasibility, Viability) with transparent reasoning, and generate aligned downstream artifacts (PRD, journeys, roadmap, cost, pitch, sprint stories) from one evolving source of truth. The human stays conductor; agents challenge the user and each other with structural differentiation (not five identical personas).

Entry is a design-thinking-style session: core idea, ideation, and constraints, closing with a detailed Figma Make prompt so the first concept UI is explorable before scope is locked. Concept visuals update live during the filter. High-fidelity UI, design tokens, and design system are intentionally deferred until after PRD and journey maps (step 5.25), when flows and architecture are known—then Luca (Motion Designer) layers motion on refined screens (5.5) before roadmap and cost absorb motion scope. Quorum does not write application code; it orchestrates external AI coding tools via rich stories—Jaymes (frontend, always in build), Damien (backend, when needed), Quinn (QA), Cipher (mandatory security audit post-build), Bob (Scrum Master). Primary MVP audience: solo founders and indie builders; secondary: enterprise teams that want the same methodology with human specialists leading agents.

Why now: Large founder population already using AI assistants, but no product owns the input side of decisions—methodology as architecture—while models are strong enough to sustain multi-agent product critique.

What Makes This Special

• Agents are the team: Named roster (John, Winston, Mary, Kinsley, Luca, Jaymes, Damien, Quinn, Cipher, Bob) maps to real roles; backbone behavior toward the user is a deliberate differentiator.
• Methodology as architecture: The pipeline is the product logic—not a template library bolted onto Jira-shaped software.
• Vision-first, filter second: Capture and organize, then argue scope with research-grade transparency; nothing important disappears without a logged decision.
• Staged design fidelity: Fast concept in Figma Make (V1 handoff; V2 deeper integration) without token/DS tax up front; refine after journeys; motion on stable pixels—reduces wasted polish on cut or reshaped flows.
• Build orchestration, not an IDE: Quorum produces the thinking and handoffs; Cursor/Claude Code-class tools execute implementation under agent direction.
• One truth, many outputs: Pitch and exec artifacts are cheap because the methodology already produced the underlying data.

Core insight: Existing tools manage the outputs of decisions (tickets, roadmaps, docs). Quorum owns the inputs—thinking, filtering, evidence—and generates outputs from that spine.

Project Classification

Note: V2-critical expansion (documented in vision notes): domain-specific agent packs for regulated industries (e.g. healthcare, fintech) as a marketplace-style capability.

Success Criteria

User Success

• Decision quality (solo): Users report clearer tradeoffs and fewer regretful scope decisions after running the three-pillar filter (qualitative interviews / in-product prompts).
• Time-to-plan: Idea to a validated MVP plan (filtered vision, PRD slice, roadmap + cost confidence) in under two weeks for a motivated solo founder using the guided path—not months of unstructured docs.
• Ship outcomes: Teams that complete the filter and follow generated stories show higher satisfaction or adoption on shipped features vs. pre-Quorum baseline (self-reported or tagged cohort where measurable).
• Scope discipline: When feedback-loop findings exist (V2), items that re-enter the filter show less unmanaged scope creep than ad-hoc backlog growth (process metric).

Business Success

• Solo adoption: 1,000 active users on solo tier within first 6 months of launch (definition: monthly active completing at least one meaningful pipeline segment).
• Enterprise funnel: >20% demo-to-pilot conversion for qualified enterprise conversations.
• Unit economics: Tiered + usage-based pricing validated so power-user cost (high session volume) is modeled and does not break margins at the solo price point.
• Positioning signal: Strong NPS theme: users describe Quorum as “my team,” not “my tool.”

Technical Success

• Orchestration reliability: Story export and handoff to supported AI coding tools (V1: Claude Code / Cursor) is repeatable—stories contain enough context that implementers rarely block on missing spec (measured by support tickets or completion rate).
• Single source of truth: Screen/feature state has one canonical representation through organize → filter → PRD → journeys → refinement (no conflicting “which design is real” drift without explicit versioning).
• Security gate: Cipher audit runs after build; critical/high issues block ship until resolved or explicitly waived with record.
• Quality guardrails: Agent outputs are scored or gated where feasible; distinguishability between agent roles does not collapse in early evals (per product quality bar in vision notes).

Measurable Outcomes

Product Scope

MVP - Minimum Viable Product

• Vision capture spine — mandatory in V1 (non-negotiable): Steps 1 → 2a → 2b → 2c are core V1, not optional and not deferrable. Step 1 (design-thinking-style session, problem/user/constraints/risks, ideation, closing Figma Make prompt), 2a (concept alignment), 2b (initial concept visuals / Figma Make handoff), and 2c (organize the vision) are the start of the methodology—the reversed-flow entry that differentiates Quorum. Shipping “Quorum” without this spine invalidates the product thesis. Ideation must support multiple proposed concept directions and external iteration (user works in another tab or window, then carries results back) per FR46. Incremental enhancements (e.g. voice-first capture, Socratic mode, mood board) are V1 candidates that add to this spine—they do not replace it.
• Full named agent team in workflow: John, Winston, Mary, Kinsley, Luca, Jaymes, Quinn, Cipher, Bob; Damien when backend is in scope.
• Guided pipeline from idea through pitch-ready artifacts: design-thinking session + Figma Make prompt → concept (2a/2b) → organize → three-pillar filter with live concept visuals → PRD → journey maps → design refinement (5.25) → motion (5.5) → roadmap → cost → pitch → sprint planning → build orchestration (10a) → QA (10b) → Cipher (10c) → UAT (10d) → ship.
• Quorum does not author app code—generates detailed stories for external AI coding tools; Jaymes always in UI path; Damien conditional.
• Team room GUI: conversational center, not dashboard-first; AI challenger behavior (push back on user, not only agents).
• Solo and enterprise experiences both present; toggle for demo (exact UX TBD).
• Built-in sprint board, backlog, roadmap (Bob).
• V1 integration priority: one primary coding-tool path (e.g. Cursor / Claude Code) with story format optimized for consumption.

Growth Features (Post-MVP)

• Feedback loop productized: passive collection, milestone activation, digest, ceremony; findings re-enter filter (scope creep firewall).
• Hospital / Morgue / Decomposer finding lifecycle.
• JIRA / Linear (or similar) bi-directional sync for enterprise.
• Confidence × complexity decision grid in ceremonies.
• Visible agent-to-agent debate (V1 stays synthesized disagreement).
• Dynamic sub-agent scaling under load.
• Deeper Figma Make ↔ Quorum integration (beyond link/export handoff).
• Product snapshots & branching (“git for product strategy”).
• Animated prototypes (beyond motion specs).

Vision (Future)

• Domain-specific agent marketplace (regulated industries: healthcare/HIPAA, fintech/PCI, legal, etc.).
• Full automated brownfield ingestion (codebase scan, multi-tool imports, design-system parse, velocity calibration).
• Multi-tool coding orchestration with API-level progress sync.
• Third-party research platform partnerships (e.g. Userlytics-class)—not in core product initially.

Explicitly Out (All Versions)

• Mobile-native app (web-first).
• Self-hosted / on-prem deployment (for stated horizon).
• End-user custom agent training (no user-trained models in scope).

MVP Boundaries & Open Decisions

• Default path: guided sequential pipeline vs. menu / non-linear access—decision required for V1 (Party Mode flagged).
• Canonical artifact schema for screen state and story export—spec TBD before build-heavy phases.
• Enterprise: one automated integration (e.g. Jira or Notion import) per premortem—pick for V1.
• PRD export formats (locked): HTML and Microsoft Word (.docx)—both from a single canonical PRD representation; styling/templates may vary by tier.

User Journeys

Narrative journeys below map who uses Quorum, how they move through the pipeline, and what must exist in the product. Personas align with the product brief: solo founder / indie builder as primary MVP; enterprise product trio as secondary; plus admin, implementer, and recovery paths.

Journey 1 — Maya (solo founder): From spark to pitch-ready plan

Persona: Maya is building a B2B SaaS alone. She has a strong idea but no PM, designer, or eng lead to challenge her. She burns time in Notion lists that never become decisions.

• Opening: Late night, Maya dumps her idea into Quorum. She expects another generic chatbot. Instead, John opens a design-thinking-style session—problem, user, risks—and Kinsley asks about vibe and references. Maya feels heard, not templated.
• Rising action: She receives a detailed Figma Make prompt, refines it with Kinsley (2a), and sees concept frames land in Figma Make (2b). The vision is organized into themes; the three-pillar filter runs as a conversation. When Winston questions feasibility, she pushes back; the UI shows concept screens updating live as features survive or get cut. She trusts the process because reasoning is transparent (sources, caveats).
• Climax: After PRD and journey maps, Kinsley’s refinement pass (5.25) makes the product feel real; Luca adds motion intent before roadmap and cost. Maya opens the pitch output and realizes she could walk into a coffee meeting tomorrow with a coherent story—not a ramble.
• Resolution: Her new normal: Quorum is “the team in the room.” She completes a validated MVP plan in days, not months, and describes the product as partners, not a tool.

Failure / recovery: If Maya abandons during long capture, save points and short aha milestones (organized vision early) pull her back. If she disagrees with a pillar verdict, she can argue, override with audit trail, or re-run a segment.

Journey 2 — Maya (edge): When the filter says “cut” and she refuses

• Opening: Maya is emotionally attached to a feature the filter recommends cutting.
• Rising action: She reads Winston’s feasibility breakdown and Mary’s desirability evidence. She challenges in-thread; agents respond with specific citations, not vibes. Kinsley shows what the concept UI looks like without that feature.
• Climax: She either accepts the cut with understanding, negotiates a scoped-down version that passes pillars, or overrides with the decision logged (for later regret-minimization).
• Resolution: She stays in control but no longer confuses hope with strategy. Requirements: human final say, audit trail, live concept sync, override semantics.

Journey 3 — Sam, Jordan, and Chris (enterprise trio): Shared vision workshop

Personas: Sam (PM) owns outcomes; Jordan (design) owns experience; Chris (eng lead) owns feasibility. They need one shared methodology, not three siloed docs.

• Opening: They import or paste context (MVP: manual + one automated integration option). They enter enterprise mode: roles visible in the team room, each can steer their domain agent.
• Rising action: Multi-user vision capture and organize; filter session becomes a facilitated workshop with pillar cards and live concept updates. Jordan validates flows with Kinsley; Chris pressures estimates with Winston; Sam holds viability and release boundaries with John.
• Climax: They leave with aligned PRD slice, journey maps, refined design targets, motion scope, roadmap, and cost bands—ready for leadership or eng planning.
• Resolution: Enterprise eval lands: “This replaced a week of alignment meetings.”

Failure / recovery: Conflict between design and eng is surfaced, not hidden—orchestrator presents trade-off briefings. Permissions: who can approve overrides and ship gates.

Journey 4 — Dana (workspace admin): Seats, access, and integration

• Opening: Dana must add seats, assign roles (who can run filter vs. view-only), and connect one external system (e.g. Jira or Notion) for enterprise pilot.
• Rising action: Guided OAuth / API key flow (exact UX TBD), sync status, conflict surfacing (“Done in Jira but QA not green”—V2 depth; V1 may be lighter).
• Climax: The trio can work without Dana every day—access is stable and billing matches usage tiers.
• Resolution: Admin work is boring on purpose: fast, auditable, no mystery permissions.

Requirements hinted: RBAC, workspace settings, billing hooks, integration health surface, audit of who changed what.

Journey 5 — Chris (implementer): Story → AI coding tool → back to Quorum

• Opening: Sprint planning (Bob + Winston) produced stories with Kinsley design refs and Luca motion notes. Chris uses Cursor daily.
• Rising action: Chris opens a story file or export from Quorum, runs it in the coding tool with Jaymes-style constraints in context. He commits, runs tests; Quinn-driven QA stories validate acceptance criteria.
• Climax: Story marked done in Quorum; board reflects truth; Cipher runs before UAT; no critical security surprises at the end.
• Resolution: Quorum is the brain; the coding tool is the hands—handoff is low-friction and traceable.

Failure / recovery: If story is under-specified, Chris flags blocked with required fields surfaced; Quorum nudges Winston/Jaymes to enrich. If Cipher finds critical issues, loop to build is explicit.

Journey 6 — Support / “stuck user” recovery (solo or enterprise)

• Opening: A user stalls mid-pipeline (filter anxiety, unclear next step, or session timeout).
• Rising action: Resume prompts from save points; checkpoint copy explains what they already have (“You have organized vision + concept boards”). Optional short recap from agents.
• Climax: They re-enter at the right step without re-doing everything; optional human support ticket references session ID and artifact versions.
• Resolution: Drop-off from “overwhelm” decreases; support has visibility into last good state.

Requirements hinted: Serializable state, step resume, artifact versioning or snapshots (aligns with V2 branching vision; V1 minimum = clear checkpoints).

Journey Requirements Summary

Deferred personas (post-MVP)

Personas noted below are recognized as real users Quorum will eventually serve, but are not scoped for MVP. They shape forward-looking product decisions (see Epic 11 features) without producing their own MVP journeys.

• Content Strategist — In larger organizations and enterprise tiers, the person who drafts poll content is often distinct from the administrator who configures the vote and manages the workspace. They care about question clarity, phrasing consistency, accessibility of question text, and maintaining a shared voice across polls published by their org. Product features addressing their needs (MVP-scoped via Epic 11): poll template library, clarity/bias/accessibility checker, suggested rewordings, inline best-practice guidance. Future considerations (not MVP): distinct permission tier separating "content author" from "workspace admin", content review/approval workflow, shared template libraries scoped to a workspace or org. Revisit when enterprise tier demand materializes.

Innovation & Novel Patterns

BMAD project-types.csv (saas_b2b): Workflow automation; AI agents. Executive differentiators are also stated in Executive Summary § What Makes This Special; this section focuses on novelty vs. market, how to validate, and innovation risks.

Detected Innovation Areas

• Methodology as product architecture: The planning pipeline (capture → organize → three-pillar filter → artifacts → orchestrated build) is not a template bolt-on—it is the core runtime behavior competitors lack.
• Agents as the team, not a feature: Named, role-differentiated agents with backbone (including pushback on the user) and structural evaluation differences—not one model with five skins.
• Input-side ownership: Owning decision inputs (reasoning, evidence, filter outcomes) and generating pitch/PRD/roadmap/stories from one spine—versus tools that only manage ticket outputs.
• Staged design + motion: Concept in Figma Make early (with handoff prompt), refinement after journeys, motion on refined screens—reduces wasted polish and matches how real teams should sequence work.
• Brain vs hands split: Quorum orchestrates AI coding tools via rich stories; it does not compete as an IDE—novel division of labor for “full stack” product development.

Market Context & Competitive Landscape

• Adjacent tools (Jira, Productboard, Notion, Aha!, etc.) optimize tracking and communication after decisions; they do not run a cross-functional methodology with AI-as-team.
• AI coding tools optimize implementation; they do not own vision → filter → roadmap → security gate as a single product surface.
• Risk: Incumbents add “AI sidebars”; differentiation depends on depth of orchestration, artifact consistency, and trust (transparency, audit trail, agent distinguishability).

Validation Approach

• Qualitative: Solo founders report “better decisions” and team framing (NPS theme); enterprise pilots report alignment speed vs. meeting-only process.
• Quantitative: Time to validated MVP plan (<2 weeks target); filter completion correlation with shipped-feature satisfaction where measurable.
• Product metrics: Activation at organized vision / concept in Figma milestones; drop-off by step; story handoff success (blocked rate for under-specified stories).
• Technical evals: Agent distinguishability suite; output quality guardrails from day one (per vision notes).

Risk Mitigation

• Innovation too heavy to build: V1 narrows to synthesized disagreement (not full visible multi-agent debate), one coding-tool integration path, Figma Make via handoff (not full bidirectional sync).
• Trust collapse: Granular pillar transparency (sources, caveats, falsifiable claims); human override with audit; Cipher gate before ship.
• Cost / power users: Per-tenant usage tracking and pricing modeled on high session volumes (premortem).
• “Just ChatGPT” perception: Structured artifacts, pipeline checkpoints, and role-specific outputs—not a single thread.

SaaS B2B Specific Requirements

Derived from BMAD project-types.csv row saas_b2b — key questions: Multi-tenant? Permission model? Subscription tiers? Integrations? Compliance? Required sections: tenant_model, rbac_matrix, subscription_tiers, integration_list, compliance_reqs. Skipped for this type: CLI-first, mobile-native (web-first).

Project-Type Overview

Quorum is a multi-audience B2B SaaS platform: solo users behave as an enterprise-of-one tenant; enterprise customers use seats, roles, and optional tool integrations. The product is web-first, conversation- and artifact-centric (team room, boards, exports)—not a mobile-first or CLI-primary interface.

Technical Architecture Considerations

• Logical isolation: Every workspace’s artifacts (vision, designs, PRD, stories, audit trails) must be tenant-scoped at the data model and API layer; no cross-tenant reads without explicit system-admin break-glass (if ever).
• Session and AI usage: Per-tenant metering for agent sessions and model calls (premortem: power users 45–100+ sessions/month) to protect unit economics.
• Export surfaces: Story and spec exports for external AI coding tools must embed tenant and workspace context without leaking other tenants’ data.
• State for resume: Serializable pipeline state and checkpoints (journey 6) should be tenant-bound and version-stable for support.

Tenant model

• Workspace = primary tenant boundary (recommended): each subscription owns one or more workspaces; enterprise may map workspace ↔ product line or squad.
• Solo: Single user, single (or few) workspace(s)—same isolation rules as enterprise to keep one code path (“solo is enterprise-of-one”).
• Growth path: Multiple workspaces per org in later tiers without merging data across unrelated products.

RBAC matrix (baseline)

Enterprise “human leads AI” mode may map human specialists to delegate or approve subsets of agent proposals—exact matrix TBD in UX.

Subscription tiers

Plans are organized into two categories (matching primary personas) with two tiers each (4 plans total in V1). Naming uses "Team" rather than "Enterprise" — the V1 target persona is a small product trio (J3 Sam/Jordan/Chris), not a Fortune 500 IT buyer; "Enterprise" is reserved as a future tier within Team once SSO/SCIM/SOC2 land.

• Plan selection at sign-up: New users pick a category, then a tier, before creating credentials (FR48, FR49). The selected plan is stored on the workspace and is the source of truth for that workspace's feature limits and billing.
• Auto-promotion: A Solo workspace that issues its first invitation auto-promotes to a Team plan (FR50); the change is recorded in audit history (FR45). No manual "upgrade" action required for this transition.
• Metering transparency: In-product visibility into usage vs. plan limits to avoid surprise throttling.
• Future: A third Enterprise tier within the Team category will land when SSO/SCIM/SOC2 are real product capabilities; not V1.

Integration list

Compliance requirements

• Baseline SaaS: Privacy policy, data processing terms, subprocessor disclosure for model providers; GDPR-aligned export/delete requests for personal data in workspaces (implementation depth TBD).
• Security: Cipher-driven pre-ship audit; secrets handling; dependency scanning—product requirement, not optional flavor text.
• Audit: Filter overrides, ship approvals, and integration connects should be auditable for enterprise customers.
• Regulated verticals: Not V1 core — V2 domain agent marketplace (HIPAA, PCI, etc.) per vision notes; architecture should not preclude BAA/support later but does not commit V1 scope.

Implementation Considerations

• Not in scope for this project type row: Dedicated CLI product surface; mobile-first native apps (responsive web only).
• Web UX: Team room, accessibility baseline for conductor workflows (WCAG target to be set in UX step).
• On-call / reliability: Enterprise expectations for uptime and incident communication—targets to be set in NFR pass.
• Open decisions: Canonical story file schema; guided vs menu pipeline default; which one import (Jira vs Notion) ships in V1.

Project Scoping & Phased Development

MVP feature list is canonical in Product Scope § MVP; this section adds strategy, minimum journey coverage, and explicit deferrals.

MVP Strategy & Philosophy

MVP approach: Experience + learning MVP as an advanced prototype (product brief): prove methodology-as-architecture end-to-end for a solo conductor and demo credibly to enterprise. Users run the full planning spine (see YAML quorumPipeline / Product Scope) with one primary AI-coding integration; some edges stay manual in V1 (Figma link handoff, single PM import choice).

Resource (indicative): Product + design + full-stack eng; ML/ops for routing, metering, guardrails. Highest leverage: story schema, team room, filter transparency.

MVP Feature Set (Phase 1)

Journeys that must be covered in V1 (minimum):

• J1 — Solo happy path: Design-thinking → Figma prompt → concept → organize → filter → artifacts through pitch; save points.
• J5 — Implementer: Story export → coding tool → QA → Cipher → ship path.
• J2 — Filter edge: Disagreement, override, audit trail.
• J3 — Enterprise: Mode toggle + workshop slice (may be scripted demo if realtime collab slips).
• J4 — Admin: Seats, roles, one import, billing basics.
• J6 — Resume: Checkpoint “you left off here.”

Capabilities: Product Scope → MVP (agents, pipeline, team room, filter, artifacts, build orchestration, gates, tenancy). Not repeated here.

Explicit Phase 1 cuts / deferrals (unless risk tests fail):

• Visible multi-agent debate, dynamic sub-agents, full feedback loop productization, Hospital/Morgue, bi-directional Jira at scale, deep Figma sync, SSO (may trail GA), animated prototypes beyond specs.

Post-MVP Features

Phase 2 (growth):

• Full feedback loop (collection, digest, ceremony, re-filter firewall).
• Hospital / Morgue / Decomposer lifecycle.
• JIRA/Linear bi-directional workflows; confidence × complexity grid in ceremonies.
• SSO and richer enterprise admin.
• Deeper Figma Make ↔ Quorum integration.
• Product snapshots / branching.
• Optional visible agent debate; sub-agent scaling.

Phase 3 (expansion):

• Domain agent marketplace (regulated industries).
• Full brownfield automation (codebase ingest, multi-import, DS parse, velocity calibration).
• Multi-tool coding orchestration with API progress sync.
• Third-party research partnerships.

Risk Mitigation Strategy

Technical risks: Narrow V1 contracts (one coding tool, one import, handoff-first Figma); canonical artifact schema decided early; quality guardrails and distinguishability evals to avoid “five ChatGPTs”; power-user metering from day one.

Market risks: 10-minute activation path to organized vision + concept; solo-first UX with enterprise demo toggle; pilot >20% demo-to-pilot tracked; qualitative “my team” signal.

Resource risks: If build bandwidth is tight, preserve filter + story export + team room; thin enterprise collab to demo quality; postpone SSO and second integrations; keep Cipher non-negotiable for any “ship” narrative.

The Three-Pillar Framework

Desirability, Feasibility, Viability is the spine of how Quorum thinks about every product idea. It's older than Quorum — IDEO, design thinking literature, business-model canvases all use the three lenses — but most tools that reference the framework treat it as a slide title, not a working method. Quorum operationalizes it. Every feature, every release decision, every story export descends from a structured evaluation across all three lenses, with named agents who own each one, defined research methods that run under each, and concrete artifacts that come out the other side.

The framework is a process discipline, not a checklist. A pillar isn't "filled in" by a one-line answer. It's earned by running the right methods, capturing the evidence, and letting the agents who own that lens push back on weak conclusions. The gates that come after (next section) only fire on outputs the framework actually produced.

Why this is the differentiator

Most tools manage the outputs of decisions. Tickets. Roadmaps. Specs. Quorum manages the inputs — the thinking, the evidence, the structured argument that produces a defensible go/no-go on every scope question. The three-pillar framework is how that thinking happens. Without it, Quorum is just another tracker.

A user finishing the framework should be able to answer, for any feature in their backlog: Why is this in scope? — and the answer is "Mary's persona research validates the JTBD; Winston's architecture confirms the build path with no blockers; John's market sizing supports the unit economics at the target price." Three lenses, three owners, three artifacts. No hand-waving.

Pillar 1 — Desirability

The lens: Do target users want this enough to change behavior, adopt a workflow, or pay for it? Desirability isn't "is this a good idea" — it's "is there evidence the user feels the need this addresses, and is that evidence strong enough to commit engineering hours to."

Lead agent: Mary (Strategic Business Analyst). Mary owns the desirability lens end-to-end. She runs the research, frames the personas, pressure-tests claims, and signs off on whether evidence is strong enough to clear the gate.

Supporting agents:

• Quentin (Content Strategist + UX research) — voice of customer, accessibility-as-desirability, copy that earns trust.
• John (Product Manager) — translates desirability findings into PRD requirements with measurable success criteria.
• Maya (Design Thinking Maestro) — facilitates empathy work and human-centered exercises when the team needs structured discovery.
• Carson (Brainstorming Specialist) — opens the solution space when desirability research surfaces a need with no obvious answer.
• Sophia (Master Storyteller) — converts persona research into the narrative spine of the pitch and case study.
• Freya (WDS Strategic UX Designer) — runs trigger mapping that connects business goals to user psychology, and scenario design that turns triggers into structured micro-steps.

Process — methods that run under desirability:

• User interviews and synthesis (Mary) — qualitative discovery, voice-of-customer extraction, theme clustering.
• Persona development (Mary, Quentin) — JTBD-framed personas with cited evidence per claim, not invented archetypes.
• Empathy mapping (Maya) — what the user says, thinks, does, feels — structured around the problem space.
• Brainstorming sessions (Carson) — 40+ ideation techniques (SCAMPER, What If, Six Thinking Hats, Worst Possible Idea, etc.) when the team needs divergent thinking before convergent.
• Design-thinking workshops (Maya) — empathize → define → ideate → prototype → test, run as guided sessions with artifacts at each step.
• Trigger mapping (Freya) — structured workshop that maps business goals down to the user-psychology triggers that drive adoption.
• Scenario design (Freya) — micro-step user-flow outlines that test whether the proposed experience earns its desirability claim.
• Moments-that-matter inventory (Quentin) — peak/valley/transition mapping across the product lifecycle, identifying where the user emotionally invests or disengages.
• Voice-of-customer synthesis (Quentin) — turns interview transcripts and feedback into a voice & tone guide that downstream copy must hold to.
• Storytelling-framework analysis (Sophia) — runs the persona's experience through Hero's Journey / SCQA / Pixar / before-and-after frames to surface narrative gaps.

Artifacts that come out:

• personas.md — JTBD-grounded personas with cited evidence per behavioral claim.
• moments-that-matter.md — full lifecycle inventory of peak / valley / transition moments with copy hooks per moment.
• user-flow-map.md — mermaid + prose map of every primary flow the desirability research validated.
• voice-tone-guide.md — the project's voice spine, derived from research, that all user-facing copy traces to.
• trigger-map.md — business goal → user psychology trigger mapping (when WDS workflows run).
• scenarios.md — micro-step scenario outlines per primary flow.
• case-study.md — the narrative shape of the project for portfolio and pitch use.
• research-synthesis.md — interview themes, observation logs, hypothesis tests.

Desirability gate is cleared when: a feature ties to a named persona's JTBD; cited evidence exists for the underlying need (research, prior-art pattern, user statement, measured behavior); Mary's confidence is ≥ moderate; Quentin has signed off that the surface has no voice or accessibility blocker. See the next section for full gate mechanics.

Pillar 2 — Feasibility

The lens: Can the team build, operate, ship, and maintain this with current or achievable capabilities, within the planned horizon, against the stack and integrations on the table? Feasibility isn't "is this possible in principle" — it's "is the path identified, are the blockers resolved, is the operational load survivable."

Lead agent: Winston (System Architect). Winston owns the feasibility lens. He produces the architecture decision records, identifies the build path, names the blockers, and signs off on whether the team can actually ship what desirability says users want.

Supporting agents:

• Damien (Backend Developer) — databases, APIs, auth, deployment; weighs in whenever a feature crosses the server line.
• Jaymes (Frontend Developer) — UI implementability; how a design translates to real components against the stack.
• Murat (Test Architect) — test strategy, NFR feasibility assessment, CI/quality-gate scaffolding.
• Cipher (Offensive Security) — threat modeling and security-feasibility assessment; surfaces "you can't ship this without X" early.
• Kinsley (UX Designer + Design Systems) — design-system feasibility; whether a proposed pattern fits the token / component inventory or requires net-new work.
• Quinn (QA Engineer) — test automation feasibility; what coverage is achievable given the surface area.
• Amelia (Senior Software Engineer) — story-level feasibility; whether the spec is implementable as written or needs decomposition.

Process — methods that run under feasibility:

• Architecture decision records (Winston) — explicit decisions with alternatives considered, trade-offs named, and consequences surfaced; not retrospective documentation.
• Technical research (Winston + Mary) — bounded investigations into stack, library, integration, or pattern viability with a written conclusion.
• Component inventory and design-system audit (Kinsley, Jaymes) — what exists vs what would have to be built; the gap is the feasibility cost.
• Test design (Murat) — system-level or epic-level test strategy that identifies coverage gaps and infrastructure needs before code is written.
• Acceptance test design / ATDD (Murat) — failing acceptance tests written first; if they can't be written, the requirement isn't feasible as specified.
• Test framework scaffolding (Murat) — Playwright/Cypress initialization with the conventions and helpers the team actually needs.
• NFR assessment (Murat) — performance, security, reliability, scalability gates evaluated against the proposed solution.
• Traceability matrix (Murat) — every requirement → every test → every artifact, surfacing coverage gaps as a feasibility flag.
• Security threat modeling (Cipher) — STRIDE / abuse-case analysis with mitigations named, ranked, and gated.
• Code review and adversarial review (Cipher + Murat + Amelia) — multi-layer review that hunts edge cases, blind spots, and acceptance gaps.
• Implementation-readiness check (Winston + John) — validates PRD, UX, architecture, and epics are complete enough to dev against.

Artifacts that come out:

• architecture.md — decisions, alternatives, consequences; not a diagram dump.
• tech-stack.md — stack inventory with rationale per choice.
• technical-research-*.md — bounded research reports with conclusions.
• test-plan.md / test-design.md — system or epic-level test strategy.
• nfr-assessment.md — non-functional gate verdict per requirement.
• traceability-matrix.md — requirements ↔ tests ↔ artifacts coverage.
• security-assessment.md — threat model, mitigations, gate verdicts.
• design-system.md — token + component inventory with usage rules.
• implementation-readiness-report.md — go/no-go on dev start.

Feasibility gate is cleared when: an implementation path is identified (stack, skills, integration surface); no unresolved blockers remain; operational cost (compute, support, complexity) fits the envelope for the target release; Winston's confidence is ≥ moderate; Cipher has cleared the security floor.

Pillar 3 — Viability

The lens: Should the business invest? Does this fit strategy, economics, compliance, timing, and the competitive frame? Viability isn't "could this make money" — it's "given everything else this team could be doing, is THIS the right bet right now."

Lead agent: John (Product Manager). John owns the viability lens. He produces the PRD, defines the success criteria, weighs the strategic fit, and signs off on whether the business case clears the bar.

Supporting agents:

• Victor (Disruptive Innovation Oracle) — strategic positioning, business model innovation, competitive disruption analysis.
• Mary (Strategic Business Analyst) — market research, competitive landscape, sizing data that John's economics depend on.
• Sophia (Master Storyteller) — pitch narrative, investor / executive framing.
• Caravaggio (Presentation Master) — visual communication of the business case in slide decks and pitch decks.
• Bob (Scrum Master) — sprint-level viability; whether the proposed scope fits the planning horizon and team capacity.
• Atticus (Legal SME) — regulatory, compliance, UPL, and ethics checks on viability claims that touch regulated surfaces.

Process — methods that run under viability:

• Market research (Mary) — sizing, segmentation, growth trends, addressable-market analysis with cited sources.
• Competitive landscape research (Mary) — direct and adjacent competitors mapped on positioning, capabilities, pricing, and weaknesses.
• Domain research (Mary) — vertical or industry-specific deep-dives when the project sits in a regulated or specialized space.
• Innovation strategy / disruption mapping (Victor) — disruptor analysis, jobs-to-be-done at market level, blue-ocean canvases.
• Business model architecture (Victor + John) — pricing tiers, monetization mechanics, unit economics modeling.
• PRD authoring (John) — the binding document; success criteria, FR/NFR contract, scope, traceability.
• PRD validation (John) — explicit pass against quality bars (completeness, coherence, testability, alignment).
• Storytelling for pitch (Sophia) — narrative shape of the investor / executive deck; the "why now, why us, why this" frame.
• Pitch deck construction (Caravaggio) — visual translation of the business case into 10-15 high-density slides.
• Sprint planning (Bob) — translates viability claims into a release rhythm; surfaces capacity / horizon mismatches.
• Compliance and ethics review (Atticus) — regulatory blockers, UPL exposure, accessibility-as-legal-floor.
• Critical / adversarial review (any agent) — cynical review pass that argues the viability claim down; if the claim survives, it passes the gate.

Artifacts that come out:

• prd.md — the binding requirements document; this PRD itself.
• market-research.md — sized market with cited sources.
• competitive-landscape-research.md — competitor map with positioning and gap analysis.
• domain-research.md — vertical-specific deep dives.
• methodology-comparison-research.md — how Quorum's approach compares to alternatives.
• innovation-strategy.md — disruption thesis and business-model architecture.
• pitch-deck.md (or .pdf) — investor / executive deck.
• executive-summary.pdf — short-form viability pitch for stakeholders.
• case-study.md — outcome narrative for portfolio and sales.
• sprint-status.yaml — release rhythm and capacity reality check.
• release-notes-format.md — viability narrative continued post-ship.

Viability gate is cleared when: the feature aligns with stated business model and positioning; ROI is positive or defensibly so for the intended horizon; no compliance / legal / timing blockers remain; John's confidence is ≥ moderate; Atticus has cleared regulatory exposure where applicable.

How the three pillars work together

The pillars are independent gates — a feature must clear all three to enter release allocation. They're also mutually informative:

• Desirability without feasibility is wishful thinking. Mary's research can prove users desperately want a feature, but if Winston identifies an unresolved blocker, the gate fails. The user-want signal still matters — it goes into the V2 / V3 hospital for re-evaluation when the blocker is resolved.
• Feasibility without desirability is engineering theater. Winston can confirm a feature is buildable in three days, but if Mary's persona research surfaces no real need, the gate fails. The build path is preserved for if a desirability case emerges later.
• Viability without desirability or feasibility is strategy fiction. John can argue a feature aligns with the business model, but if no user wants it (Mary fails) or no path exists to ship it (Winston fails), the strategic argument doesn't compensate. Override requires explicit rationale and is audit-tracked (FR45).

The framework's strength is that it distributes the argument across three orthogonal owners. A feature that should die dies because at least one of three substantively different evaluations finds it wanting. A feature that should live earns its place by surviving all three. The user can override any verdict — it's their product — but every override is recorded so future readers see where the human-over-agent call was made deliberately.

How this maps to the rest of the PRD

• Filter mechanics — see the next section ("Three-Pillar Checkpoint Gates") for pass / fail / needs-revisit logic.
• Functional requirements — FR21–FR25d cover running the evaluation, surfacing evidence, disputing conclusions, accepting or overriding verdicts, and audit trail.
• User journeys — J2 covers the "filter edge" path where disagreement, override, and audit happen.
• Success criteria — "Decision quality (solo)" and "Scope discipline" are direct measurements of the framework working.
• MVP scope — the framework is non-negotiable in V1. Shipping Quorum without the three-pillar pipeline operating end-to-end invalidates the product thesis (see Product Scope § MVP, vision capture spine).

Three-Pillar Checkpoint Gates

The three pillars — Desirability, Feasibility, Viability — are not just analysis lenses. They are checkpoint gates. A feature cannot advance out of the filter into a release allocation (MVP / V2 / V3) until it has a terminal verdict on all three. Rankings come from the gate results; the gates themselves decide go / no-go.

Why gates, not just rankings. A ranking tells you what's best relative to peers. A gate tells you whether a feature is viable on its own terms. Features that score well against each other can still all fail a viability gate together (e.g. all elegant, all unbuildable). Quorum insists on both — per-pillar verdicts first, then rankings of what passed.

Gate definitions

Desirability gate — Do target users want this enough to change their behavior, adopt a workflow, or pay?

• Passes when: the feature ties to a named persona's job-to-be-done; there is cited evidence of the underlying need (research, prior-art pattern, user statement, or measured behavior); and agent confidence is ≥ moderate.
• Fails when: the feature answers no clear user need, relies on speculative demand, or agents return low confidence with no plan to raise it.
• Needs revisit when: evidence is thin but not absent; the user has disputed the conclusion and the agents are still researching.

Feasibility gate — Can the team build, operate, and maintain this with current or achievable capabilities within the planned horizon?

• Passes when: an implementation path is identified (stack, skills, integration surface); no unresolved blockers remain (tech, team, dependency); operational cost (compute, support, complexity) fits the envelope for the target release; and confidence is ≥ moderate.
• Fails when: an unresolved blocker exists, the estimated effort exceeds the release horizon, or the operational load is incompatible with the staffing model.
• Needs revisit when: a blocker has a plausible mitigation still being explored, or the effort estimate has wide variance the user wants narrowed.

Viability gate — Should the business invest — does this fit strategy, economics, compliance, and timing?

• Passes when: the feature aligns with stated business model and positioning; ROI is positive or defensibly so for the intended horizon; no compliance / legal / timing blockers remain; and confidence is ≥ moderate.
• Fails when: the feature undermines positioning or unit economics, introduces compliance risk with no mitigation, or its competitive timing is materially wrong.
• Needs revisit when: strategy is in flux, ROI depends on an unresolved upstream assumption, or compliance is pending external clarification.

Gate exit criteria

A feature is considered gate-cleared when all three gates have a terminal verdict: pass, fail, or user-override-with-audit. Only gate-cleared features enter the release allocation output (FR25a).

• All three pass → feature enters the ranked-for-allocation pool.
• Any one fails → feature is excluded from allocation unless the user overrides with rationale (FR25, FR25d).
• Any one sits in needs revisit → feature blocks on that gate; it cannot exit the filter until the gate resolves.

Override and audit

Users can override any gate verdict — it's their product, not the agents'. But every override requires captured rationale and is surfaced, not buried:

• Override rationale is stored append-only alongside the original verdict (FR45 audit trail).
• Downstream artifacts (release allocation, PRD narrative, sprint stories) display an override marker against the feature so future readers see the human-over-agent call was made deliberately.
• Overrides never rewrite the original verdict — both stand on the record.

How this maps to functional requirements

• FR21, FR22 — running the pillar evaluation and seeing evidence
• FR23 — disputing a conclusion and keeping a feature in needs revisit while analysis deepens
• FR25 — accepting or overriding a verdict
• FR25a — release allocation output that consumes only gate-cleared features
• FR25b, FR25c, FR25d — explicit gate verdicts, gate-exit enforcement, and override audit (defined below under Organization & three-pillar filter)

Functional Requirements

Capability contract: UX, architecture, and delivery trace to FR1–FR50. Wording is implementation-agnostic (what actors can do, not how). Measurable quality is in Non-Functional Requirements below.

Workspace & access

• FR1: User can create and name a workspace for a product effort.
• FR2: User can authenticate and be associated with one or more workspaces.
• FR2a: User can register a new account by selecting a plan and providing credentials, without requiring an invitation.
• FR3: Workspace owner can invite members and assign roles with differentiated permissions.
• FR4: User can perform only actions permitted by their role within a workspace.
• FR5: System enforces isolation of data and artifacts between workspaces.
• FR6: User can leave or be removed from a workspace according to role rules.

Plan selection & workspace lifecycle

• FR48: System can display subscription plans for selection by category and tier prior to authentication.
• FR49: Plan selection during sign-up creates a workspace associated with the chosen plan; the plan is the source of truth for that workspace's feature limits and billing terms.
• FR50: Workspace plan can be changed by lifecycle events (e.g., first invitation auto-promotes a Solo workspace to a Team plan) with the change recorded in audit history (FR45).

Team room & human-in-the-loop decisions

• FR7: User can interact with the AI product team through a conversational team room.
• FR8: User can see which agent personas are active for the current pipeline step.
• FR9: User can open and navigate workspace artifacts alongside the conversation.
• FR10: Agents can surface conflicting assessments and structured trade-offs for user resolution.
• FR11: User can request clarification on agent reasoning during pipeline steps.
• FR12: Product can record user decisions on contested recommendations.
• FR13: User can resume work from a saved pipeline checkpoint.

Vision ideation & concept design

• FR14: User can participate in a structured ideation session led by the full team that runs an 8-category discovery framework (Core Idea, Features & Functionality, Look & Feel, Visual Identity, User & Audience, Reference Examples, Copy & Voice, Constraints) — each question paired with a conversational prompt and concrete examples — and produces four structured deliverables: (1) Problem & Solution Framing, (2) Features & Capabilities, (3) Master Design Prompt, (4) per-Screen Prompts.
• FR15: User can receive a documented handoff suitable for external concept-design execution — delivered as a tool-agnostic design prompt (works in any generative design tool: Figma Make, Claude, v0, Midjourney, etc.) and downloadable in the user's choice of formats (Doc, HTML, and/or PDF, selectable via checkbox/dropdown).
• FR16: User can align on directional aesthetics for early concepts without establishing a full design system.
• FR17: User can associate initial concept visuals with features and flows in the workspace.
• FR18: User can update concept visual references as the vision evolves.
• FR46: After ideation, the user can review a series of generated concept variations (scroll/browse), select one (or retain multiple) to establish the baseline for later steps, refine a selected concept with natural-language direction and/or iteration in a separate browser tab or window (e.g. Figma Make), and carry results back into the workspace—link, attach, or import—without losing place in Quorum. Quorum remains the conductor; external tabs are scratch space. Organize and three-pillar phases consume the resulting initial designs, concept labels, and core needs from ideation.

Organization & three-pillar filter

• FR19: System can propose a full product sitemap (every section mapped with per-section contents, capabilities, data flows, and relationships to adjacent sections) alongside themed groupings of features with dependencies for user confirmation.
• FR20: User can edit or confirm organized groupings before analysis.
• FR21: User can run structured three-pillar evaluation on feature groups, choosing between two modes upfront: (A) Collaborate — work alongside the AI agents, discuss each evaluation, argue back, and make calls together in real-time; (B) Let AI handle it — agents perform the full analysis independently and user reviews the finished output, overriding where needed.
• FR22: User can view evidence, sources, and rationale tied to pillar conclusions.
• FR23: User can dispute pillar conclusions and receive further agent analysis.
• FR24: Concept representations can reflect additions, removals, and merges of scope driven by filter outcomes.
• FR25: User can finalize acceptance or override of pillar recommendations with rationale retained.
• FR25a: System can produce per-pillar rankings (features ranked within Desirability, Feasibility, Viability individually), an overall combined ranking across all three pillars, and release allocation recommendations (MVP / V2 / V3 / deferred) with reasoning for each allocation.
• FR25b: Each pillar evaluation emits a terminal verdict (pass / fail / needs revisit) against documented pass criteria — not only a ranking score. Verdict, confidence level, and the evidence that supported it are stored with the feature.
• FR25c: Features cannot advance to release allocation (FR25a) unless all three pillar gates have a terminal verdict (pass, fail, or user-override-with-audit). Features sitting in needs revisit block on that gate and are held in the filter until the gate resolves.
• FR25d: User override of a failed or contested gate verdict requires rationale capture and is marked on downstream artifacts (release allocation output, PRD narrative, sprint stories). Original verdict and override both stand on the audit record; the override does not rewrite the underlying evaluation.

Planning artifacts & traceability

• FR26: System can produce a requirements document from the post-filter vision state and deliver it as HTML and as Word (.docx), generated from the same source so exports stay consistent.
• FR27: System can produce journey maps that reflect agreed user and customer flows.
• FR28: User can trigger a refinement pass that (a) updates journey maps based on all pipeline findings since they were first drafted, (b) refreshes all screens and their content against the current truth, (c) increases design fidelity and establishes the design-system structure (tokens + components), and (d) produces a fix-up design prompt for any visual tool that references previous concept designs and updates everything — plus Doc + HTML exports for all contextual material (token inventory, design system plan, screen-by-screen specs, updated journey maps).
• FR29: System can capture motion and interaction intent specifications after refined design, delivered in text and HTML formats — per screen, per transition, per interactive element — with reduced-motion alternatives as a parallel spec.
• FR30: System can produce roadmap and cost estimates informed by agreed scope and motion.
• FR31: System can produce audience-appropriate pitch or executive narrative outputs — generated, then user refines both design and content (not one-shot), then exported as PDF, DOC, and HTML.
• FR32: User can navigate between artifacts that share a consistent underlying scope state.

Sprint planning & implementation handoff

• FR33: System can generate epics and stories with acceptance criteria from approved scope.
• FR34: Stories can carry references to design and motion artifacts when applicable.
• FR35: User can export stories in a form consumable by external AI-assisted implementation tools.
• FR36: User can record implementation progress against stories in the workspace.
• FR37: System can include backend-related planning when the product definition requires it.

Quality, security & user acceptance

• FR38: User can execute or trigger QA flows tied to story acceptance criteria.
• FR39: System can require a security review pass after implementation and before release declaration.
• FR40: User can perform acceptance review comparing delivered work to design and motion intent.
• FR41: User can mark a release blocked or unblocked according to security and quality policy.

Administration, usage & integrations

• FR42: Administrator can configure subscription tier limits and seat allocation for a workspace.
• FR43: Administrator can connect an external work-tracking or knowledge import according to V1 integration policy.
• FR44: User can view usage relative to subscription limits.
• FR45: System can record auditable history of security-sensitive configuration and override actions.

Portfolio documentation and case study

• FR47: System can produce a Portfolio Document summarizing the end-to-end process the user followed (from initial idea through ship and feedback) — covering original problem/hypothesis, discovery insights, concept evolution (before/after at each stage), design decisions and rationale, three-pillar highlights, architecture choices, build process, QA/security findings, final screenshots, post-ship metrics (when available), and lessons learned — delivered as HTML, PDF, and Doc. Output shows the evolution, not just the result, and is suitable for stakeholder-retrospective or long-form internal record use.
• FR60: System can produce a Case Study as a distinct artifact from the Portfolio Document. Case Study is shorter and more polished than the Portfolio Document, optimized for external sharing with portfolio reviewers, prospective clients, or a public audience. Same data sources as the Portfolio Document (workspace audit trail, filter decisions, rationale log, artifact highlights, post-ship metrics), different selection and tone.
• FR61: At pipeline step 13 (post-ship), system prompts the user to generate the Portfolio Document, the Case Study, or both. The prompt offers tone and length options: Portfolio reviewer (short, polished, externally shareable), Internal retrospective (longer, candid, for the team), or Public case study (mid-length, shareable on a user's own channels).
• FR62: Case Study and Portfolio Document outputs apply the user's project visual identity — color palette, typography, logo — so every generated artifact looks like it belongs to the product the user built. Quorum's own meta case study uses Quorum's dark-space cyan aesthetic as a worked example.
• FR63: User can publish the Case Study to a personal portfolio endpoint: a user-owned URL, a connected portfolio website (v1 integration list TBD), or a shareable live link hosted by Quorum. Published case studies keep a canonical URL and can be updated as the product evolves post-ship.

Desktop distribution

Introduced by Epic 10 (macOS wrapper). See epics.md and adrs/adr-001-macos-wrapper-platform.md for platform rationale (Tauri + thin wrapper).

• FR51: User can download and install a signed, notarized macOS application (Quorum.app) from quorum.app/download.
• FR52: Quorum.app presents the full Quorum web experience in a native macOS window with proper dock and menubar presence (thin-wrapper scope — native menus and offline mode deferred to future iterations).
• FR53: Quorum.app checks for and applies updates on launch via a signed update manifest; unsigned or tampered manifests SHALL be rejected.
• FR54: System produces macOS distribution artifacts via automated CI — signed + notarized .dmg on tagged release — with no manual signing or notarization steps required.
• FR55: Quorum.app passes security review covering Apple entitlements (minimum-necessary), hardened runtime enablement, and network egress posture (all outbound hosts Quorum-owned or documented) before each public release.

Question crafting & content quality

Introduced by Epic 11. Accessibility-aware by default per Quorum's cross-cutting accessibility posture (see NFR-A section).

• FR56: User can browse and apply a library of WCAG 2.2 AA compliant poll templates categorized by vote type (Yes/No, Ranked Choice, Approval Voting, Sentiment, Multiple Choice, Free Response).
• FR57: System analyzes user-drafted poll questions in near-real time (debounced under 500 ms) and flags clarity, bias, and accessibility issues inline without blocking — leading phrasing, jargon, reading-level exceedance, ambiguous options, missing alt text on attached images.
• FR58: System offers plain-language alternative phrasings for flagged poll questions, preserving the original question's intent and answer options; suggestions render within 3 seconds.
• FR59: System surfaces contextual best-practice guidance and accessibility tips during poll drafting (non-blocking, dismissible, full library accessible on demand).

Non-Functional Requirements

NFRs define how well the system must perform. Only categories that matter for Quorum are included; targets should be refined into SLOs during architecture and ops planning.

Performance

• NFR-P1 (interactive UX): Primary user interactions in the team room and artifact sidebar (load panel, switch step, open artifact) SHALL achieve sub-second perceived response for cached reads under normal load; any operation exceeding 2 seconds P95 SHALL show explicit progress or streaming feedback.
• NFR-P2 (agent turns): Multi-step agent workflows SHALL surface incremental progress (partial summaries, streaming, or step labels) so users are not left >10 seconds without feedback during long model calls.
• NFR-P3 (heavy jobs): Full three-pillar analysis, large organize passes, and bulk exports MAY run as async jobs with durable status and resumability; the UI SHALL communicate queued / running / failed states.
• NFR-P4 (exports): PRD HTML and Word generation for typical workspace sizes SHALL complete within a documented upper bound (to be set per tier) or degrade gracefully with user messaging.

Security & privacy

• NFR-S1 (isolation): Workspace data SHALL be logically isolated; cross-tenant access MUST be impossible through normal APIs (enforced at authorization + data layer).
• NFR-S2 (transport & storage): Traffic SHALL use TLS in production; sensitive configuration (API keys, integration tokens) SHALL not appear in client-visible logs or exports by default.
• NFR-S3 (authN/Z): Authentication and session handling SHALL follow industry baseline practices (secure cookies or tokens, rotation, lockout policies TBD); authorization MUST align with RBAC in FR3–FR4.
• NFR-S4 (Cipher alignment): Security audit findings (FR39–FR41) SHALL map to severity, remediation state, and block-ship rules consistent with product policy.
• NFR-S5 (privacy): The product SHALL support tenant data export and deletion requests for personal data held in workspaces to a GDPR-aligned baseline (exact DPA and subprocessors documented commercially).
• NFR-S6 (audit): Security-sensitive actions (FR45, FR43, overrides) SHALL be append-only auditable with actor, timestamp, and workspace context.

Scalability & reliability

• NFR-R1 (multi-tenant growth): Architecture SHALL support horizontal scaling of stateless app tiers and partitioned persistence so new tenants do not require manual resharding for V1–V2 scale targets.
• NFR-R2 (concurrency): Multiple users in one enterprise workspace SHALL be able to work concurrently without silent data loss; conflicts SHALL be detected and surfaced (merge, refresh, or lock—UX TBD).
• NFR-R3 (usage metering): Per-tenant session and token usage (premortem power users) SHALL be metered accurately for billing and fairness.
• NFR-R4 (availability): A target uptime SLO SHALL be defined pre-GA (e.g. 99.x% excluding planned maintenance); incident communication expectations SHALL be documented for enterprise.

Accessibility

Quorum's accessibility posture applies cross-cutting to every epic. Individual stories embed accessibility-specific acceptance criteria (see NFR-A3 below); this subsection captures the product-wide commitments, target compliance level, and ownership map across agent roles.

Target compliance level: WCAG 2.2 Level AA — minimum shippable bar, not an aspiration. Stories that cannot meet AA at ship time MUST document the gap and remediation plan before shipping.

Why this matters for Quorum specifically: Quorum sits in civic-adjacent territory (voting, governance, decision workflows). Public-sector, university, and nonprofit buyers routinely require VPATs or equivalent accessibility disclosures as a procurement gate. Accessibility is a market-access commitment, not just an ethical one.

• NFR-A1: The web application SHALL conform to WCAG 2.2 Level AA for all user-facing flows (team room, workspace navigation, poll drafting, voting, results, settings, onboarding) within V1 scope — or with documented phased remediation plans dated before GA for any gaps.
• NFR-A2: Motion and animation outputs SHALL respect prefers-reduced-motion preferences; Luca's motion specs include non-animated alternatives by default.
• NFR-A3 (cross-cutting AC requirement): Every shipped story SHALL include at least one accessibility-specific acceptance criterion (e.g., keyboard navigation verified, screen-reader sanity-checked, reading level confirmed, alt text present). Stories without this AC MUST be rejected in sprint planning review.
• NFR-A4 (content reading level): User-facing copy SHALL target grade 9 reading level or below (Flesch-Kincaid or equivalent) unless a documented domain requirement makes this impractical (e.g., legal consent language).
• NFR-A5 (accessibility statement): A public accessibility statement SHALL be published at quorum.app/accessibility listing current compliance target, known gaps, remediation timeline, and a contact for reporting issues.
• NFR-A6 (VPAT readiness): The product SHALL be prepared to produce a VPAT (Voluntary Product Accessibility Template) on request for enterprise procurement.
• NFR-A7 (regression discipline): Accessibility regressions caught in QA or post-ship SHALL be logged with severity and remediation timeline consistent with the security-severity ladder (NFR-S4).

Ownership map — which agent owns which slice of WCAG:

Path to a standalone Epic 12: If an enterprise customer demands a formal VPAT with remediation commitments or a third-party audit with blocking findings, the commitments in this section can be promoted to a dedicated Epic 12 — Accessibility program with its own stories (formal audit, remediation backlog, published statement with version history). Not scoped for MVP — embedded as cross-cutting requirements instead.

Integration & interoperability

• NFR-I1 (story handoff): Exported story artifacts SHALL validate against the published schema version and include version metadata so external tools can detect incompatibility.
• NFR-I2 (external APIs): Integrations (e.g. Jira/Notion) SHALL handle rate limits, timeouts, and partial failure with user-visible status and retry-safe behavior where idempotent.
• NFR-I3 (Figma handoff): Figma Make link/export flows SHALL preserve stable references (URL + workspace association) so concept drift is traceable.

Observability & operations

• NFR-O1: Production SHALL emit structured logs and metrics sufficient to debug tenant-specific issues without exposing other tenants’ content.
• NFR-O2: Critical background jobs SHALL support alerting on failure rates and queue backlog.

---
stepsCompleted: ['step-01-init', 'step-02-discovery', 'step-02c-executive-summary', 'step-03-success', 'step-04-journeys', 'step-05-domain', 'step-06-innovation', 'step-07-project-type', 'step-08-scoping', 'step-09-functional', 'step-10-nonfunctional', 'step-11-polish', 'step-12-complete']
currentStep: 'complete'
currentStepStatus: 'complete'
lastSaved: '2026-04-23'
recentChanges:
  - date: '2026-04-23'
    summary: >
      Added **Three-Pillar Checkpoint Gates** top-level section with per-pillar pass criteria,
      exit rules, and override/audit semantics. Added FR25b (terminal verdicts), FR25c
      (gate-cleared required for allocation), FR25d (override audit with downstream markers).
      Traceability map updated. Paired with Epic 4 Story 4.7 and moments-that-matter v0.4.
sessionCheckpoint:
  summary: >
    BMAD create-prd workflow COMPLETE for Quorum. Body: conventions, traceability map, executive
    summary, classification, success, scope, journeys, innovation, SaaS B2B, scoping, FR1–FR50, NFRs.
    Polish: deduped scoping vs scope, cross-links, FR/NFR pointer fix. **2026-04-23 addition:**
    Three-Pillar Checkpoint Gates section + FR25b–FR25d (gate verdicts, exit criteria, override audit).
    Regenerate HTML/DOCX via _gen_prd_exports.py.
  prdWorkflow: 'COMPLETE. Optional: bmad-check-implementation-readiness; architecture; UX; epics.'
  elicitation: 'Six methods complete in 2b: Focus Group, War Room, First Principles, Shark Tank, Pre-mortem, SCAMPER.'
  partyModeLastSession: 'Sanity check round (2b) — Winston/Quinn/Cipher/Jaymes/John: screen state SSOT, story packaging, QA/security loops, Jaymes+Luca handoff, Cipher scope, guided vs menu default.'
  agentsInitialized:
    - 'Damien: sanctum at _bmad/memory/agent-damien (First Breath done in prior session)'
    - 'Jaymes: sanctum at _bmad/memory/agent-jaymes (First Breath — user woke agent, hybrid/mode TBD)'
  keyArtifacts:
    - '_bmad-output/planning-artifacts/prd.md (source of truth for workflow + visionDiscovery + quorumPipeline + buildArchitecture + quorumAgentRoster)'
    - '_bmad-output/planning-artifacts/product-brief-quorum.md'
    - '_bmad-output/planning-artifacts/product-brief-quorum-distillate.md'
    - '_bmad-output/planning-artifacts/research/*.md'
    - '_bmad-output/planning-artifacts/quorum-prd-executive-summary.pdf (export of Executive Summary)'
    - '_bmad-output/planning-artifacts/quorum-prd.html / .docx (body-only exports)'
    - '_bmad-output/planning-artifacts/quorum-prd-full.html / .docx (body + YAML appendix)'
    - '_bmad-output/planning-artifacts/_gen_prd_exports.py (regenerate all exports)'
    - '_bmad-output/planning-artifacts/quorum-pipeline-walkthrough.md (source of truth for pipeline **experience** design — complements quorumPipeline YAML structural definition)'
    - '_bmad-output/planning-artifacts/sprint-change-proposal-2026-04-14.md (walkthrough alignment change log)'
  optionalFollowUps: 'Deep-dive canonical data model; story export schema; pipeline default (guided vs menu). PRD: HTML + Word (.docx) locked as export formats.'
resumeAction: >
  PRD workflow COMPLETE. Next: implementation-readiness check, architecture, UX, or epics (bmad-help).
  Regenerate quorum-prd*.html/docx after edits. Source: prd.md.
partyModeInsights:
  designMandatory: 'Two-phase design: (1) After idea discussion (step 1), mandatory concept alignment (2a) + initial concept visuals in Figma Make (2b) — no formal tokens/DS. (2) After PRD + journeys, mandatory refinement (5.25) — high-fidelity, tokens, design system — then motion (5.5).'
  motionPlacement: 'Motion at 5.5 — after journey maps **and** design refinement 5.25 (stable spatial targets), before roadmap. V2: tighter Figma Make ↔ Quorum integration.'
  designIteration: '**Concept** visuals update LIVE during three-pillar filter (step 3). High-fid + tokens + DS land at 5.25 after scope and journeys are anchored.'
  testingExpansion: 'Build: 10a orchestrated dev, 10b Quinn QA, 10c Cipher security audit, 10d UAT with User + Kinsley + Luca.'
  agentRename: 'Sally UX Designer → Kinsley Product Designer. Expanded scope: visual design, design systems, information architecture, brand alignment, responsive design, accessibility-first, design QA.'
  newAgent: 'Luca Motion Designer — owns transitions, micro-interactions, loading states, scroll behavior, animation specs. Activates at step 5.5 and 10d (UAT temporal review). Communication style: leads with feeling, backs with spec. Calm + passionate blend.'
  layeredArtifactModel: 'Screens are layered structured data long-term. Kinsley owns spatial layer; **designTokens** formalize at 5.25 (not at 2b). Luca owns temporal layer on **refined** spatial targets. Winston proposed architecture: Screen { layout, components, designTokens, transitions, microInteractions, loadingStates, reducedMotion }.'
  pitchDeckMotion: 'Pitch document at step 8 should include a Product Experience section — 2-3 slides with annotated motion specs. Signals execution-ready depth to investors.'
  motionDiff: 'Luca gets awareness diff after step 3 (concept churn). Primary motion input is **refined** designs post-5.25 plus journeys — avoids animating throwaway concept frames.'
  revisedPipeline: '1→2a→2b→2c→3→4→5→5.25(refine+tokens+DS)→5.5(motion)→6→7→8→9→10a→10b→10c→10d→11(ship)→12(feedback)→13(portfolio)'
  quorumAgentRoster:
    summary: 'Named roster aligned with BMAD agent skills where applicable.'
    agents:
      - role: 'Product Owner (PO)'
        name: 'John'
        bmadSkill: 'bmad-agent-pm'
      - role: 'Dev Lead'
        name: 'Winston'
        bmadSkill: 'bmad-agent-architect'
      - role: 'UX Researcher'
        name: 'Mary'
        bmadSkill: 'bmad-agent-analyst'
      - role: 'Product Designer'
        name: 'Kinsley'
        bmadSkill: 'bmad-agent-ux-designer'
      - role: 'Motion Designer'
        name: 'Luca'
        bmadSkill: 'bmad-agent-motion-designer'
      - role: 'Frontend Developer'
        name: 'Jaymes'
        bmadSkill: 'agent-jaymes'
        buildPhase: 'always'
      - role: 'Backend Developer'
        name: 'Damien'
        bmadSkill: 'agent-damien'
        buildPhase: 'conditional'
      - role: 'QA Engineer'
        name: 'Quinn'
        bmadSkill: 'bmad-agent-qa'
      - role: 'Security Agent'
        name: 'Cipher'
        bmadSkill: 'agent-cipher'
      - role: 'Scrum Master'
        name: 'Bob'
        bmadSkill: 'bmad-agent-sm'
    implementationNote: 'Amelia (Developer, bmad-agent-dev) remains BMAD story executor when using BMAD workflows; Quorum build phase primarily orchestrates Jaymes + Damien + external AI coding tools per buildArchitecture.'
  agentTeam:
    - 'John — Product Owner (PO)'
    - 'Winston — Dev Lead'
    - 'Mary — UX Researcher'
    - 'Kinsley — Product Designer'
    - 'Luca — Motion Designer'
    - 'Jaymes — Frontend Developer (always during build)'
    - 'Damien — Backend Developer (conditional)'
    - 'Quinn — QA Engineer'
    - 'Cipher — Security Agent'
    - 'Bob — Scrum Master'
  bmadAgentsBuilt:
    - 'bmad-agent-ux-designer: Sally→Kinsley, UX Designer→Product Designer, expanded capabilities (DD, VD, DS, IA, DQ)'
    - 'bmad-agent-motion-designer: NEW agent Luca, capabilities (MS, TC, MI, LS, MR)'
    - 'agent-jaymes: Frontend Developer, memory agent with sanctum, consumes Kinsley/Luca/Damien outputs, mentor/autopilot/hybrid modes'
    - 'agent-damien: Backend Developer, memory agent with sanctum, database/auth/API/deployment specialist'
    - 'agent-cipher: Cipher, Security Agent'
    - 'bmad-agent-pm: John, PO'
    - 'bmad-agent-architect: Winston, Dev Lead'
    - 'bmad-agent-analyst: Mary, UX Researcher'
    - 'bmad-agent-qa: Quinn, QA Engineer'
    - 'bmad-agent-sm: Bob, Scrum Master'
    - 'bmad-agent-dev: Amelia — story execution in BMAD workflows; complements Quorum build orchestration'
elicitationState:
  completedMethods:
    - 'User Persona Focus Group — applied'
    - 'Cross-Functional War Room — applied'
    - 'First Principles Analysis — applied'
    - 'Shark Tank Pitch — applied'
    - 'Pre-mortem Analysis — applied'
    - 'SCAMPER Method — applied'
  appliedPremortemInsights: 'All 6 failure prevention insights applied — activation front-loading, transparency specificity, pipeline ordering by excitement, cost power-user modeling, one enterprise integration for V1, save-point reinforcement'
  appliedScamperInsights: 'All 21 insights applied across 7 lenses — voice capture, socratic capture, mood board, reverse entry, vision workshop, custom filters, investor package, agent backbone, audit trail, product snapshots, solo/enterprise unification, pipeline as menu, additional use cases (rationalization, due diligence, education)'
  remainingOriginalMethods: []
inputDocuments:
  - 'product-brief-quorum.md'
  - 'product-brief-quorum-distillate.md'
  - 'brainstorming-session-2026-04-07-1900.md'
  - 'research/competitive-landscape-research.md'
  - 'research/methodology-comparison-research.md'
  - 'research/technical-research.md'
documentCounts:
  briefs: 2
  research: 3
  brainstorming: 1
  projectDocs: 0
classification:
  projectType: saas_b2b
  domain: general
  complexity: high
  projectContext: greenfield
notes:
  - 'V2 CRITICAL: Domain-specific agent expertise for regulated industries (healthcare/HIPAA, fintech/PCI, legal, etc.) — marketplace for specialized compliance and industry agents'
workflowType: 'prd'
visionDiscovery:
  vision: >
    Quorum is the first product development platform where AI agents ARE the team.
    A solo founder walks in with nothing but an idea. First the team has a real
    **discussion** about that idea — not a rush to pixels. Then Kinsley explores
    **initial concept visuals** (Figma Make as the target surface; deep integration
    in a later version) without formal design tokens or design system overhead —
    that stays idea-stage. The team organizes themes, runs three-pillar analysis with
    concept-level visuals updating live, produces a PRD and journey maps, then
    **returns to design** for a fine-tune pass: high-fidelity screens, tokens, and
    design system foundation aligned to journeys — **before** motion and animation.
    Motion layers onto refined visuals; roadmap and cost follow; pitch, build, QA,
    security, UAT, ship. The human's role evolves — conductor during planning,
    collaborator during building, reviewer during feedback. The methodology is the architecture.
  whatMakesItSpecial: >
    The entry point is a genuine **conversation about the idea** before heavy design
    investment. Early visuals are **concept-level** in Figma Make (integration deepens
    in V2) — no design tokens or design system until after PRD and journey maps, when
    Kinsley fine-tunes to high-fidelity and establishes tokens and DS. The three-pillar
    filter runs against structured data AND live-updating **concept** visuals. After
    journeys, design refinement lands before Luca adds motion — so motion applies to
    screens that already reflect real flows and requirements. Downstream artifacts share
    one evolving source of truth. Nothing is disconnected.
  coreInsight: >
    Every existing tool manages the OUTPUT of product decisions. Quorum owns the
    INPUT — the thinking, the filtering, the reasoning — and then generates every
    downstream artifact from it. The pitch document is possible because the data
    already exists — the methodology produced it.
  whyNow: >
    29.8M solo founders, 74% using AI, zero tools that give them a team and a process.
    AI models are finally good enough to simulate genuine cross-functional product
    thinking. Enterprise teams are drowning in disconnected tools that manage tickets
    but don't improve decisions.
  quorumPipeline:
    - step: 1
      name: 'Describe your idea — design-thinking-style session'
      leadAgents: 'Full team: John (PO), Kinsley (Product Designer), Winston (Dev Lead), Mary (UX Researcher); anyone else relevant joins. Creativity comes from collision.'
      detail: 'When the user first mentions the idea, the **full team** runs a **design-thinking-style session** (not a design sprint): clarify the core concept, problem and user, constraints and risks, and **ideate** directions together — diverge before converging. Solo founders feel like they walked into a room of smart people who care about their idea. Session runs the **Kitchen Sink Discovery Framework** — 8 structured categories, each question paired with a conversational prompt and concrete examples so the user is never staring at a blank field: (1) Core Idea (one-sentence pitch, problem, success vision, what it is NOT), (2) Features & Functionality (ideal journey, single most-important feature, nice-to-haves, features to steal, error/empty-state handling, personalization), (3) Look & Feel (adjectives, reference brands, density, anti-references, consumer/pro positioning), (4) Visual Identity (color, typography, imagery, light/dark, product-as-person), (5) User & Audience (day-in-the-life, expert vs beginner, motivation level), (6) Reference Examples (screenshots, competitors, over/under-designed calibration), (7) Copy & Voice (formality, personality, vocabulary), (8) Constraints (platforms, brand guide, timeline, accessibility). The team surfaces **multiple proposed concept directions** where useful — not a single linear answer. Session closes by packaging what was learned into structured deliverables that feed every downstream step (**FR46** still applies for breakout iteration in external tools).'
      output: 'Four structured deliverables: (1) **Problem & Solution Framing** (problem, users, why-now, what-it-is-NOT, core hypothesis, JTBDs, friction, delight, key insight); (2) **Features & Capabilities** (core/supporting/delight/deferred, personalization, error/empty-state, accessibility); (3) **Master Design Prompt** (tool-agnostic — executable in Figma Make, Claude, v0, Midjourney, any generative design tool); (4) **Per-Screen Prompts** (onboarding, home/dashboard, core feature screens, empty state, error state, settings/profile).'
      premortemFix: 'Front-load the aha moment. Short capture → immediate organization → user sees structure. THEN go deeper. Exhaustive capture killed activation in pre-mortem scenario — but discussion-before-pixels prevents premature high-fid and token/DS work.'
      scamperEnhancements:
        voiceCapture: 'V1 consideration: voice-first input mode. Founders describe ideas out loud better than they type. "Talk to your team" is more natural than "type to your team." Speech-to-structured-data via existing APIs. Low overhead, high activation lift.'
        socraticCapture: 'Agent-led Socratic capture as an alternative mode. Instead of free-form description, agents lead with questions: "Whats the one problem youre solving?" "Who feels that pain most acutely?" "What happens if you never build this?" May extract better visions than free-form description. Offer both modes — free-form and guided.'
        moodBoard: 'Pre-capture mood board — users paste screenshots of products they admire, describe the vibe, reference competitors they like/dislike. Emotional input gives agents richer context for framing recommendations and understanding the founders aesthetic and tonal vision.'
        reverseEntry: 'Alternative entry point: start from an existing pitch deck and work backwards. Quorum reverse-engineers missing steps: "Your deck claims X market size but theres no analysis. Lets validate." Fills gaps backwards rather than building forwards. Serves founders who have already started.'
    - step: 2a
      name: 'Concept alignment (light)'
      leadAgents: 'Kinsley (Product Designer) + John (PO)'
      detail: 'MANDATORY — tighten the **Master Design Prompt** from step 1 with lightweight mood, reference, and directional aesthetic notes. Prompt is **tool-agnostic** — optimized for any design tool (Figma Make, Claude, v0, Midjourney, whatever the user works in). **Not** formal design tokens, token tables, or design system documentation — that is deferred to step 5.25 after PRD and journey maps.'
      output: 'Finalized concept direction brief + **execution-ready tool-agnostic design prompt** — downloadable in user-selected format(s): **Doc**, **HTML**, and/or **PDF** (checkboxes/dropdowns, one or multiple).'
    - step: 2b
      name: 'Initial concept visuals — Generated Concepts'
      leadAgents: 'Kinsley (Product Designer)'
      detail: 'MANDATORY — Kinsley produces **multiple initial concept variations** (exploratory fidelity) from the aligned prompt, and **each variation covers all screens** (not just a landing/hero page): dashboard, core feature screens, settings, onboarding, empty states, error states — the full product surface. Users need to see what features live in each section end-to-end. In Quorum, the user **scrolls through** the series (carousel / horizontal scroll or equivalent), **selects** one or more directions to keep, and on the **selected** concept sees **Refine**: natural-language instructions to Kinsley, **Breakout window** (open any design tool in **another tab/window**), and **carry-back** of updates (**FR46**). Selection establishes the **baseline concept set** that **Organize (2c)** and **Three-pillar analysis (3)** will use. V1: link, export, or user-managed file handoff. **V2 (aspirational):** deeper two-way integration with generative design tools. No motion yet. **No** formal token set or design system at this stage.'
      output: '**Generated Concepts** surface in-app: scrollable **all-screen** variations + select + refine + breakout; persisted concept boards covering the full product surface at exploratory fidelity.'
      architectureNote: 'Early artifacts may be file-first; structured component trees and full spatial data tighten at step 5.25. Layered artifact model still applies long-term — Kinsley owns spatial layer, Luca temporal at 5.5 on **refined** designs.'
    - step: 2c
      name: 'Organize the vision'
      leadAgents: 'John (PO) + full team'
      detail: '**Inputs carried forward (V1 contract):** (1) **Initial designs** from 2b—the **selected/baselined** concept variation(s) and any alternates the user kept; (2) the **concept** framing (names, labels, what each direction represents); (3) **core needs** from ideation—problem, users, constraints, risks, and capability list the team captured in step 1—so nothing “abstract” enters organization without tether. AI produces a **full sitemap** — every section of the product mapped out, and within each section the screens, capabilities, data flows, and relationships to adjacent sections. Think of it as the product''s table of contents with annotations, not just top-level navigation. Alongside the sitemap, AI clusters **features/capabilities** into themed groups with dependencies; user validates before the filter. **Concept** artifacts stay **grouped alongside** structured data by theme so **step 3** is genuine **user + AI collaboration on features** with visuals and needs in view—not a blank spreadsheet.'
      output: 'Full product sitemap (every section + per-section contents + relationships) + themed feature groupings with dependencies + concept baseline tether.'
      firstPrinciplesInsight: 'Capturing everything creates noise. Filtering noise is overwhelming. An intermediate organization step turns chaos into structure the user can review and the filter can evaluate meaningfully.'
      scamperEnhancement: 'Consider combining organize (2c) and filter (3) into a fluid "Vision Workshop" — AI organizes in real-time as user reacts. Blends structure and evaluation into one interactive session.'
    - step: 3
      name: 'Three-pillar analysis'
      leadAgents: 'All agents (filter is a team conversation)'
      detail: 'Every **feature/capability** from **Organize** goes through Desirability, Feasibility, Viability with **initial designs**, **concept context**, and **core needs** still available. **Two modes — user chooses upfront:** (A) **Collaborate** — work alongside the AI agents, discuss each evaluation, argue back, make calls together in real-time; (B) **Let AI handle it** — agents do the full analysis independently, user reviews the finished output and overrides where needed. Regardless of mode, agents internally research and compile answers to the full discovery question set from step 1 (now with research backing) plus a deeper design discovery analysis (core idea validation, feature validation, aesthetic validation, visual identity validation, user & audience validation, reference validation, copy & voice validation, constraint validation). Analysis is a CONVERSATION (or transparent delegation) — argue back, transparent sources, human final call. **CONCEPT VISUALS UPDATE LIVE** — feature gets cut, frames reflow or drop; argued back in, they restore. **Concept** fidelity, not final production UI.'
      output: 'Per-pillar rankings (features ranked within Desirability, Feasibility, Viability individually) + overall combined ranking across all three + **release allocation recommendations** (MVP / V2 / V3 / deferred) with reasoning for each allocation + concept visuals reflecting final scope + full audit trail of what data was considered, weighted, or excluded.'
      v1: 'Research-grade analysis powered by AI reasoning + web research + user input. Transparent about sources and confidence. Human decides, not the filter. Must show granular work — specific competitors with names/links, user quotes, data points with sources, complexity breakdowns, market size numbers. Full audit trail — every recommendation shows what data was considered, what was weighted, what was excluded and why.'
      v2: 'Data-grade analysis powered by real production data via feedback loop. Confidence levels upgrade from research-grade to evidence-grade.'
      designBehavior: 'Kinsley updates **concept-level** visuals in real-time as scope changes during filter. Luca is not active yet but receives a structured diff after step 3 (frames removed, merged, added, flows changed) for awareness; major spatial rework happens again at 5.25.'
      scamperEnhancement: 'User-defined filter criteria as power-user option. Three pillars are the default, but users can add custom evaluation lenses. Keeps simplicity for beginners, adds depth for domain experts.'
    - step: 4
      name: 'PRD generation'
      leadAgents: 'John (PO) + Winston (Dev Lead)'
      detail: 'AI team produces requirements from filtered vision. **Canonical PRD deliverables:** **HTML** (for in-app view, shareable link, or static export) and **Microsoft Word** (.docx)—both generated from the **same source document** so content does not drift. Solo vs enterprise differs by **depth and template**, not by primary format. References post-filter **concept** visuals. Explicitly notes that **high-fidelity refinement, tokens, and design system** land in step 5.25 after journey maps.'
      output: 'PRD in **HTML** + **.docx** (paired exports from one source)'
    - step: 5
      name: 'Journey maps'
      leadAgents: 'Mary (UX Researcher) + Kinsley (Product Designer)'
      detail: 'Both user journeys (in-product flows) AND customer journeys (discovery → purchase → onboarding → retention → expansion). Visual diagram output, not text-only. References post-filter **concept** visuals; pressures them against real flows and surfaces gaps for design refinement (5.25). Defines screen-to-screen paths and emotional state at transitions — feeds **refined** spatial design and then Lucas motion at 5.5.'
    - step: 5.25
      name: 'Design refinement — high-fidelity, tokens & design system'
      leadAgents: 'Kinsley (Product Designer) + Mary (UX Researcher)'
      detail: '**After PRD and journey maps**, Kinsley runs the fine-tune pass — and **everything gets updated**. First, **journey maps are updated** based on all research, analysis findings, and decisions made through the pipeline so far (three-pillar analysis, PRD generation, journey mapping). No stale journeys survive this step. Then Kinsley updates **all screens and their content** against the current truth — what features actually belong where, what content lives on each screen, what the hierarchy is. Nothing stale survives. Then the fine-tune pass proper: high-fidelity static screens aligned to updated journeys, formal **design tokens**, and **design system** planning — first mandatory point in the pipeline for those. Structured representation (component trees / layout data where applicable) reaches implementation-ready spatial specs for build and motion. Mary supports journey alignment and UX edge cases.'
      output: 'Refined static designs + token inventory + design system plan + handoff-ready spatial layer + updated journey maps + **detailed design prompt for any visual tool** (Figma Make, Claude, etc.) that references previous concept designs but **fixes and updates everything** — correct content, correct placement, correct hierarchy, reflecting all pipeline decisions + **Doc and HTML exports** of all contextual material (token inventory, design system plan, screen-by-screen specs, updated journey maps).'
      rationale: 'User-directed: defer token/DS investment until requirements and flows are anchored. Luca animates refined targets, not rough concepts.'
    - step: 5.5
      name: 'Motion & animation design'
      leadAgents: 'Luca (Motion Designer) + Kinsley (Product Designer)'
      detail: 'Luca ingests journey maps and Kinsleys **refined** designs from 5.25 (spatial relationships, component hierarchy, tokens). Produces: transition choreography (push, fade, expand, shared-element, direction, duration, easing matched to emotional weight), micro-interaction specs (button feedback, toggles, form states, cards), loading states (skeleton, progressive, shimmer), reduced-motion alternatives (parallel spec, not afterthought). Output: structured motion specification per screen with feeling + technical values + reduced-motion fallback.'
      output: 'Motion specification documents — per screen, per transition, per interactive element — delivered in two formats: **text file** (full spec document) and **HTML file** (formatted, browsable version with visual organization).'
      rationale: 'After journeys **and** refined static design — motion needs flow context and stable spatial targets. Before roadmap so motion scope enters timeline/cost.'
    - step: 6
      name: 'Roadmap'
      leadAgents: 'John (PO) + Winston (Dev Lead)'
      detail: 'Prioritized release plan (MVP → V2 → V3). Now includes motion design scope in timeline estimates. Enterprise: layers on top of existing commitments and in-flight work, not blank-canvas replacement.'
    - step: 7
      name: 'Cost estimate'
      leadAgents: 'Winston (Dev Lead) + John (PO)'
      detail: 'Cost and timeline per release. Includes confidence ranges, not hard numbers. Now includes motion implementation effort. Enterprise: calibrates to team actual velocity over time, not generic benchmarks.'
    - step: 8
      name: 'Pitch document'
      leadAgents: 'John (PO)'
      detail: 'Enterprise: executive pitch for internal leadership budget approval. Solo: investor pitch for VC/angel fundraising. Same underlying data, audience-adapted framing. Must be presentation-ready quality. Includes **refined** product designs (post-5.25) AND a "Product Experience" section with annotated motion specs (2-3 slides: key transitions and micro-interactions). Signals execution-ready depth to investors. **The pitch deck is created, then the user gets time to refine** — both the design (layout, visuals, slide composition) and the content (copy, data points, narrative arc). Not a one-shot export: user reviews, adjusts, art-directs, iterates until it is right, then exports.'
      output: 'Polished user-refined pitch deck exported in **PDF** (presentation-ready, shareable), **DOC** (editable, for further refinement outside Quorum), and **HTML** (web-viewable, linkable).'
      scamperEnhancement: 'Investor Package — combine roadmap + cost estimate + pitch deck into a single cohesive, shareable package with consistent formatting, cross-referenced data, and one shareable link.'
    - step: 9
      name: 'Sprint planning'
      leadAgents: 'Bob (Scrum Master) + Winston (Dev Lead)'
      detail: 'Break into epics and stories. Epics include frontend stories (design implementation, motion implementation), backend stories (database, auth, API — if needed), and testing stories. Stories are the CRITICAL HANDOFF ARTIFACT — they must be incredibly detailed because they drive external AI coding tools. Each story includes: acceptance criteria, referenced design specs (Kinsley), motion specs (Luca), technical architecture context (from PRD/architecture), file paths, and testing requirements. Enterprise: integrates with existing JIRA/Linear workflows. BACKEND CHECK: assess whether the product requires backend infrastructure. If yes, Backend Developer agent activates and backend-specific stories are created.'
    - step: 10a
      name: 'Build (orchestrated via external AI coding tools)'
      leadAgents: 'Winston (Dev Lead) + Jaymes (Frontend, always) + Damien (Backend, conditional)'
      detail: 'ARCHITECTURE DECISION: Quorum does not write code directly. Quorum orchestrates external AI coding tools (Claude Code / Cursor / Windsurf / Copilot / etc.) by generating highly detailed story files with full context. Quorum owns the thinking; the external tool owns the typing. Dev Lead directs the overall build, Frontend Developer (Jaymes) ALWAYS directs UI implementation (the product starts as a design — there is always frontend to build, consumes Kinsleys design specs and Lucas motion specs, translates into pixel-perfect responsive code), Backend Developer (Damien) directs infrastructure setup when needed (database, auth, API, deployment). Each developer agent knows how to instruct AI coding tools for their domain. Integrated testing is non-negotiable — tests written alongside code.'
      orchestrationModel: >
        Quorum generates story files → User opens story in AI coding tool (Cursor, etc.) →
        Quorum agent persona provides domain-specific direction and constraints →
        AI coding tool writes the code → Tests run → Story marked complete in Quorum.
        Quorum maintains the sprint board, tracks progress, and ensures quality gates.
        The external tool is the hands; Quorum is the brain.
      v1: 'Support Claude Code / Cursor as primary integration. Story export format optimized for AI coding tool consumption.'
      v2: 'Multi-tool support (Windsurf, Copilot, etc.), direct API integration with coding tools for automated story loading, progress tracking back into Quorum.'
    - step: 10b
      name: 'QA testing'
      leadAgents: 'Quinn (QA Engineer)'
      detail: 'Systematic test execution against PRD acceptance criteria. Automated test suites validate functional correctness. Motion implementations validated against Lucas specs. QA can be orchestrated through the same external AI coding tools — QA agent generates test stories, coding tool writes and runs the tests.'
    - step: 10c
      name: 'Security audit'
      leadAgents: 'Cipher (Security Agent)'
      detail: 'Post-build security review before UAT and ship. Cipher performs vulnerability assessment, dependency audit, auth/authorization review, data exposure analysis, injection vector scanning, OWASP Top 10 check, secrets detection, and security best practices validation. Findings categorized by severity (critical/high/medium/low). Critical and high findings must be resolved before ship — loop back to 10a for fixes. Medium/low findings documented as known issues with remediation timeline.'
    - step: 10d
      name: 'UAT — user validates against vision'
      leadAgents: 'User + Kinsley (Product Designer) + Luca (Motion Designer)'
      detail: 'The design accountability checkpoint. User validates that the built product matches the vision they have been refining since step 1. Kinsley reviews spatial fidelity (spacing, color, typography, component correctness, responsive behavior, accessibility). Luca reviews temporal fidelity (timing accuracy, easing curves, frame rate, choreography, reduced-motion behavior). Bug fixes and iteration based on findings. Loop back to 10a if changes needed.'
    - step: 11
      name: 'Ship'
      leadAgents: 'Winston (Dev Lead)'
      detail: 'Production release after QA, security audit, and UAT approval.'
    - step: 12
      name: 'Feedback loop (V2)'
      leadAgents: 'All agents'
      detail: 'Post-ship learning from production — analytics, user behavior, error rates. Dual-purpose: validate assumptions from three-pillar analysis AND discover new opportunities. Distinct from pre-ship QA/UAT — this is "is it solving the problem we thought?" not "does it work correctly?"'
    - step: 13
      name: 'Portfolio document'
      leadAgents: 'John (PO) + Kinsley (Product Designer)'
      detail: 'A comprehensive document summarizing the **entire process end-to-end** — from initial idea through ship and feedback. Designed for the user to include in a portfolio, case study, or stakeholder retrospective. Shows the *evolution*, not just the result — how the product evolved from a sentence to a shipped product through a structured, team-driven process. Covers: original problem and hypothesis; discovery insights and key decisions; concept evolution (before/after at each stage); design decisions and why they were made; three-pillar analysis highlights; architecture choices; the build process; QA and security findings; final product screenshots; key metrics (if post-ship data available); lessons learned.'
      output: 'Polished, visual process document ready for portfolio use — exported as **HTML**, **PDF**, and **Doc**.'
  buildArchitecture:
    decision: >
      ARCHITECTURE DECISION: Quorum does not write code. Quorum orchestrates external AI
      coding tools (Claude Code / Cursor / Windsurf / Copilot) by generating incredibly
      detailed story files with full context. Quorum owns the thinking — the methodology,
      the planning, the design, the specifications. External tools own the typing — the
      actual code generation. This keeps Quorum focused on what makes it unique (the team,
      the methodology, the reversed flow) while using best-in-class coding tools for
      implementation.
    storyAsHandoff: >
      Stories are the critical handoff artifact between Quorum and external coding tools.
      Each story must include: acceptance criteria, referenced design specs (Kinsley),
      motion specs (Luca), technical architecture context, file paths, testing requirements,
      and domain-specific constraints. The quality of the story determines the quality of
      the code. Quorum's entire pipeline (steps 1-9) exists to produce stories so detailed
      that any AI coding tool can execute them faithfully.
    developerAgentsAsDirectors: >
      Developer agents in Quorum (Winston/Dev Lead, Jaymes/Frontend, Damien/Backend) are
      DIRECTORS, not implementers. They know how to instruct AI coding tools for their
      domain. Jaymes translates Kinsleys designs and Lucas motion specs into coding tool
      instructions. Damien instructs database setup, auth, API patterns. Winston coordinates
      the overall build and resolves cross-cutting concerns.
    developerActivation: >
      Frontend Developer is ALWAYS active during the build phase — the product starts as a
      design, so there is always UI to implement. Backend Developer (Damien) is conditional —
      activated during sprint planning (step 9) based on whether the product needs backend
      infrastructure. Security Agent (Cipher) always runs after build — security audit is
      mandatory before ship. A design-only project can stop at step 9 with stories ready
      for whenever the user wants to build.
    v1Integration: 'Claude Code / Cursor as primary supported tool. Story export optimized for AI coding tool consumption.'
    v2Integration: 'Multi-tool support, direct API integration for automated story loading, bidirectional progress tracking.'
  designFirst:
    v1Approach: 'MANDATORY idea discussion (1) + concept alignment (2a) + concept visuals in Figma Make (2b). Filter runs on structured data + live **concept** updates. After PRD + journeys, MANDATORY refinement (5.25): high-fidelity, tokens, design system. Motion (5.5) on refined spatial layer, before roadmap.'
    v2Approach: 'Bidirectional Figma Make integration, full animated prototypes, deeper design-system code generation, motion previews in pitch decks.'
    insight: 'Founders need to **talk the idea through** then see a **concept** fast — without token/DS tax. The fine-tune hook is seeing journeys resolved into polished, build-ready design before motion.'
    warRoomDecision: 'UPDATED: Visuals are not optional, but **fidelity is staged**. Concept mandatory early; tokens/DS mandatory after journeys (5.25). Layered artifacts: Kinsley spatial (refined by 5.25), Luca temporal at 5.5. Both validate during UAT.'
    designIterationModel: '**Concept** visuals iterate through the filter (step 3). **Refined** spatial layer is produced at 5.25 once PRD and journeys anchor flows — avoids reconciling production UI during chaotic scope churn.'
    motionTiming: 'Motion at 5.5 AFTER journey maps AND 5.25 refinement — stable targets, flow context — BEFORE roadmap for cost/timeline.'
  agentInteraction:
    v1: 'Synthesized disagreement — agents assess independently, orchestrator identifies conflicts and presents structured trade-offs as a team briefing. Feels like a team that prepped for you.'
    v2: 'Visible real-time agent-to-agent debate. Users watch agents discuss and make the final call.'
    warRoomDecision: 'Multi-agent live debate is the hardest thing to build reliably (looping, repetition, walls of text). V1 synthesized disagreement is reliable and still feels like a team. V2 upgrades to visible debate.'
    scamperCritical: >
      DIFFERENTIATOR: Agents must push back on the USER, not just each other. "I hear you want
      to build this feature, but as your Dev Lead I need to tell you this is a 6-month project
      disguised as a 2-week feature. I would push back on this in a real standup and Im pushing
      back now." Most AI tools are sycophantic. Quorum agents should have backbone. This is where
      the team metaphor becomes real and where the product separates from every chatbot wrapper.
      Human still makes the final call — but agents have genuine opinions and defend them.
  teamRoomGUI:
    v1: 'Conversational center panel with distinct agent identities (name, avatar, role) + live artifact sidebar (feature list, pillar results, roadmap, board). Sidebar updates as team works.'
    v2: 'Spatial team room with drag-and-drop, visible agent debate, rich board interactions.'
    warRoomDecision: 'Spatial drag-and-drop team room is massive frontend investment. Chat with agent identity + live sidebar is buildable and still feels like working WITH a team, not using a tool.'
  enterpriseBrownfield:
    v1: 'Manual context entry + multi-user access + role-based agent interaction + ONE automated integration (Jira import OR Notion import — pick most common). Pure manual entry is a conversion killer per pre-mortem.'
    v2: 'Full automated ingestion — codebase scanning, all PM tool imports, design system parsing, velocity calibration.'
    warRoomDecision: 'Full automated brownfield ingestion is months of work. But ZERO automation is an enterprise dealbreaker.'
    premortemFix: 'Build ONE automated integration for V1. Enterprise prospects tolerate limited automation but not zero. The gap between demo and real usage must be crossable.'
  firstPrinciplesInsights:
    emotionalValue: >
      Solo founders buy Quorum for better decisions AND for the feeling of having a team.
      The emotional dimension (not being alone, having partners who challenge and support)
      is as important as the functional dimension. Market both explicitly.
    agentDifferentiation: >
      ARCHITECTURE REQUIREMENT: Agent differentiation must be structural — different evaluation
      frameworks, weighted criteria, and data sources per agent. Not just different prompt
      personalities. If agents are the same brain in five costumes, users will notice fast.
      Dev Lead weights feasibility/debt differently than PO weights business value. This must
      be enforced architecturally.
    clusteringStep: >
      Insert an "organize the vision" step between capture and filter. AI clusters features
      into themes, identifies dependencies, groups related capabilities. User validates the
      organization. Reduces overwhelm and improves filter quality by operating on meaningful
      groups, not isolated feature atoms.
    evolvingHumanRole: >
      The human role is not fixed across the pipeline. Conductor during planning/filtering,
      collaborator during building, reviewer during feedback loop. The UI should reflect
      this shift — the platform's relationship with the user evolves per phase.
    contextualAgentActivation: >
      Not all agents present at every step. Step 1 design-thinking session: John primary,
      Kinsley co-participates (outputs Figma Make prompt). Concept: Kinsley (2a/2b). Organize/filter: full team; Kinsley live **concept** updates.
      PRD: John + Winston. Journey maps: Mary + Kinsley. Design refinement (5.25): Kinsley + Mary.
      Motion: Luca + Kinsley. Sprint planning: Bob + Winston (+ backend check for Damien).
      Build: Winston + Jaymes (always) + Damien (if backend needed). QA: Quinn. Security:
      Cipher (after build). UAT: User + Kinsley + Luca. Jaymes ALWAYS in build. Damien
      CONDITIONAL. Cipher at 10c before UAT.
    threePillarsHold: >
      Three pillars (Desirability, Feasibility, Viability) are sufficient. Usability folds
      into Desirability. Timing folds into Viability. Differentiation folds into Viability.
      Resist the temptation to add more. Simplicity is the power.
    soloIsV1Priority: >
      V1 messaging, onboarding, and default UX must be unambiguously optimized for solo
      founders. Enterprise mode is accessible but clearly secondary. Trying to serve both
      equally at launch will dilute both experiences.
    soloEnterpriseUnification: >
      SCAMPER CHALLENGE to above: Consider eliminating the solo/enterprise mode distinction
      entirely in V1. Build ONE mode that scales. Solo is enterprise-of-one. Multi-user is
      just adding seats. Pipeline is the same. Outputs adapt to audience automatically based
      on context (team size, existing tools, stated goal) not a mode toggle. Fewer code paths,
      simpler architecture, cleaner UX. V1 is solo-optimized by DEFAULT but architecturally
      there is no mode switch — just contextual adaptation.
    nonLinearPipeline: >
      Pipeline is the guided default path for new users. Under the hood, the system supports
      non-linear navigation — any step can trigger revisiting earlier steps. AI team proactively
      suggests backtracking when warranted ("cost estimate exceeds budget — want to re-run
      the filter with tighter constraints?" or "journey map revealed a gap — add it to vision
      and filter it?").
    pipelineOrdering: >
      PREMORTEM CRITICAL: Order pipeline by user excitement, not methodology sequence.
      After pillar analysis, go to roadmap and cost estimate first (what founders care about),
      then pitch document (highest perceived value). PRD and journey maps are depth outputs
      for users who want rigor — offer them, dont force them as gates. Alternatively, let
      users pick which outputs to generate next. High-value outputs before depth outputs.
      80% drop-off before step 8 pitch deck = the most exciting output is buried.
    pipelineAsMenu: >
      SCAMPER REARRANGE: After the core capture-organize-filter sequence (steps 1-3), present
      a DASHBOARD of available outputs, not a sequential checklist. User picks what they need:
      "I need a roadmap and cost estimate." Quorum figures out what upstream analysis is needed
      and runs it. Pipeline-as-service, not pipeline-as-journey. The methodology still runs in
      full under the hood — the user just doesnt experience it as a mandatory sequence. Guided
      mode (default for new users) walks the pipeline. Expert mode (unlocked after first run)
      shows the dashboard. Aligns with pre-mortem pipeline ordering fix.
  sharkTankInsights:
    positioning: >
      Lead with "methodology-as-architecture," not "AI agents." Every competitor says AI.
      Quorum should say "we encoded a product development methodology as software architecture,
      and AI runs it." The reversed flow is defensible on its own. AI agents as a feature
      is not. Incumbents cant bolt the reversed flow onto tools designed around the forward
      flow — its an architecture decision, not a feature decision.
    enterpriseGTM: >
      Sell the output, not the process. "Replace your entire product process with AI" is
      terrifying to a VP. Instead: "your PM will produce better roadmaps, cost estimates,
      and executive decks in a fraction of the time." VP buys because PM suddenly produces
      10x better artifacts. PM champion program with free individual tier — land-and-expand,
      not top-down enterprise sales.
    activationMetric: >
      20-minute organized vision is the hook. The moment a solo founder sees their chaotic
      brain dump organized into coherent themed feature groups by the AI team — thats the
      activation point. After 20 min: structured vision. After 45 min: + pillar analysis.
      After 2 hours: + roadmap and cost estimate. After 3 hours: + investor pitch deck.
      Measure the 20-minute activation ruthlessly.
    savePointModel: >
      Each pipeline step delivers standalone value even if the user stops. Not a mandatory
      full sequence — a path with checkpoints. Close your laptop after step 2b and you
      still have themed vision plus **concept** frames (Figma Make path) — more tangible
      than weeks of Notion alone. This reframes the pipeline from "commitment" to
      "progressive value delivery."
    productSnapshots: >
      SCAMPER EXTENSION of save-point model: Each checkpoint creates a complete, shareable,
      timestamped snapshot of the product vision at that stage. Users can BRANCH from any
      snapshot — "what if we went B2B instead of B2C from this point?" — and run parallel
      product explorations. Git for product strategy. V2 feature but architect for it in V1
      by making state serializable and diffable from the start.
    agentDistinguishabilityEval: >
      TESTING REQUIREMENT: Build automated eval suite that measures whether users can tell
      agents apart after 3 sessions. If Dev Lead sounds like PO with different words, the
      team metaphor collapses. Test agent distinguishability as a product quality metric
      from day one, not after users complain.
    qualityGuardrails: >
      ARCHITECTURE REQUIREMENT: Agent output quality will vary by session, by model, by
      context. Ship with quality guardrails and output scoring from day one. Dont wait for
      user complaints. Quality consistency is the biggest technical risk after cost — build
      the safety net before the trapeze act.
    costGuardrails: >
      PREMORTEM CRITICAL: Model power user cost, not average user cost. Solo founders will
      treat Quorum as an always-on co-founder — 45-100+ sessions/month, not 20. Build
      per-tenant usage tracking, tiered usage limits by plan, aggressive caching for repeated
      patterns, context summarization between sessions. If happiest users bankrupt you, the
      model is broken.
  premortemInsights:
    activationDropoff: >
      FAILURE MODE: Users abandon during vision capture because the pipeline feels
      like homework, not magic. FIX: 10-min structured aha — fast capture, immediate
      AI organization, user sees structure within minutes. Progressive depth AFTER
      activation, not before. Measure 20-min activation ruthlessly.
    transparencyCollapse: >
      FAILURE MODE: Three-pillar analysis feels like a black box. Users get
      "recommended" / "not recommended" without understanding why. Trust erodes.
      FIX: Granular transparency — specific competitor names with links, user quotes
      with sources, complexity breakdowns with reasoning, market size with methodology.
      Every claim must be falsifiable and independently verifiable.
    pipelineFatigue: >
      FAILURE MODE: 80% drop-off before the pitch deck (the highest-value output)
      because its buried at step 8 behind PRD and journey maps that solo founders
      dont care about. FIX: Reorder by excitement — after filter, go to roadmap +
      cost estimate + pitch deck first. PRD and journey maps are depth options, not
      mandatory gates.
    costExplosion: >
      FAILURE MODE: Power users (solo founders using Quorum as always-on co-founder,
      45-100+ sessions/month) generate 5-10x the API cost of average users. Unit
      economics collapse on happiest customers. FIX: Per-tenant usage tracking from
      day one, tiered limits by plan, aggressive caching for repeated patterns,
      context summarization between sessions. Model power user cost, not average.
    enterpriseGap: >
      FAILURE MODE: Enterprise demos impress but real usage requires manual context
      entry for everything. Gap between demo and reality kills conversion. FIX: Build
      ONE automated integration for V1 (Jira import or Notion import). Enterprise
      prospects tolerate limited automation but not zero automation.
    savePointReinforcement: >
      FAILURE MODE: Users treat pipeline as all-or-nothing commitment. Drop off
      entirely if they cant finish. FIX: Each step delivers standalone value.
      Explicit save-point messaging — "You now have X, which alone is worth Y."
      Close your laptop after step 2b and you still have organized vision plus
      concept visuals — ahead of a blank doc.
  scamperInsights:
    voiceCapture: >
      Voice-first vision capture as alternative input mode for Step 1. Founders describe
      ideas out loud better than they type. Speech-to-structured-data via existing APIs.
      "Talk to your team" is more natural than "type to your team." Low implementation
      overhead, high activation lift. V1 candidate.
    investorPackage: >
      Combine roadmap + cost estimate + pitch deck into single "Investor Package" output
      with consistent formatting, cross-referenced data, and one shareable link. These
      outputs are always consumed together by solo founders seeking funding. The package
      IS the product for many users. High perceived value.
    agentBackbone: >
      CORE DIFFERENTIATOR: Agents must push back on the USER, not just each other.
      Most AI tools are sycophantic. Quorum agents should have genuine opinions and
      defend them. "This is a 6-month project disguised as a 2-week feature and I would
      push back in a real standup." Human still decides — but agents have backbone.
      This is where the team metaphor becomes real.
    productSnapshots: >
      Git for product strategy. Each pipeline checkpoint creates a shareable, timestamped
      snapshot. Users can branch from any snapshot to explore alternatives ("what if B2B
      instead of B2C from this point?"). V2 feature but architect state to be serializable
      and diffable from V1 day one.
    soloEnterpriseUnification: >
      Eliminate mode toggle. Build ONE mode that scales — solo is enterprise-of-one,
      multi-user is adding seats. Pipeline is identical. Outputs adapt to audience via
      context (team size, tools, stated goal), not a mode switch. Fewer code paths,
      simpler architecture.
    reverseEntry: >
      Alternative entry: start from existing pitch deck, work backwards. Quorum
      reverse-engineers missing steps and fills gaps. Serves founders who already
      started elsewhere. Multiple entry points into the same pipeline.
    socraticCapture: >
      Agent-led Socratic capture as guided alternative to free-form description.
      Agents ask structured questions instead of waiting for the user to describe.
      May extract better, more complete visions. Offer both modes.
    pipelineAsMenu: >
      After core sequence (capture-organize-filter), present dashboard of available
      outputs instead of mandatory sequential steps. Guided mode for new users walks
      the pipeline. Expert mode shows the menu. Methodology runs in full under the
      hood — user experience is flexible.
    customFilters: >
      User-defined evaluation criteria beyond three pillars. Hardware founder adds
      "Manufacturability." Marketplace founder adds "Supply-side acquisition." Default
      three pillars for simplicity, extensible for domain experts.
    moodBoard: >
      Pre-capture mood board — users paste screenshots, describe vibe, reference
      competitors. Emotional input enriches agent context for recommendations. Quick
      to build, high context value.
    auditTrail: >
      Full decision audit trail on every recommendation. What data was considered,
      what was weighted, what was excluded and why. Drill-in explainability. No
      competitor offers this level of transparency. Extends pre-mortem transparency fix.
    additionalUseCases:
      productRationalization: 'Enterprise teams audit existing products against three pillars — "what should we kill?" Massive pain point with no tools.'
      investorDueDiligence: 'Investors paste pitch deck, agents analyze feasibility/viability/competitive landscape. Same engine, different audience.'
      pmEducation: 'Universities/bootcamps use Quorum to teach product thinking. Pipeline IS the curriculum. Students learn by doing with expert AI guidance.'
  focusGroupInsights:
    brownfieldMode: 'Enterprise needs "extend existing product" mode across the pipeline — design step ingests existing context, roadmap respects in-flight work, sprint planning integrates with current tools'
    filterAsConversation: 'Three-pillar filter must be a dialogue, not a verdict. Users argue back, agents explain reasoning, data sources are transparent. Solo founders are emotionally attached to features and need the filter to feel collaborative, not punitive.'
    outputAdaptation: 'Every artifact (PRD, journey maps, roadmap, pitch doc) needs audience-appropriate versions. Solo gets lean/actionable, enterprise gets detailed/customizable with template support.'
    multiUserCollaboration: 'Enterprise vision capture needs multi-user participation — product trio contributes together, not just PO alone.'
    estimateConfidence: 'Cost estimates must include confidence ranges. Enterprise needs velocity calibration to their actual team over time. Hard numbers without ranges will be rejected by eng leads.'
    visualOutputs: 'Journey maps and other artifacts should be visual/diagrammatic where possible, not text-only.'
    pricingSignals:
      solo: '$30-50/month willingness for idea-to-pitch-deck pipeline'
      enterprise: '$200-500/month per seat for quarterly planning replacement + VP deck generation'

---