什麼是產品邊界

❶ 產品觀念的兩個錯誤是什麼

一、被用戶牽著走

我們都知道，產品是為了解決某個核心問題或者滿足某個核心需求而誕生的。所以明確產品設計的目的很重要，想清楚我的產品到底是為了解決什麼問題。

很多的朋友都在做B端的行業解決方案，說好聽一點是用數字化的手段助力行業升級，說直白一點就是外行指導內行，很多時候就被內行牽著鼻子走。

1. 真實場景

友人A所處行業是房產估價，傳統做法是通過可量化的公式對房產價值進行評估，但公式本身非常復雜，算式項很多，估價師做一份估價報告要做很久。

針對這個問題，他們給出的解決方案是：一個報告自動生成功能。通過後台的特殊配置對計算過程做簡化處理，用戶只需要幾次簡單的點擊就能夠生成准確的評估結果。

但這個功能給客戶的感覺就是：不夠專業。他們很難接受這么復雜、專業的評估報告就用滑鼠點幾下就出來了。收到用戶反饋後，他們又增加了一些「專業性」上的考慮，增加了一些花里胡哨的流程讓報告顯得更專業，效率大打折扣，最後讓這個功能變成了一個雞肋功能。

2. 分析

這種情況對應的主要問題是：產品的設計目的不明確，沒有明確產品為客戶所解決的核心問題是什麼。

出報告這個環節的核心痛點就是效率問題，高效是當前場景的第一設計需要。從整個解決方案的呈現，每一個環節和交互，都是在提高整體的效率。能夠一步得到的結果，絕不會為了照顧用戶的心理需求，讓流程變得更復雜。

在這個案例中，高效與專業顯然不是互斥的需求，用戶想要的是既高效，又符合專業需要的評估報告，所以我們思考的出發點是在合乎專業的基礎上提高生產效率，所以不見得需要在流程上讓報告更繁雜。

做tob的產品，我們面對不同群體的訴求，每個群體提出的訴求在他們看來都是實際要解決的並且非常重要的問題。這時候如果業務流程再復雜一些，分支情況再多一些，很多產品經理直接懵逼，喪失思考能力，用戶說啥就是啥了。

3. 雞湯

面對這樣的問題，身為產品經理一定要保持獨立思考，不要對客戶的意見進行盲從，透過現象看本質，找出現這個問題的根源。而不是拆東牆補西牆，想不清楚，只顧解決當下的問題，這樣的產品慢慢會做成四不像，成為「臃腫難懂、抱怨連天」的代名詞。

道理很簡單，但是在實踐的過程中容易隨著產品的演變發生變化，這種變化有好的一面也有壞的一面，需要產品經理們審慎把握好尺度。

二、需求范圍不明確

靈魂拷問：什麼樣的產品才能稱之為好產品？

如果好產品的定義是：解決用戶的問題，那麼我們的產品是不是解決越多的問題就代表越往好產品的方向發展呢？

1. 真實場景

友人B所處的是垂直領域的CRM產品，他們的產品已經做了很長時間，相對成熟，在業內也算是小有名氣。但是他最近做得很不得勁，因為他總感覺產品做到一定程度以後就沒太多內容可以做了，好像做的全是一些邊邊角角的需求。

而且用戶提的需求嚴格來說也不能算是CRM產品的范疇，例如增加一些知識庫和企業通訊之類的功能，這讓他很迷茫，產品的邊界到底在哪裡，這種情況下，什麼需求應該做什麼需求不應該做？

2. 分析

產品的邊界性是某個階段內對產品的約束，可能是一個季度、一個版本甚至一次升級的約束，讓我們在這個邊界范圍內去解決一些需求。做C端產品時經常會提到需求鏈，即用戶順延場景延伸的需求。

當我們設計一款產品時通常抓一個點，解決一個核心場景下的問題。當產品逐漸成熟之後我們就要開始思考需求的前面是什麼，有什麼場景可以進行更廣度的覆蓋，實際上這就是產品邊界的延伸。

例如一款理財產品，當用戶出現買基金這樣的需求時，可能是因為客戶需要理財，再往深入去探索可能是用戶存在一次性大額消費的需求，這可能就是一款理財產品打通購物商城的緣由，所以對需求鏈的深入探索也是產品邊界擴散的過程。

邊界是會擴散的，隨著產品被賦予不同的使命而向外進行更多的擴張。

邊界擴散的方向是無法被預知或者被計劃的，再好的棋者也只能掌控三步以內的棋局，對於互聯網這個瞬息萬變的行業也是一樣，產品難以按照一條既定的路線去前行。

所以我們可以採用控制邊界的方式來引導我們產品的發展走向。階段性的目標要清晰、邊界要明確，什麼事情該在這個版本做什麼事情不應該做都有了更加明確的定義方式。

