7.4發了一篇技術如何轉產品的文章：【周覆盤】技術如何轉產品01——1+1>2？
所謂知行合一，這邊真的就去做了一些產品相關工作，4個多月下來小有心得，這裡分享出來大家聊聊。
問題一：什麼是技術產品
首先回答第一個問題應該是，什麼樣的技術適合轉產品？
1）做技術已經達到了自己天花板，並且感覺自己很難再進一步，努力做技術ROI很低的同學；
這是我本來有一個領域（Scope）的事情做的很好，但是這個領域我已經很難再進步了，於是我發展了一個跟這個領域很相關的另一個領域，於是我就變成了所謂的兩棲人才。
2）做技術中途轉技術管理後，發現技術領域已經達到了天花板，想更多的瞭解業務，做更多創作性的工作，於是從技術總監轉成了產品；
3）發現自己技術做不下去，又不想離開網際網路行業，於是...
總而言之，就是技術這條路大概是走不下去了，所以就轉產品了......
問題二：技術轉產品有什麼難點
1）對這個世界的認知太少；
做技術比較好的同學，往往有一些蜜汁自信，因為他有將想法變成現實的能力，會認為這是一種稀缺能力（現在逐漸變多），差的只是一個想法：）
PS：他們不知道的是這個想法其實更稀缺
但真的做技術比較好的同學，在技術上（特別是程式碼）會花費大量的時間，什麼設計模式、作業系統、資料結構、前端框架，隨便一個玩意，跳進去2年就沒了，你出來的時候的感覺基本就跟跟什麼都沒學似的，有人問你什麼是設計模式，你大概率依舊回答不了......
因為個人的精力是有限的，你投入了技術，那麼你對業務、對產品、對銷售、對人際關係等等會不太懂，甚至會認為跟人打交道是個很麻煩的事情，不然寫程式碼來的簡單，技術做產品的第一個問題是對真實世界瞭解太少，並且認為真實世界是傻逼：
所以，技術想要做好的產品，首先要打破認知壁障，這裡要做的第一件事就是承認自己不行！
最近產品負責人讓我去面試產品專家的時候，我第一句話就是：我的產品專業度不行，單就產品我未必能問出太多的東西，可能會更著重做事一塊......
初期，誠實的面對自己，說自己不行，沒什麼丟臉的，但一年後還是不行的話，那可能就是真不行，不太適合做產品了。
2）產品需要深轉
產品工作有一點跟技術類似：產品需要深轉，真實的進入每一個難題，不斷的自我質疑，然後再找到解法，這裡是我們公司的對產品的定義：
產品是通過不斷的輸入，找到不同的排列組合，產生對使用者更有效、更高效、更可及的解法。
所以產品的本質是解決生活中的問題，這個跟我們解決技術上的問題是一樣的，簡單的BUG是一種解法，複雜的問題需要框架，所以複雜的產品問題是需要對應的產品框架來解決的。
可以類比你思考一個框架難點時候的的輾轉反側，也可以類比你解決了一個效能瓶頸的欣喜若狂，產品設計是需要耗費巨大心力的，這裡面是很多很多的策略，很多很多的匹配策略落地的策略。
一個產品點子，可能需要一百個策略來推動，不可謂不難！
如果認為產品比技術簡單而想要轉產品的同學，我覺得可以慎重，這條路不簡單，有時候甚至更難......
3）產品更需要交流
產品是一個對協調能力要求較高的工種，上要串聯運營，下要單挑開發，前要PUA老闆，後要跪舔設計。
如果本身“木訥”的程式設計師要做以上工作，會被傷害自尊心的，這個心理防線首先自己就要拉低，這個時候很多技術會認為還是寫程式碼輕鬆......
進入真實世界後，你會發現，當初自己認為多麼了不起的技術大神，也只是在技術領域罷了，其他領域依舊有大神，沒有優劣之分，技術不比其他工種更優越，要把這句話記住，雖然我依舊認為程式設計師是最偉大的......
問題三：技術轉產品為什麼會那麼噁心？
最後一個問題扣一下主題，尺有所短寸有所長，技術產品也會有很多天然的優勢，但這些優勢對技術來說，可能比產品本身更噁心人......
這裡不說原因，直接上幾個Case。
1）我覺得該這麼實現
一天專案組兩個前端吵得面紅耳赤，我聽了下大概內容，無非是A同學想用這個框架，B同學想用那個元件，一個事情爭完以後，又為其中一個技術細節實現拉扯了快一小時了。
考慮到專案進度，我直接嚎了一嗓子：你們這種技術之爭，不要在這扯犢子，我覺得可以用A同學那個方式去實現，原因是1、2、3，其實B同學的方案也不會有太大問題，最終都能實現我要的功能，只不過你們在這樣爭論下去會影響我專案進度，所以我建議......
2）我想重構系統
一天，後端主程跑過來給我說，之前下面同學實現不夠優雅，我想重構一下系統......
我的回答就很簡單了，重構個錘子，滾！！！
3）你怎麼不畫原型圖
第一次做我專案的同學都會發出一個疑問，你怎麼不提供原型圖？
這裡真實的答案是，我不會畫那玩意，並且我不想去學......
圖片型文件，我最多提供一個PPT，如果是這樣，技術看來，這個產品真尼瑪是low到爆了，但是：我把資料表設計出來了......
然後把我認為該提供的文案儘量提供齊全，由於職業習慣，每個策略甚至虛擬碼都會在大腦裡面跑一圈，資料流也不會出問題，於是在專案後期，就會出現另一個場景：
我：這個系統現在的資料結構，跟我最初的設計差距大不；
後端主程：差距不是很大......
4）什麼時候能實現
在專案過程中，我說個最多、最討人厭的一句話就是：
這個應該很簡單吧，什麼時候能實現......
技術同學多次據理力爭，最終卻無功而返，但是這樣有個非常重要的點要注意：
現在寫程式碼的畢竟不是你，技術同學要怎麼做實現，他說的deadline只要跟你衝突不大，不要斤斤計較，請不要斤斤計較，隨它去吧。
綜上，技術轉產品後，正常情況下可以與程式設計師完美溝通，效率奇高，做產品設計時會更考慮版本迭代，甚至可以達到，1.0、2.0、3.0三個版本毫無關係，最終迭代卻有完美一體，無論對迭代還是維護，都有莫大的好處。
5）你不要扯犢子了
有時候跟一個產品同學聊天，確實相持不下的時候，最後會忍不住冒出一句，你不要扯犢子了，你這個根本不能實現，並且成本極高，你考慮清楚再說好不，下面技術同學會怎麼罵你......
產品：那個，我......
正所謂，你跟我說產品我跟你說實現，你跟我說實現，我跟你說體驗，你跟我說體驗，我跟你說收入，噁心人莫過於此吧？
結語
以上是我做產品時候一些小小的心得，希望對各位有用。