互聯網發展到今天，產品經理已經成了各個互聯網公司的標配。很多的傳統行業公司迎合着“互聯網+”的國家戰略也開始慢慢觸網，產品經理也逐漸從互聯網行業擴散到其他各行各業。雖說傳統行業本身也有自己的產品經理，但在職責定義上會有一些區別，而今天被大衆所熟知的產品經理更準確的說應該是互聯網產品經理。尤其是隨着以喬布斯和張小龍爲代表的神級產品經理的出現，產品經理崗位更是被披上了能改變世界的戰甲，讓一批又一批的人涌入了這個職業，開始了各種廝殺。
在現行的教育體制裏，沒有產品學這麼一個學科，並不像技術研發對應的是計算機或軟件工程這個學科。所以，產品經理基本上是從其他職能轉崗，而且學習和成長過程基本靠自學或者傳幫帶。典型的像微信之父張小龍以前就是程序員出身，一己之力開發了名噪一時的Foxmail，後來進入騰訊先後負責過QQ郵箱和微信產品，最後憑藉着微信讓他名揚天下。
成功轉型產品經理的人中間，有從技術轉型的、有從設計轉型的、有從運營或者市場銷售轉型過來的，以前可能更多的是技術轉型，尤其是那些對產品有自己理解而且又不滿足於只實現功能的技術人員，到現在，除了技術人員之外，轉型產品經理的人越來越多，背景差異化也越來越大。尤其對於初轉型的產品新人，這些產品經理們在公司中承擔的職責和麪對的問題大同小異，如何能在產品之路上少一點荊棘，多一些成長呢？
結合本人從技術轉型產品的過程積累的一些經驗，給出一些建議，尤其是對於非技術背景轉型產品的同學。
生存指南1：思維切換，技術思維vs產品思維
如果把產品比喻爲房子，那產品經理就是房屋設計師。設計師如果不懂基本的房屋結構設計和施工原理，那設計出來的房屋很可能就是無法落地的空中樓閣。理想的設計和物理的限制必須有效結合，不存在真正的空中花園和通天塔，在工程領域，每一個設計都是可以被實現的。對於產品經理來說，置身互聯網領域，設計互聯網產品，每一個設計也都應該在現有互聯網技術下可被實現。產品經理學習一些基本技術知識，瞭解技術邊界，對於實際開展產品工作都有非常大的益處，所謂知己知彼，特別是在與工程師的工作配合和溝通中能起到關鍵作用。
在實際工作中不難發現，當產品經理與工程師就某一個具體問題進行討論時，雙方站在各自角度就問題進行分析和討論，固有知識結構的差異會使得各自思維模式和視角的差異，工程師更多的是路徑推理的技術思維，產品經理更多的是用戶場景的產品思維。產品思維和技術思維的碰撞讓問題沒有在正確的方向上被解決，原因其實就是雙方用了不同的語系，好比一個講英語的人和一個講法語的人討論一幅畫，結果可想而知。
非技術背景產品經理，先忘記原有背景經驗，以用戶視角來看待產品，用產品思維去設計產品，用技術思維去溝通產品實現，能在不同的場景和麪向不同角色完成思維切換，是產品經理的核心技能之一。
生存指南2：技能切換，寫文檔vs講故事
產品需求文檔（PRD）是產品經理必做功課之一，尤其是在初級產品階段，寫需求文檔更是這一階段產品經理的主要工作之一，寫PRD需要清晰的邏輯思維能力和文字表達能力，往往一個看似簡單的功能實則隱含了很多非常複雜的邏輯。在傳統軟件項目開發流程裏，產品需求文檔是非常重要的材料，產品經理需要把每個細節在文檔裏寫得非常詳細，不能有一絲紕漏。這往往適應於軟件工程裏瀑布式的開發流程，即花幾個星期甚至幾個月定義需求並寫需求文檔，然後再投入幾個月開發。
但在現在變化劇烈的互聯網時代，這種研發方式明顯無法應對市場的變化。所以敏捷研發纔會在近年來逐漸普及。對應的，PRD隨之也變的簡化，省去了很多繁瑣的文檔化流程，有的互聯網公司甚至直接用產品經理製作的可交互原型來當做PRD，工程師根據原型即開始進行開發，有問題就隨時與產品經理溝通，在過程中發現和解決問題。
在現在這種快節奏的迭代方式下，寫文檔已經不再是核心技能，能通過簡單的文字和流程把需求書面化表達出來即可，更重要的是通過講述需求的價值和場景，讓工程師能感受到產品經理和用戶的感受。以講故事的氣場去描述需求，進而把文檔轉變成故事的藍本，就像身臨其境聽故事的現場感對比閱讀書本故事的想象力那般。
以講故事的方式溝通需求和描述一個完整的故事一樣，時間、地點、人物和情節，例如一款音樂播放器產品，產品經理設計了一個隨機播放音樂的功能，如果從技術角度考慮這個功能可能覺得毫無意義，應該讓用戶選擇喜歡聽什麼類型的音樂，至少也是場景，比如搖滾和睡前。
那隨機播放音樂這個功能在什麼場景下成立呢？以講故事的方式描述需求可以這麼說：”工程師小王上班一天晚上回到家，想聽音樂放鬆下，此時已經沒有心力再去挑選，打開產品點擊隨機播放，這種放鬆感和愜意是前所未有的“。這樣，時間（晚上下班後）、地點（家裏）、人物（工程師小王）情節（需要放鬆）就都具備了，這種方式比單純討論一個隨機播放音樂的功能要生動很多，也更有利於產品經理去推行這個設計。
對於現代產品經理來說，在自身技能樹的豐富上，溝通和表達能力絕對算得上排前幾位。完成技能切換，讓講故事的能力成爲強項，會讓產品之路順暢很多。當然，不要瞎講故事。
生存指南3：溝通切換，自我vs無我
溝通，產品經理心中永恆的痛，尤其是對非技術背景的產品經理，總有一種明明自己講得很清楚對方卻一臉茫然的錯愕。在任何溝通中最大的問題是溝通方只表達自己，卻少有放下自己去溝通，所謂放下自己其實就是能聽進去別人的表達。看似簡單，可很多時候我們以爲的聽進去只是聽到了，並不代表聽懂了。
例如，產品經理聽到工程師說某個功能實現不了就以爲是技術實現不了，實際上真實原因可能是時間不夠或技術方案比較複雜。這就像挖掘用戶需求一樣，用戶want的並不是用戶真正的need，想吃包子（want）其實是餓了（need）。放下自我解讀進入溝通，能讓我們更好的在溝通中獲取有效信息並取得主動權。進入”無我“的狀態能在溝通過程中更加遊刃有餘，”無我“就是不帶有任何主觀偏見去認識和討論一個觀點，而人最大的認知誤區就是”不知道自己不知道“。
工程師的思維方式是一種線性而且邏輯性比較強的方式，考慮問題或者作出行動時往往會按照嚴密的順序和邏輯進行，他們認爲一件事情肯定是按照固定的流程執行，不喜歡中間突然變化或者出錯，因爲這會使他們感到沮喪。
工程師又是一羣極爲“自負”而且追求極致的人，這種“自負”並不是貶義的自負，而是一種對自己所做的東西的自信，這種自信又超出傳統的自信，所以用“自負”來描述這種超額自信。這種態度源於工程師對自己所編寫的代碼的掌控力，因爲計算機是嚴格按照工程師所編寫的程序代碼來執行的，這種感覺會讓程序員有一種控制力和駕控感，這種感覺會讓工程師們形成這種“自負”的效應。
所以我們經常會看到，當去和一個工程師說他們寫的程序有問題的時候，很多人的第一反應是——“不可能，怎麼會有問題呢？”沒錯，正是因爲這種“自負”讓工程師對自己所寫的代碼極爲自信，因爲計算機是對程序代碼毫無條件的嚴格執行的，一旦出現問題，就說明程序代碼在邏輯上存在錯誤，而這種錯誤肯定是工程師留下的，但人本能是不願意承認自己的錯誤的。
所以，當這種情況出現的時候，產品經理應該換一種方式去與工程師溝通。比如用一種問題轉移的方式與工程師溝通，可以說“我們在設計產品時有一個邏輯沒有考慮到，但現在我們實現時發現了這個問題，我們要一塊把這個邏輯漏洞補上”，通過這種方式就可以維持工程師們的“自負”心理，然後用問題轉移的方式將問題轉移到產品邏輯沒有覆蓋到，這樣既可以讓問題得以順利解決，也讓雙方都感覺好一些。
溝通是產品經理進階路上的必修課，在“自我”和“無我”間的溝通切換，能讓溝通來的更輕鬆些！
轉自：
http://mp.weixin.qq.com/s?__biz=MjM5NTIzMTY2MQ==&mid=2650406859&idx=1&sn=f8dbc61bf52f64a481f7b0767104b10f&chksm=bef6fd098981741fb2fda657d586b6771a1786eb9573601cc48844715c023daeb6ce1496be6b&mpshare=1&scene=23&srcid=0911LxbytKkTTGnceIH5v0io#rd
