前言：創業者轉型做產品人，把我近期悟出的道與理，送給大家!

產品經理是干嘛的？

遇到問題，提出方案，解決問題的一群人

本文目錄：

一、思維模型

二、工作方法

1、如何需求調研

2、如何需求評審

3、如何自我開展工作

4、如何與項目組成員合作

5、如何與項目組之外同事合作

三、坑有哪些

四、項目延期

一、思維模型

什么是思維模型呢？

思維模型是我們部門負責人鄧總監之前在的時候經常提到的一個詞。

我所理解的是：每個人自己在做產品思考問題給出解決方案的時候，形成的一套固有的思維方式，而且因人而異。

每個人都必須形成自己的思維模型，沒有強制要求每個人的思維模型一模一樣，但可以參考借鑒別人好的思維模型，從而悟出自己的道。

廣告（廣而告之）：雖然現在他已經不在我身邊。但是，很感激他曾經不斷的旁敲側擊，各種打磨，謝謝！

我的思維模型：用技術MVC架構思考解決產品問題。

解析：

M：數據庫底層，也就是事務的本質。

V：表現層，體現在原型界面上，也就是我們所有人看到在各種載體（網站、APP、小程序、公眾號）上UI設計好的頁面。

C：業務邏輯層，也就是各種事務之間，各個業務流程的流轉。所以，我思考問題的順序是：先挖掘此需求背后事務的本質以及他的價值，再分析涉及到的各環節的業務流程，最后用原型界面將整個事務過程串聯起來。

因為是技術出身，所以我希望將經典的MVC技術架構與我做產品經理時，思考問題的方式進行完美的結合;我不知道我是不是第一個提出使用mvc架構作為思維模型思考問題的產品，但我不希望我是最后一個。

二、工作方法

1. 如何需求調研

（1）問題現狀：問清楚需求方遇到什么問題，要解決什么問題，不爽在哪里，痛在哪里，不解決會怎樣?最后，將需求加以記錄，并與需求方確認。

（2）當前流程：問題是出現了，那么當下你們是用什么方式規避這個問題的呢？現在你們的業務流程是怎樣的呢?希望在流程上做哪些優化呢？

（3）用戶期望：你想要的結果是怎樣的？怎樣的結果才是令你滿意的？

（4）需求價值：這個問題解決后，對你有什么好處，產生什么價值？

（5）可行性分析：辨別真偽需求后，排好優先級，及時反饋結果。做還是不做，都要給合理解釋;并不是需求方說的全部就是需求，要自我加以過濾;他說的痛，是不是以偏概全，要追蹤問題的本質，他到底是要解決什么問題？

2. 如何需求評審

（1）產品出原型+規則：

評審之前，必須自己獨立想清楚此次需求所有涉及到的規則。雖然，可能未必有些情況自己考慮完全周全，但必須自己用心深度思考一番。否則，召集其他項目組成員，是極其不負責任的行為。

這里，與我以前做項目經理時候的思維方式，完全不同。相當于是我要改變以前固化的思維模型，此中過程，有些困難，還好我挺過來啦。

（2）產品初步與需求方原型評審（可多次）：

自己初步畫的原型和規則，得先跟需求方單獨過一下，確認是否達到初步預期。如果沒有的話，那就要及時調整出新的原型+規則，循環往復，直到需求方滿意為止。

（3）產品初步技術原型評審（可多次）：

需求方搞定，那么就要單獨搞定項目組中的技術成員（前端、后臺、測試、UI等），技術與需求方關注的是不同的視角。

需求方，是告知其有這樣的頁面和規則。技術，會問為什么有這樣的頁面和規則，能否解釋清楚明了。技術提出的問題，你解釋不清楚，那就要修改原型+規則，直到任何一個技術都沒有問題為止，此輪評審才算結束。

（4）產品組織項目組所有成員正式評審：

需求方與技術都搞定了，那么召集項目組所有成員，組織大會議室，進行系統當前版本的正式評審，就水到渠成了。

最后調整完畢的原型+規則，必須同步給項目組所有成員，如果此次正式評審仍有疑問，那么又要重新調整原型+規則;如果沒有疑問，那么項目評審成功，順利推進到開發階段。

（5）項目排期：

產品與技術討論項目排期，并將最終確認的上線時間，匯報給需求方。如果有延期風險，必須事前告知需求方并給出合理理由。

