工程師聊產品開發

除了領票、開發、交付外，那些我們必須知道的事。

關於 CL

• MarTech 新創, Cloud-based, 典型的 B2B 商業模式

• 願景：build #1 cloud solutions to transform our clients to better communicate with their customers.

• 100-150 員工, 30 人產品團隊
• 600+ 客戶 (台日泰)

船長經歷過些什麼 (2年10個月)

• CAAC 的創始工程師
• 橫向串連 CL 產品，實現縱效的產品策略
• 見證：30+ 到 100+ 員工
• 現在：跨產品的技術決策＆產品開發團隊輔導

CL 的每個產品有自己專屬的產品團隊

• 獨立的 product backlog 與 roadmap。
• 產品導向的團隊編制
• 執行單元 (Squad)
  => 1 PM, 1 PD, 2-6 Engineers

團隊文化

• 顧客群體的最佳利益
  • (X) 客製化, (O) 產品化
  • (X) 收益最大化, (O) 顧客關係
• 沒有局外人=> 成員們一起為產品的成敗當責。
• 在失敗中前進 (Fail forward)  => 失敗是必然的。從失敗中學習，持續前進。

產品開發流程百百種，但不外乎幾件事

1. 探索：透過市場分析、使用者訪談，找出顧客痛點、潛在機會
2. 定義：定義問題 (Why)
3. 設計：設計解決方案 (What)、制定規格 
4. 交付：功能設計 (How)、實際開發與交付
5. 發佈：功能上線、市場驗證、後續維運

核心議題

• 問題：「痛點是什麼」
• 價值：「為什麼顧客在乎」、「市場有多大」
• 成本：「怎麼解決」、「如何實現」、「成本有多高」
• 風險：「不確定性有多高」、「如何降低風險」

在 CL，人人有功練，力求發揮每個角色的最大影響力 🚴⛹🏋🏌🤸

向前站的產品開發策略

• PM 負責“問題”與“價值”
  • 了解顧客與市場，定義問題與產品行銷
  • 說服團隊一起解決當前的問題
• PD 與 Engineer 一起負責“成本“，設計解決方案
  • PD 設計功能性的產品體驗 (UI, User Flow)
  • Engineer 設計非功能性的產品體驗 (Latency, Reliability, Cost)
• Engineer 負責管理"風險"
  • 專案管理 
  • 透過實踐敏捷與 DevOps，持續交付。
• PM、PD、Engineer 共筆 PRD

產品面向：

• 增加團隊向心力，沒有人是局外人。
• PM 確保顧客的聲音、市場的訊號不會被團隊忽視。
• PD/Engineer 協力的解決方案不僅解決問題，還用最低的成本提供最好的體驗。

職涯面向：提供了職涯成長與發揮影響力的空間。

General

• 離開舒適圈，成長曲線陡峭。
• 人才招募困難，大部分都靠自己培養。
• Burnout 列車

工程師

• 產品文化 > 工程文化，身份認同議題 (我是誰？ RD 還是 PJM?)
• 產品解太方便，採用技術解的機會偏少，技術深耕養分不足。

解決這些問題，便是 Product / Engineer Lead 在團隊中的主要工作。

• Guardrail：避免團隊失速、迷失
• Mentorship＆成長框架：新人入門 -> 成長區 -> 極限突破
• 80/20：除了產品開發，保留空間讓成員健全成長，跟上公司成長。

Research 

Solutioning 

Development 

永遠都要從搞清楚「我們要怎麼賣？」開始

• 產品管理及產品行銷是同一個工作
  • 產品會成為什麼樣子、該如何解釋，之間沒有任何差別。
  • 產品故事從一開始就必須連貫。
• 要讓顧客滿意（買單），故事需要包含理性與感性的論述－訊息傳遞架構​
  • ​​痛點 (What’s my pain)：即「為什麼」，為產品提供了存在的理由。
  • 止痛藥 (Painkiller)：即「如何解決」，解決顧客問題的功能。
  • 我會什麼會想要 (Why I want it)：支持顧客感受到的情緒。
  • 我為什麼會需要 (Why I need it)：提供購買這項產品的理性理由。
• 訊息傳遞架構是北極星
  • 不只是給行銷團隊看的，也引導產品、銷售、客服等團隊。
  • 每一個團隊都應該清楚了解「是什麼」、「為什麼」、以及我們在述說的故事。

在組織內推廣的計畫，其實也是種產品。

專案管理的目的

• (X) 加速產品開發 OR 準時交付不延遲
• (O) 管理風險，避免毀滅性的災難發生。
  • 用兩週的時間證明產品假設錯誤，提前終止六週的開發計畫，賺爛 💪
  • 多花一週驗證設計可行性，發現可能上線半年內就不敷使用，決定砍掉重練，賺爛 💪

工程師主導的專案管理

• Why：工程師最懂工程師，溝通不易掉球。
• 期待管理：透過 User story 與 Acceptance criteria 與 PM/PD 溝通。
  • 誰都可以寫 User story，但 PM 當責。
• 如何解決團隊衝突：回歸產品體驗，以顧客群的最佳利益出發。

管理風險需要領導力、溝通、技術兼具，能勝任的工程師是稀缺資源

估時不是科學，是神秘學 🪬

