(本文 crossposting 於 ALPHACamp Blog)
產品經理(Product Manager)是任何新創產品的關鍵角色，他定義了產品的需求規格，找出產品的價值所在。而一個成功的產品代表結合了好的產品需求規格，以及能夠依據這個需求規格實作出來的工程團隊。我們說產品經理負責 Building The Right Product，而工程團隊負責 Building The Product Right，兩者缺一不可。由此可知產品經理與工程團隊之間的關係有多麼重要。
以下是幾點是我認為可以幫助產品經理與工程團隊的合作，一起打造更好的產品：
1. 定義清楚這個產品
這是最基本也是重要的，要講三遍：「定義產品」、「定義產品」、「定義產品」，為什麼這麼根本的事情還作不好呢? 很多時候是組織的問題，沒有人專職負責，例如：
- 產品經理就是老闆。但是老闆太忙了，只定義了「high-level」需求，而沒有定義細節規格。於是工程師就得自己腦補，最後做錯了被罵又重做。
-
行銷客服來兼職產品經理。行銷很了解如何告訴世界這個產品有多棒，但是卻不一定能夠發現需求並定義清楚這個產品，這兩者的技能是不一樣的。並且很容易發生傳聲筒現象，直接把單一客戶的需求告訴工程師，而非經過一致的產品思考規劃以及使用者體驗設計。
我們會在之後的文章繼續探討什麼是好的規格文件。它代表了使用者應該要有什麼體驗、產品有哪些功能和行為，以及功能的開發優先順序。除了基本的 User Story，也應包含 Wireframe 介面流程和關鍵的測試案例。
2. 建立良好的溝通管道
就算規格寫的再清楚，開始實作之後就會有一堆問題冒出來。如果沒有人可以問或是等不到產品經理的回覆，開發人員就會開始腦補這個功能，硬著頭皮繼續做下去(然後又做錯了被罵，需要重做)。或是就停下來，找其他低優先的事情來做。無論怎樣都是很大的浪費。
建立一個良好的溝通管道，讓工程師可以很快地跟產品經理問到答案。最好是同一個辦公室，越是 Remote 的工作環境，那麼規格文件就需要越清楚。
3. 不要負責專案管理
如果沒有專職的專案經理(Project Manager)，就請 Lead Engineer 來負責專案進度。不要讓產品經理去兼專案管理。專案管理的重點在於執行及發佈產品、協調開發、測試與營運團隊。讓產品經理來做不只是力有未逮，也會造成兩方關係的緊繃，壓榨工程師的故事不斷真實上演，就是因為由不了解軟體工程的人負責專案管理。
在知名的 Scrum 敏捷軟體開發方法中就提到：產品經理決定作什麼，讓工程團隊決定如何做及可以做多少。
4. 不要告訴工程團隊怎麼做，告訴他們要做什麼
很多產品經理喜歡把需求描述成解決方案，指定了一個不可行或者是成本效益很低的作法，而非告訴工程師他們想要達到的目標，或是想要解決的問題根本是什麼。
F-16 是史上最成功的戰鬥機之一，在一開始設計的要求是需要超過兩馬赫的速度，首席設計師問了美國空軍為什麼飛行速度這麼重要，答覆是「飛機必須可以從戰鬥中逃脫」。最後的設計並沒有超過兩馬赫，但是卻可以讓飛機很敏捷的逃脫，透過了無框的坐艙、抬頭顯示器，讓飛行員有更好的視野。可傾斜的座位降低了重力影響。飛行控制桿是安裝在右手邊上，而非傳統的在兩腿之間，用來輔助在高G值時候轉彎。這些設計不但也能達成設計目標，更降低了生產成本。
這個問題其實不只產品經理，工程師本身也常犯這個錯誤，常常可以在討論區看到有人問「請問這個指令 X 怎麼用」，然後底下的討論怎樣都無法完全解決他的問題，直到有人問「為什麼你需要這個 X？」，他回答「因為他要做 Y 功能」，大家恍然大悟用 X 來解決根本是錯的，應該用指令 A 就可以很簡單的解決了。
在大多數的情況下，工程師比產品經理更清楚知道哪個實作方案最適合。
5. 相信工程師專業
產品經理負責 Building The Right Product，而工程團隊負責 Building The Product Right。相信工程師的專業，就是讓工程團隊可以實行任何他們認為建構一個有品質產品需要的作法，例如撰寫自動化測試、Pair Programming、建構 CI 持續整合環境，Code Review 程式碼複審等等。這些工作雖然不直接與產品需求相關，卻對工程品質有很大的影響。這些事情現在不做，在專案開發幾個月之後，很快就會吞噬整個專案進度和品質。
以上五點可以幫助產品經理和工程團隊合作的更愉快，但是請記得無論工程團隊再優秀，如果產品經理無法定義出一個值得建造的產品，一切也是枉然。