萬字干貨 | 初級產(chǎn)品經(jīng)理工作技巧指南

9 評論 18352 瀏覽 240 收藏 36 分鐘

本文的主要內(nèi)容是初級產(chǎn)品經(jīng)理工作過程中各環(huán)節(jié)的技巧總結(jié),我寫的時候盡量是從現(xiàn)有工作內(nèi)容中抽離,沒有涉及到我的具體業(yè)務(wù),因此不同細分領(lǐng)域的產(chǎn)品經(jīng)理都可以通用。

剛?cè)腴T不久的產(chǎn)品經(jīng)理容易有這樣一個現(xiàn)象:看過很多的產(chǎn)品文章,學(xué)過一些產(chǎn)品課程,了解很多高大上的模型理論,每天關(guān)注互聯(lián)網(wǎng)資訊,你跟他聊天的時候發(fā)現(xiàn)他什么都懂一點,但一上手就是不出活,暴露各種基本功不扎實的問題。

為什么看了那么多大咖的分享總結(jié)、方法論的文章,依然做不好需求?

結(jié)合我自己的經(jīng)歷,我把原因總結(jié)為兩方面:

  • 一方面,看的文章寫的內(nèi)容泛泛而談不夠干貨,或者說通用性不強,僅適用于作者自己的項目和工作,難以進行學(xué)習(xí)模仿。
  • 另一方面是你只是略讀一遍,像看新聞一樣,沒有深入理解其中的精華,在實踐的時候也沒有運用上。

本文的主要內(nèi)容是初級產(chǎn)品經(jīng)理工作過程中各環(huán)節(jié)的技巧總結(jié),我寫的時候盡量是從現(xiàn)有工作內(nèi)容中抽離,沒有涉及到我的具體業(yè)務(wù),因此不同細分領(lǐng)域的產(chǎn)品經(jīng)理都可以通用。為了區(qū)分什么是技巧、技能、能力,我這里做了如下定義:

  • 技巧:是為了快速提升技能的手段,是技能的一部分,是可以學(xué)習(xí)復(fù)制的。
  • 技能:是具體的、全面的,是為了做好一項工作而需要具備的內(nèi)容,是可以學(xué)習(xí)復(fù)制的。
  • 能力:是技能內(nèi)化后的結(jié)果,是舉一反三的驅(qū)動力,很難復(fù)制,需要靠自己總結(jié)提煉。

由此可見,要提升產(chǎn)品能力,可以先從學(xué)習(xí)技巧開始,再掌握全面的技能,最后提煉出通用的能力,如此循序漸進。

本文主要內(nèi)容:

  1. 初級產(chǎn)品經(jīng)理必備素質(zhì)
  2. 需求收集和過濾
  3. 產(chǎn)品方案設(shè)計
  4. 項目管理
  5. 溝通技巧
  6. 方法論建設(shè)

一、初級產(chǎn)品經(jīng)理必備素質(zhì)

處在職場的不同階段,聚焦點是不一樣的。作為初級產(chǎn)品經(jīng)理,需要明確自己的定位和目標,練好基本功,切勿好高騖遠。

1. 清晰的自我定位

初級產(chǎn)品經(jīng)理一般完整的負責(zé)一個功能模塊或一個系統(tǒng),首先,需要對自己負責(zé)的模塊充分的熟悉然后了如指掌,讓所有需要跟這個功能對接的人知道,有問題只要找你就解決了,這也是逐步建立影響力的過程。

其次,熟悉了模塊之后,再深入思考該模塊不同競品做的怎么樣,自己產(chǎn)品所在哪個檔次,距離最好的產(chǎn)品差距有多少,如何基于公司的業(yè)務(wù)提高該模塊的競爭力。

最后,在掌握了自己負責(zé)的內(nèi)容后,以點帶面,不斷完善加深對公司產(chǎn)品和業(yè)務(wù)的理解,才能獲得更多機會承擔(dān)更重大的項目。

以上三個過程是一個遞進的關(guān)系,也是初級產(chǎn)品經(jīng)理在不同工作階段的不同定位。

2. 明確的工作目標

對于剛工作的前兩年,對于個人能力的提升目標方面,應(yīng)該著重關(guān)注執(zhí)行力、溝通力、項目管理能力三大塊,其中執(zhí)行力包含了需求分析、產(chǎn)品設(shè)計、推進項目開始到上線過程的方方面面,這三大塊內(nèi)容是作為產(chǎn)品經(jīng)理最基本的基本功。

