不想改變世界的產品經理不是好的產品經理，產品經理要有一顆創造、改變和實現一些東西的初衷和想法，不然產品經理就淪為了功能型產品經理。

總體摘要：

• 對象：非技術產品經理
• 目的：高效與技術人員溝通

掌握技能包含主要3點：

1. 技術職能劃分了解
2. 常用技術術語了解
3. 理解開發人員思維（技術思維vs產品思維）

用戶代言人：產品經理

實現代言人：技術人員

第一部分：技術思維vs產品思維

技術思維（程序員）

1. 功能實現
2. 開發難易
3. 后期維護
4. 改動成本

產品思維（產品經理）

要站在用戶思維，否則以技術思維可能最后做出來產品過于生硬，偏工具。

1. 產品定位
2. 需求場景
3. 用戶體驗
4. 業務目標

產品思維vs技術思維實例：

微信通訊錄及會話設計：

從微信第二個“tab”進去，點擊好友主頁，點擊“發消息”，點擊左上角“返回”，卻退回了第一個tab“微信”。

• 技術思維：堆棧式設計，即從哪里進入，就返回到哪里。(路徑為1-2-3 / 回退路徑即為3-2-1）
• 產品思維：更加符合場景，貼合用戶使用習慣，遵從人性。

備注：以上的微信通訊錄及會話設計操作路徑示例，本人按照上面操作實操時卻發現回退到的是上一個頁面，而非作者說的返回第一個tab“微信”，可能是新版本的微信改了吧，作者當時是舊版本吧。不過實際中確實很多類似這種例子。尤其是用戶使用習慣。

其他：技術人員往往不具備同理心，及換位思考的能力（產品方面，生活其他角度除外）。但是產品經理必須同理心及換位思考的能力。這是產品經理必須具備的一種必備素質。所以產品經理需要內心強大，來抵抗一些來自程序員方面的壓力。

但最終產品經理任然需要站在產品角度，用戶角度去完成產品設計。也是基于此方面（思維方式及心理能力）產品經理和技術人員是不同的，所以這也是產生分歧的根本原因。

第二部分：技術職能劃分

• CTO：技術部門leader或產品
• 架構師：負責系統整體技術架構和技術選型（技術角色）僅次于CTO。
• 前端開發：分為網頁前端（web）、移動客戶端前端（native),移動客戶端又分為Android、ios、Windows Phone【安卓設計和ios有不同的開發設計規范】
• 后端開發：服務端開發，包括數據庫設計與開發，應用接口開發。
• 系統運維：服務器管理與整體維護，應用發布。如服務器數量是否夠等。

上圖為作者的創業公司的一個工作流程。具體公司可能不太一樣，但大同小異。

幾點：周為節點進行產品迭代，高保真的demo，這塊是作者公司需要做的。根據筆者經歷而言，有的創業公司需要做代碼可運行的高保真demo，如需要用demo和投資人溝通融資。大部分公司只需要評審非代碼層面的原型及需求文檔即可。

個人總結：利用用戶思維去跟開發解釋更符合用戶場景，而不是技術實現。這也是我在工作中經常遇到的，有時候可能太過于同理心了【比如特別“同情”技術人員】就會把一些“不易”開發的省卻成簡單的，這其實很多時候是不正確的做法。這樣往往設計的產品過于機械化、工具化，產品經理應該站在用戶思維，不要走偏記得！

第三部分：常用技術術語

【此處需要劃重點，著重記憶，對你以后和技術溝通和理解技術有很大幫助】

1. API：服務器端的應用接口。應用接口類似于服務器端定義好的一個協議，這個協議有一些的數據結構，會有一個固定的標識。前端同學需要訪問這個協議，通過這個協議將具體的數據傳送給服務器端，服務器端基于這個固定好的協議接受數據，實現前后端互聯互通。API就是協議，前后端共同遵從的協議。
2. eg：登陸功能：后端定義好需要用戶名和密碼，前端需要將用戶名和密碼傳送給服務器端，服務器端驗證成功就好了。
3. Json/xml：屬于數據協議，eg：登錄名/密碼。實際就是通過json這個承載體，可以理解為打包文件，把用戶名和密碼放到里面，然后通過API這個協議傳送給服務器。
4. URL：地址。
5. html/css：web網頁使用的布局語言、裝飾表
6. 數據庫（DB)：存儲數據，數據查詢，檢索
7. Git/SVN：管理代碼，代碼存儲的服務，實現多分支管理，遠程和本地的開發?！敬a倉庫】不同的代碼同學共同協作。

前端術語：