❷ 產品的定義究竟是什麼

上次回家遇到同學，聊起以前他校招的時給我投產品經理的簡歷被我刷掉的事情。我便問他一個我問過所有候選人的問題：你究竟為什麼想要做產品？同學回答我：」學長告訴我，產品經理入門簡單，啥都不會就可以干，而且工資很高！」

我不禁罵了句：」我*！」

後來我又在知乎上看到一個問題：「產品經理究竟是幹嘛的？「，看到長篇大論貌似很有用的回答，實在有些看不下去，就想寫一下我所理解的產品經理的主要工作究竟是什麼。

商業模式的產品定義這一塊得考慮相當多的內容，不光得深入到行業，還得深入了解經濟趨勢，政策風險等，才能較為准確的對產品有所了解。而商業模式在未得到驗證的情況下，是不能進行快速批量投入的。得先小批量驗證，驗證無誤，解決了批量推廣的瓶頸以後，然後再花大力氣去推。

所以我們總是說創新是一件很難的事情，更好的一種方式是直接抄襲然後修改，COC ( to china)就是這樣一種把在國外得到驗證過的商業模式，直接抄到國內，然後稍微進行改造一下的商業模式。這些成功的例子有很多，比如美團就是復制高朋的團購模式，人人網復制facebook，微博復制twitter……

❸ 從項目制到產品制（1）：確定正確的產品邊界

IT不是成本中心，而應該是利潤中心——這幾乎成為轉型企業的共識。實現這一跨越，從項目制轉向產品制，則是必經之路。

一直以來，業務與IT的關系是建立在職能分割的基礎上，無論直接或間接，IT作為收單的乙方來承接業務甲方過來的投資項目。但是，項目制的思維，以管理確定性驅動，強調計劃、預算、分工、人員利用效率，帶來了很多問題：

隨著組織的規模化越來越大，這些挑戰將越來越嚴重，成為組織應對不確定性、持續創新的嚴重掣肘。大多數IT組織都意識到了這個問題，在敏捷轉型的同時，也開始了由項目制到產品制的轉型。

產品制的思維和項目制思維最本質的區別是， 項目制是以確定性（IT要解決的問題是確定的）為基礎的 ，因而注重計劃、預算、執行效率（人力利用率）； 產品制的基本觀則是，IT所要解決的問題都是高度變化的，因此應該不斷挖掘客（用）戶的真正需要，持續迭代更新解決方案，一切以提供給客（用）戶的價值為目標 。

疫情當前，互聯網公司積累的響應力勢能引人矚目，美團"無接觸配送"從確定需求，到上線只要了24小時，一周內覆蓋到全國重點城市；騰訊從采購、到直接配送45000套防護服至醫院也就是3天左右的時間。這是長久鍛煉出來應對突發情況的「高響應力肌肉」——投資能夠持續創新的基礎平台和能力、以響應力和業務成效為導向、跨職能的團隊（從供應鏈到硬體到軟體全通路協調）、鼓勵團隊自主決策（讓一線聽見炮火聲音的員工直接做決策）、快速上線迭代優化方案。

對比於當前很多企業中的IT還在運行的方式——業務和IT完全就像是甲乙雙方兩家公司、規劃時主要看是否符合預算要求、是否能達成當前KPI、以「人均交付功能點」和「人員利用率」為績效、開發測試完全各顧各、領導必須通過層層審批需求文檔來獲得安全感——差距之大，上下立見。

大多數敏捷轉型的IT組織，理念上非常接受「產品制」。等到落地時，第一個問題往往是：我們這里有項目、平台、組件、功能特性、團隊......那到底怎樣算是一個「產品」？一個項目對應於一個產品嗎？一個團隊是一個產品嗎？一個大的特性能算一個產品嗎？「產品」的正確邊界又在哪裡？

在當前數字經濟上下文裡面，我們所說的產品肯定有別於傳統的有形產品（比如杯子、肥皂），我們先稱其為「數字產品」以與傳統意義上的產品相區別。那麼，怎樣才算是一個「數字產品」呢？

首先，我們認為，數字產品具有兩個本質特性：

如果具備了前兩個本質特徵，在業務定位、服務對象、表現形態、業務模式、渠道、范圍、生命周期，則可能具有不同的樣態。以一個大型金融企業為例：

由項目制轉為產品制，不是一個「革命」的過程，一夜之間城頭變幻大王旗，由若干個XX項目，變成了若干個XX產品（如果真地這樣，那多半是假的產品制），而且也不存在絕對的產品態——組織中總有一些本質上就是應該用項目來解決。

這種情況下，要落地產品制，需要有個逐步演進的過程：