二、需求收集和過濾

1. 需求池管理

產(chǎn)品經(jīng)理對需求的管理就像廚師對食材的管理,廚師在眾多食材中挑選合理的組合,加工成美味,產(chǎn)品經(jīng)理在眾多業(yè)務(wù)方提出的需求中進行組合設(shè)計,加工成產(chǎn)品功能。好的需求池管理不僅是對需求進行過濾,也是對工作內(nèi)容的精細化記錄和總結(jié),有利于有條不紊的項目管理和后期的復(fù)盤。

我將對需求池的管理內(nèi)容總結(jié)為三大部分:

  1. 判斷并記錄需求的真?zhèn)?、重要性、緊急度、實現(xiàn)難度、業(yè)務(wù)價值、關(guān)聯(lián)方;
  2. 記錄當(dāng)前每個需求的項目實現(xiàn)狀態(tài);
  3. 追蹤需求實現(xiàn)后的用戶及數(shù)據(jù)反饋情況。

至于需求池的表格模板,我認為每個人的實際需求和習(xí)慣不同,也沒有必要照搬別人的,只要覆蓋了以上三大塊內(nèi)容,起到了需求池管理的作用即可。

2. 優(yōu)先級判斷

一般剛?cè)胄械某跫壆a(chǎn)品常常直接執(zhí)行領(lǐng)導(dǎo)分配的任務(wù),但并不代表優(yōu)先級判斷這件事對于初級產(chǎn)品不重要。需求優(yōu)先級判斷這個話題,網(wǎng)上一搜產(chǎn)品文章一大堆,各種四象限法、卡諾模型等等。但每個人處于工作不同的時間狀態(tài),對公司及行業(yè)產(chǎn)品的理解層次是不一樣的。所以就算你學(xué)完了背熟了產(chǎn)品課程中所有的需求分析方法論、或者優(yōu)先級判斷模型,你的判斷的合理程度很難跟你的領(lǐng)導(dǎo)相比。

優(yōu)先級判斷屬于洞察決策層面的高級能力,不是工作技巧,它的變量太多,需要多方權(quán)衡,比如業(yè)務(wù)重要程度、緊急程度、工作量、性價比、是否匹配系統(tǒng)當(dāng)前所處的階段、對系統(tǒng)的影響大小,甚至領(lǐng)導(dǎo)強勢程度等等,不同行業(yè)不同公司情況,用一套模型和公式是無法解決的。

我這里想強調(diào)的是,不必拘泥于具體的判斷方法和公式,而是一開始就養(yǎng)成對自己需求池進行優(yōu)先級判斷的習(xí)慣,也許一開始判斷的結(jié)果并不準確。會踩過一些坑,但隨著對業(yè)務(wù)和行業(yè)的逐漸熟悉,判斷會越來越準確。所以我建議忘掉別人總結(jié)的公式,建立自己的判斷標準,并不斷調(diào)整優(yōu)化這個標準。

三、產(chǎn)品方案設(shè)計

我將產(chǎn)品規(guī)劃設(shè)計粗暴的分為前端頁面設(shè)計和后端產(chǎn)品設(shè)計,這里的后端其實不是真正意義的后端產(chǎn)品經(jīng)理才關(guān)注的,也會包含很多前端功能邏輯層面的設(shè)計。凡是屬于用戶可見可操作界面的部分為前端設(shè)計,不可見的邏輯及系統(tǒng)設(shè)計則為后端設(shè)計。

1. 前端頁面設(shè)計

交互設(shè)計領(lǐng)域人機交互大師雅各布·尼爾森博士,在1995年提出的尼爾森十大可用性原則,對二十多年后今天的互聯(lián)網(wǎng)產(chǎn)品設(shè)計仍然影響深遠,對于軟件類著重頁面設(shè)計的互聯(lián)網(wǎng)產(chǎn)品來說,我提煉了其中4點:

(1)簡單易理解

包括了文案的簡潔明了、功能玩法的易理解,在單個頁面內(nèi)減少過多不必要的信息。

(2)操作有反饋

當(dāng)用戶進行某個操作后,以合理的形式向用戶反饋目前的狀態(tài),可能會發(fā)生什么。

(3)操作可回退

用戶走的每一條路都不能是死胡同,應(yīng)該都能讓他回到原點。

(4)功能一致性

不同位置的相同功能保持一致,保證了產(chǎn)品設(shè)計統(tǒng)一,用戶更易學(xué)習(xí)。

