# Mode PLG Launch Growth Motion This document aligns Mode's initial launch and growth motion. It defines the growth system we want to build around Mode as self-serve becomes the primary product entry point. The goal is to align on: - the softer launch approach we want to take; - the wedges we want to test; - the launch loops we want to run; - the role self-serve should play in the growth system; - how PQL and SLG support should sit underneath PLG; - the messaging and proof guardrails that keep the motion credible. Target audiences are covered in [[mode-icp-ecp]] User-title test tracking lives in [[user-title-testing-checklist]] ___ #### Agent Context: **Strategic Context** Mode should not begin with a hard sales-first launch or a single big announcement moment. The product is moving toward self-serve, which means the growth motion should be PLG-first: bring users into the product, help them experience the workflow, and let usage reveal which people and companies have real intent. The current evidence base is strong enough to act on, but not strong enough to overclaim. Mode has promising positioning around real-product design, production-aware UI changes, design QA, UI polish, existing-codebase context, and engineering review. But these need to be tested through actual market response and product usage. The launch motion should therefore do two things at once: 1. create awareness and participation around Mode's worldview; 2. bring relevant users into self-serve so we can learn from real behavior. PQL and SLG support should exist underneath this motion, but they are not the primary launch motion. They support high-signal users after product interaction. **Core Launch Thesis** Mode should grow through multiple soft launch loops that create awareness, invite participation, and bring users into self-serve, rather than relying on one large launch moment or a direct sales-first motion. The initial launch should feel like: > Mode is inviting designers, design engineers, and product teams into a new way of working closer to the real product. Not: > Mode is pushing a finished enterprise sales narrative before the market language and proof are fully validated. The launch should be: - softer rather than hard-sell; - product-led rather than sales-led; - learning-oriented rather than claim-heavy; - multi-loop rather than single-campaign; - proof-building rather than purely promotional. ___ ___ ## Starting Positioning The starting positioning should be treated as provisional. It is the best current frame to test, not a final answer. Current starting point: > Mode helps designers and product teams work directly with real product UI, turning product polish and design QA issues into production-aware changes with engineering review intact. USP/value-prop variants to test against this positioning live in [[usp-value-prop-testing-checklist]]. Important boundaries: - Mode should not lead as a generic Figma-to-code tool. - Mode should not sound like another blank-canvas AI app builder. - Mode should not imply that designers bypass engineering review. - Mode should not overclaim production readiness, design-system fidelity, or speed gains until proof assets support those claims. - Mode should use engineering review as a trust layer, not a limitation. ___ ## Initial Wedges to Test These wedges are not final taglines, CTAs, or value propositions. They are strategic directions to test through the launch loops and product behavior. Detailed test checklists for wedges, CTAs, USPs/value props, and user titles live in separate testing docs. This section only defines the strategic wedge areas. Related testing doc: [[wedge-testing-checklist]]. ### - Design directly in the real product This is the broadest and most category-shaping wedge. Core idea: > The product, not the mockup, is becoming the most important design surface. Strategic question: - Does the market resonate with moving design work closer to the real product? - Does this direction distinguish Mode from Figma, handoff, app builders, and AI coding tools? ### - Fix one real product UI issue This is the most product-entry-oriented wedge because it frames Mode around a specific real-world job rather than abstract exploration. Core idea: > [!"reviewable" might not be the best wording for this, but essentially don't send it back to dev to build] > > Bring one visible UI issue from your actual product and see how Mode can help make it reviewable. Strategic question: - Does focusing on one concrete UI issue create a clear bridge between GTM messaging and product activation? - Does this make Mode feel immediately useful rather than abstract? ### - Design QA without another engineering cycle This is the most pain-led wedge. Core idea: > Design QA and UI polish should not get trapped in endless screenshots, tickets, and engineering backlog cycles. Strategic question: - Is design QA / polish debt urgent enough to drive product usage? - Do designers feel this pain strongly enough to act? - Does this resonate more with small design teams and engineering-heavy product companies? ### - Production-aware AI for existing products This wedge contrasts Mode against blank-canvas AI app builders. Core idea: > Most product teams are not starting from zero. They need AI that understands and works with the existing product and differentiate us from generic AI app builders. Strategic question: - Do users understand the difference between generating a new app and improving an existing product? - Does existing-codebase context feel like a key differentiator? - Does this help Mode avoid being grouped with generic AI app builders? ### - Design-system faithful product changes This is a trust and enterprise/design-system wedge. Core idea: > Product UI changes should respect real components, tokens, patterns, and engineering standards, not just be influenced by them (like most ai builders) but actually use them. Strategic question: - Is design-system fidelity a primary buying hook or a supporting proof layer? - Does this resonate more with design-system operators, design engineers, and mature design orgs? - What proof is required before this claim can be made strongly? ### - Designer-to-engineering review handoff This is the workflow and trust wedge. Core idea: > Designers can propose production-aware UI changes while engineers stay in the review path. Strategic question: - Does “designers propose, engineers review” make adoption feel safer? - Does it reduce resistance from engineering stakeholders? - Does it help Mode position as workflow leverage rather than engineering replacement? ___ ## Growth Model Overview The growth model is multi-loop and PLG-first. Each loop creates attention, engagement, or learning around one or more wedges. The loops route relevant users toward self-serve. Product usage then creates signal. High-signal users can receive founder, sales, or product support. Simple model: > Content / proof / outbound / resources / community → self-serve → activation → PQL signal → SLG support ## Launch Loops ### - Content / Narrative Loop Purpose: - shape the market narrative; - establish Mode's worldview; - test language around the wedges; - create recognition around the workflow gap Mode solves. The content should not be generic product marketing. It should make people feel the problem and understand the shift. Useful themes: - real product over mockups; - design QA is broken; - UI polish debt is product debt; - AI app builders miss existing-product workflows; - designers are moving closer to production; - handoff is a workaround, not the ideal end state. Example angles: - The real design surface is the product, not the file. - Design handoff is breaking in AI-native product teams. - Most AI design tools are solving the wrong problem: new apps, not existing products. - Design QA should not be a graveyard of screenshots and tickets. ### - Product Proof / Demo Loop Purpose: - make Mode believable; - turn claims into visible proof; - show the workflow rather than only describing it; - create reusable assets for content, outbound, community, and onboarding. The proof should be small and specific. Short workflow moments are better than broad product tours. Useful proof assets: - before/after UI polish examples; - real product surface edits; - visual edit to live preview; - reviewable output or PR/diff handoff; - component and token adherence examples; - examples of respecting existing product context. Example demo moments: - Designer spots a visible UI issue. - Mode helps make a production-aware change. - The change respects existing UI patterns. - The output is ready for engineering review. ### - Outbound / Research Loop Purpose: - discover pain; - mine market language; - understand current substitutes (not direct competitors); - invite relevant users into resources, community, or self-serve; - avoid making the first touch feel like a sales pitch. Outbound should be research-first and relevance-first. Useful prompts: - How does your team handle design QA today? - What happens when shipped UI does not match the design? - Who fixes UI polish issues in your product? - Do designers ever touch production UI? - Are you using AI anywhere between design and code? - What tools or workflows do you rely on after Figma handoff? ### - Resource Loop Purpose: - create a useful non-sales reason to engage; - support outbound and community; - build authority around the problem space; - give people something valuable before asking them to try the product. Potential resources: - Design QA Workflow Map; - Production UI Polish Checklist; - AI-Native Design-to-Production Landscape; - Design QA / UI Polish Survey; - Existing Product UI vs Blank-Canvas AI Builders comparison; - Design-to-Production Workflow Guide. ### - Community Loop Purpose: - gather people exploring the shift from design to production; - create a softer social surface around Mode's worldview; - learn from designers, design engineers, and product builders; - identify early users without making the group feel sales-led. The community should not initially be framed as “the Mode user community.” It should be an identity and discussion space around the emerging workflow. Potential frames: - AI-native product design; - design-to-production workflows; - real product design; - production UI and product polish; - designers working closer to production. What should happen inside: - curated discussions; - workflow sharing; - product UI / design QA teardowns; - office hours or salons; - resource collaboration; - early access conversations where relevant. What to avoid: - making the group feel like a vendor channel; - heavy asks before there is support or pull; - turning every interaction into a sales CTA; - making the scope so broad that it becomes generic “AI design.” ___ ## Self-Serve Product Entry Self-serve is the primary product entry point for this motion. The launch loops should not only create attention; they should create enough curiosity and relevance for users to enter the product and experience Mode directly. At a strategic level, the self-serve experience should connect Mode's narrative to a real product workflow. Users should understand that Mode is not just another AI design surface, but a way to work against an actual product context and produce something closer to a reviewable change. The exact CTAs, onboarding prompts, and product-entry variants should be defined and tested in separate testing docs. This document only establishes that self-serve is the center of the PLG motion and that the first experience should be tied to real product UI work rather than generic exploration. Related testing doc: [[02-cta-testing-checklist]] The first meaningful product belief we want to create: > This could change how we move from design intent to shipped UI. ___ ## PQL / SLG Support Layer PQL and SLG support are the layers underneath PLG. The job of this layer is to identify high-intent usage and help good-fit users reach a real outcome. Potential PQL signals: User-title validation and role-specific signal tracking lives in [[user-title-testing-checklist]] - user tries Mode on a real product UI (codebase) issue; - user invites a teammate; - user asks about engineering review, security, codebase access, design-system fidelity, or team workflow (via helpdesk or community) - user describes a current design QA, handoff, or UI polish pain. (via helpdesk or community) - user emails is on a company domain The follow-up should feel like product help, not hard sales. The principle: > Let product usage create the sales signal, then support the users who show real need. ___ ## Messaging Principles These principles should keep the launch loops consistent. ### - Lead with real product workflows The strongest frame is not abstract AI design. It is working closer to the actual product. ### - Keep the product entry grounded in real work The launch motion should point users toward real product UI work rather than generic exploration. Specific CTA variants belong in separate testing docs. ### - Use soft language while proof is forming Prefer: - explore; - try; - test; - production-aware. ### - Do not lead with generic Figma-to-code Figma-to-code may be useful in comparison or search contexts, but it should not define Mode's primary positioning. ### - Do not sound like a blank-canvas app builder Mode's distinction is existing product context, production-aware UI work, and reviewable changes. ### - Keep engineering review intact Mode should not imply that designers bypass engineers. The safer and more credible frame is: > Designers propose. Engineers review. ### - Use design QA and UI polish as concrete pain These are practical problems people recognize quickly. ### - Treat design-system fidelity as a proof/trust layer until validated as a primary hook Design-system fidelity matters, but we need evidence on whether it is a primary launch wedge or a supporting trust claim. ___ ## Evidence Base / Related Docs Strategy and synthesis: - [[01-mode-launch-positioning-synthesis]] - [[02-mode-usp-value-prop-hypotheses]] - [[03-mode-opportunity-map]] - [[05-mode-icp-persona-fit-matrix]] - [[06-mode-keyword-search-language-map]] - [[09-mode-competitor-evidence-baseline]] - [[10-modeinspect-data-backed-competitor-baseline-review]] Testing docs: - [[wedge-testing-checklist]] - [[02-cta-testing-checklist]] - [[usp-value-prop-testing-checklist]] - [[user-title-testing-checklist]]