| 1 | --- |
| 2 | style_id: product-launch |
| 3 | kind: style |
| 4 | summary: Value-first launch method where every capability claim is earned by a demonstrable moment before it is named. |
| 5 | keywords: [product, launch, positioning, demo, capability] |
| 6 | --- |
| 7 | |
| 8 | # Product Launch — Style Specification |
| 9 | |
| 10 | > Method and design defaults only. No project communication contract, brand identity, page structure, or SVG prototypes. |
| 11 | |
| 12 | ## I. Style Overview |
| 13 | |
| 14 | | Property | Value | |
| 15 | |---|---| |
| 16 | | Style Name | Product Launch | |
| 17 | | Best Fit | Product and feature launches, release keynotes, capability announcements, roadmap reveals, and customer-facing product briefings | |
| 18 | | Reusable Intent | Make an audience feel the problem, see the capability work, and leave knowing what changed for them and what to do next | |
| 19 | | Sources | Authored in-repo as a bundled reference Style, 2026-08-07; distilled from launch-presentation practice, not a single external document | |
| 20 | |
| 21 | ## II. Communication Method |
| 22 | |
| 23 | - **Preferred Mode**: showcase |
| 24 | - **Argument Flow**: Open on the tension the audience already lives with, show the capability resolving it, then widen to what it makes possible and what to do next. Earn each claim with a visible demonstration before naming it; adapt the number and order of capability beats to what actually shipped rather than filling a fixed reveal template. |
| 25 | - **Page Message Discipline**: Give each page one capability, one benefit, or one moment. Write the title as what the audience gets, not as a feature name, and let the demonstration occupy the page rather than a bulleted description of it. Never combine two reveals on one page to save space. |
| 26 | - **Claim Discipline**: Keep shipped, in-preview, and planned capabilities visibly distinct, and never let a roadmap item borrow the certainty of a demo. Attribute performance and outcome numbers to their measurement or customer, mark selected or representative results as such, and pair any comparison with its basis and date. |
| 27 | |
| 28 | ## III. Page Role Vocabulary |
| 29 | |
| 30 | | Role | Communication Job | Evidence Obligation | Composition Tendency | |
| 31 | |---|---|---|---| |
| 32 | | Opening tension | Make the audience recognize the problem as theirs | Ground the problem in observed behavior, cost, or a real workflow, not a caricature | Lead with one concrete situation and keep the page uncrowded | |
| 33 | | Positioning claim | State what this is and who it changes things for | Say what it replaces or removes; avoid category words that fit anything | Give the claim the page and let one supporting line qualify it | |
| 34 | | Capability reveal | Introduce one capability by showing it | Show the actual behavior — interface, output, or result — not an icon standing in for it | Let the artifact dominate; keep naming and explanation subordinate | |
| 35 | | Demonstration moment | Let the audience watch it work | Use a real path with real input and honest timing; disclose any acceleration or staging | Give the demo the full frame with minimal chrome around it | |
| 36 | | Before and after | Make the improvement felt rather than asserted | Keep both sides comparable in task, scale, and conditions | Place the two states in direct correspondence and mark the difference once | |
| 37 | | Proof point | Establish that the improvement holds outside the demo | Attribute metrics, customer results, or benchmarks with scope, period, and method | Keep one number or one quote dominant instead of a wall of validation | |
| 38 | | Capability landscape | Show how the pieces fit for someone adopting several | Represent only shipped relationships; mark preview and planned parts | Favor a clear arrangement over an exhaustive feature inventory | |
| 39 | | Availability and access | Answer when, where, how much, and for whom | State regions, tiers, limits, and preview conditions precisely | Keep terms scannable and never bury a material limitation in fine print | |
| 40 | | Next step | Convert interest into a first action | Give a concrete, reachable action with its prerequisite | End on a single dominant action rather than a menu | |
| 41 | |
| 42 | ## IV. Evidence & Data Expression |
| 43 | |
| 44 | - **Argument Trace**: Every capability claim traces to something the audience can see now or verify later — a demonstration, an attributed metric, a customer result, or documentation. Claims that trace to none of these are cut rather than softened with confident wording. |
| 45 | - **Charts**: Use a chart only when a number is the point. Show one comparison per chart, start value axes at zero for magnitude claims, keep units and period visible, and annotate the improvement directly instead of leaving the audience to compute it. Never crop an axis, omit a baseline, or select a window to make a difference look larger than it is. |
| 46 | - **Tables**: Reserve tables for availability, tiers, limits, and capability matrices. Keep rows comparable, state units and constraints in the header, and mark preview or planned entries explicitly. Avoid competitor comparison tables that omit the axes on which the alternative wins. |
| 47 | - **Sources**: Attach measurement basis, scope, period, and version to every performance or outcome claim, close to where it appears. Name the customer only with permission and keep quotes intact rather than trimmed toward a stronger reading. |
| 48 | - **Native Editability**: Prefer editable native charts and tables for benchmark, pricing, and availability data so figures can be corrected before or after the event. Keep product screenshots and captured interface states as images; do not recreate a real interface as approximate shapes and present it as what the product shows. |
| 49 | |
| 50 | ## V. Visual System Defaults |
| 51 | |
| 52 | - **Preferred Visual Style**: photo-editorial |
| 53 | - **Composition**: Build the page around the artifact — screen, output, or result — and let the message sit in its own quiet region rather than competing with it. Use generous single-focus pages for reveals and reserve multi-region composition for landscape and availability pages. Maintain a consistent position for the recurring message region so attention returns to the same place. |
| 54 | - **Density**: Keep reveal and demonstration pages sparse enough that the artifact reads instantly at room scale. Allow density only on landscape, availability, and specification pages, and keep even those scannable in a glance from the back of a room. |
| 55 | - **Decoration**: Let the product imagery and typography carry the page. Use restrained framing, device or window treatment applied consistently, and a single accent for emphasis. Avoid stacked drop shadows, glow, gradient meshes, floating decorative particles, and badge clutter that competes with the artifact. |
| 56 | - **Color Behavior**: Keep the field neutral or dark so product imagery holds the eye, and reserve one accent for the reveal, the improvement, and the closing action. Do not recolor product screenshots to match the deck, and do not use a semantic status color decoratively. Any confirmed Brand or Deck identity replaces these tendencies. |
| 57 | - **Typography Character**: Use a confident sans-serif hierarchy with a large, well-spaced statement scale for reveals and a quiet, economical scale for terms and attribution. Let scale contrast — not ornament — signal what matters, and keep the statement voice consistent across pages. Exact families remain current-project or resolved identity decisions. |
| 58 | |
| 59 | ## VI. Image & Icon Direction |
| 60 | |
| 61 | - **Preferred Image Rendering**: corporate-photo |
| 62 | - **Image Usage**: Lead with real artifacts — interface captures, outputs, hardware, or people genuinely using the product. Use atmospheric or conceptual imagery only for opening and transition beats, never as a substitute for showing the capability. |
| 63 | - **Image Treatment**: Crop screenshots to the region that carries the reveal and keep their text legible at room scale, magnifying a detail instead of shrinking the whole window. Apply consistent framing and corner treatment, use a scrim only where text must sit over an image, and caption what to notice. Avoid distorted aspect ratios, mockups implying capabilities that do not exist, and synthetic text inside generated images. |
| 64 | - **Icon Treatment**: Use one coherent icon family at consistent weight, only to mark recurring capability classes, platforms, or states. Keep an icon's meaning fixed across the deck. Avoid icon grids used as a feature list, third-party logos as decoration, and mixed icon languages on one page. |
| 65 | |
| 66 | ## VII. Review Focus |
| 67 | <!-- visual-review-trigger: explicit-user-only --> |
| 68 | > Apply this section only after the user explicitly activates visual review. It never triggers that stage. |
| 69 | |
| 70 | - Each reveal page communicates one capability and its benefit at the rendered slide size. |
| 71 | - Product screenshots and their embedded text remain legible at room scale rather than only on a laptop. |
| 72 | - Shipped, preview, and planned capabilities remain visually distinguishable wherever they appear together. |
| 73 | - Numbers carry their basis, scope, and period; axes are not cropped and baselines are not omitted. |
| 74 | - Availability terms, limits, and conditions are readable and not reduced to unreadable fine print. |
| 75 | - The accent color marks emphasis consistently and does not compete with product imagery. |
| 76 | - The closing page presents one concrete action rather than a menu of possibilities. |
| 77 |