前端設(shè)計我只總結(jié)了以上4點,比較適用于產(chǎn)品原型的交互設(shè)計,但卻是任何一個優(yōu)秀的產(chǎn)品必不可少的核心設(shè)計原則。

2. 后端產(chǎn)品設(shè)計

后端設(shè)計的細節(jié)太多,沒法像前端設(shè)計原則一樣進行高度歸納,我這里也是根據(jù)自己大大小小的項目經(jīng)驗逐條進行總結(jié),內(nèi)容不夠系統(tǒng),可以當(dāng)做幾個關(guān)鍵點設(shè)計的參考。

(1)MECE原則,相互獨立,完全窮盡

這個基本原則相信每個產(chǎn)品經(jīng)理都知道,它是一個能讓產(chǎn)品方案條理有序、不遺漏、不重復(fù)的重要標準。我這里主要強調(diào)一下它具體體現(xiàn)在了什么方面。

a)產(chǎn)品方案對標業(yè)務(wù)需求

我們假設(shè)這里的業(yè)務(wù)需求都是相對合理的需要實現(xiàn)的。那設(shè)計的產(chǎn)品方案需要對應(yīng)滿足這些業(yè)務(wù)需求,不能遺漏任何一個,同時也不能讓產(chǎn)品方案內(nèi)部出現(xiàn)重疊的功能,而是剛好完美的滿足了業(yè)務(wù)需求,也使開發(fā)的系統(tǒng)內(nèi)部達到軟件工程上的最優(yōu)解,這就叫滿足MECE原則。

b)需求文檔的書寫

落實到具體的執(zhí)行,需求文檔中描述功能時也需要盡量滿足這個原則。首先做到描述不遺漏,充分考慮異常流、特殊邏輯;然后需要語言精簡客觀,對同一功能和模塊不必重復(fù)贅述,對于有耦合關(guān)系的模塊,用語言上的邏輯因果、時間先后來進行描述。

(2)強化對狀態(tài)的認知

對于一個后臺系統(tǒng),狀態(tài)無處不在,靈活多變的業(yè)務(wù)需求是靠一張張數(shù)據(jù)庫的表在記錄的,除了業(yè)務(wù)數(shù)據(jù)的記錄,狀態(tài)是非常重要的基礎(chǔ)。訂

單必須有狀態(tài),用于區(qū)分不同業(yè)務(wù)環(huán)節(jié):一個上線的活動必須要有狀態(tài),是進行中、已暫停、還是已下線;一個員工賬號也要有狀態(tài),是啟用中、禁用中還是已注銷。

設(shè)計一個功能或系統(tǒng)通常需要先繪制流程圖,而流程圖中一個個狀態(tài)的連接支撐起了整個功能設(shè)計的骨架,然后才是具體細節(jié)的設(shè)計。

如何正確的強化對狀態(tài)的認知和理解,我大概總結(jié)以下幾點:

a)狀態(tài)的獨立互斥

這點與上面說的唯一判斷字段有點類似,但實際不是一回事。因為狀態(tài)是用于描述不同業(yè)務(wù)節(jié)點的,每個狀態(tài)要與實際業(yè)務(wù)的關(guān)鍵節(jié)點進行一一對應(yīng),狀態(tài)之間不能出現(xiàn)二義性,否則會出現(xiàn)多個狀態(tài)對應(yīng)同一個業(yè)務(wù)關(guān)鍵節(jié)點,不但會造成理解混淆,還可能使系統(tǒng)做具體判斷時出問題。

b)狀態(tài)在時間維度上是穩(wěn)定的

這點其實也很好理解,一個具體業(yè)務(wù)的發(fā)展是有階段性的,而狀態(tài)就是在每個階段取一個值,各個值連接起來就串聯(lián)的業(yè)務(wù),但如果狀態(tài)的值取在各個階段的臨界點,這就很不好描述業(yè)務(wù)了。比如一個運營活動,可以用“進行中”和“已下線”兩個狀態(tài)來區(qū)分發(fā)生和不發(fā)生兩個階段,這是合理的,但如果狀態(tài)叫做“下線中”,這就不是處在一個穩(wěn)定的狀態(tài),而像一個瞬時態(tài),到底是上線還是下線,我們從狀態(tài)命名中就感覺很模糊。

c)注意子狀態(tài)和組合狀態(tài)