所以，」如何確定數字產品的邊界「， 本質上不是」如何切（劃分產品團隊）「的問題，而是識別出戰略性產品，為這些產品配齊從需求到價值角度端到端的能力，構成真正的跨職能產品團隊 。

同樣，以如上的金融企業為例，首批可能識別出了10個左右的戰略產品，比如：

這10個左右的產品覆蓋了所有的業務定位類型：

從產品形態上覆蓋了系統應用、觸點應用、平台、API服務等；從產品生命周期來看覆蓋了從孵化到成熟期的四個階段（處於衰退期往往趨近於停止投資，所以不會是戰略重點）。這在第一期足以支撐在產品制實踐落地措施的方案反饋和驗證。

這些產品的團隊構成現狀總體來看分為三種類型，各自的能力配備措施如下：

這在真正落地中，即使在IT內部，當涉及到人員的調配、職責的調整，也會受到當下現實的各種約束和阻礙。這種配齊也可以先由」虛擬崗「和」虛擬團隊「（比如保留原職責崗位歸屬，但給定辦公空間，讓這些人坐在一起），逐步過渡到真正的跨職能團隊。不過無論如何妥協，都要先保證開發和測試歸屬於同一團隊。

當然，怎樣認知一個數字產品、怎樣識別組織中的戰略數字產品、怎樣識別戰略數字產品所需要的能力是簡單的，真正的落地挑戰還有很多：數字產品團隊，該有怎樣的工作流程和實踐？實踐如何一步步真正把產品制的原則落地？如何衡量數字產品管理的成熟度？數字產品的成效和進展如何度量？如何動態調整持續積累」高響應力肌肉「，如美團一樣？讓我們持續探討。

文/ThoughtWorks亢江妹 王汝佳

❹ 一張圖講清楚產品架構，手把手教你畫產品框架圖

什麼是產品架構圖

產品架構圖是產品經理用來表達自己產品設計機制的一張概念圖：

它將可視化的具象產品功能，抽象成信息化、模塊化、層次清晰的架構，並通過不同分層的交互關系、功能模塊的組合、數據和信息的流轉，來傳遞產品的業務流程、商業模式和設計思路。

由於產品架構圖通常用於比較復雜的產品項目中，目前介紹產品架構圖的相關書籍和資料極少（尤其是入門級別的資料很少提及），卻是設計復雜產品時不可或缺的文檔之一。

沒有資料的探索過程漫長且沒有方向，在終於有所沉澱後，我花了四周寫下了這篇總結，希望可以為你繪制產品框架圖時提供簡明的參考。

為什麼要畫

梳理自己對產品方向的判斷：

思考這張圖如何設計的過程，也是幫助你梳理「半年內自己的產品該往何處去、需求應該如何分期和落地、和其他產品的依賴&競爭關系是什麼、未來的可拓展性在哪裡」等問題的過程。

為技術&運營的輸出形成支撐：

當這張圖被設計出來後，按照產品架構圖的結構和路徑，項目的里程碑（RoadMap）就可以被清晰的拆解出來，同時項目成員也可以根據這張架構圖產出運營計劃、技術系統架構方案等強依賴產品方向的方案。

讓他人可視化的理解你的產品架構：

能較為清晰簡單的呈現自己的思路、明確自己的產品邊界、指明發展的方向，常用於在項目規劃或項目總結中進行演示，幫助不了解你的產品的人快速的建立對你的產品結構、功能、復雜度的認知。

何時需要畫

建議在復雜項目開始前寫：

當你要開始設計一個系統性、完整的需求時，如果跳過畫產品架構圖的步驟，直接開始畫原型、寫PRD、kick off，就很容易發生「改了又改」、「做了一版需求然後又推翻」的情況。

但「種一棵樹最好的時間是十年前，其次是現在」：

如果你的項目已經進行到一半，自己卻從未產出過這張圖，那麼就從此刻開始，按照下文的步驟嘗試為自己的產品產出一張產品架構圖吧。

如何畫

之前我們分享了【AR最全乾貨及資料】設計AR產品，你一定要看的總結 ，你可能對AR相關的背景知識已經有所了解。為了分享的延續性，我們來做一個大膽的假設*：

假設你是 微信-掃碼功能 的產品經理，有一天老闆把你叫到辦公室，一番鼓勵後拍著你的肩對你說：

「蘋果發布會看了沒？蘋果這么重視對AR能力的支持，我們微信也要趕緊把AR功能做起來。這是個Allen（張小龍）很重視的項目，你回去好好設計一下，明天來跟我過方案。記住，要能夠一炮打響，全民參與喔！」

啊，張小龍級別的項目啊！明天就要出方案，怎麼辦 ？

畫前准備

列出問題域

在需求初期，產品經理得到的往往只是一句比較模糊的需求描述，它們可能來自於老闆、運營或用戶。

