季初的整體配置#
季初時，公司有 16 個產品團隊，組成如下：
角色 人數 工程師 60 產品經理 12（注意只有 12 個 PM，但有 16 個團隊——下方說明） 產品設計師 10 使用者研究員 2 資料分析師 3
匯報結構：
- 2 位 PM 總監（雇主端 & 求職者端）+ 1 位 UX 設計總監 → 都向 CPO 匯報
- 3 位工程總監（雇主、求職者、平台）→ 都向 CTO 匯報
拓撲總覽#
公司的拓撲分為三組：
體驗團隊：對齊兩種主要顧客#
- 雇主團隊（5 個團隊）
- 求職者團隊（6 個團隊）
平台團隊：為兩端體驗團隊提供基礎#
- 平台團隊（5 個團隊）——大約 1/3 資源
雇主端的 5 個團隊#
雇主端的存在是為了滿足招募經理與 HR 部門。當前模式：第一個職缺免費（freemium）；額外刊登或精選方案需付費。
| 團隊 | 責任範圍 |
|---|---|
| Employer Home | 雇主儀表板（顯示職缺與應徵狀態）、發布職缺、SEO 自然搜尋曝光 |
| Recruiter Tools | 進階能力（大量職缺管理、應徵流程、面試與決策、主動搜尋求職者並接觸） |
| Premium Services | 各類加值方案（email 推送、精選職缺等） |
| Employer Communications | email、簡訊、推播；交易性（職缺狀態）與行銷性（鼓勵發更多職缺）；新雇主線上招募（SEO、SEM） |
| Enterprise Tools（新團隊） | 滿足大型企業所需能力，例如與大型 ATS（applicant tracking system）整合 |
Enterprise Tools 團隊後來嵌入了一位全職產品行銷人員——因為要做的關鍵 go-to-market 工作量極大（建立可被引用客戶、go-to-market 考量、業務啟用素材的準備）。這對「產品要進入新區隔或新業務」的場景是很好的實踐。
求職者端的 6 個團隊#
| 團隊 | 責任範圍 |
|---|---|
| Seeker Home | 求職者的核心體驗（網頁＋原生 app）：追蹤的職缺、應徵狀態、推薦 |
| Job Search | 依職缺屬性搜尋市場 |
| Job Recommendations | 從搜尋與履歷產生推薦 |
| Job Applications | 為特定職缺投遞——結合既有資料與該職缺特定資訊 |
| Seeker Communications | email、簡訊、推播——交易性與行銷性；新求職者線上招募（SEM、SEO） |
| Mobile Apps | iOS 與 Android 原生體驗——與 Seeker Home 緊密合作維持兩平台一致 |
此案例所在年份，許多公司因為 iOS/Android 工程師稀缺而設立專責的「原生 app 團隊」。約一年後，這項工作會回流到求職者各團隊（尤其 Seeker Home）——這通常是更好的解法。
平台端的 5 個團隊#
平台組織的存在是讓體驗團隊更有效率服務各自顧客。
| 團隊 | 責任範圍 |
|---|---|
| Shared Services | 認證、偏好設定等共用服務——把跨團隊重複工作收斂為單一方案 |
| Payments and Billing | 所有金流、訂閱、折扣、各種支付方式——複雜度由經驗豐富的小團隊封裝 |
| Data and Reporting | 報表基礎設施——餵給雇主／求職者儀表板，並支援公司其他部門的自助式報表 |
| Infrastructure | 確保技術基礎建設能滿足業務需求；領導重大技術債修復；協助其他工程師解決規模／效能問題 |
| Tools | 為各團隊提供生產力工具與更可靠系統——站點監控、測試／發版自動化（DevOps）、團隊協作 |
為何 16 隊只有 12 PM#
多數平台團隊的 PM 角色由 tech lead 兼任——這對部分團隊（Infrastructure、Tools、甚至 Shared Services）是可行的。
但對某些團隊（Payments and Billing、Data and Reporting），業務複雜度會壓垮 tech lead——後續本年度公司會為這些團隊新增專責的平台 PM。
「產品」的定義#
本公司的「產品」是整個求職媒合市場——上述 16 個團隊各自負責這個更大產品的子集合。