（6）上線驗收：

測試驗收需求后，進入產品+需求方驗收階段，此時一般在灰度環境，不會影響正常線上數據。雙方同意上線后，測試走上線流程，項目當前版本上線成功。

3. 如何自我開展工作

（1）遇到問題，先至少想個解決方案，再和別人溝通

不要無腦去與別人討論一個你沒有想清楚的問題。如果實在沒想清楚當前問題，你可以去請教相關人員，再自我探尋答案。

（2）事事有反饋

出于尊重，任何人任何事，都要給予反饋。即使當下沒有解決方案，即使當下很忙。消息已讀未回復，容易給人造成誤解，也容易讓別人失望。

（3）多聽少說，不要插話，不要強加個人觀點

此點更像是為人處世之道，要懂禮貌。實在要插話，請先說句：不好意思。有時候，產品經理組織會議，作為主持人，必須要打斷大家偏離主題相關的話題，必須要有控場能力。

這不是不尊重人，我們只是想讓會議變得更高效有價值，產品經理的會議多而復雜，如果不會控場，那會浪費極其多的時間；別人討論的時候，不要用自己的主觀意識誘導別人、誤導別人。特別是需求方的吐槽，讓其暢所欲言，讓其說個痛快。然后，自我再總結挖掘問題的本質。

（4）時刻關注問題現狀、業務流程、功能價值

這三點缺一不可，很重要很重要很重要。公司當初系統改造的時候，我就吃過不少虧，就是因為自己當初還是個小白產品，沒有自己的思維模型，沒有關注問題現狀、當下業務流程、功能的價值，為后來自己所做的產品，挖了不少坑。

結果，上下游系統嵌套太深，坑也是越陷越深，好不酸爽。

（5）對上下游系統必須要有所了解

這點，也是感悟很深。很多時候，各個系統的產品，都是只關注自己那一畝三分地，想需求想問題，沒有把涉及到的上下游系統考慮進去。導致的結果就是，在自己系統沒有什么問題，結果串聯上下游系統就暴漏各種問題。

有些時候，也能理解，自己系統的需求不斷，加班加點趕原型寫規則，哪有時間去了解其他系統哦？不過，時間猶如X溝，擠擠還是有滴，各位老鐵。

（6）控制好情緒，別激動

產品，被人質疑，背鍋俠，被人diss，那再正常不過的啦。

你會不會做產品？你做的什么垃圾產品？我要換產品，你不行。你會不會畫原型？你有沒有想清楚？這個項目做出來有什么意義？你是什么垃圾？

老鐵，淡定，陽光總在風雨后滴，干巴爹!

（7）多換位思考，保持同理心

不同的人，你要切換自己成為不同的角色，爭取與其保持同頻，明白其所思所想，這點很難，我也就說說，目前感覺依然差之十萬八千里

（8）對過程和結果都要負責

很多時候，咱們明白對過程要負責。但是，結果其實我們更要負責。產品上線了，就算是完成任務了嗎？后續能不迭代就不迭代？產品的死活，與我無關，反正我已經做好了。

這些想法，我認為都是不對的。我們只是做了0到1，1到100，依然是任重而道遠，要有產品人該有的情懷，要創造更多的社會價值。

（9）自己做的產品一定要比任何人熟悉

自己做好的產品，一定要將輸出物弄完整。至少有原型+規則+操作手冊，如果有視頻那就更好了。一來便于傳承，二來便于后期自己回憶。

有時候自己負責的系統有點多，部分功能忘記細節，有資料的好處就體現的淋漓盡致，希望各位產品多為后人栽樹，讓其乘涼。

（10）一定要經過關鍵大佬同意

有些新的產品、新的業務、新的需求，會牽涉到多個部門多個關鍵人物，這個事能不能做、怎么做，一定要跟相關關鍵大佬正式確認，全部同意才能去做，千萬不能火急火燎。不能因為一個關鍵人物的單方面決定(其他大佬未知，或者不同意)的情況下，去為其做這件事。

要不，不僅吃力不討好，而且夾在中間里外不是人。總結：必須正式會議正式文件，所有關鍵人物必須都在，沒有最終定方案，產品不做任何調整。

（11）關鍵節點及時通知