當(dāng)業(yè)務(wù)相當(dāng)復(fù)雜時,一個狀態(tài)下面還可以設(shè)置子狀態(tài),比如單據(jù)的撤銷狀態(tài),可以包括用戶主動撤銷、系統(tǒng)撤銷、人工撤銷,用于區(qū)分具體是怎么被撤銷的。

而組合狀態(tài)的意思是在用戶側(cè)展示的狀態(tài)不單是訂單表里存的狀態(tài)名稱,而是一個組合狀態(tài),比如在用戶側(cè)顯示“已發(fā)貨”,其實包含了訂單狀態(tài)為“創(chuàng)建成功”、支付狀態(tài)為“已付款”、物流狀態(tài)為“已出庫”。像比較復(fù)雜的保險訂單狀態(tài),還會包含訂單狀態(tài)、支付狀態(tài)、續(xù)保狀態(tài)等,因此不能用一維的線性的來看待狀態(tài)。

d)狀態(tài)機的流轉(zhuǎn)路線

狀態(tài)機圖的確定,基本確定了系統(tǒng)和功能主體結(jié)構(gòu),各狀態(tài)之間的起點終點、流轉(zhuǎn)路線、判斷條件決定了功能的玩法和限制,狀態(tài)機圖是梳理并對照實際業(yè)務(wù)的必備工具。當(dāng)業(yè)務(wù)有功能拓展時,首先查看狀態(tài)機圖是否滿足,如何調(diào)整才能滿足,已經(jīng)涉及到哪些相關(guān)調(diào)整,都需要用到這個圖。

e)合理的狀態(tài)有利于數(shù)據(jù)統(tǒng)計

當(dāng)狀態(tài)的設(shè)計都按照上述原則進行,狀態(tài)與狀態(tài)之間非常清晰,這對數(shù)據(jù)統(tǒng)計是非常有益的。因為很多的數(shù)據(jù)統(tǒng)計都強依賴對狀態(tài)的定義,如果你在做數(shù)據(jù)統(tǒng)計的時候發(fā)現(xiàn)很難準確的提需求,或者發(fā)現(xiàn)無法按照業(yè)務(wù)需要的維度來進行統(tǒng)計,可以反思下系統(tǒng)的狀態(tài)是否合理。

(3)預(yù)留拓展性邏輯

我之前經(jīng)常遇到一種情況,當(dāng)我做一個功能上線之后,業(yè)務(wù)方有時會再提一個與這個非常類似的需求,有時候僅僅只是改動很少的內(nèi)容。如果在第一次設(shè)計時并沒有預(yù)留可能的拓展性,就算只是很少的改動,還是要排期開發(fā)和測試,特別是有的功能還需回歸測試,非常浪費開發(fā)資源,而且影響迭代速度。這時就考驗在設(shè)計之初能否大概看出可能有的拓展性,在開發(fā)工作量幾乎不變的情況下預(yù)留一些類似的邏輯,這樣會非常便于類似功能的迭代。

舉個例子,對于一個人工審核的結(jié)論頁,有多種狀態(tài),每種狀態(tài)下結(jié)論頁的不同模塊的元素、文案、以及對用戶的觸達文案,都是首次開發(fā)時配置好的。

首次開發(fā)時業(yè)務(wù)方提出有三種狀態(tài),上線之后業(yè)務(wù)方說要再加一種特殊的狀態(tài),如果事先在狀態(tài)機中預(yù)留了待定的狀態(tài),只需要把該待定狀態(tài)下頁面的元素、文案、對用戶的觸達進行設(shè)置即可,改動的工作量很小,可以快速的上線。

不過值得注意的一點是,在預(yù)留拓展性時盡量保證首次開發(fā)的工作量影響很小,如果為了暫時使用不到的預(yù)留需求消耗過多開發(fā)資源,就有點本末倒置了。最好的針對復(fù)制一份代碼、預(yù)留一個狀態(tài)這種相似功能進行考慮。

(4)對變量的抽象

對變量的抽象是一種模塊化思維,能夠減少很多重復(fù)的工作量,提高后期的開發(fā)效率,我將分成兩種情況來描述。

一種是當(dāng)多個頁面都用到同一個內(nèi)容時,該內(nèi)容應(yīng)該被抽象為公共變量,供各頁面調(diào)用。比如一個常用聯(lián)系人組件包含姓名、證件類型、證件號碼、性別、出生日期這五要素,那么可以把這五要素設(shè)置成一個公共變量模塊,在不同產(chǎn)品下單需要用到時直接調(diào)用即可。如果有的產(chǎn)品下單時只需要用到姓名、證件類型、證件號碼三要素,則可以把五要素的變量模塊拆細為五個變量元素,這樣可以達到最大自由度的組合。

