起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識萬字干貨 | 初級產品經理工作技巧指南
本文的主要內容是初級產品經理工作過程中各環(huán)節(jié)的技巧總結，我寫的時候盡量是從現有工作內容中抽離，沒有涉及到我的具體業(yè)務，因此不同細分領域的產品經理都可以通用。
剛入門不久的產品經理容易有這樣一個現象：看過很多的產品文章，學過一些產品課程，了解很多高大上的模型理論，每天關注互聯網資訊，你跟他聊天的時候發(fā)現他什么都懂一點，但一上手就是不出活，暴露各種基本功不扎實的問題。
為什么看了那么多大咖的分享總結、方法論的文章，依然做不好需求？
結合我自己的經歷，我把原因總結為兩方面：
- 一方面，看的文章寫的內容泛泛而談不夠干貨，或者說通用性不強，僅適用于作者自己的項目和工作，難以進行學習模仿。
- 另一方面是你只是略讀一遍，像看新聞一樣，沒有深入理解其中的精華，在實踐的時候也沒有運用上。
本文的主要內容是初級產品經理工作過程中各環(huán)節(jié)的技巧總結，我寫的時候盡量是從現有工作內容中抽離，沒有涉及到我的具體業(yè)務，因此不同細分領域的產品經理都可以通用。為了區(qū)分什么是技巧、技能、能力，我這里做了如下定義：
- 技巧：是為了快速提升技能的手段，是技能的一部分，是可以學習復制的。
- 技能：是具體的、全面的，是為了做好一項工作而需要具備的內容，是可以學習復制的。
- 能力：是技能內化后的結果，是舉一反三的驅動力，很難復制，需要靠自己總結提煉。
由此可見，要提升產品能力，可以先從學習技巧開始，再掌握全面的技能，最后提煉出通用的能力，如此循序漸進。
本文主要內容：
- 初級產品經理必備素質
- 需求收集和過濾
- 產品方案設計
- 項目管理
- 溝通技巧
- 方法論建設
一、初級產品經理必備素質
處在職場的不同階段，聚焦點是不一樣的。作為初級產品經理，需要明確自己的定位和目標，練好基本功，切勿好高騖遠。
1. 清晰的自我定位
初級產品經理一般完整的負責一個功能模塊或一個系統，首先，需要對自己負責的模塊充分的熟悉然后了如指掌，讓所有需要跟這個功能對接的人知道，有問題只要找你就解決了，這也是逐步建立影響力的過程。
其次，熟悉了模塊之后，再深入思考該模塊不同競品做的怎么樣，自己產品所在哪個檔次，距離最好的產品差距有多少，如何基于公司的業(yè)務提高該模塊的競爭力。
最后，在掌握了自己負責的內容后，以點帶面，不斷完善加深對公司產品和業(yè)務的理解，才能獲得更多機會承擔更重大的項目。
以上三個過程是一個遞進的關系，也是初級產品經理在不同工作階段的不同定位。
2. 明確的工作目標
對于剛工作的前兩年，對于個人能力的提升目標方面，應該著重關注執(zhí)行力、溝通力、項目管理能力三大塊，其中執(zhí)行力包含了需求分析、產品設計、推進項目開始到上線過程的方方面面，這三大塊內容是作為產品經理最基本的基本功。
二、需求收集和過濾
1. 需求池管理
產品經理對需求的管理就像廚師對食材的管理，廚師在眾多食材中挑選合理的組合，加工成美味，產品經理在眾多業(yè)務方提出的需求中進行組合設計，加工成產品功能。好的需求池管理不僅是對需求進行過濾，也是對工作內容的精細化記錄和總結，有利于有條不紊的項目管理和后期的復盤。
我將對需求池的管理內容總結為三大部分：
- 判斷并記錄需求的真?zhèn)?、重要性、緊急度、實現難度、業(yè)務價值、關聯方；
- 記錄當前每個需求的項目實現狀態(tài)；
- 追蹤需求實現后的用戶及數據反饋情況。
至于需求池的表格模板，我認為每個人的實際需求和習慣不同，也沒有必要照搬別人的，只要覆蓋了以上三大塊內容，起到了需求池管理的作用即可。
2. 優(yōu)先級判斷
一般剛入行的初級產品常常直接執(zhí)行領導分配的任務，但并不代表優(yōu)先級判斷這件事對于初級產品不重要。需求優(yōu)先級判斷這個話題，網上一搜產品文章一大堆，各種四象限法、卡諾模型等等。但每個人處于工作不同的時間狀態(tài)，對公司及行業(yè)產品的理解層次是不一樣的。所以就算你學完了背熟了產品課程中所有的需求分析方法論、或者優(yōu)先級判斷模型，你的判斷的合理程度很難跟你的領導相比。
優(yōu)先級判斷屬于洞察決策層面的高級能力，不是工作技巧，它的變量太多，需要多方權衡，比如業(yè)務重要程度、緊急程度、工作量、性價比、是否匹配系統當前所處的階段、對系統的影響大小，甚至領導強勢程度等等，不同行業(yè)不同公司情況，用一套模型和公式是無法解決的。
我這里想強調的是，不必拘泥于具體的判斷方法和公式，而是一開始就養(yǎng)成對自己需求池進行優(yōu)先級判斷的習慣，也許一開始判斷的結果并不準確。會踩過一些坑，但隨著對業(yè)務和行業(yè)的逐漸熟悉，判斷會越來越準確。所以我建議忘掉別人總結的公式，建立自己的判斷標準，并不斷調整優(yōu)化這個標準。
三、產品方案設計
我將產品規(guī)劃設計粗暴的分為前端頁面設計和后端產品設計，這里的后端其實不是真正意義的后端產品經理才關注的，也會包含很多前端功能邏輯層面的設計。凡是屬于用戶可見可操作界面的部分為前端設計，不可見的邏輯及系統設計則為后端設計。
1. 前端頁面設計
交互設計領域人機交互大師雅各布·尼爾森博士，在1995年提出的尼爾森十大可用性原則，對二十多年后今天的互聯網產品設計仍然影響深遠，對于軟件類著重頁面設計的互聯網產品來說，我提煉了其中4點：
（1）簡單易理解
包括了文案的簡潔明了、功能玩法的易理解，在單個頁面內減少過多不必要的信息。
（2）操作有反饋
當用戶進行某個操作后，以合理的形式向用戶反饋目前的狀態(tài)，可能會發(fā)生什么。
（3）操作可回退
用戶走的每一條路都不能是死胡同，應該都能讓他回到原點。
（4）功能一致性
不同位置的相同功能保持一致，保證了產品設計統一，用戶更易學習。
前端設計我只總結了以上4點，比較適用于產品原型的交互設計，但卻是任何一個優(yōu)秀的產品必不可少的核心設計原則。
2. 后端產品設計
后端設計的細節(jié)太多，沒法像前端設計原則一樣進行高度歸納，我這里也是根據自己大大小小的項目經驗逐條進行總結，內容不夠系統，可以當做幾個關鍵點設計的參考。
（1）MECE原則，相互獨立，完全窮盡
這個基本原則相信每個產品經理都知道，它是一個能讓產品方案條理有序、不遺漏、不重復的重要標準。我這里主要強調一下它具體體現在了什么方面。
a）產品方案對標業(yè)務需求
我們假設這里的業(yè)務需求都是相對合理的需要實現的。那設計的產品方案需要對應滿足這些業(yè)務需求，不能遺漏任何一個，同時也不能讓產品方案內部出現重疊的功能，而是剛好完美的滿足了業(yè)務需求，也使開發(fā)的系統內部達到軟件工程上的最優(yōu)解，這就叫滿足MECE原則。
b）需求文檔的書寫
落實到具體的執(zhí)行，需求文檔中描述功能時也需要盡量滿足這個原則。首先做到描述不遺漏，充分考慮異常流、特殊邏輯；然后需要語言精簡客觀，對同一功能和模塊不必重復贅述，對于有耦合關系的模塊，用語言上的邏輯因果、時間先后來進行描述。
（2）強化對狀態(tài)的認知
對于一個后臺系統，狀態(tài)無處不在，靈活多變的業(yè)務需求是靠一張張數據庫的表在記錄的，除了業(yè)務數據的記錄，狀態(tài)是非常重要的基礎。訂
單必須有狀態(tài)，用于區(qū)分不同業(yè)務環(huán)節(jié)：一個上線的活動必須要有狀態(tài)，是進行中、已暫停、還是已下線；一個員工賬號也要有狀態(tài)，是啟用中、禁用中還是已注銷。
設計一個功能或系統通常需要先繪制流程圖，而流程圖中一個個狀態(tài)的連接支撐起了整個功能設計的骨架，然后才是具體細節(jié)的設計。
如何正確的強化對狀態(tài)的認知和理解，我大概總結以下幾點：
a）狀態(tài)的獨立互斥
這點與上面說的唯一判斷字段有點類似，但實際不是一回事。因為狀態(tài)是用于描述不同業(yè)務節(jié)點的，每個狀態(tài)要與實際業(yè)務的關鍵節(jié)點進行一一對應，狀態(tài)之間不能出現二義性，否則會出現多個狀態(tài)對應同一個業(yè)務關鍵節(jié)點，不但會造成理解混淆，還可能使系統做具體判斷時出問題。
b）狀態(tài)在時間維度上是穩(wěn)定的
這點其實也很好理解，一個具體業(yè)務的發(fā)展是有階段性的，而狀態(tài)就是在每個階段取一個值，各個值連接起來就串聯的業(yè)務，但如果狀態(tài)的值取在各個階段的臨界點，這就很不好描述業(yè)務了。比如一個運營活動，可以用“進行中”和“已下線”兩個狀態(tài)來區(qū)分發(fā)生和不發(fā)生兩個階段，這是合理的，但如果狀態(tài)叫做“下線中”，這就不是處在一個穩(wěn)定的狀態(tài)，而像一個瞬時態(tài)，到底是上線還是下線，我們從狀態(tài)命名中就感覺很模糊。
c）注意子狀態(tài)和組合狀態(tài)
當業(yè)務相當復雜時，一個狀態(tài)下面還可以設置子狀態(tài)，比如單據的撤銷狀態(tài)，可以包括用戶主動撤銷、系統撤銷、人工撤銷，用于區(qū)分具體是怎么被撤銷的。
而組合狀態(tài)的意思是在用戶側展示的狀態(tài)不單是訂單表里存的狀態(tài)名稱，而是一個組合狀態(tài)，比如在用戶側顯示“已發(fā)貨”，其實包含了訂單狀態(tài)為“創(chuàng)建成功”、支付狀態(tài)為“已付款”、物流狀態(tài)為“已出庫”。像比較復雜的保險訂單狀態(tài)，還會包含訂單狀態(tài)、支付狀態(tài)、續(xù)保狀態(tài)等，因此不能用一維的線性的來看待狀態(tài)。
d）狀態(tài)機的流轉路線
狀態(tài)機圖的確定，基本確定了系統和功能主體結構，各狀態(tài)之間的起點終點、流轉路線、判斷條件決定了功能的玩法和限制，狀態(tài)機圖是梳理并對照實際業(yè)務的必備工具。當業(yè)務有功能拓展時，首先查看狀態(tài)機圖是否滿足，如何調整才能滿足，已經涉及到哪些相關調整，都需要用到這個圖。
e）合理的狀態(tài)有利于數據統計
當狀態(tài)的設計都按照上述原則進行，狀態(tài)與狀態(tài)之間非常清晰，這對數據統計是非常有益的。因為很多的數據統計都強依賴對狀態(tài)的定義，如果你在做數據統計的時候發(fā)現很難準確的提需求，或者發(fā)現無法按照業(yè)務需要的維度來進行統計，可以反思下系統的狀態(tài)是否合理。
（3）預留拓展性邏輯
我之前經常遇到一種情況，當我做一個功能上線之后，業(yè)務方有時會再提一個與這個非常類似的需求，有時候僅僅只是改動很少的內容。如果在第一次設計時并沒有預留可能的拓展性，就算只是很少的改動，還是要排期開發(fā)和測試，特別是有的功能還需回歸測試，非常浪費開發(fā)資源，而且影響迭代速度。這時就考驗在設計之初能否大概看出可能有的拓展性，在開發(fā)工作量幾乎不變的情況下預留一些類似的邏輯，這樣會非常便于類似功能的迭代。
舉個例子，對于一個人工審核的結論頁，有多種狀態(tài)，每種狀態(tài)下結論頁的不同模塊的元素、文案、以及對用戶的觸達文案，都是首次開發(fā)時配置好的。
首次開發(fā)時業(yè)務方提出有三種狀態(tài)，上線之后業(yè)務方說要再加一種特殊的狀態(tài)，如果事先在狀態(tài)機中預留了待定的狀態(tài)，只需要把該待定狀態(tài)下頁面的元素、文案、對用戶的觸達進行設置即可，改動的工作量很小，可以快速的上線。
不過值得注意的一點是，在預留拓展性時盡量保證首次開發(fā)的工作量影響很小，如果為了暫時使用不到的預留需求消耗過多開發(fā)資源，就有點本末倒置了。最好的針對復制一份代碼、預留一個狀態(tài)這種相似功能進行考慮。
（4）對變量的抽象
對變量的抽象是一種模塊化思維，能夠減少很多重復的工作量，提高后期的開發(fā)效率，我將分成兩種情況來描述。
一種是當多個頁面都用到同一個內容時，該內容應該被抽象為公共變量，供各頁面調用。比如一個常用聯系人組件包含姓名、證件類型、證件號碼、性別、出生日期這五要素，那么可以把這五要素設置成一個公共變量模塊，在不同產品下單需要用到時直接調用即可。如果有的產品下單時只需要用到姓名、證件類型、證件號碼三要素，則可以把五要素的變量模塊拆細為五個變量元素，這樣可以達到最大自由度的組合。
另一種情況是兩個頁面絕大部分內容相同，只有幾個元素有差異時，這幾個有差異的元素應該抽象為配置變量，做成一個配置文件或者管理后臺，這樣在調整該配置時就不用再寫代碼。有的同學可能對配置文件不太懂，它可以理解為一段未被編譯器編譯的配置代碼，是對一個軟件運行時狀態(tài)的本地儲存形式，可以實現對軟件靈活的實時調整。
比如：同樣一個商品的詳情頁需要在A平臺是紅色背景，有評論模塊，在B平臺是綠色背景，不要評論模塊。如果事先將背景色、有無評論模塊這兩個變量做成配置項，只需要更改配置文件或在管理后臺做相應勾選即可。
（5）時刻考慮系統的靈活性
講完兩種基本的變量抽象方式，我再講講整個系統的靈活性。
比如一個普通的商品詳情頁，如果只給你1天時間從0到1來做這個頁面，你會把頁面的所有元素、邏輯寫清楚，找到前端后端開發(fā)按照你的邏輯進行實現，然后發(fā)布上線。如果你想修改一個banner圖，必須要找前端開發(fā)從代碼層面幫你換圖，然后再發(fā)布，這時我們認為這個頁面是非常不靈活的。
因此你把banner、標簽、價格、尺碼分類等等都抽象成了配置變量，就可以在管理后臺靈活的調整這些內容，無需再發(fā)布，看起來非常靈活了。但是當這個頁面需要對不同商家顯示不同商品時，你就需要再把這整個頁面做成配置項，對每一個商家可以單獨配置一套商品詳情頁。
接下來業(yè)務需求再進一步演化，每個商家想要自己去配置自己的商品詳情頁，這時你還需要把商品詳情頁的配置功能做成一個商家管理后臺，讓商家自己去靈活設置，這時候單是這個商品詳情頁就已經很復雜了。
如果每個商家還要對自己的員工分別配置權限，有的員工只能修改banner圖和名稱，有的員工可以修改商品sku、價格等等，那你還需要把這個商家的商品詳情頁配置功能結合賬號權限再細分配置，讓商家自己靈活勾選什么員工可以操作什么權限。
我這里只是簡單的描述了一下電商平臺商品詳情頁的配置演化路徑，就可以看出，當業(yè)務需求越來越細化，對系統靈活性的要求就越來越高，也意味著系統的復雜程度越來越高。為了盡可能充分的滿足業(yè)務需求，我們需要時刻注意系統的靈活性，在每一版迭代的時候避免太多寫死的邏輯。
（6）總結遇到的異常流
每做一個項目，在上線之后可能都會遇到反饋的線上問題，特別是一些在設計時考慮不全的異常邏輯，會在用戶真正使用的時候暴露出來。做完項目遇到這種情況并不可怕，因為人無完人，產品經理不是神，設計之初漏掉一些異常流是很正常的，但如果每次項目都漏掉一些，或者同樣的異常問題多次出現，這就是產品經理的問題了。
我們可以認為，在業(yè)務拓展沒那么快的情況下，軟件層面的設計的異常流是很有限的，只要遇到一個就把它解決掉，總會消滅干凈的。
產品經理每天的工作時間，可能會有一部分都是在處理自己留下的坑，但在填坑的時候我們能否不僅僅只為了填坑，能否思考是怎么漏掉這些異常流的，并一一總結出來，這樣也許能大大提升產品設計的完整性。
四、項目管理
項目管理之前應該先判斷該項目的類型，不同的項目推進和管理的方式區(qū)別很大，根據項目大小與任務并行程度，我分為以下三類：
1. 周期較長的大項目管理
對于單個部門內部開發(fā)周期較長的項目（超過2周），我總結有以下項目管理的關鍵點：
（1）提前溝通開發(fā)方案
一般較大項目功能比較復雜，因此整體方案設計時需要預先跟開發(fā)人員溝通，明確一些關鍵限制因素和影響點，避免需求評審時方案不可行，或者調整太大，在評審會上難以達成一致。
（2）關注功能先后順序
提前關注項目中不同功能的相互依賴性以及對外部系統依賴性，根據功能依賴的先后順序確定項目的排期節(jié)奏，提高排期銜接程度，避免一個功能開發(fā)完很久之后還不能與其他功能聯調，浪費開發(fā)資源。
（3）對項目的強推動力
每日跟進關鍵點的結果，盡早發(fā)現風險（日報、周報、晨會等形式）。
（4）項目復盤總結
項目完成后回顧項目過程中哪些過程效率有待提高、哪些過程安排的不夠合理，如何避免在下一個項目中繼續(xù)出現。
2. 跨部門跨公司合作的項目管理
跨部門和跨公司合作的項目，開發(fā)量不一定很大，但由于牽連方較多，比起團隊內開發(fā)有了更多的不確定因素，項目容易延期，因此在上述大項目的管理基礎上需要額外關注這幾點：
（1）找到合作關鍵點
不管是跨部門還是跨公司合作，首先要明確對雙方的關鍵利益點，并強調合作對對方的好處，才能獲得對方的積極支持，否則很容易被踢皮球；
（2）書面確認詳細事項
跨部門和跨公司合作，一般都是遠程電話溝通，因此對會議上達成一致的點需要書面記錄郵件至對方，對達成一致的點也需要記錄并積極跟進對方的最新答復。這一點主要是為了提高需求的確定性，明確雙方職責，避免因為溝通沒有記錄影響項目開發(fā)進度。
3. 多個小項目并行的項目管理
對于互聯網的敏捷開發(fā)模式，超過兩三周的大項目少有，多個小項目并行才是更常見的狀態(tài)，這里的小項目其實是單個很明確的需求，粒度比較小，這種狀態(tài)下產品經理一周可能同時在跟進十多個需求在開發(fā)狀態(tài)，這對多項目并行的考驗很大，我總結了以下幾點：
（1）更合理的排期節(jié)奏
由于項目太多，為了避免同一天過多需求同時在開發(fā)或者在測試，在排期的時候盡量均勻的分布，這樣保證在一些需求已經進入測試或已發(fā)布，另外的項目剛進入開發(fā)，避免某一天的事情太多。
（2）每日tips跟進每個項目的狀態(tài)
首先需要實時記錄這些并行的需求的開發(fā)狀態(tài)、開發(fā)人員，然后每天早晚跟對應的開發(fā)人員跟進需求狀態(tài)，及時解決相關問題。
（3）小需求歸檔
小需求上線一時爽，后期維護痛苦不已。每個小需求在開發(fā)過程中是獨立的，但對于整個產品來說它是一個個的迭代，只有及時將這些迭代歸檔到對應的功能模塊，才能后續(xù)方便的了解查詢當前線上的產品規(guī)則是怎樣的。否則后期連自己都忘了到底最新的迭代是什么，這個坑誰踩過誰就知道有多苦。
五、溝通技巧
與項目管理類似，溝通之前我們要對溝通的對象進行分類，不同溝通對象需要注意的事項是不一樣的。
1. 與合作方溝通
（1）溝通方式的合理選擇
一般與合作方很難面對面溝通，大多是電話和在線溝通，因此對于不同的事項要選擇合適的溝通方式。比如首次確認合作內容，需要電話詳細說明合作細節(jié)，然后書面記錄達成共識的事項；確認完合作內容后，有小的疑問點可以在線溝通。
（2）催進度也有技巧
有依賴合作方確認的事項或開發(fā)進度時，催進度是最頻繁的事。但是催進度需要包含幾個關鍵因素才能起到好的效果。
首先是良好的態(tài)度，對對方的尊稱是必須的，就算對方態(tài)度比較冷淡也需要保持著熱臉貼冷屁股的熱情，因為在工作中，合作的順利完成才是最重要的，這也是職場人的必備素質。
其次是明確具體內容和時間點，比如當希望對方對某個點反饋結果時，反面教材是這樣的“請問你們這個功能可以快一點開發(fā)嗎？”、“麻煩盡快確認下XXX這個點哦”，這樣的詢問都沒有明確時間點，對方感受不到壓力，催進度的效果不明顯，正確的方式是“請問某某負責人，針對這個三點事項（一一列舉），您可以在今天下午5點之前確認嗎，麻煩您了”。
再次是要找對關鍵人確認，比如你一直跟對方的一個開發(fā)人員催進度沒什么用，需要直接找到對方的產品或項目負責人，甚至是對方領導。
2. 與需求方溝通
（1）搞清需求方的本質訴求
需求方可能是運營、銷售、客服，他們會根據自己當前遇到的問題直接跟產品經理提需求。大家都知道快馬和汽車的故事，需求方需要一匹快馬，我們是直接按他說的給他快馬，還是思考他提出這個需求的本質訴求是什么，能否轉化成另一個需求，是否還有更合理的解決方案？如果來一個需求就做一個，缺乏對需求背后的思考，這不叫產品經理，叫需求實現師。
（2）明確產品和需求方的邊界
當與需求方長期合作時，需要形成一個良好的溝通模式，明確各自的職責范圍和邊界。比如與運營合作上線一個項目，哪些內容是運營需要明確的，哪些內容是產品可以有施展空間的。
這個過程中，產品不能隨意修改運營確認的規(guī)則，但也不能放任需求的不斷變化，不能讓運營直接干涉產品系統層面的影響。優(yōu)雅的把握好邊界，相互尊重彼此的工作內容，能夠減少很多扯皮，讓合作效率更高。
3. 與開發(fā)溝通
對于初級產品經理偏重于項目執(zhí)行，日常溝通的對象最多的一定是開發(fā)人員，如果溝通太少，要么是你需求文檔完美無缺（幾乎不可能），要么是你不夠主動。
（1）跟開發(fā)大佬和開發(fā)小弟溝通的區(qū)別
開發(fā)大佬就是某條線的技術負責人，在有重大功能迭代的時候，可能會需要先跟他對方案。與開發(fā)大佬溝通時最好是提前想好靠譜的方案，而不是偏差太大的天馬行空，這樣避免浪費雙方時間，也能提高大佬對你的信任。
開發(fā)小弟就是除了大佬之外的開發(fā)同學，與他們溝通的核心技巧是要建立利益共同體，因為他們是具體做需求的人，你需要把需求的背景、實現后的價值講給他們，以及上線之后的效果也要多同步給他們，提高他們的自豪感。開發(fā)小弟也需要成功的項目來體現自己的價值，讓他們感受到你們是一條線上，他們也會盡心盡力幫助把系統做的更好，開發(fā)過程中改點小需求也就不在話下了。當然，這些技巧是要建立在需求文檔質量合格的前提下。
（2）預期管理
產品立項時、項目開發(fā)過程中，對開發(fā)人員的預期管理是很有必要的，有的開發(fā)覺得這個項目不是很重要，重視程度不夠，最后導致延期；有的開發(fā)對這個功能上線期待很高，最后上線后效果并不理想；有的開發(fā)在立項時認為這個項目開發(fā)這些功能需要2周，但中途你又加了幾個小需求導致開發(fā)時間壓縮，開發(fā)人員非常不滿。這些都是實際的情況與開發(fā)人員預期情況產生較大不一致造成的。
因此一些關鍵的事項，需要跟開發(fā)人員預期保持一致，我主要總結以下幾點：
a）項目目標和價值
比如一個非常重要的項目，需要在2周內上線，預計可以獲取新增用戶10萬個，這些明確的項目目標和價值需要在立項時及時同步給開發(fā)人員，有時候你的重視程度會影響開發(fā)的投入程度。
b）關鍵時間節(jié)點
開發(fā)時間、轉測時間、上線時間，幾個關鍵的節(jié)點要時刻強調，建議直接寫在項目群公告中，避免有的開發(fā)同學遺漏忽略。
c）風險和備用方案
項目可能產生的風險和備用解決辦法，在立項時也應該跟開發(fā)同學保持同步，一些外部的不可控因素可能會產生什么影響。比如一個項目可能臨時更換合作方這種突發(fā)事項，提前同步可以讓大家心里都有底，不至于發(fā)生時產生太多不利于合作的情緒。
（3）跟開發(fā)的工作氛圍建設
除了工作中，工作之余與開發(fā)同學經常一起玩，開開玩笑，建立良好的工作氛圍和私人關系也很有必要，會讓工作的合作效率更高。也許一個小需求對于關系一般太嚴肅的開發(fā)來說需要排期才能處理，但關系融洽的開發(fā)可能隨手就幫你解決了。
六、方法論建設
1. 建立自己的能力模型
產品經理從第一天開始工作起，基于自己的工作內容和所在領域，就可以開始規(guī)劃自己的能力模型，并不斷的完善，這樣一個能力模型既與工作內容相關，又是獨立于當前的工作內容，是抽象出來的通用的能力模型，這樣才能保證自己在產品經理這個崗位中的競爭力。關于如何建立自己的能力模型，可直接查看我的這篇文章。《工作重復單調成長太慢？如何從中提煉核心能力》
2. 注重思維方式的迭代
根據我個人建立的產品能力模型，相比于各種經驗技巧方法論，我認為最底層的是思維方式，優(yōu)秀的思維方式可以讓你在面對不同工作內容時舉一反三。而產品經理到底要具備哪些思維方式？
這個問題我建議你也不要看別人直接輸出的結論文章，我給出兩點建議：
（1）閱讀經典的評分高的思維方式書籍，相比于產品同行寫的產品思維的文章，優(yōu)秀的思維方式書籍的含金量更高且內容更系統，更有利于對思維方式的學習。如《思考，快與慢》、《窮查理寶典》、《用理工科思維理解世界》。
（2）根據自己實際的工作經歷，復盤做得不好的項目各個環(huán)節(jié)欠缺哪些思考，回頭看如何思考可以做得更好。而對于做得好的項目又是怎么思考的。以此進行演繹，形成自己認為重要的思維方式。
以上是我結合工作經歷，對初級產品經理工作過程中一些技巧的復盤總結，一共寫了兩周時間，反復修改了多次，希望對你有所幫助。
作者：haven，非典型工科中年男孩，云擼貓，愛做飯；公眾號：PM何小澤
本文由 @haven 原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
謝謝你，對于小白來說很受用。
很棒
太厲害了
寫的很用心，有共鳴
謝謝作者，很多點有共鳴，加油！
整理不易，作為一個剛開始入門產品工作的設計師來說有些視角的思考還是挺受用的。
很簡單的玩意搞那么復雜？
確實有點啰嗦了
寫的很詳細，有點老師講課的感覺，確實是干貨。
特別是后端設計的2、3、4、5點，其實都是些比較常見的工作場景，
這塊能用簡略的圖片配以解說就更易懂了。
不愧是工科出身，文章結構很扎實。