#計劃上線時間通知：需求方最關注的是，什么時候能上線？所以原型正式評審通過后，項目組成員必須溝通討論評估出最終上線時間，由產品經理統計好所有時間【UI設計時間+后臺開發時間+前端開發時間+測試時間】，最后反饋回給需求方和整個項目組。

#已上線版本通知：項目上線了，要及時告知需求方和項目組所有成員，上線功能+功能價值等關鍵信息；

#未來規劃通知：項目當前版本上線了，未來的規劃，要簡明扼要的通知給需求方和項目組所有成員。

#項目風險通知：這個必須通知，下面第大四點（項目延期怎么辦）我有再次強調。不僅要通知，而且還要解釋清楚原因。

（12）會議關鍵人物

會議關鍵人物必須到場，如果沒到場，那會議沒有開下去的意義，也沒有討論的意義。所以，提前跟相關關鍵人物約好確定到場時間是很關鍵的一個事情。

我踩過的坑告訴我，相關關鍵人物沒有參與的會議，跟沒開差不多。

4. 如何與項目組成員合作

（1）我們應該互相尊重，相親相愛形同一家人

可能因為是技術出身的產品吧，我更希望與技術是相親相愛的情況，而不是網絡上報道的相互拳打腳踢的情況。這點因人而異吧，反正我不會跟技術反目成仇。

（2）站在用戶的角度去寫代碼

我時常提醒自己項目組的技術，不要死寫代碼，多思考下他背后的意義。如果你是用戶，你會用這個功能嗎？價值何在？有的技術就做的特別好，根本不用我提醒，反而很多時候能給予我極大的幫助。

（3）有鍋我來抗

產品，很多時候是背鍋俠。有時候，項目組其他成員的鍋，我覺得沒必要去追究，就是咱們的鍋。單獨再去找出問題的項目成員溝通，讓其注意就好。

（4）不會為難你，但請別給我挖坑

說實話，如果我要較真，技術同事評估的工期，我自己都能評估的出來（之前創業時幾乎天天給客戶評估工期）。我并沒有干涉技術評估的工期，并不是放任不管，而是對他們的尊重，各自評估自己的開發時間，我心中自然有一桿秤。

但是，不要總是快到上線的時候才告訴我要延期。評估工期，不是兒戲，請認真對待。我喜歡，未雨綢繆，提前告訴我任何風險，這樣我好把控項目進度。

（5）所有新需求必須經過我同意

所有需求，必須經過我這邊過濾。部分小改動，需求方有可能直接跟技術溝通。但必須告知我，我同意才能改，不同意我會告知需求方與技術原因。

5. 如何與項目組之外同事合作

（1）關鍵人物溝通

外部團隊協作，一定要找到關鍵人，能拍板、有話事權、決定權的人，這樣溝通協調事情事半功倍。

（2）借助外力

如果外部團隊相關關鍵人不配合，那么請求上級領導協助，并告知此事來龍去脈。反正，逐級往上匯報，直到此事有個處理結果。不要害怕得罪人，我們是做事的人，對事不對人。

（3）所有正式的決定必須有據可查

所有正式的決定必須有資料保存（公司郵件等），便于日后以防雙方忘記，或者扯皮。

三、常遇到的坑有哪些

（1）歷史數據

任何一個系統改造的大難題，我就深深地被其困擾過。要把按照以前舊規則的幾萬條舊數據匹配系統改造后的新規則，而且還要保證這些數據上下游系統能夠跑通，此種過程是極其困難和麻煩的。

（2）技術沒空，導致項目延期

有的時候，被這樣坑，也是無語的很。本來大家都溝通好的上線時間，突然技術跑過來說我這邊沒空搞你這個項目，要搞其他更重要的項目，你的項目要延期。此時，心中一萬個策馬奔騰。

一次還好，一次又一次，你爽嗎？你的需求方爽嗎？

（3）遺漏的技術bug

測試小哥哥小姐姐其實很給力，沒有他們把關，一個項目上線肯定更多問題。但百密也有一疏，上線后仍有技術bug情況，也是有的。

如果重要緊急的，要求團隊成員加班加點必須解決；如果不重要緊急的，也別太為難人加班加點，雙方定個寬松點的優化時間期限就好，技術都是很好的一群人，不要為難他們。

（4）需求變更

又一個老大難問題，需求變更導致的風險，是很麻煩嚴重的。不過，要根據自己的經驗與能力判斷，此次需求方變更需求的影響范圍。