另一種情況是兩個頁面絕大部分內(nèi)容相同,只有幾個元素有差異時,這幾個有差異的元素應(yīng)該抽象為配置變量,做成一個配置文件或者管理后臺,這樣在調(diào)整該配置時就不用再寫代碼。有的同學(xué)可能對配置文件不太懂,它可以理解為一段未被編譯器編譯的配置代碼,是對一個軟件運行時狀態(tài)的本地儲存形式,可以實現(xiàn)對軟件靈活的實時調(diào)整。

比如:同樣一個商品的詳情頁需要在A平臺是紅色背景,有評論模塊,在B平臺是綠色背景,不要評論模塊。如果事先將背景色、有無評論模塊這兩個變量做成配置項,只需要更改配置文件或在管理后臺做相應(yīng)勾選即可。

(5)時刻考慮系統(tǒng)的靈活性

講完兩種基本的變量抽象方式,我再講講整個系統(tǒng)的靈活性。

比如一個普通的商品詳情頁,如果只給你1天時間從0到1來做這個頁面,你會把頁面的所有元素、邏輯寫清楚,找到前端后端開發(fā)按照你的邏輯進行實現(xiàn),然后發(fā)布上線。如果你想修改一個banner圖,必須要找前端開發(fā)從代碼層面幫你換圖,然后再發(fā)布,這時我們認為這個頁面是非常不靈活的。

因此你把banner、標簽、價格、尺碼分類等等都抽象成了配置變量,就可以在管理后臺靈活的調(diào)整這些內(nèi)容,無需再發(fā)布,看起來非常靈活了。但是當(dāng)這個頁面需要對不同商家顯示不同商品時,你就需要再把這整個頁面做成配置項,對每一個商家可以單獨配置一套商品詳情頁。

接下來業(yè)務(wù)需求再進一步演化,每個商家想要自己去配置自己的商品詳情頁,這時你還需要把商品詳情頁的配置功能做成一個商家管理后臺,讓商家自己去靈活設(shè)置,這時候單是這個商品詳情頁就已經(jīng)很復(fù)雜了。

如果每個商家還要對自己的員工分別配置權(quán)限,有的員工只能修改banner圖和名稱,有的員工可以修改商品sku、價格等等,那你還需要把這個商家的商品詳情頁配置功能結(jié)合賬號權(quán)限再細分配置,讓商家自己靈活勾選什么員工可以操作什么權(quán)限。

我這里只是簡單的描述了一下電商平臺商品詳情頁的配置演化路徑,就可以看出,當(dāng)業(yè)務(wù)需求越來越細化,對系統(tǒng)靈活性的要求就越來越高,也意味著系統(tǒng)的復(fù)雜程度越來越高。為了盡可能充分的滿足業(yè)務(wù)需求,我們需要時刻注意系統(tǒng)的靈活性,在每一版迭代的時候避免太多寫死的邏輯。

(6)總結(jié)遇到的異常流

每做一個項目,在上線之后可能都會遇到反饋的線上問題,特別是一些在設(shè)計時考慮不全的異常邏輯,會在用戶真正使用的時候暴露出來。做完項目遇到這種情況并不可怕,因為人無完人,產(chǎn)品經(jīng)理不是神,設(shè)計之初漏掉一些異常流是很正常的,但如果每次項目都漏掉一些,或者同樣的異常問題多次出現(xiàn),這就是產(chǎn)品經(jīng)理的問題了。

我們可以認為,在業(yè)務(wù)拓展沒那么快的情況下,軟件層面的設(shè)計的異常流是很有限的,只要遇到一個就把它解決掉,總會消滅干凈的。

產(chǎn)品經(jīng)理每天的工作時間,可能會有一部分都是在處理自己留下的坑,但在填坑的時候我們能否不僅僅只為了填坑,能否思考是怎么漏掉這些異常流的,并一一總結(jié)出來,這樣也許能大大提升產(chǎn)品設(shè)計的完整性。

四、項目管理

項目管理之前應(yīng)該先判斷該項目的類型,不同的項目推進和管理的方式區(qū)別很大,根據(jù)項目大小與任務(wù)并行程度,我分為以下三類:

1. 周期較長的大項目管理

對于單個部門內(nèi)部開發(fā)周期較長的項目(超過2周),我總結(jié)有以下項目管理的關(guān)鍵點:

(1)提前溝通開發(fā)方案

