這篇工作總結(jié)更多的是寫給自己的，但也希望自己的一些感悟能引起一些共鳴。

從16年9月走上產(chǎn)品之路開始，到現(xiàn)在也已經(jīng)一年多的時間了。我很感激公司給予我的成長環(huán)境，我們是創(chuàng)業(yè)公司，而我負責整個公司的產(chǎn)品線。

和從成熟的互聯(lián)網(wǎng)公司的產(chǎn)品助理開始做起相比，劣勢可能是沒有一個更有經(jīng)驗的人能夠帶著你少走一些彎路，任何事情都需要你自己來摸索。但更多的優(yōu)勢是：你能有一個機會去以全局的角度去看自己的產(chǎn)品，去做產(chǎn)品規(guī)劃，對我而言既是機遇也是挑戰(zhàn)。

這一年以來走過了不少彎路，也經(jīng)手了多個產(chǎn)品。產(chǎn)品團隊從我獨身一人也擴充到了四人。有過和技術們鬧矛盾彼此不說話的場景，也有過在工作之余大家敞開心扉彼此理解的釋懷。

在年假這段時間里，我好好地又看了一遍蘇杰的《人人都是產(chǎn)品經(jīng)理》這本書。發(fā)現(xiàn)和剛做產(chǎn)品那會兒看相比，又有了不同的體會。在有了一定的實踐經(jīng)驗基礎上再看，發(fā)現(xiàn)自己能夠把書中的某些理論和實踐相對應起來，那種「紙上得來終覺淺」的感覺少了很多。

于是我想，不如就借著這本書里自己有感觸的一些點，結(jié)合這一年以來的工作感受做一個自己的年終工作總結(jié)吧，同時也是對這本書的一個個人回顧。

工作回顧

這一年多的時間以來我個人主要負責了三個項目。

• 第一個項目是一款服務于校園的短信平臺，也是我們創(chuàng)業(yè)的啟動項目。這個項目也在2017年2月在聚募眾籌拿到了天使輪融資。
• 第二個項目是一款針對企業(yè)的在線短信群發(fā)平臺，在傳統(tǒng)的短信基礎之上我們提供了較為創(chuàng)新的短信模式，希望能做出自己的個性化差異產(chǎn)品。
• 第三個項目是APPlan，這是一款針對美本留學，為出國學生提供全方位智能測評與規(guī)劃的產(chǎn)品，這個項目在2017年12月也成功入駐寧波肯特學校。

這些可能在某些大佬看來不過如此的小成就，其實也是我們整個公司努力的結(jié)果，我很高興自己能在其中做好自己的那一份工作，和公司一起成長。

在這個過程中我自己的一些感悟和心得，結(jié)合《人人都是產(chǎn)品經(jīng)理》這本書，我總結(jié)成了以下10個點，希望能和大家一起分享。如果某些感悟過于片面，還望看官們及時不吝指出。

心得篇

1. 聽用戶的但不要照著做

案例：

這句話應該在產(chǎn)品經(jīng)理領域聽得比較多了，但我自己深有體會還是在「聽用戶的并且照著做」了之后；準確來說，應該是「聽客戶的并且照著做了」之后。

在17年的5月份到9月份期間，我們和一個客戶合作開發(fā)一款針對美本留學的產(chǎn)品，包括Web端以及App端，也就是APPlan?？蛻艉苡邢敕?，對產(chǎn)品的功能架構(gòu)以及功能實現(xiàn)的具體方式都有自己的方案。

一個例子是，客戶希望留學顧問是產(chǎn)品中的一個付費項目，用戶可以直接通過App購買留學顧問服務，購買之后留學顧問能夠通過App中的即時聊天功能對學生進行指導。

當時的我和另一個產(chǎn)品同事都只是剛工作不久，雖然知道有「聽用戶的但不要照著做」這么一句話，但迫于當時的項目周期壓力并沒有花太多時間和客戶深究她的方案就照做了。

兩個月后，產(chǎn)品開發(fā)初步完成。在交給客戶驗收之前，我們內(nèi)部先對產(chǎn)品進行了一次復盤。在看到上面這個功能的時候，老板以及UI小哥就提出了質(zhì)疑。

首先留學顧問收費高，動輒五位數(shù)的申請費用讓用戶在只是瀏覽了顧問的基本信息，沒有任何合同保障的情況下直接付費基本不可能。