直接把這句話作為核心產品功能是不恰當的，合理的做法是先把這個產品所有的問題域列清楚。

「問題域」是指自己的產品能夠解決的所有問題的空間集合。從核心需求出發，將所有當前需要解決、未來可能要解決的問題放入產品框架的范圍，能夠幫助你的產品架構圖擁有更高的可拓展性，在後續具備迭代和優化的空間。

以微信AR的需求為例，問題域是這樣一個集合：

詳細操作步驟：

1. 找到收到的需求中，跟產品形態、產品目標相關的詞句，去列出「XX的流程會是什麼樣」、「XX該怎麼達成」之類的問題，直到如果這些問題解決，能夠實現核心需求的方向和業務目標。

2. 去逐次尋找這些問題需求被解決的過程中，是否有其他要先解決掉的問題、或者其他跟業務相關的問題能夠被解決/改善。

3. 按照層級去羅列出所有的問題，並附上自己的初步回答，從而形成一個初步的、自己的產品能夠解決的「問題域」。

確定產品方向

在經過問題域的羅列後，你應該能夠得到一個模糊的產品方向和功能范圍。把這些問題域的答案抽象總結成一個確定的產品需求。

以微信AR的需求為例，根據問題域，我們發現需求不只是掃碼組件增加AR識別能力這么簡單，整個需求里需要引入廣告主的角色，並且需要和廣點通、騰訊開放平台等團隊合作。最終得到的產品方向描述是這樣的:

詳細操作步驟：

問題域的環節非常發散，這一步需要回歸基礎，把模糊的需求補充、拓展和翻譯成一個在商業模式和用戶體驗上能夠形成閉環的產品需求。

1. 核心需求確定：我的產品核心解決的是哪批用戶、哪個用戶需求？

2. 產品目標：如果以一個數字指標衡量我的產品，它應該是什麼？

3.用戶場景：核心需求基本的產品形態、用戶使用的路徑是怎樣的？

清晰的業務流程

這一步需要根據核心產品需求和問題域的答案，畫出簡單的業務流程。業務流程是產品設計中常見的圖表，繪制方法就不再多做說明。

以微信AR的需求為例，從廣告主准備AR互動，到用戶在前台使用攝像頭參與互動，整個業務流程如下:

著手繪制

搭建基礎框架

基礎的產品框架脫胎於業務流程，但相比業務流程，更加註重產品功能的枚舉、功能模塊之間的分界。

詳細操作步驟：

1. 對照業務流程，根據自己設想的產品機制、基本產品形態和用戶的使用路徑，列出需要的頁面&功能&模塊等前後端邏輯。

2. 將剛剛得到的多個流程圖中所有功能類似或者范圍有包含關系的機制/功能放在一起，以模塊化的形式形成一張簡單的矩陣圖。

3. 將明顯是同一個產品范圍、同一組產品功能的模塊放在同一層級，得到一個基礎的產品框架。

明確架構分層

一個具備前後台關系的產品架構圖至少分為三層：用戶感知層（在何種場景下通過何種方式觸達用戶）、功能模塊層（通過哪些功能模塊實現產品的核心功能、和哪些外部平台功能有信息交互）、數據層（產品的數據從哪裡來、產品的數據沉澱到何處去）。

在上一步進行簡單分層後，我們已經得到一個初步框架，但是難免會有分層不明確的問題。此時需要按照兩種維度來處理架構圖的層級：不同信息層級的邊界、同一層級內模塊和模塊的邊界。

1. 處理不同信息層級的邊界：

架構圖的層級表達的其實是信息之間的流轉關系，不同信息層級之間一定是有邏輯關系的。

其中用戶感知層和數據層通常可以簡化為一層（用戶端的功能表達往往邏輯簡單、數據的來源問題則不是自己產品的核心功能），而功能模塊層則需要按照自己產品的邏輯去將功能模塊層內的主要模塊變成新的層級。

2. 處理同一層級內子模塊的邊界：

各層次之間雖然相關，但同一層次內的子模塊之間一定是互相獨立、界限分明的（常常對應著不同的開發團隊和系統應用）。將解決不同問題的功能拆分成兩個子模塊，做到一個問題只在同一層解決，避免牽一發而動全身的情況出現。

3. 明確產品間的邊界：

產品邊界對於開發設計系統架構、業務間的合作模式都非常重要。用不同顏色標識清楚產品框架中，各個部分所屬產品的邊界，通常其中屬於自己團隊的部分用亮色表示。

加入信息流轉機制

產品架構圖在表達產品的核心功能外，也應該體現信息流動的路徑：當前層級數據的交互形成產品功能，產品功能又產生新的數據，從而推動下一層級的功能運轉起來。