如果影響不大，那能改就改;如果影響較大，那必須報風險；如果是影響思維模型中的底層數據架構，那必須報嚴重風險。

（5）緊急需求

最怕這類人，不講理還霸道，整個項目正常的上線流程又不是不知道，但還要提出我現在就要，一周之內就要這種不懂互聯網項目正常上線流程的無理要求。

誰的事不急，誰的需求不重要？你現在要，我也給不了，小需求我可以快速評估，盡快上線，盡量做到能今天上線絕不拖延到明天。但是，大需求該怎么走流程還是得怎么走。

（6）影響上下游系統

上面已提過，再次強調其重要性。我覺得此牽一發而動全身之事，應該是整個項目組的成員，都要去考慮，而不只是產品經理。

（7）部分原型規則遺漏

這個鍋，是產品經理的，考慮問題不周全。但是，我覺得不完全是，項目是有需求方、所有項目組成員一起評審的，大家都沒發現，咱們不小心漏掉也是無心之舉。只能通過不斷刻意練習，盡量避免這種問題的發生咯。

（8）項目組臨時換人

項目開發到一半，技術突然離職或者被其他項目借調，導致項目突然報風險，也是很容易讓人措手不及。如果技術離職，得找人盡快接手咱們的項目。如果技術被借調，咱們產品得去了解具體原因，想解決方案。最終目的，保證項目正常上線。

（9）修數據

數據在，各上下游系統中流轉，難免出現一些錯漏的數據，在系統上已經是無法修改的了。這種時候，只能通過技術手段，后臺修改該部分問題數據，保證數據正常流轉。

（10）雜事纏身，無法專心出原型+規則

很多時候，咱們會被各種雜事干擾自己正常的工作。各個需求方的需求都很急，但卻被各種雜事、會議拖慢了項目正常進度。很多事很多問題，不得不處理；很多會議，不得不參與。

此時，高效的處理問題并給出解決方案，高效的討論會議并達到會議目標，尤其重要。這一點，仍然堅持對事不對人原則。

（11）各系統需求邊界劃分不清

估計很多產品，自己都沒搞清楚自己做的系統目的是什么，只要需求方提出來的需求就接進來，根本不在乎自己系統的定位是什么，邊界是什么。這樣做，沒錯。

但是，需求方提出的是其他系統的需求，你是不是應該找其他系統產品聊聊，將各個系統邊界劃分清楚？我是覺得很有必要的

（12）崗位職責劃分不清

越做越發現，產品經理的崗位職責很難界定清楚，需求溝通，產品設計，運營，客服，系統維護等等，貌似很多方面都會涉及的到。我們就像個家里的保姆，哪里需要，就去哪里解決問題。

四、項目延期該怎么辦

看到這里，相信大家也發現了，項目最大的風險就是項目延期。因為延期，導致的后果，可大可小，這點因項目而異。那么，該如何解決呢?

（1）查明原因

導致項目延期的原因：離不開需求變更、原型+規則考慮不周全、技術bug、項目工期評估有誤、突然更換項目組成員等等。是其中哪個原因，還是哪幾個原因，找出來，然后對癥下藥，爭取下個版本或者其他項目，不要再犯。

（2）定解決方案

出現問題不可怕，可怕的是連產品經理都手足無措，沒有解決方案。

（3）上報風險

項目都報風險，導致延期了，如果該知道的人還不知道相關原因的話，那就說不過去了。而且，必須給出大家合理解釋。

總結

此文之前有過一版，由于之前的排版一直被人diss，為了不是因為表現層的東西而影響了本文質量的傳達，特此增加個人新的體會及排版，以便后人查閱。

最后，我建立了各大城市的產品交流群，想進群小伙伴加微信：yw5201a1??我拉你進群。

關注微信公眾號：產品劉?可領取大禮包一份。

··················END··················

今日研報：有米有數發布《2021年抖品牌營銷白皮書》，公眾號后臺回復“?抖品牌”，即可下載完整PDF文件。

申明：報告版權歸?有米有數?所有，此處僅限分享學習使用，如有侵權，請聯系小編做刪除處理。

RECOMMEND

推薦閱讀

手把手教你做數據產品經理

手把手教你做產品經理

一道京東的面試題

手把手教你編寫接口需求文檔

點擊“閱讀原文”

查看更多干貨

總結

以上是生活随笔為你收集整理的啊！多么痛的领悟···的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。