一般較大項目功能比較復(fù)雜,因此整體方案設(shè)計時需要預(yù)先跟開發(fā)人員溝通,明確一些關(guān)鍵限制因素和影響點,避免需求評審時方案不可行,或者調(diào)整太大,在評審會上難以達成一致。

(2)關(guān)注功能先后順序

提前關(guān)注項目中不同功能的相互依賴性以及對外部系統(tǒng)依賴性,根據(jù)功能依賴的先后順序確定項目的排期節(jié)奏,提高排期銜接程度,避免一個功能開發(fā)完很久之后還不能與其他功能聯(lián)調(diào),浪費開發(fā)資源。

(3)對項目的強推動力

每日跟進關(guān)鍵點的結(jié)果,盡早發(fā)現(xiàn)風(fēng)險(日報、周報、晨會等形式)。

(4)項目復(fù)盤總結(jié)

項目完成后回顧項目過程中哪些過程效率有待提高、哪些過程安排的不夠合理,如何避免在下一個項目中繼續(xù)出現(xiàn)。

2. 跨部門跨公司合作的項目管理

跨部門和跨公司合作的項目,開發(fā)量不一定很大,但由于牽連方較多,比起團隊內(nèi)開發(fā)有了更多的不確定因素,項目容易延期,因此在上述大項目的管理基礎(chǔ)上需要額外關(guān)注這幾點:

(1)找到合作關(guān)鍵點

不管是跨部門還是跨公司合作,首先要明確對雙方的關(guān)鍵利益點,并強調(diào)合作對對方的好處,才能獲得對方的積極支持,否則很容易被踢皮球;

(2)書面確認詳細事項

跨部門和跨公司合作,一般都是遠程電話溝通,因此對會議上達成一致的點需要書面記錄郵件至對方,對達成一致的點也需要記錄并積極跟進對方的最新答復(fù)。這一點主要是為了提高需求的確定性,明確雙方職責(zé),避免因為溝通沒有記錄影響項目開發(fā)進度。

3. 多個小項目并行的項目管理

對于互聯(lián)網(wǎng)的敏捷開發(fā)模式,超過兩三周的大項目少有,多個小項目并行才是更常見的狀態(tài),這里的小項目其實是單個很明確的需求,粒度比較小,這種狀態(tài)下產(chǎn)品經(jīng)理一周可能同時在跟進十多個需求在開發(fā)狀態(tài),這對多項目并行的考驗很大,我總結(jié)了以下幾點:

(1)更合理的排期節(jié)奏

由于項目太多,為了避免同一天過多需求同時在開發(fā)或者在測試,在排期的時候盡量均勻的分布,這樣保證在一些需求已經(jīng)進入測試或已發(fā)布,另外的項目剛進入開發(fā),避免某一天的事情太多。

(2)每日tips跟進每個項目的狀態(tài)

首先需要實時記錄這些并行的需求的開發(fā)狀態(tài)、開發(fā)人員,然后每天早晚跟對應(yīng)的開發(fā)人員跟進需求狀態(tài),及時解決相關(guān)問題。

(3)小需求歸檔

小需求上線一時爽,后期維護痛苦不已。每個小需求在開發(fā)過程中是獨立的,但對于整個產(chǎn)品來說它是一個個的迭代,只有及時將這些迭代歸檔到對應(yīng)的功能模塊,才能后續(xù)方便的了解查詢當(dāng)前線上的產(chǎn)品規(guī)則是怎樣的。否則后期連自己都忘了到底最新的迭代是什么,這個坑誰踩過誰就知道有多苦。

五、溝通技巧

與項目管理類似,溝通之前我們要對溝通的對象進行分類,不同溝通對象需要注意的事項是不一樣的。

1. 與合作方溝通

(1)溝通方式的合理選擇

一般與合作方很難面對面溝通,大多是電話和在線溝通,因此對于不同的事項要選擇合適的溝通方式。比如首次確認合作內(nèi)容,需要電話詳細說明合作細節(jié),然后書面記錄達成共識的事項;確認完合作內(nèi)容后,有小的疑問點可以在線溝通。

(2)催進度也有技巧

有依賴合作方確認的事項或開發(fā)進度時,催進度是最頻繁的事。但是催進度需要包含幾個關(guān)鍵因素才能起到好的效果。

首先是良好的態(tài)度,對對方的尊稱是必須的,就算對方態(tài)度比較冷淡也需要保持著熱臉貼冷屁股的熱情,因為在工作中,合作的順利完成才是最重要的,這也是職場人的必備素質(zhì)。