如果當前產品的主要使用角色只有一個，則只需要用箭頭標明模塊間信息流動的方式即可。如果當前產品會涉及的主要角色比較多，則需要用不同顏色的線條將他們和各個模塊之間的信息交互關系外化出來。

最終檢查

一張好的產品架構圖，應該具備以下特點。

清晰的模塊功能邊界

功能經過抽象，做到標准化、互相獨立

上下游產品功能邊界清晰，架構分層明確合理

具備迭代優化的能力

記得不斷根據你的產品的發展情況來更新產品架構圖，每次修改的過程對提升產品架構能力的幫助非常巨大。

————————————————

原文地址：https://blog.csdn.net/pmcaff2008/article/details/78111282

❺ 產品的頂層架構是什麼

有時候大家發現做事情會很順，有的時候會很擰巴，為什麼開發和產品老在打架？為什麼各種資源政策都在和我作對？為什麼男生思路和女生思路永遠走不到一塊去？談到根上，這都是頂層架構決定的。

頂層架構就是一個產品或者體系的宏觀設計，設計准則，邊界規范。 一款優秀的產品或者一個高效的體系，一定擁有一套優秀的頂層架構。

產品的頂層架構包括:

1.擁有確定性的目標和願景。

這款產品，我的願景是什麼？我要達成的目標是什麼？要去到哪個地方？

2.有著明確的邊界。

邊界就是克制和約束。產品是有邊界的，世界上不存在無限大的產品。想清楚，什麼東西能做，什麼東西不能做。用戶能聯想到嗎，用戶的心智邊界在哪裡，做出來的是不是無用功？

3.清晰的產品定位和承載的使命。

我的產品定位是什麼，要在哪個場景下解決哪個問題？對公司/用戶/產品不同的緯度來說，產品的使命是什麼？

4.聚焦的服務和服務人群。

我要提供什麼樣具體性的服務，我的服務對象是誰。

5.邏輯清晰的功能框架。

對產品要做的事情和提供的服務進行歸類排序。哪些功能屬於同一等級？同層級下哪個功能是我的第一優先順序，哪個是第二？

這五條就是我理解的產品頂層架構，他決定你的產品會走到哪，走的好不好順不順，如果沒想清楚開始做產品，是不負責任的。

舉個例子，我們來看看互傳這類文件傳輸產品（當然我們作為一個廠商應用有和純粹的第三方應用不一樣的地方就是我們要更多的考慮換機用戶的體驗）的架構是怎麼樣的，

目標願景：成為市場第一的文件傳輸工具，3000萬月活，50%以上的用戶換機使用

邊界：互傳要提供的是基於近場通信的文件傳輸服務

產品定位：互傳是服務於換機和跨平台近場文件傳輸的工具產品

使命：對公司側，降低換機成本提升復購率；對用戶側提供高速免流的傳輸服務滿足用戶求；對產品側能持續產生保持用戶黏性和產生價值養活團隊

服務的人群：換機人群，網路環境不好或分享文件時對流量有訴求的用戶

聚焦的服務：近場傳輸、一鍵換機、跨設備互聯傳輸

架構可以有大有小，都沒問題，也可以隨著體量和階段的變化不斷調整。但無論怎麼變化， 重要的是清晰+完整 。

優秀的產品不一定是復雜的產品，不一定提供多麼精緻多麼全面的服務。很多爆款產品往往聚焦在一個痛/癢/爽點上，針對性的解決用戶的某個問題或滿足某種訴求，麻雀雖小五臟俱全，就是一款能打的產品。比如說臉萌、ZEPETO、足記，都算一款好產品。因為他們滿足了用戶的確定性需要，那五個問題每條都很清晰。

同時，頂層架構某種程度上代表了格局和願景，就是你能解決多大問題，干多大的事。

再拿「臉萌」舉例，為什麼臉萌的開發團隊不繼續在臉萌的基礎上迭代，而是另起爐灶做了一款Faceu呢？因為架構包含了產品邊界，產品達到了他的邊界，用戶的心智向外拓展是非常困難的，對於小團隊來說我寧願再做過一個。在原有的邊界里，我幹不了更多的事情了。

但有的時候我們不得不去打破產品的邊界，因為市場和競爭對手在不斷變化，不做你就死了，做不做？這也是互傳不斷探索能夠打破的產品邊界的原因。當然，能夠帶領產品跨越非連續的產品經理都是最優秀的產品經理，因為這可能比做一款新產品更困難。最經典的案例可能就是我們自己了，從當時命懸一線的功能機時代跨越生死線，慢慢變成了今天這個平台型公司。這真的是非常難的，不僅僅是產出的產品發生了變化，組織架構，供應鏈，思維模式都要發生巨大的變化， 所以vivo真的是很厲害的企業 。

