做產品，坑千萬，不踩光，非好漢。

若踩光，事可成矣。一起加油吧！

內部產品，顧名思義就是提供給內部員工使用的產品。之前我在網易實習做支付，關注的都是to C的東西，頁面呈現效果，表單設計，用戶行為路徑，用戶反饋，活躍數據。從來沒有接觸過這類內部產品，什么CMS、CRM、ERP，當時就像發現了新大陸一樣的興奮，想著又有新技能要解鎖了。后來才知道，這內部產品，并不好做。

1.淪為需求傳達器（只勤奮不思考）

據我不客觀的猜測，剛入行的產品新人，絕大部分都會踩到埋頭執行不思考這個坑。我也一樣。

而且當時我自認為做的很認真了，每天跟業務方反復溝通，跑到他們位置上把一個一個問題復現，整理好按優先級排序，寫文檔畫交互，重要的提給開發，預發環境里我自己測試一遍，確定沒問題了再反饋給業務方。

業務方說這里要加個篩選按鈕，我說“好”。業務方說想一鍵分享到微信，我說“行”。業務方說前臺頁面展示信息混亂，我說“OK，我去畫原型?！?/p>

工作中最可怕的狀態莫過于此，你每天努力勤奮，充滿動力。走過一陣路后，回頭一望，發現做了好多無用功，好多事的解決方案不夠優雅，甚至一些改動為將來埋下了禍患。

保持這個工作狀態一陣子后，我的leader找到了我。她當時很生氣，狠狠地批評了我：“如果你的做法只是把業務方的解決方案轉交給了開發，只起到傳達而沒從全局思考的話，公司為什么還要養著我們？！”她的話很重，當時的我很委屈，明明業務方很認可我的工作成果，為什么到領導這就變成有問題了？

后來，隨著我自己在產品路上的經驗有所增長，開始教導別人。再來細品，越想越覺得當時leader批評的對。

悶頭執行就容易這樣，用戶要一匹跑的更快的馬，我就花盡心思地找馬。而忘記了“馬”只是用戶提出的解決方案，他的需求是更快的速度。了解了背后的需求，你就能盡情發揮，不管是汽車、火車還是飛機都能滿足用戶的真實需求。

前兩天看到一則需求的小故事，也是這個意思：

顧客向服務員要一杯水，服務員端了一杯熱水過來，顧客一摸，“太燙了！”，服務員聽罷，轉而端了一杯冰水，顧客一摸，“太冰了！”。服務員換了一杯溫水，顧客拿著很開心地，用了這杯溫水洗了手……

怎么避免呢？

leader后來教我一個方法：連問五個Why！(你為什么需要XXX？)

連問五個Why，你基本就把用戶最真實的需求挖掘出來了（雖然在最開始的時候會顯得你很笨蛋）。用戶要一杯水，如果是渴了，他需要的是一杯溫水。如果是擦干凈手，他需要的是一張濕巾。如果是為了兌酒，可能雪碧和紅牛更配噢！

不要簡單聽信業務方提出的解決方案，要回到他的用戶場景和業務目標，去挖掘他真實的需求是什么，再給出合理的解決方案。因為內部產品的用戶比你懂業務，但不如你懂產品，他提出的解決方案常常是局部和片面的，這時就需要你能站在產品的更高角度，優雅地解決問題。

2.沒有深鉆業務

如果你是旅行App的產品經理，你得去了解旅行行業的需求和痛點。如果你是短視頻App的產品經理，你得去研究短視頻的功能和需求。這是毋庸置疑的。

但如果你是個HR系統、CRM、CMS的產品經理呢？你該做什么？守住產品的一畝三分田就可以了么？

不，你要成為一個業務專家和系統專家。你得懂業務，一個完整的招聘流程是怎樣的？怎么組織銷售，激勵銷售，尋找機會？怎么提高編輯的效率？這些問題你都得清楚，成為一個業務專家，和業務方站在一起。

