發佈策略
此技能可協助你使用結構化、可重複的框架來規劃和執行產品發佈。核心見解是：大多數團隊只會進行大型的、引人注目的發佈。藉由將每個部署都視為潛在的發佈時刻——並根據其重要性調整規模——你可以建立持續的知名度、獲取和啟用。目標是建立一個發佈引擎，而不是一次性活動。
發佈層級
每個版本都對應到三個層級之一。層級決定了訊息、資產和發佈所需投入的精力。
層級 1：重大新產品或平台轉型
全面發佈。這是你的重要時刻——一個新產品、重大品牌重塑或平台擴展。預計準備時間為 2-4 週。
典型資產： 發佈影片（動態設計或創辦人敘事）、專用目標頁面、部落格文章、新聞媒體推廣、社群活動（所有平台）、發送給完整名單的電子郵件、內部推廣。
層級 2：重大新功能
一個會改變使用者能力的實質性新增功能。足以值得單獨宣佈，但不需要全面的媒體推廣。預計準備時間為 1-2 週。
典型資產： 發佈推文/討論串、部落格文章或更新日誌條目、更新的目標頁面區段、發送給相關受眾區隔的電子郵件、在 2-3 個平台上發佈社群貼文。
層級 3：較小的改進和迭代
錯誤修復、UI 打磨、漸進式改進。仍然值得宣佈——它們顯示了動力和用心。準備時間：幾小時到一天。
典型資產： 更新日誌條目、單一篇社群貼文、可選的電子郵件摘要提及。
選擇層級
詢問：「如果一個潛在客戶看到這個宣佈，它會改變他們對這個產品能力的看法嗎？」如果「是」→ 層級 1 或 2。如果更多是關於品質和可靠性 → 層級 3。
如果不確定，就往高一層。發佈力道不足比用力過猛更常見。一個應該是層級 3 卻被當成層級 2 來發佈的成本只是多花幾個小時。但一個本該是層級 1 的發佈卻被當成層級 3 處理，就是錯失了一個成長機會。
訊息框架
訊息優先於一切。在訊息鎖定之前，不要建立任何資產。一段平庸的影片配上絕佳的訊息，其效果勝過一段華麗影片配上模糊的定位。
訊息簡報
對於每個發佈（任何層級），請定義：
-
名稱 — 你要怎麼稱呼它？對於有 SEO 潛力的功能，請使用搜尋資料來選擇。檢查人們實際上搜尋什麼（例如，「speech to text」與「transcription API」——如果目標受眾相符，選擇搜尋量較大的一個）。Google Trends 和關鍵字研究平台在這裡很有幫助。
-
目標受眾 — 誰是特定受益者？要精準。「開發者」太廣泛。「正在建立即時語音應用的後端工程師」給你一個明確的寫作方向。
-
主要價值主張 — 一句話。他們現在能做什麼以前做不到的事，或者什麼東西有了顯著改善？這將成為所有地方的標題。
-
次要價值主張 — 2-3 個支持要點。這些會填入部落格文章、目標頁面區段和討論串推文。
-
證明點 — 數字、基準測試、比較、客戶引言。任何能讓價值主張具體化而非空想的東西。
訊息測試
大聲讀出你的主要價值主張。如果它同樣適用於描述競爭對手的產品，那就太籠統了。最好的價值主張夠具體，讓目標受眾中的某人能立即知道這是否適合他們。
發佈檢查清單系統
建立一個主檢查清單，包含每一個可能的發佈行動，並按層級組織。對於每個新的發佈：
- 將主檢查清單複製到一個新的實例（新分頁、新工單、新頁面）
- 刪除不適用於此層級/發佈的列
- 為剩餘的列分配負責人和截止日期
- 將其作為發佈日當天的唯一事實來源
工具選擇
選擇一個系統並堅持使用。特定工具的重要性低於一致性。
- 試算表（Google Sheets、Notion 表格） — 最簡單。對小型團隊運作良好。一個主工作表，每個發佈一個分頁。缺點：沒有內建的分配或通知功能。
- 專案管理工具（Linear、Asana、Notion） — 更適合團隊。建立一個發佈範本專案。每個發佈都會複製一份，包含可分配的任務和截止日期。Linear 的標籤或 Asana 的區段可以對應到下方的層級欄位。
- 文件 + 檢查清單（Notion、Google Docs） — 折衷方案。一個帶有核取方塊的範本文件。易於複製，但難以跨發佈追蹤狀態。
無論使用哪種工具，請在每次回顧後更新主範本。這個範本是一份活文件——它會隨著每次發佈而變得更好。
檢查清單範本結構
| 類別 | 行動 | 層級 1 | 層級 2 | 層級 3 | 負責人 | 截止日期 | 狀態 |
|---|---|---|---|---|---|---|---|
| 訊息 | 撰寫訊息簡報 | ✓ | ✓ | ✓ | |||
| 訊息 | 為命名進行 SEO 關鍵字研究 | ✓ | 可選 | — | |||
| 資產 | 發佈影片 | ✓ | 可選 | — | |||
| 資產 | 目標頁面（新建或更新） | ✓ | ✓ | — | |||
| 資產 | 部落格文章 | ✓ | ✓ | 可選 | |||
| 資產 | 更新日誌條目 | ✓ | ✓ | ✓ | |||
| 社群 | 發佈推文/討論串 | ✓ | ✓ | ✓ | |||
| 社群 | LinkedIn 貼文 | ✓ | ✓ | 可選 | |||
| 社群 | 其他平台（BlueSky、Threads） | ✓ | 可選 | — | |||
| 發佈管道 | Product Hunt 提交 | ✓ | 可選 | — | |||
| 發佈管道 | Hacker News 貼文 | ✓ | 可選 | — | |||
| 發佈管道 | 新聞媒體/記者推廣 | ✓ | — | — | |||
| 發佈管道 | 邀請網紅/網路轉發 | ✓ | ✓ | — | |||
| 電子郵件 | 完整名單宣佈 | ✓ | — | — | |||
| 電子郵件 | 特定受眾區隔電子郵件 | 可選 | ✓ | — | |||
| 電子郵件 | 更新日誌摘要提及 | — | 可選 | ✓ | |||
| 內部 | #amplify 頻道貼文 | ✓ | ✓ | 可選 | |||
| 內部 | 團隊簡報 | ✓ | 可選 | — | |||
| 追蹤 | 為所有連結設定 UTM | ✓ | ✓ | 可選 | |||
| 追蹤 | 驗證分析事件是否觸發 | ✓ | 可選 | — | |||
| 追蹤 | 記錄基準指標 | ✓ | ✓ | — | |||
| 發佈後 | 安排回顧（一週後） | ✓ | ✓ | — |
發佈時間表
層級 1 時間表（2-4 週）
發佈前 3-4 週： 鎖定訊息簡報。開始目標頁面和影片製作。開始新聞媒體推廣（記者需要前置時間）。
發佈前 1-2 週： 完成所有資產。撰寫社群文案。準備電子郵件。向內部團隊簡報。設定追蹤（UTM、分析事件）。執行一次發佈管道的模擬演練。
發佈當天： 依序執行發佈管道——先社群（上午），然後電子郵件，最後新聞禁令解除。全天監控並回覆留言與回應。
發佈後一週： 進行回顧。
層級 2 時間表（1-2 週）
發佈前 2 週： 鎖定訊息。開始撰寫部落格文章和更新目標頁面。
發佈前 1 週： 完成文案。撰寫社群貼文。準備受眾區隔電子郵件。
發佈當天： 發佈社群貼文、發佈部落格文章、發送電子郵件。回覆回應。
發佈後 3-5 天： 快速回顧（非同步，例如 Slack 討論串）。
層級 3 時間表（當天或隔天）
推出它。撰寫更新日誌條目和一則社群貼文。完成。如果這是一批小型改進的一部分，將它們捆綁成一個每週摘要。
發佈後回顧
不要跳過這一步。回顧是將個別發佈轉變為複合發佈引擎的關鍵。
需要涵蓋的內容
- 什麼有效？ 哪個管道帶來了最多的流量、註冊或互動？哪個訊息引起共鳴？
- 什麼沒效？ 哪些資產表現不佳？時間表在哪裡延誤了？
- 意外之處？ 是否有意料之外的管道爆紅？某個特定的表述方式是否比預期中效果更好？
- 數字 — 流量、註冊、啟用、社群互動、新聞報導。如果有資料，請與先前的發佈進行比較。
- 檢查清單更新 — 根據所學到的經驗，從主檢查清單中新增或移除項目。
回顧形式
保持輕量。對於層級 2，一個 Slack 討論串或 15 分鐘的通話就足夠了。層級 1 則需要一份簡短的文件。關鍵產出是對檢查清單和流程的具體更改，而不是一篇回顧性文章。
「任何發佈都是機會」的理念
如果你每個月部署多次，但每季只發佈幾次，那你正在錯失成長機會。每次部署都是一個訴說故事、提醒人們你的存在並展現動力的機會。
這不代表每個錯誤修復都需要一則新聞稿。而是意味著每個改進都應該有某種宣佈，並根據其重要性調整規模。層級 3 的發佈只需幾分鐘。持續曝光的複合效果是巨大的。
養成習慣：當 PR 合併時，就開啟發佈檢查清單。
與配套技能協作
此技能負責策略與規劃。若要執行，請參考：
- launch-tweet — 撰寫社群文案（推文、討論串、LinkedIn、跨平台）
- launch-email — 電子郵件主旨行、宣佈結構、受眾區隔、更新日誌摘要
- launch-blog-post — 撰寫宣佈貼文（結構、SEO、AEO）
- launch-video — 示範影片、GIF、螢幕截圖以及使用 Remotion 的程式化影片
- launch-landing-page — 建立目標頁面（結構、急迫性機制、SEO、轉換）
- launch-distribution — 按管道劃分的發佈管道和發佈日當天的執行順序
- launch-metrics — UTM 設定、按層級劃分的 KPI、基準預期、回顧資料框架