簡介
產品經理，一個不太懂技術，又不直接負責業務，手裏還沒什麼實權的角色，偏偏從上到下都在跳躍，哪裏都能看到他的身影，哪裏都能有他參與。那麼就產品經理如何去做到尊重這個崗位，又能優雅的管理好自己，我們來細緻的聊一聊。
前言：
無意中看到一篇關於和產品經理做業務溝通溝通的文章，趁着有空，好好的閱讀了一下，發現對話的過程很有意思，也很值得思考。
有一個前公司關係還不錯的同事跳槽到新公司了，正好在現在的公司附近，就約了一起出來坐坐。其實就是敘敘舊，相互聊聊天而已，但真實的情況是整個過程都在聽他訴苦，在各種抱怨。
A告訴我，在入職前和入職後，面試官和公司之間發生了巨大的變化，在面試時，說的工作內容和時間工作內容有很大的偏差，而且涉及到跨行業所以有很多條件是A完全沒有接觸過的，沒有人對接，一上來就直接要負責填坑。不光要解決前任留下來的各種問題，還要解決銷售對外吹破天然後拿回來的單子，還有就是入職半年了，基本都是幹雜活，都是些體力輸出的事情，比如因系統故障導致200個單據無法同步，就需要A同學手動一個一個錄單。哪怕是這樣他現在的上級對他也很不滿意，覺得他在這邊價值不大，做的事情也不重要，沒事還要PUA他一下。
A同學現在壓力很大，經常懷疑自己的能力，不得已只能持續加班，又被同事說內卷，然後在排斥他。
其實A同學本身還是很優秀的，重點本科畢業，之前又是在大廠做事，還是優秀員工，還有優秀項目獎章，在任何一家中小公司做個高管不成問題的。只不過被大廠畢業了而已，所以自己也降低了身份，到了一家中型互聯網公司去任職，做了副總監，下面有幾個新人，老人歸總監管。
A同學說，他被PUA印象最深刻的一次是：那天中午，大家在一起開會，A同學正在教導新人產品邏輯定義的時候，被總監吼了一嗓子：A，你的原型爲什麼還沒做出來......
話說A同學雖然不算行業裏的大牛，但他的價值遠遠在畫原型、寫文檔的工作範圍之上。A同學特別想不明白的是，爲何這個公司要如何對待一個高能力的人，花大價錢招來一個好手，卻給安排做一些常規的事情。
話說我在經歷的衆多公司了，多多少少都會遇到這個情況，就是公司招來一個大佬，但實際卻沒有可以發揮的地方；另外可能外加一些其他的客觀原因：辦公室政治內鬥、部門領導不希望下屬太強等、團隊裏的人排擠等，很多的時候，並不是上級在施壓，還有同事之間的相互關聯。其實，很多的時候，這就是互卷的原因，同樣都是工作了10年的人，憑什麼你從大廠跳槽來的，薪資就要高一倍，我跟着公司做了這麼多年，還要受到空降兵的壓迫。
有時候，可能是無心，但這也充分體現出一個人的教養問題，如何保持對他人的“尊重”。當我無意中說了一句話，當我無意中做了一件事情，就會刺傷到別人，而我卻無感知。
產品經理這個行業，因爲入崗快、基礎低、要求不高，所以來了很多人，我們都知道“人人都是產品經理”，但好的產品經理卻不多，這就導致很多人對產品經理這個崗位有歧義，認爲做這塊都是高崗高薪低水平的人。
通過幾個案例，來溝通下如何去“尊重”一個產品經理，希望能夠糾正一些錯誤的觀念，也希望能改變一些產品經理的職業素養，想要別人看得起，先得看得起自己，尊重是用能力來說話的。
1、承認當前業務系統的遺留下來的老舊“技術”
所謂當局者迷旁觀者清，當你沉醉在自己的世界中，你是無法站在客觀的角度來評價這個事情的真實情況。就拿實際的業務來說，使用Axure來畫原型依然是很多產品經理的傳統模式，他們更習慣在自己的環境中去做事，較少能夠學習和利用新技術來提升自己。
這種情況在傳統企業，在老一輩的產品經理經理中最爲常見，他們需要進行產品設計的時候，依然還是用線框畫出來一個一個的方格，然後在裏面做交互。實際我們都知道，產品原型的表達方式有很多，而使用Axure如果還依然是在用單機版，那麼團隊協作、交互設計將會增加很多的額外的工作量。
視野開闊一點的產品經理都知道，現在的原型設計，並不只是簡單的做出來一個線框圖就可以了，也不是說你在原型上面加點文字描述丟給研發就能實現。你要基於商業化的策略進行考慮，這個產品——要怎麼樣能賺到錢。只有考慮如何能夠賺到錢，才能滿足產品設計的最基礎定義——解決溫飽。產品功能設計是最業務流程中最基礎的概念，之所以很多人複雜是因爲：沒有很好的梳理出來對應的業務流程、節點、規則和處理條件。好的產品設計是要保證業務流程簡單，數據交互清晰，節點有對應的判斷條件，並且可在一定的情況滿足和包容特殊的分值情況。
如果你對產品設計上升到一定的高度，你就會發現，很多的時候需求其實“很簡單”，特別是在信息化的時候，用戶並不需要那麼多高端的流程，他們要的很簡單。只不過這個“簡單”在歷史遺留的糟糕產品設計之上，就變得複雜起來的。比如你要做一個一人申請多人報銷的功能，初始的想法就是在申請單上添加一個關聯人，報銷的時候關聯人去選這個申請單就可以了。但實際在做的時候，你發現“申請單和報銷單之前是定死了一對一的綁定關係”，然後你又發現“報銷單的審批關係是完全匹配申請單，多人沒辦法用新的審批規則”，等等這些實際的歷史問題，會困擾着每一個產品經理。
這也導致了很多人在新規劃產品設計的時候，特別不習慣改舊流程，總是希望能夠使用新的規則。
作爲一個產品經理，吸收多元化的知識，這是一個基本的常態。我們既要做到適應當前的環境和條件，先去解決問題，把當前的節點處理掉，然後在想辦法來優化、完善、改變。要事有三條，解決爲優先。
案例：今年我們要調整組織架構
之前的系統條件是：先和各部門確認好，然後在約定的當天進行手動調整，同步其他各系統接收新組織架構做部門和人員同步。這當中有一個很大的問題：既新組織架構生效後，舊組織架構中在走的審批流無法變更，要麼催促儘快完成審批，要麼管理員手動根據舊組織架構的審批條件，重新定義新組織架構的審批條件。
現在的系統新增了一個條件：允許存在新舊組織架構，既同時存在兩套規則，在新組織架構生效後，新申請的申請都按照新組織架構的流程進行。原來舊組織架構的審批流還可以繼續扭轉，但會在審批流和給節點審批人做標註提醒，還可以做加簽處理。這樣就不會影響實際業務的正常運作，避免
2、接收新型的事物，不把經驗當理由
社會在進步，人類也在進步，你的經驗只是在過去的時間裏產生的價值，也用在當前，但無法適應未來。在任何的領域，底層邏輯是相對的固定，但在應用的前端一定是隨着市場、時間、環境等客觀原因在進行變化。
在多數的時候，經驗很重要，當你有經驗的時候意味着你可以快速下手，可以馬上定位問題。但由於很多表面的經驗都是死的，大多數人缺乏的是一個熟能生巧的過程，也不懂得在常規的經驗中體驗出精髓，只會盲目埋頭幹，所以我們不應該因爲自己知道很多的知識，就以爲會比別人更強，以爲自己高人一等。
在很多的時候，我們會發現一個事件：當系統發生了某件事故的時候，需要做大量的單據處理，量居多而且相對麻煩，那麼一些人在沒有排查清楚問題和定位好解決方案前，就先夜以繼日的埋頭苦幹，加班加點的熬夜手動去操作。然而，他們不知道的是，很多的時候只需要程序員寫一個SQL就能解決：
sql="select * from 數據表 where字段名=字段值 order by字段名[desc]"
sql="select * from 數據表 where字段名like '%字段值%' order by 字段名 [desc]"
sql="select top 10 * from 數據表 where字段名=字段值 order by 字段名 [desc]"
sql="update 數據表 set字段名=字段值 where 條件表達式"
sql="update 數據表 set 字段1=值1,字段2=值2 …… 字段n=值n where 條件表達式"
做產品，不是說有苦勞就好，還得看你的功勞纔行，團隊的概念就是集合大衆之長，取之精華。所以這裏我們要不斷的接收新型的事物，暫時拋棄自己已有的經驗，去學習和獲得更好的知識。
請教同事，沒什麼不好意思的，很多的時候我們只是不知道還有更好的方法而已，出現問題的時候，多一句話問問，或許就有一個新的解決方案。
在需求討論會的時候，用正確的態度，誠懇的表達出自己希望能夠希望大家的想法，來打破自己固有的思維，其實是一種很不錯的提升方法。如果能持續以這種方式和方法來保持自己的態度，同事相對也會很“高興”的讓你從他那裏學到新的內容。
案例：今年我們要處理一個業務審批流。
之前的系統條件是：先是正常審批，如果是超標要升1級；額外條件1如果是申請人身兼多崗，以最低崗提交還要自動升級高崗匹配條件；額外條件2在審批規則中如果遇到節點爲空（沒有部門負責人）時，需要往上升1級審批，最高到當前當前申請人的第三級領導；額外條件3如果當前人員的上1級領導已是最高截至。額外條件4如果是遇到指定審批人，要同時判斷是否1人多崗，按照最高崗位來定審批規則。每次遇到審批規則調整，都需要系統管理員，對着手工表格，一條一條覈對，異常繁瑣，且容易配錯誤。之前一直不肯上新的業務，就是來回調整過基礎，每次都出問題，還要系統管理員自己收拾爛攤子。
現在的系統新增了一個條件：複製模擬審批流，既可以從當前的審批規則中，複製出來一條線（含主線下的分支），做臨時使用，可針對個人、部門、單據、時間做臨時管控。
3、合理的判斷情商，不要隨意批判別人
當你以專家的去指點別人的時候，雖然能夠解決問題，但很多的人並不服你。而你在不小心說錯話，或做錯事的時候，就會被人落井下石。特別是當你在趕時間出貨粗糙的時候，更會被別人指指點點。
在大多的時候，人們只能看到他希望看到的東西，憑什麼他比我高一級，他連一點邏輯都做不好。實際上一個小時的評審會，別人只有這一點出錯了，而你卻恰好看到了這一點，並放大到了這一個小時裏。很多的時候，我們會不由自主的把自己代入到其他的角色上，並幻想如果是我在這個職位上，我要怎麼怎麼做的更好，其實這種阿Q精神就是對自己能力的一種隱晦折射。
要考慮一點：大多數的人都會很在意別人說自己的不好，會忽略別人高於自己的地方，會下意識的提升自己順便貶低別人。其實在職場上，同事的面試該賣還是要賣一下，維護好同事之間的關係，有利於持續發展。其實在工作上每個人的精力都是有限的，特別是遇到跨系統對接、跨部門協調，稍微遇到一點扯皮的事情就要糾纏半天，本身是爲了一個問題要協同解決，結果到了最後是賠笑了半天求人家解決這一個問題。
不同崗位上的人，就是對其他崗位上的補充，比如數據分析，你以爲的數據分析就是得到結果，識別狀態，做下標記，得出結論就可以。實際數據分析崗要先拿到數據，然後去清洗數據，然後在對一些條件做客觀的判斷去做數據驗證，最後是匹配規則，最後才能生成結果，最後進行驗證。對於自己不太清楚的崗位內容，不要隨意的下結論去否定他人，更不要以自己以爲的結論就去定義他人。
當然，有些確實是在磨洋工的，就一定要提出反駁意見。
案例：系統要新增一個小衆的功能，產品提出後，研發直接拒絕
之前的系統條件是：產品先自我評估，然後產品內部評估，然後在找業務評估，最後上會和研發團隊一起評審。當研發團隊按照研發的角度來定義時，就會發現產品需求可能沒那麼重，或者該流程會增加額外的工作量。研發團隊也會對產品需求進行評估，看工作量，看應用程度， 看結果轉化。這個時候就特別怕產品一直在磨人，研發受不了就會直接拍桌子。
現在的系統新增了一個條件：產品帶着研發體驗用戶實際操作的過程，讓一個特別熟悉系統的人去模擬不怎麼用系統人的操作，這樣研發才能切身的感受到對於需求優化帶來的好處。所謂的切換角色考慮，並不是說你直接把自己當做另外一個人，你還要把自己降低到當前環境的條件中，這樣你才能真正的考慮到爲什麼做，要怎麼做。
4、學會利用已有的資源，不要悶頭造車
任何一個行業，任何一個崗位，都有很多的前輩遺留下來很多的資源，這些資源都可以很好的拿來利用。一個真正有能力的人，是會借力打力，在遇到困難的時候能夠第一時間找到能夠解決的人，或能夠給出解決方案的人，他們會尊重公司的“前輩”，學習他們特有的長處，並轉爲自己可在利用的能力，讓自己在激烈的競爭中處於不敗之地。如果你一味的自我專研，很容易就陷到誤區中，做出來的產品只會自嗨。
大多數的人都是平庸的人，他們無法思考跨越天空的難題，只能小步快跑，那這裏就是看你是在別人已經鋪好的路上面跑，還是選擇一條充滿着艱難險阻的道路。
已有的資源是在已有的環境中，通過驗證後得出的結論，很多的時候都是經驗堆積出來的，新人在剛接觸的時候，確實會不知道里面的規則，那麼友好的請教一些別人，就能夠馬上掌握裏面的規則。
案例：公司需要做一套業務流程
業務部門提報：有一個新業務誕生，需要新作一套業務流。通過溝通，發現該需求和公司很早之前一套廢棄的流程有60%的內容是匹配的。那麼在這裏我們就可以複製這套業務流，然後在此基礎上進行二次修改。切記不要直接啓用然後變更，廢棄的內容，不用放着不要緊，一旦啓用會出現很多意想不到的事故。
1、先定義好角色和層級。
2、在定義業務主線流程和各逆向分支節點。
3、定義各字段的設定條件。
4、做好節點跳轉關係。
5、識別判斷逆向條件的處理方案和扭轉條件。
6、各終點結果呈現和對應結果通知。
7、數據大屏呈現。
這個是對應的業務條件，那麼對應着這些業務條件去看公司當前有哪些已做好，可借用的內容，拿來去做二次轉化。
這裏要注意的是：你需要的是請教和溝通，而不是直接上來指導。對話和指令是兩種方式，不要以你當前的結論去定義別人的行爲，良好的對話是兩個人直接相互碰撞、融合，產生精華。
5、產品經理的思考，不能簡單用時間來衡量
很多的時候，產品經理會被追問一個時間節點，比如組合商品銷售，A商品40元，B商品30元，C商品33元，組合售價100元（含10元店鋪紅包），現在A商品僅退款，B商品既退貨又退款，需要產品經理給個完整流程的方案和數學定義公式。
先不說數學公式怎麼做到通用匹配，就說這個業務關係的正向流程和逆向流程要怎麼判斷就夠產品經理好一陣思考了，這怎麼直接給你一個時間節點的呢，我是說1個小時？還是1天？還是10天？
很多的領導不懂得思考的時間，不懂得如何估算大家的工作量，只會定義這個需求很簡單，你去說下，明天上線，實際這裏會有很多的問題，要經過思考，要梳理流程，才能確認各節點之間的關係和最終結果的定義，然後在進行開發、測試，最終上線運行。
思考是一種本質的定義，在通常的定義中，我們會下意識的形成肌肉記憶，既遇到問題自然的想到當前問題之前是怎麼解決的，現在還沿用之前的方法一樣就能夠解決。但，節點會變、場景會變、條件會變，那麼一成不變的方法就不能解決大多數的場景。產品經理這個時候就會考慮，如果我把條件擴大一些，把範圍設計廣泛一點，這樣是不是就可以包容了更多的場景，就能達到一力降十會的條件了。就比如手機號的限制，通常我們以大陸的手機號來做定義都是數字1開頭、11位字符、純數字這三個條件就能夠基本滿足了對吧，在此基礎上，然後還可以在加上前面2位不可重複，在前端多增加一步判斷，就可以讓後臺少一步識別。
案例：用戶需要買個錘子
用戶不想要個錘子，用戶想要的是照片能夠在我看到的地方：用膠水貼上去。電子屏、投影儀和錘子的區別是什麼，是解決掉用戶想要在我想要看到的地方有一個影像，那麼基於這個場景條件，然後在看自己的產品能匹配上哪些。如果依然還是一個錘子的事情，我可以提供長釘、膨脹螺絲，還可以提供組合相框，或上門服務。
都說人人是產品經理，但很多人實際做不好產品，因爲他們只會從自己的角度來理解問題，來解決需求，並不能系統化、大衆化、合理化的定義需求。而是通過不斷的迭代產品，不斷的提升成本，不斷的複雜流程來定製+針對來滿足需求。
那麼真實的理解一下當前的需求，多問兩句，真實的用眼睛去看下，用腦子想一下，實際操作一下，你就會發現用戶說的和想要的實際有較大的偏差。一款好的產品，必須包括這三大要素：充分的動機、足夠的執行能力，以及一個恰到好處的觸發機制。