本文作者將結(jié)合自己從技術(shù)轉(zhuǎn)型產(chǎn)品的一些經(jīng)驗，給出了一些建議，尤其是對于非技術(shù)背景轉(zhuǎn)型產(chǎn)品的同學。

互聯(lián)網(wǎng)發(fā)展到今天，產(chǎn)品經(jīng)理已經(jīng)成了各個互聯(lián)網(wǎng)公司的標配。很多的傳統(tǒng)行業(yè)公司迎合著“互聯(lián)網(wǎng)+”的國家戰(zhàn)略也開始慢慢觸網(wǎng)，產(chǎn)品經(jīng)理也逐漸從互聯(lián)網(wǎng)行業(yè)擴散到其他各行各業(yè)。雖說傳統(tǒng)行業(yè)本身也有自己的產(chǎn)品經(jīng)理，但在職責定義上會有一些區(qū)別，而今天被大眾所熟知的產(chǎn)品經(jīng)理更準確的說應該是互聯(lián)網(wǎng)產(chǎn)品經(jīng)理。尤其是隨著以喬布斯和張小龍為代表的神級產(chǎn)品經(jīng)理的出現(xiàn)，產(chǎn)品經(jīng)理崗位更是被披上了能改變世界的戰(zhàn)甲，讓一批又一批的人涌入了這個職業(yè)，開始了各種廝殺。

在現(xiàn)行的教育體制里，沒有產(chǎn)品學這么一個學科，并不像技術(shù)研發(fā)對應的是計算機或軟件工程這個學科。所以，產(chǎn)品經(jīng)理基本上是從其他職能轉(zhuǎn)崗，而且學習和成長過程基本靠自學或者傳幫帶。典型的像微信之父張小龍以前就是程序員出身，一己之力開發(fā)了名噪一時的Foxmail，后來進入騰訊先后負責過QQ郵箱和微信產(chǎn)品，最后憑借著微信讓他名揚天下。

成功轉(zhuǎn)型產(chǎn)品經(jīng)理的人中間，有從技術(shù)轉(zhuǎn)型的、有從設計轉(zhuǎn)型的、有從運營或者市場銷售轉(zhuǎn)型過來的，以前可能更多的是技術(shù)轉(zhuǎn)型，尤其是那些對產(chǎn)品有自己理解而且又不滿足于只實現(xiàn)功能的技術(shù)人員，到現(xiàn)在，除了技術(shù)人員之外，轉(zhuǎn)型產(chǎn)品經(jīng)理的人越來越多，背景差異化也越來越大。尤其對于初轉(zhuǎn)型的產(chǎn)品新人，這些產(chǎn)品經(jīng)理們在公司中承擔的職責和面對的問題大同小異，如何能在產(chǎn)品之路上少一點荊棘，多一些成長呢？結(jié)合本人從技術(shù)轉(zhuǎn)型產(chǎn)品的過程積累的一些經(jīng)驗，給出一些建議，尤其是對于非技術(shù)背景轉(zhuǎn)型產(chǎn)品的同學。

生存指南1：思維切換，技術(shù)思維vs產(chǎn)品思維

如果把產(chǎn)品比喻為房子，那產(chǎn)品經(jīng)理就是房屋設計師。設計師如果不懂基本的房屋結(jié)構(gòu)設計和施工原理，那設計出來的房屋很可能就是無法落地的空中樓閣。理想的設計和物理的限制必須有效結(jié)合，不存在真正的空中花園和通天塔，在工程領(lǐng)域，每一個設計都是可以被實現(xiàn)的。對于產(chǎn)品經(jīng)理來說，置身互聯(lián)網(wǎng)領(lǐng)域，設計互聯(lián)網(wǎng)產(chǎn)品，每一個設計也都應該在現(xiàn)有互聯(lián)網(wǎng)技術(shù)下可被實現(xiàn)。產(chǎn)品經(jīng)理學習一些基本技術(shù)知識，了解技術(shù)邊界，對于實際開展產(chǎn)品工作都有非常大的益處，所謂知己知彼，特別是在與工程師的工作配合和溝通中能起到關(guān)鍵作用。