總之，大有大的雄渾，像阿里一出手就是氣吞天下片甲不留天下萬物都在我雙手間翻覆；小有小的精巧，像soul准確的咬住興趣靈魂社交在巨頭遍布的時代守住一片江山。重要的，是完整和清晰。

回到最開始的問題，

為什麼開發和產品老在打架 ？

是因為誰很傻難以溝通嗎？不。是因為目標和願景不同，如果開發小哥的目標和KPI是保證產品的穩定性和效率，產品的目標是不斷迭代新功能提升產品指標，你們當然就打一起去了。如果統一一下目標，我相信大家能很快達成一致，這也就是為什麼涉及錢的問題大家總是能同仇敵愾，因為沒人和錢過不去呀，換個說法，團隊里的所有人目標是一致的。PS：這里講一句題外話，我很感謝我的團隊，總是在盡力滿足我各種傻逼需求，從產品的角度保證目標達成，感謝這幫小哥小姐。

為什麼各種資源政策都在和我作對？

因為大傢伙的目標會有區別，因為你產品的定位和使命不清晰，大家理解得這產品就是解決巴掌這么大個問題的產品，產品經理不死心，非得把他做的氣吞山河功能把天都頂破，那當然走不到一塊去。所以怎麼才能走得順，一上來給團隊和老闆講明白了，我到底要幹啥，要走到哪，怎麼走，你們全力支持我，自然就順了。所以一個有戰鬥力的團隊一定要心齊。

為什麼男生思路和女生思路永遠走不到一塊去？

因為你們的思維模式不同，腦子結構決定了，男生偏理性，女生偏感性，這叫功能框架結構不同。社會對男性要求的社會屬性是硬漢，所以你不能多愁善感要快速的解決問題；社會對女性要求的屬性是柔軟和包容，所以她需要更細膩的感受，這叫產品使命不同。

總結一下，頂層架構就好像血肉皮里的骨頭，他是撐住一個產品和體系的關鍵，一定得想明白了。（這么簡單是因為我寫累了）

❻ 消費者需求特徵分析

產品價值的最終落腳點——需求

我們先來看一下俞軍提出的新三條軍規。

產品價值分析法：用戶價值=(新體驗-舊體驗)-換用成本
用戶樣本量：用戶即需求，用戶是自然人的某一類需求，用戶不是自然人，隨著內外部場景變化會發生變化。
懷疑精神：自我迭代。
俞軍新三條軍規中的第一條建立在一個前提條件之下——需求不是被創造出來的。第二條將最重要的需求融入用戶之中。這也和上圖中描述一致，需求分析在輸入階段， 要進行對需求的收集、發現、挖掘。

需求決定了最終的產品價值。

所以需求分析推導至現在，目的開始越來越清晰——發現、挖掘具有商業價值的需求，並給出具備用戶價值和商業價值的解決方案。

這時應該會有人疑問，產品的日常工作中很多時間是對單個功能的分析，根本涉及不到商業價值啊。別著急，東方還沒講完呢。不是所有的需求都能挖掘出商業價值，一個好產品也不等於一個能夠賺錢的產品。

剛才已經提到過，商業價值建立在用戶價值的基礎上。所以我們首先要滿足的是用戶需求，然後將其與企業的需求結合。剛才的疑問只不過源於我們更多時候只是在提升用戶價值，這和產品屬性與所在職位等級有關。

需求分析的幾個要素
需求分析的過程當中，會誕生出幾個極其重要的產物——產品目標、產品定位、產品邊界、產品規則。

產品目標——產品承載的使命
產品是需求分析得出的解決方案的最終承載地方。它承載了實現用戶價值和商業價值的使命。明確的產品目標能夠讓我們實現產品價值的時間變得更短。比如工具產品轉型為社區，是在一開始就預設的產品目標還是市場所逼？可能兩者都能轉型成功，但前者贏在了時間上面。

產品定位——產品要做什麼
到底做一個什麼樣的產品好呢？社交、社區、社群，傻傻分不清楚。社交好像也可以做社區，好像也可以做成社群。好，那就都做試試吧！不能評斷到底是對是錯，但是做得越多，耗費的時間也就越多。大公司可能無所謂，試試水嘛。小公司可拖不起啊！

產品定位圍繞產品目標確定。產品定位不清晰可能造成的問題是選擇太多而不知道要做什麼。

產品邊界——產品不做什麼
雖然我是做金融的，但我就是要做社交！我不僅要做社交，我還要讓全國人民都參與進來，調動他們的荷爾蒙積極性，走出金融社交的第一步！

產品邊界由產品目標和產品定位確定。強行打破產品邊界，要麼出現跨領域引領時代帶動革命浪潮的生態化反，要麼就是自己閑坑太少再多挖幾個。

強行打破產品邊界和自掘墳墓沒有多大區別。