• 在持續成長的產品與團隊裡，估時不可能精準。
  • 成長痛：產品持續變得複雜，成員大多在面對自己的第一次
  • 產品開發不是第一優先，維持顧客體驗才是 (想想 P0 Incident)
• 估時不會加速產品開發
  • 任何方法論都無法減少實際開發的工時
  • 加速：調整 Spec、投資工具、團隊成員成長

為風險預留緩衝－60法則

• 風險沒有發生 => 團隊成員成長 => 未來產能上升

投資工具，以優化 CI/CD 為例

• 情境：團隊有 6 個工程師，每人每週上 Code 10 次，每次要跑 40 分鐘。
• 工程提案：用一個工程師花一週，把 CI/CD 縮短 10 分鐘。

做還是不做？讓我們估算個 ➕➖✖️➗

• 價值
  • 每次少等 10 分鐘 => 每週少等 100 分鐘 => 每個工程師一年少等 86.6 小時
  • 等於團隊一年可以節省 520 人時 (86.6 x 6)
• 成本：40 人時
• 影響力
  • 團隊視角：優化 CI/CD 可以讓團隊在接下來的一年內多出約兩週的可用時間
  • 職涯視角：13 倍時間槓桿的職涯故事

Stepping stones，小步快走：

• 目標：風險越來越小
  • (X) 從最容易交付的項目開始
  • (O) 從風險最高的項目開始執行
• 隨著每週過去，時程越來越明朗
  • 總時程 = 已花費 (已知, 高風險) + 預估​ (未知, 低風險)
  • 4-7 週 (d0) => 5-6.5 週 (d7) => 5 週 1-4天 (d14) => 5週 2天 (上線)
     

讓未知的風險 (Unknown Unkowns) 顯形

• PoC：實際開發前，先打造原型，驗證概念。
  • 在產品上做成效報表功能 => 用真實的資料 + BI 工具收集顧客回饋
  • 支援任意會員資料欄位查詢 => 實驗與驗證 DB Schema 設計可行性
• MVP：做個簡化版，先把路打通。
  • 支援 8 種會員資料上傳格式 => 先支援最重要的 2-3 種

Ref: Stepping Stones not Milestones

無論我們所在的公司是用什麼產品開發方法，本質都是一樣的：

• 說好產品故事
• 管理好風險
• 確保自己與團隊跟得上產品成長

身為工程師，我們並不需要真的喜歡產品才能成為團隊好咖。

關鍵是：​

產品開發 Workshop

請大家尊重、友善、包容，共創優質團隊文化

主題：曼陀號科技股份有限公司要開發產品啦！

親愛的科技人才們,

我們是 MentorShip Tech Inc.，是一間設置於台灣的軟體新創，致力於透過 AI 技術打造全新體驗的職涯導師媒合平台，以協助台灣的科技人才建立健全的職涯發展。

為了確保我們的產品能真正解決你的需求，我們希望邀請你分享在職涯發展過程中的經驗與痛點，並告訴我們在職涯的每個階段，哪些部分讓你感到困難或需要幫助。

攜手打造你的職涯未來—我們想聽到你的聲音！

以下是一些指導性問題，希望能幫助你組織想法：

• 你目前的職涯階段是什麼？

• 在職涯發展中，你遇到的最大挑戰是什麼？
• • 尋找工作機會、職場技能提升、導師資源不足、其他？

• 你曾經想過找職涯導師嗎？如果有，遇到了哪些困難？

  • 資源不足、合適的導師難尋、平台缺乏？

• 如果你有一個 AI 助手來幫助你找到導師，什麼樣的功能或支持會讓你覺得最有幫助？

  • 個性化推薦、技能匹配、職涯發展建議等？

• 你覺得現有的職涯平台或導師服務有哪些不足？

• 我們的 AI 平台應該專注於哪些方面來真正解決你的需求？

Workshop I — 找出顧客痛點

Part1 - 小組討論時間 (20 mins)

• 根據主題與指導性問題，彼此分享想法。

• 從收集到的想法中，找出一個值得被解決的痛點。

Part2 - 小組分享時間 (8 mins)

• 小組分享 (2 x 4 mins)

  • 分享你們想解決的痛點與它的價值 (1 min)

  • 回答 1-2 題 follow-up (1 min)

Workshop II — 產品故事設計

Part1 - 小組討論時間 (20 mins)

• 設計解決方案

• 透過產品訊息傳遞架構，設計產品故事。

  • ​痛點：即「為什麼」，為產品提供了存在的理由。
  • 止痛藥：即「如何解決」，解決顧客問題的功能。
  • 我會什麼會想要：支持顧客感受到的情緒。
  • 我為什麼會需要：提供購買這項產品的理性理由。

Part2 - 小組分享時間 (8 mins)

• 小組分享 (2 x 4 mins)

  • 分享你們的產品故事 (1 min)

  • 船長回饋 (1 min)

Workshop III — 風險管理

Part1 - 小組討論時間 (20 mins)

• 根據經驗分享提及的 stepping stone 的概念，設計專案管理計畫。

  • 風險最高的項目優先

  • 以兩週為一單位，總共 2-3 輪。

Part2 - 小組分享時間 (12 mins)

• 小組分享 (3 x 4mins)

  • 分享你們的專案管理計畫 (2 mins)

  • 船長回饋 (1 min)