其次是明確具體內(nèi)容和時間點,比如當(dāng)希望對方對某個點反饋結(jié)果時,反面教材是這樣的“請問你們這個功能可以快一點開發(fā)嗎?”、“麻煩盡快確認下XXX這個點哦”,這樣的詢問都沒有明確時間點,對方感受不到壓力,催進度的效果不明顯,正確的方式是“請問某某負責(zé)人,針對這個三點事項(一一列舉),您可以在今天下午5點之前確認嗎,麻煩您了”。

再次是要找對關(guān)鍵人確認,比如你一直跟對方的一個開發(fā)人員催進度沒什么用,需要直接找到對方的產(chǎn)品或項目負責(zé)人,甚至是對方領(lǐng)導(dǎo)。

2. 與需求方溝通

(1)搞清需求方的本質(zhì)訴求

需求方可能是運營、銷售、客服,他們會根據(jù)自己當(dāng)前遇到的問題直接跟產(chǎn)品經(jīng)理提需求。大家都知道快馬和汽車的故事,需求方需要一匹快馬,我們是直接按他說的給他快馬,還是思考他提出這個需求的本質(zhì)訴求是什么,能否轉(zhuǎn)化成另一個需求,是否還有更合理的解決方案?如果來一個需求就做一個,缺乏對需求背后的思考,這不叫產(chǎn)品經(jīng)理,叫需求實現(xiàn)師。

(2)明確產(chǎn)品和需求方的邊界

當(dāng)與需求方長期合作時,需要形成一個良好的溝通模式,明確各自的職責(zé)范圍和邊界。比如與運營合作上線一個項目,哪些內(nèi)容是運營需要明確的,哪些內(nèi)容是產(chǎn)品可以有施展空間的。

這個過程中,產(chǎn)品不能隨意修改運營確認的規(guī)則,但也不能放任需求的不斷變化,不能讓運營直接干涉產(chǎn)品系統(tǒng)層面的影響。優(yōu)雅的把握好邊界,相互尊重彼此的工作內(nèi)容,能夠減少很多扯皮,讓合作效率更高。

3. 與開發(fā)溝通

對于初級產(chǎn)品經(jīng)理偏重于項目執(zhí)行,日常溝通的對象最多的一定是開發(fā)人員,如果溝通太少,要么是你需求文檔完美無缺(幾乎不可能),要么是你不夠主動。

(1)跟開發(fā)大佬和開發(fā)小弟溝通的區(qū)別

開發(fā)大佬就是某條線的技術(shù)負責(zé)人,在有重大功能迭代的時候,可能會需要先跟他對方案。與開發(fā)大佬溝通時最好是提前想好靠譜的方案,而不是偏差太大的天馬行空,這樣避免浪費雙方時間,也能提高大佬對你的信任。

開發(fā)小弟就是除了大佬之外的開發(fā)同學(xué),與他們溝通的核心技巧是要建立利益共同體,因為他們是具體做需求的人,你需要把需求的背景、實現(xiàn)后的價值講給他們,以及上線之后的效果也要多同步給他們,提高他們的自豪感。開發(fā)小弟也需要成功的項目來體現(xiàn)自己的價值,讓他們感受到你們是一條線上,他們也會盡心盡力幫助把系統(tǒng)做的更好,開發(fā)過程中改點小需求也就不在話下了。當(dāng)然,這些技巧是要建立在需求文檔質(zhì)量合格的前提下。

(2)預(yù)期管理

產(chǎn)品立項時、項目開發(fā)過程中,對開發(fā)人員的預(yù)期管理是很有必要的,有的開發(fā)覺得這個項目不是很重要,重視程度不夠,最后導(dǎo)致延期;有的開發(fā)對這個功能上線期待很高,最后上線后效果并不理想;有的開發(fā)在立項時認為這個項目開發(fā)這些功能需要2周,但中途你又加了幾個小需求導(dǎo)致開發(fā)時間壓縮,開發(fā)人員非常不滿。這些都是實際的情況與開發(fā)人員預(yù)期情況產(chǎn)生較大不一致造成的。

因此一些關(guān)鍵的事項,需要跟開發(fā)人員預(yù)期保持一致,我主要總結(jié)以下幾點:

a)項目目標和價值

比如一個非常重要的項目,需要在2周內(nèi)上線,預(yù)計可以獲取新增用戶10萬個,這些明確的項目目標和價值需要在立項時及時同步給開發(fā)人員,有時候你的重視程度會影響開發(fā)的投入程度。

