最近一段時間在規劃新項目。之前，大部分情況下，項目的方向甚至具體的內容都是由領導來掌控，我去補充細節，然后推動產品落地。例如在大房鴨的時候，老板定義產品方向及大部分功能范圍，我去梳理流程，產出交互和文檔，協同設計、開發推進產品上線，我自己主導推動的內容大部分是一些業務相對簡單的模塊。在學霸君，雖然做什么由我自己去定義，但由于需求是明確的，大部分時間只用確定優先級去執行就行。
而這次，根據業務的總體目標、市場拓展計劃，我自己去定義該做的方向，拆分、明確這個方向上的目標，規劃目標實現的路徑，進而向領導申請相應的資源。
在產品規劃過程中，我嘗試不斷地去梳理自己之前掌握的內容，也查資料拓展知識邊界，于是有一些自己的總結和見解。
一、確定項目目標
《用戶體驗要素》里的戰略層其實就能很好的說明如何確定目標：
- 產品目標：我們（公司）要通過這個產品得到什么？
- 用戶需求：我們的用戶要通過這個產品得到什么，他們為什么會依賴我們？
產品目標很好定義。通過參加公司的戰略會議，我理解了公司新的戰略方向，然后從戰略目標中，拆解出產品能夠提供的支持就可以。
2018年的業務目標和銷售策略有很大的變化，導致目前的產品無法適應這些調整，我需要通過這個項目去推動產品進行優化，協助銷售提高銷售演示效率及效果，并對最終的效益目標做出貢獻。
定義完產品目標，我們需要去定義用戶需求。
演示產品的用戶是銷售和渠道商，所以我們要解決的問題的方向也比較明確，就是銷售和渠道商出去演示的時候，會遇到很多產品或者非產品的他們無法解決的問題，需要產品經理通過產品手段為他們提供支持。
于是問題的關鍵在于如何去拆分目標，即我們需要做哪些事情來達成這個目標。因為對于項目比較熟悉，之前跟銷售也有一些的溝通，所以我有大概的想法，未來要做什么。但大部分想法都是我的假設，接下來我要做的事情是去調研，去驗證我的想法和假設。
于是我對銷售進行了用戶訪談，了解他們的銷售場景、流程以及遇到的問題，并且到銷售前線去了解銷售售賣的具體場景。
經過調研，我弄清楚了用戶需求，即這個方向下涉及到的角色，各個角色的使用場景，他們當前的動作流程，以及這些動作流程中的需求和疼點，這些其實也就是用戶故事。
在這一階段，我弄清楚了現狀是什么，也對于未來產品的發展方向有了較為清晰的認知，也拆分出了我需要滿足的需求/提供的服務。
二、梳理實現路徑
經過上一步的梳理，我拿到了一堆需要做的事情，那么我們如何來安排這些事情，讓產品通過不斷的迭代去持續交付成果？這其實就是如何去定義產品RoadMap的問題。
我們在梳理RoadMap最常犯的錯誤是去梳理每個時間點或版本需要完成的功能點。例如，在3月份我們要完成以下幾個功能，在4月份我們要完成另外幾個功能。
這樣梳理會有2個問題：
第一個，我通過什么依據去安排每個版本的功能點？
第二個，版本迭代過程中，如何形成節奏感？
所以，與其梳理每個版本的功能點，不如梳理每個版本的版本目標。這樣我就能清楚的說明，我這個版本要實現什么目標，最終會帶來什么變化，為了實現這個目標，我要實現哪些功能。
基于這個，我就梳理清楚了目標的實現路徑。在制定版本計劃時，能夠清晰地定義出每個版本想要實現的目標，確保所有的需求都是為了這個目標的實現做出貢獻。
三、資源爭取和利用
作為產品經理，我們的直接產出是沒有價值的，我們必須爭取資源，讓他們來利用我們的產出，進而實現最終的目標。我需要爭取設計、開發資源，這樣才有人力配合我完成我的項目；我需要爭取銷售的信任，進而在后續的工作，對我們產生依賴，從而不斷地反饋新的需求。
于是，我召集了各部門的老大，去講解我對于銷售目前遇到的問題的理解，當前的產品是什么樣子，未來的產品會是什么樣子，它解決了銷售的哪些疼點，以及明確的迭代節奏。這次匯報內容得到的銷售leader的認同，認為我的產品規劃能夠極大的解決銷售目前遇到的問題，技術leader因為之前體驗過銷售環節，所以也能感知到我在解決正確的問題，也能感知到產品未來會對業務的幫助，所以也愿意從現有項目中調配一部分開發資源。
這就是我爭取資源的方式，讓團隊里的每個人都認同這個項目所帶來的價值，也知道自己的投入會有產出，所以也愿意給予資源支持。
目標、路徑、資源，這個項目規劃的梳理邏輯，是我從我領導那里學到的，在網上搜索之后，發現這是傅盛提到的“管理三段論”。
采銅的《精進》這本書中，有一個章節的標題是“技能，才是學習的終點”。
在運用的過程中，我也發現，在看文章，聽別人講中得到的知識只是信息，我們得反復去使用，獲得反饋后修改，才能將知識變為我們的技能。
