產品策略：把公司目標化為團隊行動#

公司目標清晰、產品願景與原則就位後，產品組織的領導者（CPO、CTO、與其下主管）需要更新產品策略以兌現公司目標。

不保證每個董事會的期望都能一年內達成。若領導者判斷不可行，會升級至 CEO，討論「增加投資」或「降低期望」或兩者混合。但在那之前，必須先與產品團隊充分對話。

公司目標是年度的，團隊目標是季度的——產品領導者與團隊有能力依進度、阻礙、新學習與新機會調整方向。

產品策略總覽#

回顧四個元素：

• 聚焦（Focus）：聚焦少數真正關鍵的目標
• 洞察（Insights）：辨識可以對這些目標產生衝擊的洞察
• 行動（Actions）：把洞察化為「每個團隊要追求的一組目標」
• 管理（Management）：主動追蹤進度、移除阻礙

聚焦#

公司高層已透過「縮減為兩個目標」幫助 focus 工作做了很多——若清單更長，產品策略就要先處理收斂。

被討論但未被選入本年度的機會：

• 地理擴張
• 對雇主的額外服務（驗證、藥檢）

脈絡也包含一條關鍵指引：追求新業務機會不能犧牲核心業務。

洞察#

核心業務目標的洞察#

期望成長 25%——但領導者意識到：只靠優化既有產品大概只能拿到 5 ～ 10%。

雖有自然成長，但已有新進競爭者出現，不能仰賴自然成長。必須：

• 比過去更好地照顧現有顧客（雙邊）
• 同時去贏取新顧客

雇主端：應徵數量的「最佳區間」#

KPI 與使用者研究的關鍵發現：

雇主想快速填補職缺，但希望給招募經理一組合格候選人。

• 沒有應徵 → 雇主失望
• 太少應徵 → 受挫、決策慢
• 太多應徵也是問題：難以篩選、決策變慢；最熱門職位收到爆量，留下大量失望求職者

數據顯示：8 ～ 25 份合格應徵之間時，職缺填補最快、招募經理最滿意。

這比帳面上看起來嚴重：最熱門的職缺正在收到太多應徵，造成大量求職者失望。

直接相關性：

• 應徵不足 → 雇主流失上升
• 應徵過多 → 求職者滿意度下降

求職者端：48 小時與 mobile app#

關鍵發現：

若求職者沒有在前 48 小時內提交至少一次應徵，極不可能再回來。

而只有 27% 的註冊求職者真的提交至少一份應徵。

第二個發現是意外的：

第一個洞察（48 小時黃金期）並不令人意外；第二個則出乎意料——註冊已經是「應徵流程的大部分工作」，為何這麼多人完成註冊卻沒應徵？

策略焦點：對應行動#

企業端目標：先求 product/market fit#

第二個目標相對清楚但不容易：建立新團隊，明確任務基於公司目標。

知道很多核心業務的假設可能在新產品上不成立——所以從識別 product/market fit 開始。

不希望團隊在追求 PMF 時被任何其他事分心。

預期會影響其他多個團隊（多數雇主端、Job Application、多數平台）——這些團隊需要把這項工作納為自己的目標支援。

重新平台化目標#

還有一個目標不來自公司高層或董事會，而來自產品領導者本身：重新平台化（re-platforming）。

背景：

• 公司因高速成長累積大量技術債
• 上一年工程組織提出兩年計畫：把組織轉到現代、AWS 為基礎、microservices 為基礎的實作
• 列出 20 個主要系統元件，按特定有意的順序逐季處理
• 估計約兩年完成
• 工程曾考慮「暫停其他工作以更快完成」，但會嚴重打斷業務——太冒險，採取漸進方案

當前是該計畫的第三季。

行動：開放團隊參與策略對話#

領導者本可以直接指派目標——但這會錯失關鍵資訊：團隊掌握的可用技術，以及他們對問題的點子與熱情。

因此把每季的團隊目標討論開放給整個產品組織：

• 產品長更新公司目標
• 進入產品策略，分享相關資料與洞察
• 接下來幾天，會帶著「為了這三個目標，我們需要解決的 1 ～ 2 個重要問題」找各團隊
• 但同時請各團隊先思考自己能怎麼貢獻

「若每個團隊都想做同一件事——當然不行；我們必須涵蓋三個目標。

但若團隊對某問題特別樂觀，我們很有動機盡力配合。」

管理：實際出現的阻礙#

接下來看實際的團隊目標前，要先說明過程中出現的主要阻礙——以及是怎麼處理的。

工作量集中#

• 過多工作落在 Employer Home 團隊
• 解法：把部分工作分給其他團隊 + 增加工程師（兩者並用）

跨團隊依賴#

• 最常見的阻礙——團隊發現自己依賴另一團隊（多半是平台團隊）
• 解法：管理者直接與相關方對話，做「horse trading」——多數時候能讓雙方滿意
• 偶爾平台團隊無法及時兌現 → 體驗團隊延後到下一季

SEO 支援#

• Employer Home 發現需要產品行銷的 SEO 支援
• 解法：本季把一位 SEO 人員嵌入該團隊
• 預期：改善 SEO → 吸引更多合格求職者 → 提升成功率

重新平台化的順序調整#

• Infrastructure 把計畫分享給各團隊
• Enterprise Tools 發現本季時程不利於他們的關鍵領域
• 解法：Infrastructure 調整本季排程，避免重做工作

平台請求的優先序#

• Shared Services 收到大量來自體驗團隊的請求清單，需要協助排優先序
• 解法：給予優先指引；某些情況下讓體驗團隊自己撰寫所需軟體並回饋給平台（需 Shared Services 核可）

這家公司鼓勵所有團隊成員參加策略簡報會議——他們深信工程師在創新中扮演的角色。其他公司可能只請 PM、設計師、tech lead，或只請 PM——這是文化與規模的選擇。