在實際工作中不難發(fā)現(xiàn)，當產(chǎn)品經(jīng)理與工程師就某一個具體問題進行討論時，雙方站在各自角度就問題進行分析和討論，固有知識結(jié)構(gòu)的差異會使得各自思維模式和視角的差異，工程師更多的是路徑推理的技術(shù)思維，產(chǎn)品經(jīng)理更多的是用戶場景的產(chǎn)品思維。產(chǎn)品思維和技術(shù)思維的碰撞讓問題沒有在正確的方向上被解決，原因其實就是雙方用了不同的語系，好比一個講英語的人和一個講法語的人討論一幅畫，結(jié)果可想而知。

非技術(shù)背景產(chǎn)品經(jīng)理，先忘記原有背景經(jīng)驗，以用戶視角來看待產(chǎn)品，用產(chǎn)品思維去設計產(chǎn)品，用技術(shù)思維去溝通產(chǎn)品實現(xiàn)，能在不同的場景和面向不同角色完成思維切換，是產(chǎn)品經(jīng)理的核心技能之一。

生存指南2：技能切換，寫文檔vs講故事

產(chǎn)品需求文檔（PRD）是產(chǎn)品經(jīng)理必做功課之一，尤其是在初級產(chǎn)品階段，寫需求文檔更是這一階段產(chǎn)品經(jīng)理的主要工作之一，寫PRD需要清晰的邏輯思維能力和文字表達能力，往往一個看似簡單的功能實則隱含了很多非常復雜的邏輯。在傳統(tǒng)軟件項目開發(fā)流程里，產(chǎn)品需求文檔是非常重要的材料，產(chǎn)品經(jīng)理需要把每個細節(jié)在文檔里寫得非常詳細，不能有一絲紕漏。這往往適應于軟件工程里瀑布式的開發(fā)流程，即花幾個星期甚至幾個月定義需求并寫需求文檔，然后再投入幾個月開發(fā)。

但在現(xiàn)在變化劇烈的互聯(lián)網(wǎng)時代，這種研發(fā)方式明顯無法應對市場的變化。所以敏捷研發(fā)才會在近年來逐漸普及。對應的，PRD隨之也變的簡化，省去了很多繁瑣的文檔化流程，有的互聯(lián)網(wǎng)公司甚至直接用產(chǎn)品經(jīng)理制作的可交互原型來當做PRD，工程師根據(jù)原型即開始進行開發(fā)，有問題就隨時與產(chǎn)品經(jīng)理溝通，在過程中發(fā)現(xiàn)和解決問題。

在現(xiàn)在這種快節(jié)奏的迭代方式下，寫文檔已經(jīng)不再是核心技能，能通過簡單的文字和流程把需求書面化表達出來即可，更重要的是通過講述需求的價值和場景，讓工程師能感受到產(chǎn)品經(jīng)理和用戶的感受。以講故事的氣場去描述需求，進而把文檔轉(zhuǎn)變成故事的藍本，就像身臨其境聽故事的現(xiàn)場感對比閱讀書本故事的想象力那般。

以講故事的方式溝通需求和描述一個完整的故事一樣，時間、地點、人物和情節(jié)，例如一款音樂播放器產(chǎn)品，產(chǎn)品經(jīng)理設計了一個隨機播放音樂的功能，如果從技術(shù)角度考慮這個功能可能覺得毫無意義，應該讓用戶選擇喜歡聽什么類型的音樂，至少也是場景，比如搖滾和睡前。那隨機播放音樂這個功能在什么場景下成立呢？以講故事的方式描述需求可以這么說：”工程師小王上班一天晚上回到家，想聽音樂放松下，此時已經(jīng)沒有心力再去挑選，打開產(chǎn)品點擊隨機播放，這種放松感和愜意是前所未有的“。這樣，時間（晚上下班后）、地點（家里）、人物（工程師小王）情節(jié)（需要放松）就都具備了，這種方式比單純討論一個隨機播放音樂的功能要生動很多，也更有利于產(chǎn)品經(jīng)理去推行這個設計。