其次這個申請費用超多了絕大多數(shù)用戶的銀行卡單筆消費限額，即使有那么一個用戶想要直接付費，也會存在無法付錢的可能。

和客戶交流之后，雖然這個方案是她設想的，但她也贊同我們的觀點，認為這樣的設計不合理。

當然這鍋客戶是不會背的，只能是我們產(chǎn)品團隊背走。

后來的解決方案是下掉直接付費的功能，取而代之的如果有興趣那么用戶可以發(fā)起線上溝通，付費則采用線上溝通之后雙方都認可的方式進行。

總結(jié)：

就像人人都是產(chǎn)品經(jīng)理里說的：

用戶提出的需求往往片面，我們需要找到用戶內(nèi)心真正的渴望，把用戶需求轉(zhuǎn)化為產(chǎn)品需求。

2. 產(chǎn)品的可用性測試應找到對產(chǎn)品不熟悉的用戶進行

可用性測試是指通過讓實際用戶使用產(chǎn)品或原型方法來發(fā)現(xiàn)界面設計中的可用性問題，通常只能做少數(shù)幾個用戶的測試，看他們怎么做。

案例：

我們的創(chuàng)業(yè)啟動項目是一款針對大學生的基于短信的信息收集平臺。在16年的7月份產(chǎn)品內(nèi)部beta版開發(fā)完成，內(nèi)部人員測試通過，認為產(chǎn)品的穩(wěn)定性還有體驗都還可以。然后我們就找了一批對產(chǎn)品不熟悉的人來試用產(chǎn)品，然后問題就暴露了：

產(chǎn)品對新用戶的引導完全不夠，甚至某些頁面沒有數(shù)據(jù)的時候會出現(xiàn)很多不友好的彈窗警告；結(jié)果就是：新用戶注冊進來完全不知道自己要做什么，一臉懵逼。

由于這個問題發(fā)現(xiàn)得太晚，修改成本已經(jīng)很高了。最終的解決方案是我們對產(chǎn)品進行了整體的復盤和大修改，也將產(chǎn)品上線的時間延后。

總結(jié)：

公司內(nèi)部的人對產(chǎn)品太過熟悉因此會認為產(chǎn)品中一切的流程都是理所當然，只有讓對產(chǎn)品完全陌生的用戶使用產(chǎn)品才能暴露問題。

再附上書中一句話：

記住，一切的錯都是產(chǎn)品和我們的錯，用戶絕對沒有錯。

3. 慎重地考慮一些細節(jié)的改變，在沒有大影響的前提下，不要對穩(wěn)定的版本做一些雞毛蒜皮的動作

案例：

我自己是一個對細節(jié)要求比較苛刻的人，因此在我剛做產(chǎn)品的頭幾個月，我會特別想要去修正產(chǎn)品中一些細節(jié)不到位的地方，比如某個地方?jīng)]有對齊，某個地方按鈕大小不一致，某個地方可以增加一個發(fā)送人的信息等等。

我當時說服自己的理由是：反正改改也快的。但有時候也會惹得開發(fā)們很不開心，可能在我們看來某個容易修改的細節(jié)在他們眼里牽連較大不易修改，又可能他們覺得這樣的修改不好或者沒有意義，有更加值得修改的地方。

總結(jié)：

我認為不是細節(jié)不重要，而是要拿捏好哪些是重要的細節(jié)。在敏捷的背景下可能某些用戶很少會進入的頁面細節(jié)稍微毛糙一點問題也不大，重要的是要把核心體驗做好。

書中提到的一個相似的原則是：

我們要區(qū)分哪些是雪中送炭的功能，哪些又是錦上添花的功能。

雪中送炭是基本功能，對用戶很有用，產(chǎn)品缺了這個功能根本跑不起來。比如 E-mail 系統(tǒng)里的“收發(fā)郵件”；

錦上添花的功能是指非必須的，用戶有時用得到，有的話會給用戶的使用帶來方便，比如在發(fā) E-mail 填寫收件人的時候，系統(tǒng)根據(jù)你輸入的內(nèi)容自動提示你曾經(jīng)發(fā)送過郵件的聯(lián)系人

在資源有限的情況下我們要完成「雪中送炭」的功能，在資源有盈余的情況下我們再去完成「錦上添花」的功能。個人認為敏捷開發(fā)也是相似的思想。

4. 制定開發(fā)周期時，技術人員會覺得無法評估開發(fā)量