• Activity（Android）：每一個屏幕展示的頁就是這個，這個界面上所有的邏輯，所有的展示。
• ViewController（IOS)：每一個屏幕展示的頁就是這個。同上，只是一個是ios一個是安卓。
• lib（第三方庫）：eg：用百度地圖的sdk，可直接使用這項服務（定位服務）第三方庫幫助我們做復雜的事情。
• ListView（Android）：其實就是app里面經常能看到的列表，例如微信里面的聊天頁面就是個列表。
• TableView（iOS)：同上。
• View：基礎組件都是一個view，如一個按鈕，一個選擇框，一個復選框都是一個view，甚至一段文字的展示都是一個view。指的是具體前端頁面展示的一個具體的組件。

第四部分：如何與技術人員溝通

【翻譯】【很重要，非技術產品經理90%都會遇到】

產品經理說白話，技術人員說黑話。產品經理需要自己翻譯給自己聽，給用戶聽。（哈哈）

產品經理主導溝通方向，實際工作中討論往往從原本的產品討論很容易陷入技術細節討論。應該避免陷入技術細節討論，從場景和用戶體驗出發。對實現方案的討論，非技術產品經理是無法參與的。技術人員找產品經理討論，往往是確認產品需求但最終就成了討論技術問題。

如何解決這個問題：

1. 從場景出發；
2. 從用戶體驗出發。

真正用戶能用的產品。

因此產品經理與開發人員溝通的過程中要把握溝通的方向，要知道聊的是什么，每一次溝通要有目的和結論。溝通要往哪個方向引導。一切以用戶場景和用戶體驗為主。否則討論就會走向偏題的狀態。這也不是自己擅長的。

如下圖為技術人員經常會對產品經理說的話，你是不是很有同感？

如果遇到以上問題：產品經理是改產品設計還是改需求？

產生上述原因可能有產品需求文檔里面沒寫，或者技術人員覺得這個重新做成本太大。實現不了，或者技術人員直接告訴你只是后端的問題。

如何解決上述問題，舉兩個例子：

【引導型溝通，有序的溝通】

第一個“這個實現不了”：不要被技術所限制，但要在技術邊界之內。產品是需要衡量投入產出比，挖掘技術人員背后的初衷，是因為時間不夠（講清楚緊急程度，就改為可實現了），還是技術難度（技術人員也是需要技術調研），另一種是確實技術實現不了。一定要搞清楚是哪一種，不要隨意更改需求，不然是對用戶的不負責，是對產品的不負責。

第二個“這是后端的問題”：當我們使用產品時發現了一個bug，可能第一時間直接問開發同學或測試，問怎么解決，技術人人員往往告訴你是后端的問題。那么你應該找誰，是找前端是找后端，正確的方式是不應該直接找后端，而是需要問前端：你是如何排查這個問題的，我們應該怎么解決這個問題，如果要解決這個問題，我能為你做什么，一起探討這個問題的解決方案。

分析技術人員的需求：Want or Need，需求的本質。

• 用戶：需要一個更快的馬；
• 福特：提供了一個汽車。

第五部分：非技術背景產品經理學習指南

懂用戶比懂產品重要，懂產品比懂技術重要

“設計一款產品：最先考慮的不應該是技術，而應該是用戶，需要我們在什么場景下位他們解決什么問題，這樣才能更好的設計，呈現給用戶。產品本身不能過于流程化和機械化，設計一款符合用戶使用習慣的產品?！?/p>

總結

1. 發揮非實現模式思維的優勢，理解并思考場景；
2. 多與技術人員溝通，理解實現模型思維；
3. 學會講故事，講故事能力非常重要，往往都說產品經理就是ceo的學前班，這個我很認同。產品經理需要面向運營、市場、財務、法務等等，產品經理要讓這個故事講得精彩，讓大家一起把事情做好。這個故事的引導者和制造者就是產品經理，并且產品經理需要有廣度思維。

最終我們所創造的用戶價值，才是最終能帶來實際效果的，才能造福用戶，被這個行業和市場所接受，我們應該為這個行業創造價值，為這個行業改變一些事情，為這個世界做一些事情。

最后送給大家：

不想改變世界的產品經理不是好的產品經理，產品經理要有一顆創造、改變和實現一些東西的初衷和想法，不然產品經理就淪為了功能型產品經理。什么是創造型產品經理，什么是功能型產品經理，相信大家都有自己心里面的一些思考。

ps：以上內容基于在起點學院觀看Ryan視頻的一些整理及個人工作中的感悟，僅分享和交流，保持求同存異的觀點和態度。

本文由 @對方正在輸入 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議