產品規則——指明方向的北斗七星
產品目標、產品定位、產品邊界共同構成產品規則。進行需求分析的時候，我們要隨時提醒自己遵從產品規則，以避免偏離產品重心和陷入分析誤區。無論是需求評估，還是需求優先順序排序，如果不遵循產品規則很容易走上很多彎路。

兩點之間，直線最短。我們可以通過很多種方式實現產品目標，但明晰的產品定位和產品邊界能夠讓我們更快速地達到產品目標。不管夜晚有多黑暗，只要北斗七星依舊閃耀，我們就絕不會偏離方向。

❼ 產品架構圖的定義和基本畫法

本小節主要介紹 產品架構圖 的相關知識，整個內容框架分為三個部分，分別是： 產品架構圖是什麼（what） ； 為什麼要畫產品架構圖 （why） ； 如何畫產品架構圖（how） ，下文將對各部分的內容做詳細介紹。

1、產品架構圖的定義

產品架構圖是一種將具象產品的業務架構、功能架構、信息架構、技術架構，生態架構以及商業模式等，通過層級劃分、模塊組合，而設計出的可視化圖形，其抽象且精簡的表達形式，很適合用來介紹復雜產品體系。常見的產品架構圖有業務架構圖、功能架構圖、信息架構圖，以及混合架構圖。

有句俗語叫做： 思考常常越復雜，形式往往越簡單 。人類歷史上許多偉大的知識和定律都是以精簡而優美的形式表達出來的，例如亞里士多德的三段論表述、牛頓的三大定律、歐拉的上帝公式，達爾文的進化論表述等。思考的足夠通透後，只需要用簡單的形式就可以表達復雜的體系結構和邏輯關系，相反很多看似簡單的表現形式，背後卻承載著巨大的復雜。

對比各種產品輸出物（文檔、原型圖，流程圖等），產品架構圖的形式最為精簡，都是由單一的矩形控制項排列組合形成，但卻在所有的產品輸出物中擁有最高的抽象程度和復雜度，輸出產品架構圖是對產品經理產品設計能力的衡量和體現。

2、為什麼要畫產品架構圖

在進行產品設計的時候，首先應該輸出的是產品功能架構圖，思考這張圖如何畫的過程，是幫助你梳理產品設計思路以及確定產品邊界過程。例如，現在讓你設計一個CRM系統，可以試著先畫出具體業務的CRM系統的功能架構圖，在畫的過程中，會輔助你思考整個CRM系統有哪些核心功能模塊組成，各模塊的關聯關系是怎樣的，每個階段應該做什麼，從而形成完成的產品設計思路。

其次，產品設計的過程就像是蓋大樓的過程，輸出產品功能架構圖就好比是搭建大樓地基的過程，產品原型設計的過程就像是大樓建造的過程，地基沒有問題，後面的添磚加瓦就不會有太大問題。如果一開始地基質量就有問題而沒有被重視，後續蓋了一半發現整個工程出現問題，修復重建則會浪費巨大的資源和成本。所以項目初期產品功能架構圖是很重要的交付物，當你要開始設計一個完整的產品方案時，如果跳過畫產品架構圖的步驟，直接開始畫原型、寫PRD文檔，就很容易發生改了又改，甚至是做了一版需求然後又推翻的情況。

最後，在產品上線後無論是對內普及還是對外推廣都需要有高度抽象，簡潔易懂的載體來介紹產品整個情況，介紹和推廣的不可能去用繁雜的頁面和文字去描述，這個時候產品架構圖會是介紹整個產品理念，功能和設計的一個很好的傳達媒介。

3、如何畫產品架構圖

上文介紹了什麼是產品架構圖以及為什麼要畫產品架構圖，接下來要介紹如何畫產品架構圖，產品架構圖的畫法主要分為四個步驟，分別是：（1）確定對象；（2）拆解結構；（3）挖掘關系；（4）表達輸出。

圖5-1產品架構圖的畫法

（1）確定對象

首先要明確產品架構圖描述對象的范圍和邊界是什麼，例如，對於一個CRM系統，要畫的是CRM系統的業務架構圖、功能架構圖、信息架構圖、還是綜合了多種元素混合在一起的混合架構圖。

（2）架構拆解

確定好描述對象的類型後，要對其進行架構拆解，例如，輸出一家借貸平台的業務架構圖圖，可以拆解為貸前業務、貸中業務，貸後業務等。又例如輸出一個CRM系統的功能架構圖可以拆解出整個CRM系統的功能模塊，如賬戶管理模塊、客戶管理模塊、用戶管理模塊、許可權管理模塊，系統設置模塊等。

（3）關系挖掘

