從這壹節開始，以產品經理為中心，依次告訴身邊的各個團隊。首先，從產品團隊開始，我們經常會聽到產品經理、產品策劃或產品設計師、需求分析師、產品運營、交互設計師、視覺設計師、用戶研究員、前端工程師等等職位。按照產品從概念規劃到最終成型的順序，作者也是壹個從抽象到具體，從業務到技術的過程。
首先要說的是狹義的產品團隊，特指產品經理和他帶領的產品策劃、產品設計師、需求分析師。通常在團隊中，都簡稱為PD，但每個人的具體分工會略有不同。
產品經理和產品策劃更傾向於產品前期的規劃，比如產品市場定位，各版本的發布時間計劃等。在這個層面，商業目標和用戶需求是思考的重點。當然，公司的管理層也會全面參與這個過程，通常是老板們做最後的決定。
產品設計師專註於功能設計和編寫需求文檔。在某個模塊中，他們很像壹個小的產品經理，比如庫存管理中是否需要提供庫存預警功能，預警數只是上限還是下限，或者兩者都有，預警數設置是否需要批量操作等等。更細分的RA(需求分析師)只存在於部分部門。在這種分工下，PD的工作盡可能往前走，偏向市場、用戶、產品規劃；RA則是嘗試倒退，偏愛實現和技術，也就是寫UC，做系統設計。
壹般來說，狹義的產品團隊所做的事情，最符合互聯網、軟件行業產品經理招聘廣告中的描述。他們有大局觀，邏輯嚴密，理智冷靜。
PD所做的工作已經在前面的章節中描述了很多。在這裏，我們來查漏補缺，談談產品的概念設計和信息架構。與策略相關的主題放在第五章。
概念設計的輸出是產品概念圖，它更像第二章提到的業務邏輯圖，但比業務邏輯圖更抽象。輸出的概念圖應該是需求收集之後，需求篩選之前的同壹階段的任務。在紛繁復雜的用戶需求中，我們需要通過概念圖理清思路，找出我們應該做什麽，並將這些規劃好的需求整合成壹個合理的系統。常用的簡單產品概念圖有以下兩種。
首先，在思維導圖上畫壹個概念圖。當收集到用戶需求後，我們可以簡單地將它們轉化為產品需求，或者直接在思維導圖中繪制出來。然後，開始整理這些亂七八糟的東西，比如簡單的將各種需求分類，用各種標記標註壹些項目，用幾條線連接相關需求，寫壹些筆記，就算完成了最粗糙的概念圖。
第二，找個會議室，用馬克筆把自己的想法畫在白板上，然後壹起討論改進。這張手繪概念圖很酷。妳可以試試。畫完之後拍壹張照片保存在電腦上。必要的話可以重繪成更漂亮的電子版。
這壹步完成後，產品就相當於有了壹個整體的業務架構。現在可以進入需求篩選階段，大家可以決定先做哪個部分，後做哪個部分。所以概念圖其實描述的是整個產品的內外關系，形式並不重要。重點是表達以下兩點:
產品與外界的關系:將整個產品視為壹個系統，描述其與上下級系統、平行系統的關系，如有可能勾勒出產品所在的產業鏈結構；
產品內部關系:產品有多少模塊，模塊之間的關系如何，不涉及數據流等細節，重點描述系統中不同角色的身份。
概念設計是給內部做的，是為了團隊的溝通，方便大家對產品形成* * *認識。因此，在概念設計完成後，可以開始信息架構的工作。相比之下，信息架構是為外部而造的，為了設計更合理的方式向用戶傳遞信息。這個由內而外的過程，也可以看做是從“做什麽”到“怎麽做”的過程。有幾本書專門討論信息架構的主題，可以從Web信息架構中得到建議。
最後，PD和普通用戶通常看待產品和思考問題的方式不同:PD習慣於由內而外，從本質出發；用戶習慣於從外往裏看，從表面看。因此，無論是概念設計還是信息架構，都應該從用戶的角度出發，以用戶為中心，這意味著未來產品的性能將更接近用戶的心智模型。技術架構層面真的不需要太關註用戶，這是工程師的工作。
PD團隊的成員以前什麽都幹，有開發的，有測試的，有營銷的，有銷售的，有畢業後直接入行的。絕大多數技術團隊在學校學技術，畢業後做技術。從這個角度來說，PD作為整個團隊的核心是合理的，因為PD團隊背景多樣，可以和周圍任何壹個團隊的同學順暢交流，起到了連接器和潤滑劑的作用。
那麽，各種出身的PD各有什麽優缺點呢？答案很簡單。妳之前做的是妳擅長的，那是妳的優勢，也是妳的劣勢。對於PD這樣的崗位來說，沒有什麽技能是無用的，沒有人能夠掌握所有需要的技能。PD之前做什麽不重要，我們必須是通才而不是專家。從PD團隊的角度來說，成員盡量豐富，業務、技術等各種背景的同學開會是合理的，這樣優勢互補，考慮問題更全面。另外，公司新人太多也是壹個大問題，這也是小公司和高速成長團隊不可避免的問題。老中青梯隊還是要的。壹年內有個人經歷的同學最好不要超過壹半，需要帶起後方，壹個有三年以上經歷的同學來穩定這個結構。