這是我感受最深的一點，每次我們產(chǎn)品會議到制定工期的時候都是最沉默的時候，開發(fā)人員們會覺得無法評估工期，因為有些功能他們也沒有做過，不知道實現(xiàn)要多久。

案例：

APPlan里面有一個功能是即時聊天（IM），我們需要接入第三方服務，但開發(fā)們無法評估所需要的工作時間，但對于我們產(chǎn)品來說，我們是需要有一個開發(fā)日程來把控整體進度的，特別是某些和客戶合作的項目，我們需要保證在截止日期之前交付。因此工期的制定在我在公司期間是產(chǎn)品團隊和技術團隊最大的矛盾。

其實我認為雙方都沒有錯，站在技術人員的角度來看對一個完全陌生的功能確實不好評估一個周期。因此后來同事提出了一個方案，就是技術人員評估一個開發(fā)可能的周期范圍給我們，而不需要一個精確的時間。這樣我們產(chǎn)品團隊也能對整個開發(fā)的周期有個大概的把控。

總結(jié)：

這樣的方案也和書中的觀點契合，開發(fā)量是非評估不可的，但我們在初評的時候允許誤差存在。

5. 不要試圖滿足所有的用戶

不要試圖滿足所有的用戶，一切皆看性價比

案例：

在做第二個項目的時候，我們和用戶接觸得比較多，我們也很樂意去根據(jù)用戶的反饋優(yōu)化產(chǎn)品。但我當時犯的一個錯誤就是我嘗試去滿足所有的用戶。因為用戶的反饋乍一聽都是有道理且有說服力的，因為他們才是真正使用產(chǎn)品的人。但有些時候用戶的反饋會太過片面，可能他會反饋一個就他自己有使用場景的功能。

Minfo的查看已發(fā)通知的功能中能夠看到用戶的回復內(nèi)容，當然用戶能夠在任何時候?qū)貜蛢?nèi)容進行更新。一個用戶就向我們反饋希望能有一個類似日志的功能能夠保存用戶對自己提交內(nèi)容的修改情況。他也分析地頭頭是道，說用戶隨時都可以修改太過隨意，需要這樣的一種留檔。

后來我們開發(fā)了這個功能，但發(fā)現(xiàn)實際使用幾乎沒有。甚至連提出這個需求的用戶他自己后來也沒有用。

總結(jié)：

我后來也反思。第一點是我們對用戶的反饋還是要有起碼的判斷。第二點則是其實某些時候用戶的反饋也并不是他自己的剛需，可能有些時候我們找用戶訪談，希望他給我們一些反饋。某些時候用戶會出于不好意思或者礙于面子，可能會較隨意地提一些建議，那這種時候我們就更需要自己的判斷力了。

6. 需求的性價比

絕對不能因為某個需求的實現(xiàn)難度很小就馬上去做，也不能因為另一個需求的實 現(xiàn)難度大就不做。

案例：

可能是自己和工程師接觸太多，所以在考慮需求的時候非?？粗貙崿F(xiàn)難度。我會站在技術人員角度考慮覺得一個需求實現(xiàn)難度太大而把這個需求砍掉，而并沒有拿捏好這個需求的性價比。

按照書中，也就是這個需求的商業(yè)價值/需求的實現(xiàn)難度。

當我發(fā)現(xiàn)自己這個問題的時候是我在和UI小哥討論需求的時候，因為他相對我而言不了解技術，因此對技術實現(xiàn)沒有顧慮，只是提出自己認為好的方案。技術人員們一開始當然是抗拒的，但是當被說服并且實現(xiàn)之后，我們發(fā)現(xiàn)這樣的方案比我們在技術實現(xiàn)上退一步的折中方案效果要好得多。

例如APPlan中有一個任務界面，UI小哥提出每個任務條目背景從純色改成插畫背景，一開始我覺得太花哨，但實現(xiàn)之后看起來產(chǎn)品有活力了不少，更討人喜歡。

還有一個例子就是名師輔導界面，一開始只有老師的姓名和簡介，但后來UI小哥主張加上老師的亮點介紹，性格標簽，從業(yè)經(jīng)驗等信息，一下子讓老師的形象更加親切了。

總結(jié)：

這些例子也驗證了有些時候我們更應該看重需求的性價比而不單單考慮需求的難度。當然性價比高低的判斷就需要一定的產(chǎn)品經(jīng)驗了。