輸出對象的架構拆解完成後，需要發掘出各個模塊之間的關聯關系，同樣以CRM系統的功能架構圖為例，在拆分完整個系統的功能模塊時，接下來要分析出各個功能模塊的關系，產品架構圖內部元素之間的關聯關系主要有四種：統計並列關系、父子包含關系、輔助支撐關系，底層支撐關系。

（4）表達輸出

確定了各個功能模塊的關系之後，則需要進行關系表達，層級相同的模塊元素，則按照同級並列關系，需要排列在一起。

例如，在CRM系統中，客戶管理模塊和許可權管理模塊就屬於同層級的並列關系。而許可權管理模塊和許可權分配這個功能模塊之間則屬於父子包含關系，在表達父子包含關系時，通常父級模塊會包含住子級模塊。

其次，一些產品的非核心的功能模塊或者產品之外的一些功能模塊，例如第三方平台的簡訊功能模塊，這些模塊對產品自身功能的實現起到了一定的輔助作用，與其他產品功能模塊呈現出輔助支撐的關系，輔助支撐模塊一邊畫在產品架構圖的右側。

最後是底層支撐關系，例如產品的 會員體系 是建立在賬戶體系的基礎上的，所以賬戶體系與會員體系屬於底層支撐關系。底層支撐關系的表達方式一般是支撐模塊在底下，被支撐模塊在上面。這些基本關系的圖形化表達方式，會在後面小節結合實際的案例做詳細介紹。

整個邊界范圍內的結構關系表達完成後，整體檢查一遍是否有遺漏和錯誤，檢查完畢後配上整個架構圖的標題，架構圖標題往往是對整個架構圖內容的說明，一般放在最上面或者框架左右兩邊，最終輸出完整的產品架構圖。

愛因斯坦說過： 如果你不能把一件事情用最簡潔的語言描述清楚，說明你還沒有理解他。 對於產品架構圖而言： 如果你不能用簡單的矩形， 通過 排列組合的方式 ， 把一個復雜的產品 結構描述 清楚，說明你還沒有真正理解 你做的產品 。 所以，在日常的產品工作中，要培養自己去畫產品架構圖的習慣，培養抽象思考能力的同時，輔助自己高效的完成產品方案設計。

原文地址：https://www.cnwebe.com/articles/157113.html

❽ 什麼是超出產品邊界的需求

產品定位於只滿足用戶甲的需求，然而你想把乙的需求也去滿足，那麼就算超出產品邊界的需求。

需求邊界的重要性：

首先，在任何階段對客戶的需求來者不拒，肆意擴大邊界范圍，那麼將導致項目遲遲無法交付上線。

其次，在開發階段，需求依然充滿變數，團隊將產生疲憊抗拒心理，對團隊士氣是」致命「的。

最後，對公司來說，階段性驗收形同虛設，無法交付就沒有項目尾款，最終造成項目虧損。

我們需要有個認知，在業務方面，我們的客戶是專家，他們一定是有需要沒有得到滿足，所以希望我們提供解決方案。我們無法根據業務技能去識別產品需求，只有使用對象才能決定需求邊界的范圍和深度。

當對需求還沒有認知時，最好的辦法就是深入業務場景，通過調研、模擬、模擬，建立對需求理解的一致性，這樣使我們能想像最終的產品形態是什麼樣的。

再從結果倒推出需求邊界，清晰界定自己的邊界，以及需要遵守的邊界。畢竟客戶只是需要解決問題，而如何解決，功能如何呈現，還是靠產品經理決定。

❾ 產品差異是否存在邊界為什麼

摘要 謝邀，我認為產品差異是否存在邊界要視情況而定，有時候是存在邊界，有時候是沒有邊界的。因為每個企業的實際情況是不同的，所以服務單應該屬於定製開發的項目，不是標准產品。

❿ 企業的三個基本屬性是什麼

企業的基本屬性

1、經濟性。企業是從事商品生產和商品流動的經濟組織，因此，經濟性便成了企業的首要特徵。通過這個特徵來實現自己的價值和商品的使用價值。

2、營利性。由第一個特徵導致第二個特徵，企業的經濟性是從企業的營利水平來體現的，也就是說，企業是為贏利而經營的一個經濟組織。因此，構成企業的一個根本性的標志就是營利。需要說明的一點是，有些組織它也從事一些經濟性的活動，但是它並不是以贏利為目的的，所以就不能稱為企業。

3、獨立性。企業除了要具備經濟性、營利性之外，還必須要具備一定的獨立性，企業必須要能夠獨立核算、自負盈虧、自主經營，並且是一個獨立的法人組織。這里，我們要弄清楚企業與工廠並不是同一個概念。企業它可以是一個工廠，但是工廠就不一定都是企業。工廠只不過是一個從事生產活動的場所而已。有些工廠雖然也從事經濟性的活動，也以營利性為目的，但是不具備獨立性，因此，就不能稱為企業。