什麼叫做產品架構？
純銀說真正擁有產品架構能力的PM十分之少。
能請大家結合案例具體說一說什麼是產品架構，以及如何具備這方面的能力嗎？
如何提升產品架構能力？ - huiter 的回答
很慚愧，在搞不清「產品架構」是個什麼東西的情況下，回答了上面那個問題。我想，純銀老師所說的「產品架構」，應該就是指做產品的能力。
架構，是一個偏向宏觀的事情。
設計，是一個偏向細節的事情。技術架構，是將產品需求轉變為技術實現的過程。
產品架構，應該是將需求轉變為產品需求的過程。產品架構，最考驗PM的判斷力和設計能力。
這個地方結合案例具體比較難講。我們就以大家都熟悉的知乎為例，設計一個問答網站。
首先會有 用戶、問題、回答 這幾個對象。用戶對回答可以，贊同 或 反對。用戶可以通過 評論 回答，或 私信 的方式與答主交流。用戶可以 關注 答主。
...所以我們可以先整理出基本的信息 對象 和 動作。
用戶、問題、回答、贊同、反對、評論、私信、關注。隨後，我們要提供問題和回答的曝光方式，
我們可以在首頁做一個 中心化列表 ，來把問題曝光出來，獲取流量。運行了一段時間後，我們發現一個中心化列表很難滿足所有用戶，
於是我們推出 話題 對問題進行分類，提供信息流的效率。又運行了一段時間，我們發現話題也解決不了中心化帶來的問題，大部分都集中在少數問題上，
於是我們退出了 動態 來形成每個人的 Feed，讓問題有了更好的曝光，隨後我們又增加了無所不能的 關注，來豐富 Feed，對人、問題、話題、收藏夾...為了收集回答，我們推出了 收藏，
而為了整理收藏，我們提供了將問題列入一個個 清單。......
這個過程中，我們不斷遇到問題，然後判斷它是不是要被解決，再選出解決問題的方法。
我想這就是產品架構中最重要的部分。判斷需求的真偽和優先順序，需要PM對業務有足夠的了解。
選出優秀的問題解決方案，則需要PM有足夠的工具方法積累。知乎，本身就是一個功能比較豐富的產品，學透了知乎，就完了積累的一大半。
當然，一切都不是萬能的。之前李奇老師提出過，並不是所有的需求都可以利用現有的組件堆一堆來解決問題。一個典型的例子就是，微信如何解決公眾號抄襲問題。
普通的做法就是加個舉報功能了事。微信後來則推出了「原創」功能，利用機器來自動識別是否抄襲。這就是一個超越現有方案來解決問題的方式。當然這部分更偏向細節，與架構並不那麼相關。
======先寫這麼多。我理解的產品架構，對應《用戶體驗要素》中的「結構層」。架構分2個層面，1是物理架構，2是邏輯架構，舉個例子，比如一個樓盤，物理架構：樓盤→期→棟→單元→樓層→房號→房間
邏輯架構：
- 指示系統
- 中央空調系統
- 水電氣網路系統
- 進水排水系統
- 監控系統
- 房屋結構系統
- ……
產品也是這樣的，物理架構：頻道→頁面→模塊→元素
邏輯架構：登錄註冊系統、導航系統、搜索系統……所以，我認為產品架構能力就是指這2方面是否考慮周全並架構合理。個人覺得產品架構就是產品願景、產品功能的具體物化體現，根劇信息的同質性、結構的聚合性、操作的可行性、交互設計的原則性以及未來的發展等等來分解產品的一個過程，這是信息設計當中的從上至下複雜逐層分解的一個過程！
如何提升產品架構能力？ - Jeffery李的回答
作為一個新手，最近也在思考這個問題。不過得出的結論比較簡單粗暴，不知對錯，貼出來求討論。從理論的角度，我覺得上面的回答說得都很有道理。但是從我實踐當中的感悟，其實產品架構就是在充分理解產品用戶需求基礎上對產品數據流轉的邏輯梳理。可能太抽象，所以貼了上面那個回答裡面的內容，如下：
首先我對「產品架構」的理解，就是在充分理解面向用戶的需求之後，從0開始設計完整產品體系方案，並將其實現的過程。這裡面包括一個產品形成的全過程，包括數據層的資料庫表、後台數據處理平台和運營維護平台、前後端數據交互體系，前端的基礎產品框架等一整套系統的構造和運轉邏輯。這也就是所謂一個產品可以誕生之前所需的「骨架」。當這套骨架完成後，大家熟知的前端功能、數據介面等等實體性質的產品開發才正式開始。
有兩點可以概括產品架構的特點：
1. 架構最大的特點在於，眼中沒有產品形態的概念，只有數據流轉的過程產品架構的工作本質是在梳理數據流。如果梳理的順，那麼未來產品會做的非常順暢，用戶需要的功能可以快速實現，產品的穩定性也很高，同時可以有效支撐幾年甚至十幾年的業務發展。而界面只是對數據的窗口或者入口而已，那是未來各位前端產品經理或者後端產品經理考慮的事情。2.需要深刻理解不同崗位的職責，以及他們工作的內容，也要深刻理解最終的用戶簡單來說，如果開發、運營、產品、市場的目標都是打造好產品，那麼架構師需要考慮的就是如何讓這幫人打造出好產品。知乎經典問題「產品經理是否需要懂技術」，並不是需要產品懂寫代碼，而是理解技術對於實現需求時的優勢、劣勢、風險。同樣的對於運營、市場、銷售各個環節都是一樣的道理。
現在回到問題：如何提升架構能力？產品架構與傳統產品經理以用戶為中心的基本精神雖然是相通的（只不過這裡的用戶不再是公司產品的用戶，而是公司內部的運維團隊、產品團隊甚至是技術團隊），只不過因為系統的複雜程度和擴展性要求，比起做一個支付流程、做一個評論功能來說大得多，所以一般的產品經理很難有機會接觸到。除了產品經理的常規能力要求外，還有幾個重點感悟想單獨拿出來說說：1. 好奇心，主動性。比如負責做註冊的，至少可以接觸到註冊的數據存到了哪裡，怎麼入庫的，中間經過了哪些技術實現環節，增刪改查可能會有什麼場景，未來其他部門或功能哪裡會用到用戶信息，一般會有哪些使用維度等等。這是一個相對完整的數據流程了。理解數據流程後，再進一步思考業務發展點，比如未來運營部門可能會用到這部分數據做用戶運營，比如會有精準的運營內容推送，就涉及到數據關聯，那麼用戶數據這塊他們如何調用可以最高效合理。帶著類似的問題去和相應的開發或運營部門去溝通，不經意間也許就可以蹦出啥火星子來，領導覺得考慮沒準就讓你去牽頭搞了。。。不關心？那除了每個月的工資其他都和你沒啥關係了。。。不主動，上哪兒知道這些東西去。。。2. 對於養成考慮極端情況的習慣。現在的產品經理設計功能的時候，都是正向思維，正常場景下沒有問題，但是對於一些極端情況很少考慮。這也是開發讓產品懂技術的一個主要原因。int不能為空值，最大數量上限多少，主鍵這些基本的概念如果產品懂一點的話，未來產品的穩定性可以大大增強，需求返工的概率也大大降低。而這些細節往往是資料庫架構、介面規則制定時必須要考慮的。3.一定要懂數據一定要懂數據，一定要懂數據，一定要懂數據。只要能把一個產品還原回一個動態的數據形態和流轉過程，就可以去架構師的副本去練級了。
由於本人做的是B端產品，也許與C端產品的形態和產品模式差別較大，但是我覺得歸根結底任何產品都是一堆數據加上一個與用戶進行數據交互的體系。所以做產品架構，本質上最核心就是數據的架構。
歡迎拍磚，不過還是。。。輕點兒。。。架構是關於一個系統由哪幾個子系統或模塊構成，以及各模塊之間的關係的設計。
好的架構能夠通過盡量少的修改而適應各種變化。
比如UNIX的架構：
產品的架構分為五個層面：
- 戰略層
- 範圍層
- 結構層
- 框架層
- 表現層
- 我們要通過這個產品得到什麼？ 產品目標
- 我們的用戶要通過這個產品得到什麼？ 用戶需求
這兩個問題必須在範圍層結束之前解決，不然你的產品從開始就已經偏離了主線，我想這個產品離著失敗也就不遠了。
在這一層，我提供一個方法論：可以從四個方向去想產品：- 第一點：藍海市場，我們發現了強需求（佔先機）
- 第二點：紅海市場，我們有天然的優勢（占天賦）
- 第三點：藍海市場+當前弱需求（超前佔位）
- 第四點：紅海市場+自身無優勢（被迫阻擊）
如果做前兩點的產品，可以說是幸運的，也是相對容易做出成績的，這裡你的天賦可以說是技術、平台等等。如果是藍海市場而且目前是弱需求，可以這麼說這個產品超前了，但不是說天馬行空，在目前來說只是弱需求。（比如從目前來說，可穿戴設備領域，智能硬體領域。）如果是紅海市場而且沒有優勢，但是如果不做原本業務就會受到影響，甚至傾覆或者對未來的業務拓展造成了很大的阻礙。那麼，硬著頭皮也要做。（比如阿里巴巴做來往，以及支付寶改版中的9.0版本）
在這一層還要考慮的是在用戶頭腦的品牌形象，這是很多大公司在拓展新業務的時候，需要想到的事情。因為當一個品牌在人們心中根深蒂固的時候，往往會產生下意識的映射。這樣對你的新產品的推廣起不到好的作用，因為人們會覺得你不專業。 此外，在這一層一定要將「用戶」搞清楚：- 「用戶是誰」
- 「用戶的需求是什麼（根本需求）」
- 「用戶細分」
- 」創建人物角色「
最後，戰略是可以演變和改變的，它貫穿於一個產品的始終，它是產品的初衷，也就是上面所說的產品的靈魂。
範圍層：這個層面上，我們要回答這個問題：我們要開發的是什麼？- 從功能型角度來考慮，我們需要考慮功能規格。
- 從信息型角度來考慮，我們需要考慮內容需求。
這兩者是血肉關係，你中有我，我中有你。正如」知乎「是一個UGC的產品，其中一定要有一個內容管理系統，在系統中要有編輯，審核等功能。在功能需求方面，我們往往會會用到一個詞-」場景「，他的意思是通過想像我們的用戶將會經歷什麼樣的過程，我們幫助他順利的完成這個過程的潛在需求。
在這個層面上，我們要寫一個熟悉的文檔，叫prd文檔。關於prd文檔怎麼寫好，這裡不再贅述。結構層： 在這個層面上，逐漸由抽象向具體轉變。在這裡最關鍵的就是」理解用戶「-理解用戶的工作方式、行為和思考方式。將這些轉化為知識，注入到我們的產品中。在交互設計方面，要注重邏輯，模型。在信息架構方面，要注重內容的管理，分類和順序。框架層：- 界面設計：比如說用什麼控制項表現，哪塊需要重點呈現（大大的按鈕）。做界面設計時，要遵循大多數人原則。建議大家去看看人機界面相關的書籍。
- 導航設計：這個要解決的問題就是要清楚的告訴用戶，」你在哪「，」你能去哪「。」你怎麼去「。（現在大家都在用搜索啦，首頁頂部都會有一個大大的搜索框）
在這裡提一句，在這裡還有一個老朋友就是，我們要做線框圖。（建議不加多餘色彩，不然容易被吐槽，用黑灰色）
表現層： 這一層也就是感知設計。大部分是視覺方面的，也會有聽覺、觸覺等方面（比如聲音、震動）。這個也就是我們產品的」顏值「。這個方面產品經理要多與我們的設計師溝通啦，充分激發設計師的想像力。這就是平常我們所說的-」性感的產品「。本文的大體框架來自：用戶體驗要素 (豆瓣)，向大家推薦本書。我的理解與前面的幾位可能有些不一樣。總覺得用「生態」一詞概況產品架構，強調要多實踐、要做個多少年等等把產品架構說得太玄乎了，產品架構應該且必須是可以方法化、技巧化。
所謂架構，就是對架構的對象進行合理的抽象，其結果是讓架構的對象更高效、更簡單、更易用、更易變。簡單說，架構就是為了：簡單、高效。
架構不是完美存在的結果，是一個不斷改進優化的過程。但是在每個節點上，都有好壞多少之分，這也是架構能力的體現。
產品架構的對象就是產品的商業需求以及用戶需求。如何讓滿足產品兩個需求的產品設計更加簡單、高效的規劃就是產品的架構。這裡有兩個重要的目標：1、滿足需求高效簡單；2、產品設計過程高效簡單。
產品的架構需要考慮的是與產品相關的各種影響因素，包括：用戶需求、產品戰略/商業需求、開發資源、市場運營人員等。這些因素都是在不斷變化的，一個合理的架構是要爭取儘可能能夠採用最簡單的方式去應對這些變化。而細分開來，產品架構應該包括兩個重要方面，即：需求架構和設計架構。需求架構更多的是業務架構，即把用戶需求、商業需求、業務流程在產品層面做個合理的組織和輕重緩急的設計。這也是產品架構最主要的事情。而設計架構，則是在產品設計時，保證產品在設計層面的通用和可重用的元素一致，是個更細節的層面，提高設計效率。
上面可能有點概念化，這裡舉個例子：
新浪微博的Page化戰略，在產品層面，就是一個架構的設計過程：將人、機構、興趣、地點等事物都對象化成Page，並且將Page的關係梳理成贊、關注、訂閱三種關係。在這種產品架構下，如果要把微博上用戶正在看的書的信息整合，那就很簡單：書的Page；如果要把用戶對於「產品架構」這個話題的信息整合，那就是：」產品架構「的Page……很簡單的實現了以不變應萬變！這樣的一種架構，所帶來的好處是：圍繞微博的生態不再是之前搞的那些微群、微吧、微刊、話題等這些完全脫離微博的另外一個孤立的產品，而是現在的一個一個Page類型。這樣滿足用戶、商業需求更簡單了、產品設計也更簡單了，這就是產品的生態：不是把孤立的產品鏈接起來，而是通過產品架構組織起來。這種簡單帶來的高效就更不用說了。當然這不是說微博的Page化的產品設計做到上述的架構就完成了，而是要在上述大架構的基礎上，去細化一個個細的架構，比如：Page的要素有哪些，Page的產品形態有哪些，這都是進一步的抽象，也是更進一步的架構。同樣的分析，在豆瓣的產品上，也是一樣的：小組 + 單頁面的讀書、電影、同城……
奧卡姆剃鬚刀法則同樣在產品架構設計中適用，越簡單的架構越有利於產品的生長。
其實產品架構和技術架構沒啥區別，只是架構的對象不同而已：前者架構需求和設計，後者架構硬體、軟體和數據。產品架構做得好，會有利於技術架構，同樣也就提高了開發的效率。產品架構和技術架構如何協調、配合這個就是另外一個話題了。
--------------------看了問題的描述再來補充一下如何具備這樣的能力------------------------------我一直希望在產品經理這塊相關的能力能夠具體化，別再是那些什麼邏輯能力、溝通能力、文檔能力、學習能力等等這些放在什麼崗位都或多或少的需要的抽象能力。所以對於這個問題，我將會從如何去鍛煉這種能力的具體方法去回答：1、系統地學習信息系統分析的方法和技巧。這可以培養抽象化能力，同時理解業務流程、產品設計、系統開發三者之間的關係。有相應的教材，是某些專業必修的一門課。2、產品調研中，將產品架構作為一個單獨的部分調研。現在很多產品調研報告中，只是從產品現狀、功能點、產品形態等方面去調研，忽略了產品架構的調研和分析。這也是很多產品只能抄個表面，抄不到本質的一個原因。沒有分析透產品架構，很難去理解一個產品的內在業務邏輯。3、任何時候，要注意產品架構來自於需求，杜絕過度化架構，簡單的才是好的。私以為
產品的架構
1.首先面向你所要進入的行業或市場，面向你當下模式以及對未來模式的生態是個什麼樣，產品是應該預見未來 場景化未來，理論來講沒人能準確看到未來，但這並不限制我們最大化的去預見設想他；這樣對於你下面的信息架構和系統層面的邏輯架構心裡會有點底；在造商場的時候能預見需要預留地下車庫；萬達一期在北方造的大商場好像因為沒有對廁所合理的規劃，整改的成本甚至高於重建，於是推到重來；
在造核心地段的公路的時候採用8道這樣的預見可能還得評估到這一天到來的時間成本和你當下的整體預算成本；能預見和你當下是否要為這個架構預留或者進行相應策略，還需要對當下資源，時間成本，市場存活周期進行一輪綜合評估，可以想像不去預見不能預見對於未來發展的瓶頸...
到產品層面來說預見性的產品架構設計可能能減少你在新增某一個大功能項的研發成本、調整成本、時間成本、維護成本...
2.其次面向用戶得產出清晰的 信息架構，即用戶便捷快速的找到自己最想要的
這裡邊當然用戶體驗因素占很大比重，比如功能入口的重要性比重，用戶所適應的同一層選擇數量等...
3.與技術架構其實都在實踐一類原則可擴展、易維護、可持續當然技術架構還得承擔更多。性能方面、分割減壓方面等等...假設本話題限於互聯網、軟體領域。學過編程的人可能會比較容易理解「架構」。事實上，產品的設計和軟體的設計有很多相通之處。比如大部分產品的架構設計可以參考編程中的「面向對象」思路。比如很多產品功能的處理可以用分級思想解決，類似於軟體設計中的cache。還有很多其他的軟體設計思路，也可以指導產品設計：比如張小龍比較看重的分類，RISC思路對交互設計的指導意義等等。
說下：【面向對象的產品架構】，英文名暫定為OOPA
涵義：與面向功能過程的產品架構思路相對，面向對象的產品架構思路的核心，是認為用戶使用我們的產品，不是為了做某些事情，而是為了處理某些事物。在面向功能過程的產品架構思路下，用戶使用產品就是為了完成一系列的行為。而在面向對象的產品架構之下，用戶使用產品，是為了處理一系列的「對象」。這個對象，指的是用戶天然認知到的實體事物，或者普遍理解的一些抽象概念。OOPA操作步驟：
第一步：提煉對象，找出用戶需要處理的對象 我們假設所有產品都是幫助用戶來處理一系列的「對象」，注意，這些對象都是用戶心目中的具體事物，應該是一系列名詞。「幫用戶裝逼」這種需求，就不算是一個對象，最後一個字兒才是對象！搞清楚這些對象的關係和特性之後，產品的架構就呼之欲出了，就好像編程時大部分類和介面已經想清楚了一樣。 比如： 媒體類產品幫助用戶閱讀一條一條消息，所以媒體類產品都在折騰消息的屬性和關係。 比如陌陌幫助用戶找到可約可聊的人，所以陌陌在第一屏直接給出附近的人。 比如360安全衛士，幫助用戶處理病毒、木馬、各種系統故障，所以，第一屏就讓用戶體檢，把這些對象的具體實例找出來。然而很多用戶不關心具體某個小問題，只關心整體上系統的情況，所以，做一個體檢的分數出來，來具體表徵電腦的狀態。用戶操作引起分數的變化，對應的，引起了電腦的狀態變化。 比如facebook，幫助用戶處理其社交關係，再深入來說，就是幫助用戶獲得朋友們的消息，所以其主屏就是feed。 以微信為例： 早期微信實照搬了類似競品和手機系統的簡訊會話設計，將「會話」作為用戶主對象提煉出來放在第一屏，是非常正確的選擇。回顧下整個業界對消息對象的提煉過程：最早期：我們按照時間順序收到一條條的郵件和簡訊；後來：gmail做出了會話郵件；再後來：早期智能機做出了簡訊會話，並且按照每個會話的最新一條信息的時間進行會話的排序，非常合理。對會話對象的提煉，是整個產業的進步，不斷的走到更加符合人們需求的程度，也更加接近人類的心智模型，似乎會話原本就是人類大腦里產生的東西一樣。第二步：整理對象的分類和繼承關係
張小龍說產品就是分類，有些誇張，但是對用戶需要處理的對象，進行正確的分類，是做好產品架構的關鍵步驟。 對象的分類有的極端複雜：參見淘寶的類目系統。有的也比較清晰簡單：比如陌陌的附近的人：男人、女人。現在陌陌已經進一步細分了。 分類完成之後；進一步進入對象的繼承關係梳理； 從對象的分類開始，產品架構已經直接作用於用戶界面和技術邏輯了。對象的繼承關係，對用戶界面和技術邏輯的影響已經比較重大了，直接影響到後續設計迭代和技術迭代。 繼承的涵義：對象A屬於對象B的一個子類，A具有B的屬性和行為，但是有某些特殊的屬性和行為B不具備。 比如附近的女生是附近的人的一個子類，在附近的人的基礎上，她的特徵屬性和行為介面有何特殊之處？比如空調屬於電器的一個子類。第三步：梳理主要對象的屬性和行為
此步驟對產品架構和技術架構的分期實現非常重要。 用戶使用軟硬體產品，就是為了處理某些對象。 他們需要增刪查改對象的屬性，使對象執行某些行為。 這些屬性、行為介面的重要性、需求強烈程度、需求頻率，屬性和行為之間的關聯關係等也需要梳理清楚，以便為具體的產品設計和技術方案設計提供指導。 第四步：根據對象分析結果輸出產品方案設計、技術方案設計產品架構 類似於一座商業小區的整體布局和生態結構，小區中其中一棟樓房相當於某個功能，內部結構相當於系統結構，這是和技術的「系統架構」的區別。
考慮的層面當然是「生態」，不同於系統結構的「」面向對象、模塊化，差別還是挺大的
如何具備：首先工作10年再說吧我擅長舉例，就舉例說下我心目中的產品架構。至於為什麼要舉例說明，因為我個人覺得每個人心中的產品架構都不太一樣。
我覺得，產品如菜，每個產品都是一道小菜，而把各類小菜通過一些規則組合在一起了，則變成了一桌菜。
當然，一桌菜，有組合的好的，也有組合的差的。這裡的組合規則，就是產品架構。
為什麼？
因為每道菜都有不同的口味、效果、作用，而不同的組合搭配也可能產生不同的效果，比如為什麼一些菜叫開胃菜？一些菜叫填肚子的？而這其中，難道僅僅是很隨意的搭配嗎？我想應該不是的，想必大一點的酒店在推出一些酒席的時候，那些菜的組合、上菜的先後順序都是有一些道理在裡面的。
而我個人感悟的產品架構，也僅僅是這樣，要有大的產品眼光，同時也應該知道你的這個產品和別的產品應該怎麼樣配合（如果一個公司只有一個產品，那就要挖掘出對這個產品有用、有幫助、或者幫助了其他的產品的東西來進行揉合），而且，同樣也應該考慮到這個產品中的一些功能上線的先後順序，因為很多產品就是因為某些東西上線時間錯了，得不償失。
很多朋友可能會問。怎麼樣去了解那麼多，我感覺，調研是最好的辦法。所謂架構，是支撐、是邊界、也是包容。大多數人都能知道什麼是支撐，但明白邊界在哪的人就十不存一了，能理解包容的，簡直百中無一
我理解的產品架構是需求的歸類/組織方式，而擁有產品架構能力的PM應該具有對用戶需求的洞察力、抽象能力和拆分能力。
舉個大家最熟悉的產品例子：微信
首先，思考一下微信的本質是個什麼東西？滿足什麼用戶需求？
我認為微信的本質是人獲取信息的主要工具/渠道。移動互聯網時代幾乎人人都有微信，而微信的註冊方式是將用戶ID與手機號綁定，基於手機號信息的真實性，可以認為微信帳號是移動互聯網時代的用戶ID（個人身份標識），即用戶與移動互聯網上的信息發生交互的主要方式是用微信帳號登錄微信（即使用微信這個信息獲取渠道）。再次，想清楚微信的本質是什麼之後開始考慮做哪些事可以建立這個信息獲取渠道？
既然是信息獲取工具，類似地想想我們平時可以通過什麼渠道獲取信息？仔細想想，信息來源可以簡單抽象和分類為人和非人的信息源，而非人的信息源本身又可以抽象為信息。那現在好了，用戶藉助某一信息通道獲取信息的行為（用戶使用微信）可以看作【人】和【人信息】發生了某種交互，而讓用戶感知到發出動作之後的有效反饋還要明確通道兩端的聯繫/規則。綜上，我們把建立微信這件事拆分為四個需求大類：人即帳號體系（帳號、用戶資料、許可權控制、錢包...）、信息即信息的組織形態/存在形式（文本、圖片、語音、視頻、表情、紅包、訂閱號文章...）、人與人的關係即關係鏈（分類標籤、拉黑好友、微信群好友、附近的人...)、人與信息的關係即通知狀態(Push、時間戳、未讀信息/朋友圈小紅點...)。所以，產品架構應該是對需求抽象和分類之後自然產生的。產品經理需要看清解決問題的關鍵路徑合理地進行合併沒必要的支路，而路徑應該是【最短】且【完全能解決目標問題】的。
———————————————————————————————————————————
那問題來了：為什麼要做產品架構？一個好的產品架構對解決用戶需求有什麼好處？1、讓產品看起來簡單易上手。當一個產品做大特別是開始商業化之後一定會有各種各樣的需求蜂擁而至，一個好的產品架構可以使產品功能不斷增加後並不顯得臃腫，給用戶的感覺依舊是看幾眼就知道這個App是用來幹嘛的；而一些低頻/個性化功能可以隱藏在更低級Tab中卻不會使用戶找不到，因為背後的需求總是和場景相關。2、可擴展性。技術架構往往重視可擴展性和高效的代碼復用（純YY，不懂技術哈），產品架構道理也是一樣的。好的產品架構的可擴展性在於讓上線新功能後不用此功能的用戶並不會感到被打擾，因為並不會改變產品解決主要問題的關鍵路徑，不關注新功能的用戶可能並沒有覺察到產品的改變，用戶體驗與上一版一致。同樣，好的產品架構在調整產品規則時只需要動某一個模塊的規則，可以有效減小開發量，提高迭代速度。3、影響產品留存。我認為用戶體驗就是用戶需求，需求即體驗，將用戶的最主要訴求解決得最好的產品擁有最好的體驗。好的需求分類/組織方式在解決用戶的主要訴求上一定有不錯的產品體驗，這樣的產品即便很多細節的體驗並不完美但依然有比較好的用戶粘性。最典型的例子應該是百度貼吧（貼-吧-人）。最後，PM怎麼提高產品架構能力？
這個我也沒想清楚，產品架構能力應該天分/積累都有關係，可以肯定的是同上面我提到的3種產品能力（洞察力、抽象能力和拆分能力）呈正相關。________________________________________________________________________________補充上面提到的一個觀點：為什麼非人的信息源可以抽象為信息，而人不能？人和信息這兩種信息源的區別是什麼？我認為人做出動作是有目的性的，人發出交互請求是為了獲取信息，而此時請求接受方也是人的話他發出反饋動作後也是希望得到反饋的（不過微信並沒有陌陌之類IM已讀狀態提示），因此人和人可以一直聊下去（人和人交互），而一般人在朋友圈沒有小紅點之後並不會一直刷下去（人和信息交互）。顯而易見，也並不存在信息間的交互，信息的流動方向是由人的交互請求動作決定。戰略性架構
功能架構
信息結構
交互架構
視覺架構
架構是把孤立的元素系統性的組合在一起，以達到一定的外部目的。
何謂系統性？系統泛指由一群有關聯的個體組成，根據預先編排好的規則工作，能完成個別元件不能單獨完成的工作的群體。系統性即是群體間能夠有效協作的規則和方法。如果是非系統性的組合，那可以叫堆砌、可以叫排列、可以叫混裝、可以叫......只是無論如何不能稱為架構。因此，產品架構就是把多個不同的孤立的產品系統性的組合在一起的，以達到一定的市場目的。比如百度搜索、千千靜聽、百度殺毒、百度相冊等產品彼此之間完全沒有關係，但通過搜索掙錢、音樂相冊增加粘性、殺毒建立競爭壁壘的產品架構設計（管中窺豹而已，實際上的架構要大得多），穩固其整體盈利能力。個人認為：產品架構這麼多年的發展已經是一個很成熟的概念，不需要太多的解釋，做好產品架構設計，只需要考慮到以下幾個點就夠了。
產品是解決問題的方案，解決大問題，需要一系列產品解決很多小問題，這些產品如何設計，搭配，每個產品如何運營，運營優先順序分別是什麼，所有這些可以叫產品架構，我覺得最好叫產品規劃。
老闆說的就是架構，你說老闆三天兩頭改這改那的你提個架構出來有個毛用
這裡我用歐賽斯的一個產品品牌架構的案例給你做一個說明。
1、產品開發背後的商業邏輯
產品即營銷。
這個是新時代的商業邏輯。
這是一個供大於求的時代，一個消費者主權日益升級時代，這是一個分享及口碑佔主導的時代的商業邏輯。
一個偉大的產品是新時代成就品牌的第一步，在新時代人人都是產品經理。
在貨架上完全不缺產品的情況下，產品該如何開發，如何包裝呢？
用顧客需求定義你的公司，無可置疑的是：任何一個企業之所以能存在，是因為社會需要它。而任何一個企業能夠做的優秀，是因為它比其他企業有效效率地滿足社會需求。產品要解決一個社會問題，或者說是解決一群消費者的痛點，用需求來定義產品。
產品開發的第一步在於發現客戶的需求，或者潛在需求，或者說引領客戶的需求；產品打造的第二步在於定義產品利益點及客戶價值及產品的自我表徵價值；產品的第三步在於構築產品的自傳播能力。
在消費升級的大背景下，每一款產品不但需要一個購買理由，而且需要給消費者一個自我表徵的價值，對於新消費者而言，選擇的某一樣茶具就已經隱含了TA的品位，隱含了TA的審美趣味、生活方式及精神氣質，產品不但是做為一個內容物而存在，也以情感屬性而存在。
產品的本質就是購買理由，開發產品就是創意購買理由。產品的價值不是我們去創造，而是去發現。包裝設計是對產品完成定義，從這個角度來講，包裝設計甚至是產品開發的起點。因為先有價值定義，後有產品。
產品第一個層次核心產品是指產品能夠滿足消費者怎樣的需求；第二層次為有形產品，即產品實物及產品包裝；第三層次為期望產品，即滿足消費者核心需求的基礎上，能給消費者帶來的額外利益，比如有效地滿足了消費者自我表徵的情感需求；第四層次為附加產品，即產品代表的思想理念、生活方式、產品服務、內容分發等都是產品的一部分，都在構建產品的獨特性及不可替代性。第五層次為潛在產品，即未來還可以增加及豐富的產品內容。
一個完善的產品策劃應該包括以下內容：
一個多維產品例子（歐賽斯）：
2、定義消費場景
「初學者在設計產品，而大師在設計場景」。
那麼如何精心設計一個場景，讓它內容更加豐富呢？
有內容
讓產品不再是產品本身，而是提供意義、故事和內容。例如：「智能體質分析儀，也不僅僅是一種測量體脂率的工具，而是宣揚一種意義」，「我們對脂肪的態度也是對世界的看法」，從而催生了「脂肪派」、「脂肪主義者」這種亞文化族群。
任何一個精心設計的「場景」，必然是有內容的。人們真正消費的，可能並不是你的干炒牛河，而是其背後的故事、充滿談資的製作工藝以及吃一盤牛河所代表的意義。塑造場景，先多講講故事吧。
有遊戲
你應該在線下的場景中設計更多的遊戲，以此來豐富你的場景，讓用戶「玩起來」。
如優衣庫在自己的門店中組織「搭出色」的活動。在門店中設置一個巨大的鏡像屏幕，用戶站在屏幕前，屏幕會自動把人像扣出來加到屏幕的背景圖片中（比如巴黎夜景）。
有跨界合作
專車不僅僅是一種出行服務，更是塑造了一種乘車場景，這個場景自然要好好利用。易到跟單讀空間跨界合作，推出「單讀車」，讓用戶在車上讀書。還可以跟花色優品旗下的午睡神器「睡小寶」合作，推出睡眠車……
有社交
設計你的線下場景，那麼怎麼能少了社交功能？你可以為你的場景加入各種各樣的社交屬性。小豬短租提倡「有人情味的住宿」，讓旅客直接住在當地的人家，感受本地的文化。
有分享
要設計一個豐富的場景，就要刺激人的分享需求，讓所有用戶可以「表達自己的想法」，而不是坐在那裡沉默。
有用戶反饋
比如TFboys的成功就是深諳此道——他們甚至會按照粉絲的建議去修改髮型。 EXO的鹿晗在是否單飛等重大問題上，也都參考粉絲的意見，讓粉絲投票。所以，既然要豐富場景，讓你的產品、店面更加互聯網化，比如把品牌的控制權教給用戶。
3、包裝設計的本質
包裝的本質是購買理由及陳列效果：著名的杜邦定律指出，大約63％的消費者是根據商品的包裝和環境進行購買決策。
包裝設計的思維不是平面設計思維，是產品開發的思維。
4、產品線開發的方法
在一個產品為王的時代，產品戰略是企業戰略的核心部分，應該基於企業競爭戰略制定有效的產品戰略，產品戰略應該至少包括以下部分：
產品線規劃
產品推出次序及每隻產品的戰略任務
產品系列開發的內在邏輯
4、產品自帶流量
產品矩陣
那麼怎麼辦呢？這就需要開發更加高頻、低門檻的產品，從而形成一個「漏斗」型的產品矩陣。比如免費的公眾號內容（也能最低成本解決技術問題）、免費或者低價的社群等，都相當於補充了原有產品頻次不夠、門檻太高的問題。
產品迭代
既然我們都知道「公眾號」「社群」等本質上不是營銷引流方式，而是產品，就要像真正的產品一樣對待它們。總之，「迭代精神」就是「這次不是最好的，但是總比上次更好一點。」同樣，你的所有「產品」也需要不斷迭代，周期性地比上次更好一點。
一個構建完整的多維產品公司，可能就會變成一個漏斗型的產品矩陣，從免費、大量的消費者一層層過濾到最高凈值消費者，並且每一層都有不同的產品角色，每一層都是共同服務於一個消費者需求。
產品內容分發
產品的內容力是企業核心能力。是基於用戶眼球的爭奪，內容是性價比最高的流量，承載的是新客獲取、老客留存、品牌建設與提升的諸多功能集合，我們要藉助微信+、頭條+、短視頻+、直播+、VR+抓緊形成內容生產與分發的能力。
歐賽斯渴望與眾不同。
歐賽斯渴望成為立意高遠、格局宏大、思維深邃、洞察深刻、商業敏銳，渾身上下又充滿了創新的氣息的公司。
歐賽斯研究的是新時代背景下，面向新消費者，在媒體環境下的品牌及營銷突破之道；
1、泛90後消費群體崛起，消費升級的背景下，消費者主權大幅度提升背景下的品牌及營銷突破之道；
2、 品牌傳播發生深度變革，傳播主陣地從電視端向移動端轉型時代背景下的品
牌及營銷突破之道；
3、 品牌傳播背景噪音指數級上升，消費者品牌接觸點大幅度增加的時代背景下
的品牌及營銷突破之道；
一個以產品為中心的時代坍塌了，一個以消費者為中心的時代到來了，世界的變化比想像得還要快，商業模式迭代的速度正在加速，一個通過新思維、新策略、新創意、新營銷用突破性的想法在新時代創造大品牌，成就新冠軍的時代到來了，這就是歐賽斯要做的所有事情。
歐賽斯不認為自己單純是一家策劃公司，或者說是一家創意公司，或者說是一家數字營銷公司，歐賽斯更願意認為自己是一家戰略與技術驅動型的品牌諮詢創意公司，歐賽斯認為當諮詢顧問懂得創意的時候是偉大的，歐賽斯認為當品牌開始擁抱數字化手段的時候是偉大的，歐賽斯是認為當嚴謹的商業邏輯與腦洞打開的創意發想相結合是偉大的，歐賽斯認為系統化的品牌諮詢與最前沿的技術相結合是偉大的；歐賽斯立志於用前瞻性的視野、時代發展的高度、對商業深刻的理解及洞察構築歐賽斯獨一無二的方法論體系。
歐賽斯渴望用領先的思想、正確的方法及多元化優秀的人才武裝自己，歐賽斯努力工作、深度學習，歐賽斯開放、共享、迭代、跨界，建立一個「以奮鬥者為本」的學習型組織，打造一個「不斷迭代、兼收並蓄」自我更新的知識管理體系。
歐賽斯認為要達到以上目的，需要實現統一及多元矛盾統一。統一即六大統一：價值觀統一、文化統一、方法論統一、形象統一、管理統一、財務統一；多元即人才多元、團隊多元、策略多元、創意多元、風格多元、設計多元。
歐賽斯認為思想是戰略、策略、創意及設計背後的根本源動力，思想產品及成功案例是歐賽斯的追求目標，也是本質。
歐賽斯如何做事
1. 以始為終：目標為導向
2. 三大思維基石：戰略思維（Strategic Thinking）、創意思維（Design Thinking）、數字思維（Digital Thinking）
3. 銷售力：短期、中期、長期的盈利能力
4. 一件事：頂層設計只能有一個主腦，每一個驅動引擎都需要系統化打造， 一體化成型。
5. 做正確的事，把正確的事做好：一個是頂層設計，一個是執行，兩手抓，兩手都要硬；戰略上藐視敵人，戰術上重視敵人。
6. 跨界及融合：創意能力最強的品牌戰略公司及營銷能力最強的數字創意公司。
7. 開放及迭代：開放能打敗封閉，快速迭代將會打敗一成不變，這個是我們的做事方式，甚至是我們的信仰。
8. 正道誠信、真知灼見：思考、說話、做事的出發點是純粹善良的；真知灼見；至誠勝於至巧。
產品架構，是將產品功能分配到產品物理構件的配置方案。
簡而言之，產品架構是 :
1.排列各個功能元素
2.將各功能元素映射到相應的物理構件
3.對各物理構件之間的介面進行定義
產品架構的目的：
定義組成產品的基本物理模塊應該完成的功能以及這些模塊之間的介面。
產品架構主要分為：
1.模塊化產品架構
2.集成產品架構
3.混合產品架構
推薦閱讀：
※作為產品經理，如何培養考慮周全的思維？
※如何分析評價 QQ 安裝時默認捆綁軟體的行為？
※開放平台的產品經理應該多注意哪方面的東西呢？
※在未越獄 iOS 系統下實現特定功能，有哪些 「機智」 的做法？
※什麼樣的產品流程才是好的產品流程？