b)關(guān)鍵時間節(jié)點

開發(fā)時間、轉(zhuǎn)測時間、上線時間,幾個關(guān)鍵的節(jié)點要時刻強調(diào),建議直接寫在項目群公告中,避免有的開發(fā)同學(xué)遺漏忽略。

c)風(fēng)險和備用方案

項目可能產(chǎn)生的風(fēng)險和備用解決辦法,在立項時也應(yīng)該跟開發(fā)同學(xué)保持同步,一些外部的不可控因素可能會產(chǎn)生什么影響。比如一個項目可能臨時更換合作方這種突發(fā)事項,提前同步可以讓大家心里都有底,不至于發(fā)生時產(chǎn)生太多不利于合作的情緒。

(3)跟開發(fā)的工作氛圍建設(shè)

除了工作中,工作之余與開發(fā)同學(xué)經(jīng)常一起玩,開開玩笑,建立良好的工作氛圍和私人關(guān)系也很有必要,會讓工作的合作效率更高。也許一個小需求對于關(guān)系一般太嚴肅的開發(fā)來說需要排期才能處理,但關(guān)系融洽的開發(fā)可能隨手就幫你解決了。

六、方法論建設(shè)

1. 建立自己的能力模型

產(chǎn)品經(jīng)理從第一天開始工作起,基于自己的工作內(nèi)容和所在領(lǐng)域,就可以開始規(guī)劃自己的能力模型,并不斷的完善,這樣一個能力模型既與工作內(nèi)容相關(guān),又是獨立于當(dāng)前的工作內(nèi)容,是抽象出來的通用的能力模型,這樣才能保證自己在產(chǎn)品經(jīng)理這個崗位中的競爭力。關(guān)于如何建立自己的能力模型,可直接查看我的這篇文章。《工作重復(fù)單調(diào)成長太慢?如何從中提煉核心能力》

2. 注重思維方式的迭代

根據(jù)我個人建立的產(chǎn)品能力模型,相比于各種經(jīng)驗技巧方法論,我認為最底層的是思維方式,優(yōu)秀的思維方式可以讓你在面對不同工作內(nèi)容時舉一反三。而產(chǎn)品經(jīng)理到底要具備哪些思維方式?

這個問題我建議你也不要看別人直接輸出的結(jié)論文章,我給出兩點建議:

(1)閱讀經(jīng)典的評分高的思維方式書籍,相比于產(chǎn)品同行寫的產(chǎn)品思維的文章,優(yōu)秀的思維方式書籍的含金量更高且內(nèi)容更系統(tǒng),更有利于對思維方式的學(xué)習(xí)。如《思考,快與慢》、《窮查理寶典》、《用理工科思維理解世界》。

(2)根據(jù)自己實際的工作經(jīng)歷,復(fù)盤做得不好的項目各個環(huán)節(jié)欠缺哪些思考,回頭看如何思考可以做得更好。而對于做得好的項目又是怎么思考的。以此進行演繹,形成自己認為重要的思維方式。

以上是我結(jié)合工作經(jīng)歷,對初級產(chǎn)品經(jīng)理工作過程中一些技巧的復(fù)盤總結(jié),一共寫了兩周時間,反復(fù)修改了多次,希望對你有所幫助。

 

作者:haven,非典型工科中年男孩,云擼貓,愛做飯;公眾號:PM何小澤

本文由 @haven 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 謝謝你,對于小白來說很受用。

    來自上海 回復(fù)
  2. 很棒

    來自北京 回復(fù)
  3. 太厲害了

    來自陜西 回復(fù)
  4. 寫的很用心,有共鳴

    回復(fù)
  5. 謝謝作者,很多點有共鳴,加油!

    來自北京 回復(fù)
  6. 整理不易,作為一個剛開始入門產(chǎn)品工作的設(shè)計師來說有些視角的思考還是挺受用的。

    回復(fù)
  7. 很簡單的玩意搞那么復(fù)雜?

    回復(fù)
    1. 確實有點啰嗦了

      回復(fù)
  8. 寫的很詳細,有點老師講課的感覺,確實是干貨。

    特別是后端設(shè)計的2、3、4、5點,其實都是些比較常見的工作場景,
    這塊能用簡略的圖片配以解說就更易懂了。

    不愧是工科出身,文章結(jié)構(gòu)很扎實。

    來自上海 回復(fù)