同時你不能僅陷在業務里，得跳脫出來成為系統里的專家。畫各種系統組織架構圖，抽象出各種概念。對系統的發展有自己的規劃和預期，按自己的節奏去迭代升級系統以滿足業務的拓展需求。這些系統的理論知識，經過這么多年的發展演變，已然長成了大家伙，里面的門門道道可多，夠我們鉆研很久。

一位產品前輩曾說過：做產品要把70%的精力花在業務上，這才是安身立命之本；而剩下的30%是產品通用技能，算不上什么核心競爭力。回想當時的我，一個勁地只顧做需求，改Bug，醉心于產品細節。沒有相應的高度，鉆到角落里而不自知，也算是當時經驗尚淺的表現吧。

3.不了解開發成本（不懂技術）

關于產品經理要不要學技術，業界爭論了很久，大部分人得出的結論是：產品可以不學技術，但是得懂。

懂什么呢？至少得清楚原理和具體的實現成本，才便于平衡多方利益，做出恰當的決策。就好像給你一千塊預算辦活動，你可以組織的風風火火的，在預算內把事情做漂亮。但如果光讓你做活動，不知道最后能報下來多少錢，那你一定會畏手畏腳的，很受限制。

不懂技術，就像給了你一個“黑箱”，里面不知道是黑貓還是白貓（三個梗好像串了）。必定影響你決策的能力。我當時就是這樣，鬧的第一個笑話，就是出了Bug不知道找前端還是后端。東問問西問問不得要領。

第二點是無法評估一個需求背后的代價，從而影響優先級的排定。因為做的是內部產品，最重要的事是提升效率。我入職第一天拿到一張列著一百多個需求的表，一半以上是Bug……排期的時候，第一個需求開發說要兩天，我說“好”。第二個需求開發說要三天，我說“哦”。這樣一周的時間就排滿了，其它活得下周再排。留下原本排了十個P0優先級需求準備大干一場的我在會議室黯然神傷，于是接下來幾周在排期和接需求的時候，我心中都沒有底氣，擔心笑話+1。

第三點，做業務系統的產品經理，需要有更堅實的基本功，出色的抽象和建模能力，要懂概念模型，畫各種圖。而我當時幾乎是第一次接觸這些概念，每天九、十點下班回家抱著UML的專業書籍啃，很是痛苦。

4.要做正確的事（不只有用戶體驗）

小時候，我幼稚地認為世界上只有兩個國家：中國和外國。長大后，我們仍免不了犯這類低級錯誤。把一類事物抽象為一個整體。比如，把業務部門抽象為一個利益共同體，把一個公司的不同部門當做一個利益共同體。但從微觀看不是的，可能內容編輯人員和內容組負責人的利益并不一致，甚至是相悖的。

業務組成員都是和我們朝夕相處的人，相隔不過幾個工位。這時我們很難從用戶的情感中跳出來，我們習慣性地把提高他們的操作便捷度當做最高優先級的需求，仿佛這是一款to C的產品。當他們利益受損，向你抱怨的時候，你更傾向于解決他們的問題。

舉個例子，當時我們在開發內容審核流程的時候，對流程進行了重新梳理，增加了多個審核狀態，完善了操作規范，并要求三審必須由領導審核，大大拉長了審核流程。對于內容編輯人員，原本五分鐘能做完的事，現在要用十分鐘才能完成，而且操作更加繁瑣。這是件對公司利好，對編輯利空的事情。編輯們對此積極性不高，不愿配合。我也松松垮垮能拖就拖，仿佛這個功能一上線，就和編輯們做不了朋友了。從某種程度來講，這是對公司不負責的表現。

常有人抱怨，這類to B產品操作繁復，用戶體驗奇差。但我們做內部產品的不得不承認，在開發資源非常有限的后臺，用戶體驗只是一堆重要問題的其中之一。像系統穩定、流程合理、信息安全、定制功能這些都很重要。一味地強調用戶體驗，照顧眼前看得見的操作者，忘記了背后看不見的公司，重視部分而忽略了整體，同樣是值得引起注意的進階問題。

作者：潘潘，公眾號：Hey潘潘

本文由 @潘潘 原創發布于人人都是產品經理。未經許可，禁止轉載。