7. 項目晨會和項目日報

項目晨會和項目日報都有進行過，但后來因為覺得壓迫感太大且任務有時候不能細化到每日這么仔細，因此后來取消了。

案例：

我們曾經(jīng)執(zhí)行過一段時間的項目晨會和項目日報。我會在晨會上了解各位技術人員今日的工作計劃，然后在下班前確認今日計劃的完成情況。

但后來發(fā)現(xiàn)不適用，原因是：技術人員們覺得將任務分割成每天每天的工作計劃太過于細化且?guī)聿槐匾膲毫?，效果不如定一個一周計劃然后周內(nèi)讓技術們自己安排時間。

后來改成了周會的形式，執(zhí)行效果也還不錯，因此晨會和日報就取消了。

總結(jié)：

項目晨會和項目日報無非就是為了督促公司完成工作計劃，其實只要能達到督促的目的，形式是什么并不重要。

我想每個公司都有一個內(nèi)部的考核機制去保證工作計劃的完成，這就夠了。

8. 項目發(fā)布的時間

案例：

項目發(fā)布的時間，我當時一般都定在周五，現(xiàn)在看來是一個比較重大的錯誤。因為項目發(fā)布前我們會進行測試，而萬一測試出來的問題比較多，那么技術們就又要修復，可能會拖得比較晚。周五大家又歸心似箭，那這時候產(chǎn)品和技術的矛盾就又會凸顯了。按照書中，周二和周四晚上是比較好的時間。

總結(jié)：

這些教訓告訴我：周五絕對不是一個項目發(fā)布的好時間，至少在創(chuàng)業(yè)公司是這樣。

9. 別忘了給大家買夜宵

案例：

這是書中的原話：

「買夜宵」只是傳達一個意識。就是作為產(chǎn)品團隊的帶頭人，在大家覺得疲憊或者需要增強大家士氣的時候，需要想些辦法鼓舞大家的士氣。比如項目發(fā)布的當晚，比如項目啟動大會。

這一點其實老板做得比我好很多，他會在覺得士氣低落的時候請大家吃飯，也會在外出的時候給我們帶點下午茶，也確實能帶來提升士氣和緩解氣氛的效果。

總結(jié)：

有時候花點心思在團隊建設上，往往能更好地提升團隊工作效率。

10. 關于產(chǎn)品需求文檔PRD

案例：

關于PRD，我們產(chǎn)品團隊其實也做過一些思考。我們嘗試用過很規(guī)范的模板，也嘗試過把這些規(guī)范的模板進行精簡。但一個很大的問題都是，我們的技術人員往往不看PRD。

因為我們是創(chuàng)業(yè)公司，總共就是十來人的團隊，大家坐在同一個辦公室里，很多不清楚的點口頭交流就能解決。而且技術們覺得看產(chǎn)品的切圖和高保真圖就能完全理解了，他們不喜歡看大段大段文字的PRD。

但實際情況是：技術人員們并沒有完全理解產(chǎn)品的意圖，很多細節(jié)，例如輸入框的限制還是需要用文字的方式去約定的，如果技術們不看完全按照自己的感覺來，那最后出來的產(chǎn)品給人的感覺就相當隨意了。

最后我們采用了高保真圖+注釋的方式來替代PRD，事實證明這樣的方案效果不錯。文字注釋就在高保真圖旁邊，技術們不得不看，產(chǎn)品們寫起來也方便，都是最最重要的信息才會寫在上面。

總結(jié)：

我認為PRD的目的就是要傳遞給技術人員們產(chǎn)品要做成什么樣，PRD只是工具。那既然是工具，我就相信針對不同規(guī)模不同情況的公司，就一定會有這個公司最適合的PRD。

作為創(chuàng)業(yè)公司的產(chǎn)品經(jīng)理，就有責任發(fā)掘出最適合公司情況的PRD形式。

寫在最后

這一年的產(chǎn)品之路自己也走得磕磕絆絆，由于自己剛剛?cè)胄?，?jīng)驗也還不足，深知山外有山人外有人。這篇工作總結(jié)更多的是寫給自己的，但也希望自己的一些感悟能引起一些共鳴。但無論如何，這都是是我自己回首過去這一年有感觸并且想和大家分享的東西，如有觀點過于片面，還望各位前輩予以指正。

2018，與諸君共勉。

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

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