產品經理應如何提高團隊的執行力

1、產品經理首要確定的工作原則：戰略決策產品，產品驅動開發;

2、結合實際情況，設計可執行的工作流程，明確各職能環節的工作成果輸出(原型/介面設計，需求文件/思維導圖或流程圖);

P線：產品管理，產品設計，介面設計，互動設計，及其它

T線：專案管理，技術架構，技術Leader，開發人員(前端，頁面，後端，服務端，資料端，運維等)

3、儘可能的明確可度量的工作成果標準，由P線經理提供需求要點綱要，表明要做到什麼，不用做到什麼，T線經理根據需求與相關人員共同設定工作目標和標準;

虛擬示例：某功能模組，進行V2版本優化，2周為一次迭代週期，共2個週期

需求要點是：功能性流程與V1版本相比無增加點，重點是實踐前後端分離的開發模式重構該功能模組的實現程式碼，交付給使用者更有驚豔效果的操作流程，強化每個操作環節的引導或提示體驗

第一個週期的關鍵是：需求明確，各職能角色的充分交流

第1周目標是：P線成員完成產品細節需求策劃，T線成員相關技術架構的預研

第2周目標是：需求策劃完成交付，二個關鍵展示頁面的技術功能性開發完成

第二個週期的關鍵是：保證質量，在進度內完成既定目標

第1周目標是：所有技術功能性開發完成，關鍵業務流程可以走通無誤

第2周目標是：所有需求策劃細節開發完成，重點是用驗設計、介面設計無損實現

此產品開發組團隊共4人：責任產品經理1人，技術骨幹兼專案經理1人，相關技術開發人員2人;周邊支撐資源：介面設計、、互動設計、頁面製作，約6人/天

4、抓住一切機會點，在團隊內告知及說明工作原則和流程標準的重要性，特別關注對老闆的告知;

5、對於執行過程中的各職能環節協調問題，保持高度的敏感，最及時的處理此類問題;

6、對不同職能角色的溝通技巧，產品經理本身需要在思考上有相當的彈性來去適應不同的角色思維模式，老闆，技術Leader、成員，介面設計、使用者體驗、前端開發、客戶等

在和P線角色溝通時，要適當的講解技術實現相關原理，能做為什麼，不能做更要為什麼，並在滿足需求本質的前提基礎上，提出妥協或更合理的解決方案;

在和T線角色溝通時，儘可能說明該功能需求的來源，使用者反饋次數和態度，分析其合理性，以具體案例和模擬用例來推演出合理性;

虛擬例項：專案管理=》專案成員管理與授權功能=》產品提出需要可以增加部門為專案成員

已有功能流程：進入專案成員管理，可選擇部門下拉框=》員工下拉框，點加入成員

產品的思路：選定部門後，即可直接將該部門加入專案成員，讓專案經理操作減少，當部門員工離職後也無需再取消該員專案成員身份

技術的思路：該需求技術可行，需要涉及到的功能點有，專案成員管理介面可增加部門，部門繫結的許可權角色被授權，3個其它功能模組中類似的人員選擇區做同樣的處理，約2-4人/日工作量。

我的分析：能理解該需求思路，選部門的出發點在於減少專案經理操作次數，這個能認同，但一個專案經理在此專案裡選了部門為成員以後，如果該部門有人員增加而又正好不是參與該專案的，豈不是還要再回來把這個專案的成員裡去掉這個部門，再加上原有的員工;其二，這個漏洞雖然很小，使用者實際操作中碰到的機率很低，但既然我們提供出這個功能，就一定會有使用者使用到出現問題，那豈不是違反了我們做這個修改的.目的：改善使用者操作，獲取使用者認可。須知，對於使用者而言，我們做的更好是應該的，大部分使用者未必感知到，感知到的使用者也未必會傳播;但如果我們做了一個會出某問題的產品，大部分沒出現該問題的還是沉默狀態，出現問題的就一定會進行傳播反饋(抱怨不爽投訴。。。)，影響到本來沒此問題的使用者群體了。

結論：需求決策的原則：產品環節對沒有問題的解決方案進行判斷或優先順序選擇時，可以按關注使用者機率的多少來進行，但如果有問題的方案，就不能按使用者關注機率來判斷，哪怕只有百分之1的使用者有可能出現問題，就是致命。該需求應該尋求其它解決方案。

我的方案：專案經理選擇部門後，人員下拉框裡第一項是“加入該部門所有員工”，產品認為可以滿足需求的出發點，技術認為需要投入的工作量約0.5人/日，達成共識;

7、以合理的方式展現團隊的各階段工作成果，一則收集需求反饋，二則收穫公司及客戶的認可提升團隊士氣