對于現(xiàn)代產(chǎn)品經(jīng)理來說，在自身技能樹的豐富上，溝通和表達能力絕對算得上排前幾位。完成技能切換，讓講故事的能力成為強項，會讓產(chǎn)品之路順暢很多。當然，不要瞎講故事。

生存指南3：溝通切換，自我vs無我

溝通，產(chǎn)品經(jīng)理心中永恒的痛，尤其是對非技術(shù)背景的產(chǎn)品經(jīng)理，總有一種明明自己講得很清楚對方卻一臉茫然的錯愕。在任何溝通中最大的問題是溝通方只表達自己，卻少有放下自己去溝通，所謂放下自己其實就是能聽進去別人的表達。看似簡單，可很多時候我們以為的聽進去只是聽到了，并不代表聽懂了。

例如，產(chǎn)品經(jīng)理聽到工程師說某個功能實現(xiàn)不了就以為是技術(shù)實現(xiàn)不了，實際上真實原因可能是時間不夠或技術(shù)方案比較復雜。這就像挖掘用戶需求一樣，用戶want的并不是用戶真正的need，想吃包子（want）其實是餓了（need）。放下自我解讀進入溝通，能讓我們更好的在溝通中獲取有效信息并取得主動權(quán)。進入”無我“的狀態(tài)能在溝通過程中更加游刃有余，”無我“就是不帶有任何主觀偏見去認識和討論一個觀點，而人最大的認知誤區(qū)就是”不知道自己不知道“。

工程師的思維方式是一種線性而且邏輯性比較強的方式，考慮問題或者作出行動時往往會按照嚴密的順序和邏輯進行，他們認為一件事情肯定是按照固定的流程執(zhí)行，不喜歡中間突然變化或者出錯，因為這會使他們感到沮喪。

工程師又是一群極為“自負”而且追求極致的人，這種“自負”并不是貶義的自負，而是一種對自己所做的東西的自信，這種自信又超出傳統(tǒng)的自信，所以用“自負”來描述這種超額自信。這種態(tài)度源于工程師對自己所編寫的代碼的掌控力，因為計算機是嚴格按照工程師所編寫的程序代碼來執(zhí)行的，這種感覺會讓程序員有一種控制力和駕控感，這種感覺會讓工程師們形成這種“自負”的效應。

所以我們經(jīng)常會看到，當去和一個工程師說他們寫的程序有問題的時候，很多人的第一反應是——“不可能，怎么會有問題呢？”沒錯，正是因為這種“自負”讓工程師對自己所寫的代碼極為自信，因為計算機是對程序代碼毫無條件的嚴格執(zhí)行的，一旦出現(xiàn)問題，就說明程序代碼在邏輯上存在錯誤，而這種錯誤肯定是工程師留下的，但人本能是不愿意承認自己的錯誤的。

所以，當這種情況出現(xiàn)的時候，產(chǎn)品經(jīng)理應該換一種方式去與工程師溝通。比如用一種問題轉(zhuǎn)移的方式與工程師溝通，可以說“我們在設計產(chǎn)品時有一個邏輯沒有考慮到，但現(xiàn)在我們實現(xiàn)時發(fā)現(xiàn)了這個問題，我們要一塊把這個邏輯漏洞補上”，通過這種方式就可以維持工程師們的“自負”心理，然后用問題轉(zhuǎn)移的方式將問題轉(zhuǎn)移到產(chǎn)品邏輯沒有覆蓋到，這樣既可以讓問題得以順利解決，也讓雙方都感覺好一些。

溝通是產(chǎn)品經(jīng)理進階路上的必修課，在“自我”和“無我”間的溝通切換，能讓溝通來的更輕松些！

#專欄作家#

唐韌，人人都是產(chǎn)品經(jīng)理專欄作家，微信公眾號：ryantang007，互聯(lián)網(wǎng)技術(shù)產(chǎn)品運營玩家，《產(chǎn)品經(jīng)理必懂的技術(shù)那點事兒》作者。

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