Last updated: 2026-04-13 Purpose: Step-by-step description of what the user experiences at each stage of the Quorum pipeline. Source of truth for pipeline experience design — complements the PRD pipeline YAML (structural definition).
Lead: Full team — John (PO), Kinsley (Product Designer), Winston (Dev Lead), Mary (UX Researcher), and anyone else relevant. The more minds the better.
You open Quorum and you have an idea — maybe it's sharp, maybe it's half-formed. Doesn't matter. You start talking to your team.
This isn't a form. It's a design-thinking-style session — the full team participates, not just John and Kinsley. Creativity comes from collision. The team diverges before converging — surfacing multiple proposed concept directions, not funneling you into one linear answer.
You're a solo founder, but you don't feel solo. You feel like you walked into a room of smart people who care about your idea. They push back. They ask the questions you didn't think to ask. They get excited about the parts worth getting excited about.
The session runs through a comprehensive discovery framework — dump everything, then reverse-engineer to a simple, desirable product. Eight categories, guided but not rigid. Each question comes with a conversational prompt and concrete examples so the user is never staring at a blank field.
Q: If you could only describe this in one sentence — what is it and who is it for? - Prompt: Don't worry about getting it perfect. Just say it out loud like you'd explain it to a friend at dinner. - Examples: "An app that helps nurses track patient meds without switching screens" / "A loyalty program for small coffee shops that actually feels personal"
Q: What problem does this solve that nothing else does well right now? - Prompt: Think about the frustration or gap that made you think of this idea in the first place. - Examples: "Everything else is too complicated" / "Existing tools aren't built for mobile" / "There's no version that works for small teams"
Q: What does success look like 6 months after launch? What are users doing or saying? - Prompt: Paint a picture — reviews, word-of-mouth moments, behaviors you'd want to see. - Examples: "People recommend it without being asked" / "Users log in daily without being prompted" / "It becomes part of their routine"
Q: What is this product NOT? What would you never want it to be or do? - Prompt: Just as important as the vision. Defining boundaries early prevents scope creep later. - Examples: "Not a social network — it's private" / "Not trying to do everything like Notion does" / "Not a replacement for a real professional"
Q: Walk me through the ideal user journey — what does someone do from the moment they open it to the moment they get value? - Prompt: Step-by-step, even if rough. What happens first? Then what? When do they feel the 'aha moment'? - Examples: "Open > see their dashboard > one tap to take action > done in under a minute"
Q: If you had to pick the single most important thing this needs to do, what is it? - Prompt: The feature that, if it didn't exist, the product would be pointless. - Examples: "Real-time notifications" / "The ability to share results instantly" / "The search — it has to be fast and accurate"
Q: What are the 'nice to haves' — things that would make users delight but aren't essential right now? - Prompt: Think wish list. No filtering yet — dump everything here. - Examples: "Dark mode" / "Offline mode" / "Custom themes" / "Import from other tools" / "AI-suggested actions"
Q: Are there any features you've seen in other apps that you absolutely want to steal? - Prompt: This is a safe space. Name names. What did you see that made you think 'we need that'? - Examples: "The way Spotify shows lyrics live" / "How Duolingo uses streaks and rewards" / "The clean onboarding flow of Calm or Headspace"
Q: What happens when something goes wrong — how should the product handle errors, empty states, or failures? - Prompt: Think about the moments when data is missing, a process fails, or a user gets lost. What should they feel? - Examples: "Friendly, human error messages — not tech jargon" / "Always give a clear next step" / "Never leave a blank screen"
Q: Should this remember things about the user and personalize over time, or stay neutral every session? - Prompt: This shapes architecture early and affects how 'smart' the product feels. - Examples: "Yes — learn my preferences like Netflix" / "No — it's a tool, neutral is fine" / "Maybe — show recent history but don't make assumptions"
Q: Give me 3–5 adjectives that describe how this product should feel when you use it. - Prompt: Don't think about visuals yet — just the emotional experience. How should it make people feel? - Examples: "Calm, focused, effortless" / "Bold, energetic, fast" / "Warm, trustworthy, approachable" / "Premium, quiet, refined"
Q: Is there an app, website, or brand (even outside your industry) whose visual style you admire and would want to borrow energy from? - Prompt: Doesn't have to be in the same space. Could be a fashion brand, a newspaper, a video game interface. - Examples: "Linear — clean and minimal" / "Apple — restrained but premium" / "Notion — neutral and flexible" / "Stripe — developer-facing but still beautiful"
Q: On a spectrum from minimal/clean to rich/dense, where does this product live? - Prompt: Neither is better — it depends on context and user. Dense works for power tools; minimal works for casual daily use. - Examples: "Minimal like a Japanese tea ceremony" / "Dense like a Bloomberg terminal" / "Balanced — easy on the surface, powerful underneath"
Q: Is there anything you've seen (anywhere) that made you cringe and think 'I never want this to look like that'? - Prompt: Negative examples are extremely useful design input. What aesthetic turns you off? - Examples: "Anything that looks like a 2010 corporate intranet" / "Overly playful with too many cartoon elements" / "Dark patterns, cluttered nav, 12 CTAs on one screen"
Q: Should this feel like a consumer product (approachable, fun, personal) or a professional tool (structured, serious, powerful)? - Prompt: Some products try to be both — that's valid too, but it requires a clear strategy. - Examples: "Consumer — like Airbnb or Spotify" / "Pro tool — like Figma or Notion" / "Hybrid — friendly surface, serious engine underneath"
Q: Do you have a color palette in mind? Or a color that absolutely must be there — or never appear? - Prompt: Can be based on brand, personal taste, industry convention, or emotional association. - Examples: "Must feel blue and trustworthy — it's a finance product" / "No red anywhere — we don't want to trigger alarm" / "Our brand is already green — everything needs to work with it"
Q: How should the typography feel — light and editorial, sturdy and utilitarian, geometric and modern, or something else? - Prompt: Describe it in feel-words or reference a publication, brand, or even a person whose communication style you admire. - Examples: "Like the New York Times — serious and readable" / "Like Apple — clean SF Pro energy" / "Startup-ish — slightly informal, modern, Grotesk-style fonts"
Q: Should the product use photography, illustration, icons, or data visualization — or avoid imagery entirely? - Prompt: Each choice carries emotional weight. Photos = real world; illustrations = personality; icons = utility; data viz = intelligence. - Examples: "Icon-forward — clean and fast like Linear" / "Real photography only, nothing stock-looking" / "Illustration-heavy — friendly and branded like Mailchimp"
Q: Light mode, dark mode, or both? Is there a default? - Prompt: This affects contrast strategy, icon style, and perceived premium-ness. Dark mode reads as modern/technical; light reads as accessible/professional. - Examples: "Dark mode default — it's a dev tool" / "Light only — our users are in bright office environments" / "Both — user choice at onboarding"
Q: If this product were a person, how would you describe them? - Prompt: This is a classic brand exercise. The persona you describe tells us voice, tone, typography, and color all at once. - Examples: "A calm, competent doctor who explains things in plain language" / "A sharp, witty designer who sweats the details" / "A knowledgeable friend who doesn't talk down to you"
Q: Who is the primary user — what does their day look like and when would they use this? - Prompt: Context shapes design. A tool used once a day in a quiet office is different from one used in 30-second bursts on a phone. - Examples: "A nurse on the floor, grabbing their phone between patients" / "A startup founder checking in first thing every morning" / "A parent doing this at night after the kids are asleep"
Q: Is this for experts who want power and control, or beginners who need guidance and hand-holding? - Prompt: Power users hate onboarding friction; beginners need scaffolding. Both are valid but demand opposite design decisions. - Examples: "Experts — hide nothing, give us full control" / "Beginners — guide me through everything, I'll graduate later" / "Progressive — simple until you're ready for more"
Q: Will users be highly motivated to use this or do you need to earn their attention every session? - Prompt: Motivated users tolerate complexity. Reluctant users need every session to earn its keep. - Examples: "Highly motivated — they're paying for a specific outcome" / "Reluctant — they were told to use it at work" / "Habitual — this becomes routine, like a morning checklist"
Q: Can you share any screenshots, links, or images of things you like — even from completely unrelated fields? - Prompt: Drop anything. A fashion website. A video game UI. A magazine spread. A receipt you thought looked nice. Everything is input. - Examples: "Paste a link or screenshot directly" / "Even a photo of a physical object with a texture you like works"
Q: What are your top 2–3 direct competitors and what do you think they do well vs. badly? - Prompt: This defines your table stakes (things you must match) and your opportunity to differentiate. - Examples: "Good: their speed. Bad: the onboarding never gets better" / "Good: feature set. Bad: it looks like 2014 and feels like a chore"
Q: Is there a product you think is wildly overdesigned for what it does, or wildly underdesigned? - Prompt: Calibrating the design ceiling and floor is useful. Not everything needs Apple-level polish or Craigslist rawness. - Examples: "Overdesigned: fintech apps with 3D animations everywhere" / "Underdesigned: the tool we're replacing — it hasn't changed since 2008"
Q: How should this product speak to users — formal and professional, casual and friendly, or somewhere in between? - Prompt: This governs button labels, error messages, onboarding copy, empty states — everything a user reads. - Examples: "Like a smart colleague — direct and respectful" / "Like a coach — encouraging and action-oriented" / "Like documentation — precise and neutral"
Q: Should the product have a distinct personality in its writing, or should it stay invisible and get out of the way? - Prompt: Mailchimp jokes with you. Stripe stays silent. Both are deliberate choices. - Examples: "Personality-forward — we want people to feel something" / "Invisible — it's a tool, writing should be furniture" / "Subtle — dry humor in the right moment, mostly invisible"
Q: Are there specific words, phrases, or industry terms you always want to use — or actively avoid? - Prompt: Vocabulary shapes trust. Using the wrong word in a medical or legal context can erode credibility instantly. - Examples: "Always say 'members' not 'users'" / "Never say 'synergy' or 'leverage'" / "Use 'veteran' not 'vet' — our users are specific about that"
Q: What platforms must this work on from day one — web, iOS, Android, or all three? - Prompt: Platform constraints shape everything from navigation patterns to typography to gesture support. - Examples: "iOS only for now, expand later" / "Web first — our users are on desktops at work" / "All three — it's a cross-platform workflow tool"
Q: Is there an existing brand guide, design system, or set of assets we have to work within? - Prompt: If yes, how strict are the constraints and how much creative latitude do we have? - Examples: "Full brand guide exists — colors and fonts are locked" / "Loose guidelines only — we're the first to build this" / "No guide yet — we're creating the standard with this product"
Q: What's the timeline pressure — are we building a quick MVP or a polished V1? - Prompt: This shapes how much complexity to design in and how many features to defer. - Examples: "Ship fast and learn — we want something in 6 weeks" / "Take time to get it right — this is a flagship product" / "MVP to stakeholders first, then iterate with real users"
Q: Are there accessibility requirements — screen readers, high contrast, large text, motor accessibility? - Prompt: Many products require WCAG 2.1 AA compliance. Even without a mandate, accessible design is better design. - Examples: "Required — healthcare products need full accessibility" / "Best effort — we want to do the right thing" / "Must support: screen readers, keyboard navigation, and sufficient contrast"
Problem statement: [One clear sentence defining the core user problem, written from the user's perspective.]
Who it's for: [Primary user — role, context, environment, motivation level.]
Why now / why this: [What gap exists in the market or existing tools that makes this worth building today.]
What it is NOT: [Explicit boundaries. What this product will never do or become.]
Core hypothesis: [If we build [X] for [user], they will [behavior/outcome], because [reason].]
Ideation notes:
Jobs to be done: - When [situation], I want to [motivation], so I can [outcome]. - When [situation], I want to [motivation], so I can [outcome]. - When [situation], I want to [motivation], so I can [outcome].
Moments of friction today (without this product): - [Friction point 1] - [Friction point 2] - [Friction point 3]
Moments of delight this product should create: - [Delight moment 1] - [Delight moment 2] - [Delight moment 3]
Key insight from discovery session: [The single most important thing learned that should influence every design decision.]
Core features (must ship): - [Feature 1] — [one line description of what it does and why it matters] - [Feature 2] — [one line description] - [Feature 3] — [one line description]
Supporting features (should ship): - [Feature 1] — [one line description] - [Feature 2] — [one line description]
Delight features (nice to have): - [Feature 1] — [one line description] - [Feature 2] — [one line description]
Explicitly deferred (not in scope): - [Feature or capability] — [reason for deferral]
Personalization & intelligence: [Does the product learn, adapt, remember? What data does it use and how does it surface it back to the user?]
Error & empty state handling: [How the product behaves when data is missing, an action fails, or a user is brand new with no content yet.]
Accessibility requirements: [WCAG level, screen reader support, contrast requirements, motor accessibility needs.]
Use this prompt in Figma Make, Claude, Google AI Studio, v0, or any generative design platform to produce a high-fidelity starting point.
Design a [platform: mobile app / web app / responsive web] called [Product Name] for [primary user description].
Product purpose: [One sentence — what it does and for whom.]
Emotional direction: The product should feel [adjective 1], [adjective 2], and [adjective 3]. Think [reference brand or product] in terms of restraint and tone, but warmer and more [differentiator].
Visual style: - Density: [minimal / balanced / dense] - Mode: [light / dark / both — default: X] - Color: Primary is [color/hex or description]. Avoid [color]. Supporting palette should feel [warm/cool/neutral]. - Typography: [editorial / utilitarian / geometric / humanist]. Reference: [font or brand]. - Imagery: [photography / illustration / icon-forward / data visualization / none] - Personality: If this product were a person it would be [persona description].
Key screens to generate: 1. Onboarding / splash 2. Home / dashboard 3. [Core feature screen] 4. [Core feature screen] 5. [Secondary feature screen] 6. Empty state 7. Error state 8. Settings / profile
Do not: - [Anti-pattern 1 from discovery] - [Anti-pattern 2 from discovery] - [Anti-pattern 3 from discovery]
References to match energy from: - [Reference 1] - [Reference 2] - [Reference 3]
Individual prompts for each screen — paste directly into any design or generative AI tool.
Screen: Onboarding / Welcome Design a [light/dark] onboarding flow for [Product Name]. It should feel [adjective] and take no more than [X] steps. The value proposition should be front and center. Use [illustration / photography / icons] as the visual anchor. The CTA should be [button label]. Tone is [voice description]. No sign-up walls before the user sees value.
Screen: Home / Dashboard Design the main dashboard for [Product Name]. The primary action a user takes here is [action]. Surface [key data point or status] prominently. Secondary information includes [X, Y, Z]. Navigation is [bottom tab / side drawer / top nav]. The emotional feeling on this screen should be [adjective — e.g. calm and in-control]. Empty state should show [placeholder content or prompt to get started].
Screen: [Core Feature — e.g. Detail / Action Screen] Design the [feature name] screen for [Product Name]. The user arrives here to [task]. They need to see [information] and take [action]. Keep the interface [minimal / structured / guided]. This screen should feel [adjective]. Include states for: loading, success, error, and empty.
Screen: [Core Feature — e.g. List / Browse Screen] Design the [feature name] screen for [Product Name]. This is a [list / grid / feed] of [content type]. Users scan this to [goal]. Prioritize [speed / richness / discoverability]. Each item should show [data point 1], [data point 2], and [status indicator]. Include filter/sort controls that feel [lightweight / prominent].
Screen: Empty State Design the empty state for [Product Name] for a brand new user with no data yet. It should feel [welcoming / motivating / instructive] — not broken or abandoned. Show a clear first action: [CTA]. Use [illustration / icon / minimal text] as the visual. Tone: [voice description].
Screen: Error State Design error and failure states for [Product Name]. When something goes wrong, the product should feel [calm / apologetic / proactive]. Always show: what happened, why, and what to do next. Never show raw error codes. Tone: [voice description].
Screen: Settings / Profile Design the settings and profile screen for [Product Name]. The user comes here to [manage account / customize experience / control notifications]. Keep it [simple / comprehensive]. Group settings by [category logic]. Tone is [neutral / functional]. Include: [profile info, notification preferences, appearance controls, account actions].
You leave with: Shared problem/solution framing, ideation notes, structured feature list, and ready-to-execute design prompts for any tool.
Lead: Kinsley (Product Designer) + John (PO)
Before you generate anything visual, Kinsley tightens the prompt. Lightweight mood notes, reference direction, aesthetic guardrails. This isn't a design system — no tokens, no formal documentation. It's Kinsley saying "based on what I heard, here's the direction I'd take this visually" and you nodding, adjusting, or redirecting.
Quick. Intentional. Sets the visual trajectory without over-investing.
The prompt is tool-agnostic — optimized for any design tool (Figma Make, Claude, v0, Midjourney, whatever you use). Not locked to one platform.
Downloadable output. The finalized prompt is available in the user's choice of format(s) — Doc, HTML, and/or PDF — selected via checkboxes or dropdowns. Pick one, pick all three, whatever you need.
You leave with: Finalized concept direction brief + execution-ready design prompt as a downloadable file in your chosen format(s).
Lead: Kinsley (Product Designer)
This is where you see your idea for the first time.
Kinsley produces multiple concept variations across all screens — not just a landing page. You need to see what features live in each section: the dashboard, the core feature screens, settings, onboarding, empty states, error states. The full product surface, at exploratory fidelity.
In Quorum, you scroll through the variations — a carousel or horizontal scroll of different directions your product could look and feel like. You see one you like. You select it. Now you get Refine — natural language instructions back to Kinsley ("make the header bolder," "this feels too corporate"), a Breakout window to open your design tool in another tab and iterate freely, and carry-back to bring your changes back into Quorum.
You might select multiple directions. You might refine one heavily and keep another as a reference. The point is: you're choosing, not just receiving. Your selections become the baseline concept set that everything downstream builds on. Because you've seen all the screens, you know what the product actually looks like end-to-end, not just the hero shot.
No formal token sets. No design system. Exploratory fidelity — enough to feel the idea, not enough to slow you down.
You leave with: Full-product concept variations (all screens), selected and refined, persisted in-app.
Lead: John (PO) + full team
Three things carry forward into this step: (1) your selected designs from 2b — the visual baseline; (2) the concept framing — names, labels, what each direction represents; (3) the core needs from step 1 — problem, users, constraints, risks, capabilities.
The AI produces a full sitemap — every section of the product mapped out, and within each section, what will potentially live there. Not just top-level navigation — the contents of each area, the features nested inside, the relationships between sections. Think of it as the product's table of contents with annotations.
Each section shows: what screens belong there, what capabilities exist, what data flows through, and how it connects to adjacent sections.
The AI clusters features and capabilities into themed groups with dependencies. You validate the groupings — merge, split, rename, reorder. The concept artifacts stay grouped alongside the structured data by theme, so when you move into the filter next, you're looking at features AND visuals AND needs together, not a detached spreadsheet.
You leave with: A complete product sitemap with every section mapped, contents defined, and features organized by theme — tethered to your designs and core needs.
Lead: All agents
Every feature and capability from Organize goes through three lenses: Desirability (do users want this?), Feasibility (can we build this?), Viability (does it make business sense?).
Two modes — user chooses upfront: - Collaborate — work alongside the AI agents, discuss each evaluation, argue back, make calls together in real-time - Let AI handle it — agents do the full analysis independently, you review the finished output and override where needed
Your initial designs, concept context, and core needs are all still visible — this is genuine collaboration (or transparent delegation), not an algorithm in a black box.
Regardless of mode, the agents internally research and compile answers to the full discovery question set — the same kitchen sink framework from step 1, but now with research backing:
The agents also run through a deeper design discovery analysis internally:
Core Idea validation — Does the one-sentence pitch hold up against market reality? Is the problem gap as real as assumed? What does success actually look like based on comparable product launches?
Feature validation — For each feature: user journey impact, single-feature importance ranking, competitive parity vs. differentiation, error/edge case complexity, personalization implications.
Aesthetic validation — Do the chosen adjectives and references align with the target user's expectations? Does the minimal/dense positioning match the use context? Are the anti-references actually being avoided in the concepts?
Visual identity validation — Color psychology alignment with product purpose, typography readability for target context (mobile in bright light, desktop in dim office, etc.), imagery strategy effectiveness for the audience.
User & audience validation — Day-in-the-life accuracy check, expert/beginner spectrum implications on feature complexity, motivation level impact on engagement design.
Reference validation — Competitor feature-by-feature comparison, overdesign/underdesign calibration against the product's actual complexity.
Copy & voice validation — Tone consistency across all touchpoints, vocabulary accuracy for the domain, personality level appropriateness for the audience.
Constraint validation — Platform capability gaps, brand guide compliance, timeline feasibility per feature, accessibility requirement impact on design/dev effort.
The analysis is a conversation. Agents have opinions and they defend them. Winston might say "this feature is a 6-month project disguised as a 2-week feature — I'd push back on this in a real standup and I'm pushing back now." John might counter with business value. You argue back. You see the reasoning, the sources, the data points. You make the final call.
Cut a feature — the frames reflow or drop. Argue one back in — they restore. You're watching your product take shape in real-time as decisions land.
V1: Research-grade analysis — AI reasoning, web research, specific competitors with names and links, user quotes, data points with sources, complexity breakdowns. Full audit trail — every recommendation shows what data was considered, what was weighted, what was excluded and why. V2: Evidence-grade, powered by real production data.
You leave with: A filtered, ranked, defensible feature set with per-pillar rankings, overall priority order, release allocation recommendations, and concept visuals reflecting final scope.
Lead: John (PO) + Winston (Dev Lead)
The AI team produces formal requirements from your filtered vision. This isn't you writing a PRD — it's your team writing it for you, from everything they've learned.
Output is HTML (for in-app viewing, sharing, static export) and Word (.docx) — both generated from the same source so content never drifts. The PRD references your post-filter concept visuals and explicitly notes that high-fidelity design, tokens, and design system come later at 5.25.
Solo founder or enterprise PM — same deliverable, different depth and template.
You leave with: A complete PRD in two formats, ready to share or hand off.
Lead: Mary (UX Researcher) + Kinsley (Product Designer)
Two kinds of journeys: user journeys (in-product flows — how someone actually moves through your product screen by screen) and customer journeys (discovery → purchase → onboarding → retention → expansion — the full lifecycle).
Visual diagram output, not text walls. The journeys reference your concept visuals and pressure-test them against real flows. Where does the user get stuck? Where is the emotional low point? Where's the transition that needs to feel seamless?
This step surfaces gaps that design refinement (5.25) needs to close. It defines screen-to-screen paths and the emotional state at each transition — which feeds directly into Luca's motion work at 5.5.
You leave with: Visual journey maps covering both product flows and customer lifecycle, with transition points and emotional beats mapped.
Lead: Kinsley (Product Designer) + Mary (UX Researcher)
Now — and only now — the design gets serious. And everything gets updated.
First, journey maps are updated based on all the research, analysis findings, and decisions made through the pipeline so far. Anything learned in the three-pillar analysis, PRD generation, or journey mapping that affects flows gets folded back in. No stale journeys survive this step.
Then Kinsley updates all screens and their content. Every screen gets reviewed against the current truth — what features actually belong where, what content lives on each screen, what the hierarchy is. Nothing stale survives this step.
High-fidelity static screens aligned to updated journeys. Formal design tokens — color, typography, spacing, all documented. Design system planning — reusable components, patterns, the vocabulary your product speaks visually.
This is the first mandatory point in the pipeline for tokens and design system work. Everything before this was intentionally exploratory — you don't invest in production-grade design until requirements and flows are anchored.
Mary supports journey alignment and catches UX edge cases. The output reaches implementation-ready spatial specs — what Jaymes will build from, what Luca will animate on top of.
You leave with: Refined designs, updated journeys, token inventory, design system plan, tool-ready design prompts, and doc/HTML exports of everything.
Lead: Luca (Motion Designer) + Kinsley (Product Designer)
Luca enters.
He ingests the journey maps and Kinsley's refined designs — spatial relationships, component hierarchy, tokens. Then he choreographs:
Every spec includes the feeling ("this transition should feel like opening a gift") backed by technical values (duration: 300ms, easing: cubic-bezier(0.4, 0, 0.2, 1)) and reduced-motion fallback (crossfade, 150ms).
You leave with: Per-screen, per-transition, per-element motion specifications in both text and HTML formats.
Lead: John (PO) + Winston (Dev Lead)
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.
You leave with: A phased release plan with motion work scoped in.
Lead: Winston (Dev Lead) + John (PO)
Cost and timeline per release. Confidence ranges, not hard numbers. Now includes motion implementation effort. Enterprise: calibrates to team actual velocity over time, not generic benchmarks.
You leave with: Realistic cost/timeline estimates with confidence ranges.
Lead: John (PO)
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). This is not a one-shot export. You review, adjust, art-direct, iterate until it's right.
When ready, export to: - PDF — presentation-ready, shareable - DOC — editable, for further refinement outside Quorum - HTML — web-viewable, linkable
You leave with: A polished, user-refined pitch deck exported in PDF, DOC, and HTML.
Lead: Bob (Scrum Master) + Winston (Dev Lead)
The pipeline's output becomes the build's input. Everything breaks into epics and stories.
Stories are the critical handoff artifact — they drive external AI coding tools, so they must be incredibly detailed. Each story includes: acceptance criteria, referenced design specs (Kinsley), motion specs (Luca), technical architecture context, file paths, and testing requirements.
Backend check happens here: Does this product need backend infrastructure? If yes, Damien activates and backend-specific stories are created alongside frontend stories.
Enterprise: integrates with existing Jira/Linear workflows.
You leave with: A sprint plan with implementation-ready stories. The thinking is done. The building can begin.
Lead: Winston (Dev Lead) + Jaymes (Frontend, always) + Damien (Backend, conditional)
Quorum doesn't write code. Quorum is the brain — the external AI coding tool is the hands.
Quorum generates story files. You open a story in Cursor, Claude Code, Windsurf, whatever you use. The Quorum agent persona provides domain-specific direction and constraints. The coding tool writes the code. Tests run. Story marked complete.
Jaymes is always active — the product started as a design, there's always frontend to build. He consumes Kinsley's design specs and Luca's motion specs and translates them into pixel-perfect, responsive code. Damien activates when there's backend to set up — database, auth, API, deployment.
Quorum maintains the sprint board, tracks progress, enforces quality gates. The external tool types. Quorum thinks.
You leave with: Working code, tested, matching your specs.
Lead: Quinn (QA Engineer)
Systematic test execution against PRD acceptance criteria. Automated test suites validate functional correctness. Motion implementations validated against Luca's specs. QA can be orchestrated through the same external AI coding tools — Quinn generates test stories, coding tool writes and runs the tests.
You leave with: Validated, tested product.
Lead: Cipher (Security Agent)
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.
You leave with: Security clearance or a punch list of what to fix.
Lead: User + Kinsley (Product Designer) + Luca (Motion Designer)
The design accountability checkpoint. You — the person who started with an idea in step 1 — validate that the built product matches the vision you've been refining since the beginning.
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.
You leave with: Approval to ship, or specific fixes to make.
Lead: Winston (Dev Lead)
Production release after QA, security audit, and UAT approval. Go.
Lead: All agents
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?"
V2 upgrades the three-pillar analysis from research-grade to evidence-grade with real production data.
Lead: John (PO) + Kinsley (Product Designer)
A comprehensive document that summarizes 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.
Covers: - The 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
Shows the evolution, not just the result — how the product evolved from a sentence to a shipped product through a structured, team-driven process.
You leave with: A polished, visual process document ready for portfolio use.