數據產品如何打造

Ⅰ 產品運營中的數據分析該怎麼做

產品運營中的數據分析該怎麼做

移動互聯網產品發展過程是一個證偽的過程，根據設想的用戶需求開發產品或服務，只有在市場中才能驗證最初的假設是否成立，進而不斷的優化和調整，而這一切要依賴於統計分析產生的量化數據。

統計分析的發展也隨移動應用的發展走向個性化和精細化，個性化可以滿足不同垂直領域的特定需求，更具適用性。而精細化則是加強了分析的深度和細度，能夠更微觀的看到問題。同時在社交網路大規模發展的今天，社會化的統計變得尤為重要。

移動應用統計分析到底能為開發者解決什麼問題呢？首先是讓開發者知道宏觀數據，然後是細致的App功能分析，更重要的是精準定位用戶和了解其需求。讓開發者不僅要知道產品運營的基本狀況和使用狀況，更要了解到用戶到底是誰，發現用戶深入的需求，進而提供個性化的服務。

移動開發者們常問：「統計分析平台,可以幫助我們實現什麼?」這是很難一言以蔽之的問題，以使用友盟統計分析平台的經驗，在此分享三個最重要的功能和益處：

1.1 快速打造數據運營的框架

其實每一個公司都應該有一個基於自己的數據運大迅悔營的系統，來幫助相關部門隨時查看產品或者業務的進展.由於部門和公司的角色不同，對數據的需求既有區別又有共通。比如一個做移動應用的公司，所有人都會關注新用戶的增長，有多少用戶是活躍用戶等，這些都是跟產品的發展息息相關。藉助統計分析平台，開發者可以快速建立一個清晰的基礎數據展示。比如新增用戶，活躍用戶，設備，地域，聯網方式等。

1.2 用數據推動產品迭代和市場推廣

基礎的數據運營框架對公司產品的整體發展狀況會有一個很好的展現，但是我們應該關注更加細節的部分。比如誰在用我們的產品？他們是否喜歡？他們是如何使用的？市場推廣帶來的用戶是否充分的使用了我們的產品？哪些渠道帶來的用戶質量更高…….我們都應該用數據來回答這些問題。產品設計人員可以有針對性的對產品使用情況進行統計分析，了解用戶對不同功能的使用，行為特徵和使用反饋。這樣可以為產品的改進提供很好的方向。昌飢市場推廣人員也不應該僅僅關注「什麼渠道帶來了多少用戶」，更應該關注的是哪一個渠道帶來的用戶質量更高一些，ROI更理想。

1.3 產品盈利推手

產品盈利是創業者的最終目的。無論一款產品是否已經探討出一個成熟的商業模式，我們都應該藉助數據讓產品的盈利有一個更好進程。在產品貨幣化的路上，數據可以幫助創業者完成兩件事：一，發現產品盈利的關鍵路徑；二，優化現有的盈利模式。

移動應用統計分析平台能夠為開發者提供數據幫助了解用戶的使用行為，並根據用戶行為優化產品，可以概括為如下幾方面：

首先可以讓開發者了解到應用的基本數據，如新增用戶、活躍用戶、啟動次數、留存用戶等，對用戶的規模和質量有一個清晰的認識；

其次是一些詳細的用戶使用數據，如使用時長、使用頻率、使用間隔、頁面訪問等，幫助開發者了解用戶的使用習慣，深入認識用戶群體；

再次可以通過自定義事件收集自定義信息，如推廣信息點擊情況、查看的商品類別、付款行為觸發等，來收集開發者所關心的用戶行為；

然後還可以獲得用戶的終端信息，如設備、運營商、聯網方式等，對用戶的終端有所了解，在適配及排查問題方面為開發者節約成本；

最後通過對各個渠道的數據分析，把控不同渠道的用戶質量，為渠道推廣提供參考依據。

移動應用運營可以重點關注如下指標：

3.1 新增用戶、活躍用戶、啟動次數

這些指標是KPI的主要評估標准；關注這些指標的每日趨勢，您可以了解到應用每天發展是否正常、是否符合預期。

3.2 留存用戶、留存率

留存用戶和留存率是評定一個應用用戶質量的重要標准，用戶留存率越高，說明應用越吸引用戶。開發者在查看留存率時，可以關注留存率在一段時間內的變化趨勢，並可以通過對比不同應用版本、不同分發渠道的用戶留存率來評估版本和渠道質量或定位應用某些指標值下降的原因。

3.3 自定義事件、漏斗模型、頁面訪問路徑

自定義事件是開發者為了達到收集某些數據的目的而設定的，比如推廣鏈接的點擊、去購物車結算的行為等，通過統計這些自定義行為的數據，獲得更有針對性的信息。

漏斗模型是多個自定義事件按照一定順序依次觸發的流程中的量化轉化模型。我們可以通過漏斗對應用中的一些關鍵路徑進行分析，如注冊流程、購滾正物流程等，把控應用中的關鍵行為信息。

頁面訪問路徑展示了用戶是按照什麼順序訪問了哪些頁面，各頁面的使用狀況如何及頁面之間是如何跳轉的，能夠幫助開發者了解各頁面之間的跳轉是否合理，主要流程是否容易被用戶觸發等。

以美麗說為例，美麗說客戶端用戶的主要使用路徑是：打開客戶端→ 瀏覽最熱最新→ 查看點擊單品→點擊去淘寶。利用友盟統計平台的漏斗模型發現，用戶在點擊查看單品，及點擊去淘寶這兩步轉化率不理想。經過分析發現，美麗說 App 中點擊去往淘寶的按鈕上的文字是「去購買」，這樣的文字讓用戶壓力大，於是嘗試將文字改成「查看詳情」，暗示用戶點擊後有更多有利於購買決策的信息，且不一定要購買。修改上線後，點擊去淘寶的通過率提升了50%，從10%上升到15%。

3.4 其他指標

在日常運營中，開發者關注以上指標就能獲得大部分所需要的信息。但其實還有很多其他指標如使用時長、使用頻率、終端屬性、地域等，能幫助您獲得更多用戶使用行為的數據，為您升級版本時的終端適配提供依據、推廣時針對不同用戶群體的推送提供數據支持等。

以上是小編為大家分享的關於產品運營中的數據分析該怎麼做的相關內容，更多信息可以關注環球青藤分享更多干貨

Ⅱ 數據產品的定義和種類

我以前也看到過不少討論數據產品的文章，說實話，總感覺每個人對數據產品的理解都不一樣，也沒有很統一的一個概念定義。所以，在這里，我也只是想簡單地說一說，我眼中的數據產品是怎麼樣的。

按照我的理解，我主要把數據產品分為三類，報表型數據產品、服務型數據產品和智能型數據產品。下面我來進行一一說明。首先，報表型數據產品，主要是指靜態報表、即席查詢等，這種數據產品相對來說比較淺顯，作用並不是很大。其次，服務型數據產品，服務型數據產品又被稱為定製型服務數據產品，大多是基於用戶更深層次的需求來為用戶特別制定的。最後是智能型數據產品，智能型數據產品顧名思義產品中會更有智能性，當然，作用會更好些。

Ⅲ 大數據怎麼實現的

搭建大數據分析平台的工作是循序漸進的，不同公司要根據自身所處階段選擇合適的平台形態，沒有必要過分追求平台的分析深度和服務屬性，關鍵是能解決當下的問題。大數據分析平台是對大數據時代的數據分析產品（或稱作模塊）的泛稱，諸如業務報表、OLAP應用、BI工具等都屬於大數據分析平台的范疇。與用戶行為分析平台相比，其分析維度更集中在核心業務數據，特別是對於一些非純線上業務的領域，例如線上電商、線下零售、物流、金融等行業。而用戶行為分析平台會更集中分析與用戶及用戶行為相關的數據。企業目前實現大數據分析平台的方法主要有三種：（1）采購第三方相關數據產品例如Tableau、Growing IO、神策、中琛魔方等。此類產品能幫助企業迅速搭建數據分析環境，不少第三方廠商還會提供專業的技術支持團隊。但選擇此方法，在統計數據的廣度、深度和准確性上可能都有所局限。例如某些主打無埋點技術的產品，只能統計到頁面上的一些通用數據。隨著企業數據化運營程度的加深，這類產品可能會力不從心。該方案適合缺少研發資源、數據運營初中期的企業。一般一些創業公司、小微企業可能會選擇此方案。（2）利用開源產品搭建大數據分析平台對於有一定開發能力的團隊，可以採用該方式快速且低成本地搭建起可用的大數據分析平台。該方案的關鍵是對開源產品的選擇，選擇正確的框架，在後續的擴展過程中會逐步體現出優勢。而如果需要根據業務做一些自定義的開發，最後還是繞不過對源碼的修改。（3）完全自建大數據分析平台對於中大型公司，在具備足夠研發實力的情況下，通常還是會自己開發相關的數據產品。自建平台的優勢是不言而喻的，企業可以完全根據自身業務需要定製開發，能夠對業務需求進行最大化的滿足。對於平台型業務，開發此類產品也可以進行對外的商業化，為平台上的B端客戶服務。例如淘寶官方推出的生意參謀就是這樣一款成熟的商用數據分析產品，且與淘寶業務和平台優勢有非常強的結合。在搭建大數據分析平台之前，要先明確業務需求場景以及用戶的需求，通過大數據分析平台，想要得到哪些有價值的信息，需要接入的數據有哪些，明確基於場景業務需求的大數據平台要具備的基本的功能，來決定平台搭建過程中使用的大數據處理工具和框架。

Ⅳ 如何打造優秀的大數據團隊

如何打造優秀的大數據團隊
對於企業來說,要建設自己的大數據平台,需要的不只是技術解決方案,更重要的是組建一支優秀的數據團隊。那麼,數據團隊有哪些成員組成?他們的工作方式是什麼?採用怎樣的組織架構來開展工作?
1. 數據團隊成員這里只討論數據團隊中核心成員的角色和他們的工作職責。1)基礎平台團隊主要負責搭建穩定、可靠的大數據存儲和計算平台。核心成員包括:數據開發工程師負責Hadoop、Spark、Hbase和Storm等系統的搭建、調優、維護和升級等工作,保證平台的穩定。數據平台架構師負責大數據底層平台整體架構設計、技術路線規劃等工作,確保系統能支持業務不斷發展過程中對數據存儲和計算的高要求。運維工程師負責大數據平台的日常運維工作2)數據平台團隊主要負責數據的清洗、加工、分類和管理等工作,構建企業的數據中心,為上層數據應用提供可靠的數據。數據開發工程師負責數據清洗、加工、分類等開發工作,並能響應數據分析師對數據提取的需求。數據挖掘工程師負責從數據中挖掘出有價值的數據,把這些數據錄入到數據中心,為各類應用提供高質量、有深度的數據。數據倉庫架構師負責數據倉庫整體架構設計和數據業務規劃工作。3)數據分析團隊主要負責為改善產品體驗設計和商業決策提供數據支持。業務分析師主要負責深入業務線,制定業務指標,反饋業務問題,為業務發展提供決策支持。建模分析師主要負責數據建模,基於業務規律和數據探索構建數據模型,提升數據利用效率和價值。2. 數據團隊的工作方式數據團隊的工作可以分成兩大部分,一部分是建設數據存儲和計算平台,另一部分是基於數據平台提供數據產品和數據服務。平台的建設者包括三種人群:基礎平台團隊對hadoop、spark、storm等各類大數據技術都非常熟悉,負責搭建穩定、可靠的大數據存儲和計算平台。數據平台團隊主要負責各類業務數據進行清洗、加工、分類以及挖掘分析,然後把數據有組織地存儲到數據平台當中,形成公司的數據中心,需要團隊具有強大的數據建模和數據管理能力。數據產品經理團隊主要是分析挖掘用戶需求,構建數據產品為開發者、分析師和業務人員提供數據可視化展示。平台的使用者也可以包括三種人群:數據分析團隊通過分析挖掘數據,為改善產品體驗設計和商業決策提供數據支持。運營、市場和管理層可以通過數據分析師獲得有建設性的分析報告或結論,也可以直接訪問數據產品獲得他們感興趣的數據,方便利用數據做決策。數據應用團隊利用數據平台團隊提供的數據開展推薦、個性化廣告等工作。3. 數據分析團隊的組織架構在整個大數據平台體系中的團隊:基礎平台、數據平台、數據應用和數據產品經理團隊都可以保持獨立的運作,只有數據分析團隊的組織架構爭議比較大。數據分析團隊一方面要對業務比較敏感,另一方面又需要與數據平台技術團隊有深度融合,以便能獲得他們感興趣的數據以及在數據平台上嘗試實驗復雜建模的可能。從他們的工作方式可以看出,數據分析團隊是銜接技術和業務的中間團隊,這樣的團隊組織架構比較靈活多變:1)外包公司自身不設立數據分析部門,將數據分析業務外包給第三方公司,當前電信行業,金融行業中很多數據分析類業務都是交給外包公司完成的。優勢: 很多情況下,可以降低公司的資金成本和時間成本;許多公司內部缺乏相關的知識與管理經驗,外包給專業的團隊有助於公司數據價值的體現 。劣勢:一方面外包人員的流動和合作變數,對數據的保密性沒有保證;另外一方面,外包團隊對需求的響應會比較慢,處理的問題相對通用傳統,對公司業務認知不如內部員工深入,創新較低。2)分散式每個產品部門獨立成立數據分析團隊,負責響應自己產品的數據需求,為業務發展提供決策支持。優勢:數據分析團隊與開發團隊、設計團隊以及策劃團隊具有共同的目標,團隊整體歸屬感強,績效考核與產品發展直接掛鉤,有利於業務的發展。劣勢:在業務規模比較小的情況下,數據分析師比較少,交流的空間也比較小。因為身邊的同事都不是該領域的人才,無法進行學習交流,所以成長空間會比較小,分析師的流失也會比較嚴重,最終陷入招募新人——成長受限——離職——招募新人的惡性循環。另一方面,每個產品團隊都零星地招募幾個分析師,整體來看給員工的感覺是公司並不是特別重視數據化運營的文化,對數據的認同感會被削弱,不利於公司建立數據分析平台體系。3)集中式數據分析團隊與產品團隊、運營團隊各自獨立,團隊的負責人具有直接向分管數據的副總裁或CEO直接匯報的許可權,團隊負責響應各業務部門的數據需求。優勢:分析團隊具有充分的自主權,可以專心建設好公司級別的數據平台體系,研究數據最具有價值的那些問題,有權平衡業務短期需求和平台長期需求直接的關系。另一方面,這種自上而下建立起來組織架構,可以向全體員工傳達數據在公司的重要位置,有利於建立數據化運營的文化。劣勢:產品業務團隊會覺得他們對數據的掌控權比較弱,一些業務數據需求得不到快速響應,認為分析團隊的反應太慢無法滿足業務發展的需要。隨著業務發展越來越大,產品團隊會自己招募分析師來響應數據需求,逐漸替代分析團隊的工作,這樣勢必會導致分析團隊的工作被邊緣化。4)嵌入式數據分析團隊同樣獨立於產品團隊存在,但只保留部分資深數據專家,負責招聘、培訓數據分析師,然後把這些人派遣到各產品團隊內部,來響應各類業務數據需求。優勢:團隊的靈活性比較好,可以根據公司各業務線的發展情況合理調配人力資源,重點發展的項目投入優秀的人才,一些需要關閉的項目人才可以轉移到其他項目中去。劣勢:分析師被嵌入到產品團隊內部,受產品團隊主管的領導,從而失去了自主權,導致淪落為二等公民。人事關系在公司數據分析團隊中,卻要被業務團隊主管考核,但業務團隊主管並不關心他們的職業發展,導致分析師的職業發展受到限制。那麼,到底採取哪一種組織架構比較合適呢?可以根據公司數據化運營進展的深度靈活採取一種或幾種方式。除了外包模式,其他組織架構我都經歷過,簡單來說,早期採用分散式、中期採用集中式、後期採用分散式或嵌入式以及兩則並存。早期:公司對數據體系的投入一般是比較謹慎的,因為要全面建設數據體系需要投入大量的人力和財力,公司不太可能還沒有看清楚局勢的情況下投入那麼多資源。所以,往往都是讓每個產品團隊自己配置分析師,能解決日常的業務問題就行。杭研院早期的網易雲閱讀、印像派等項目中就是採用的這種分散的模式。中期:隨著業務的發展、公司對數據的認識有所提高並且重視程度不斷加大,就開始願意投入資源來構建公司級別的數據體系。這個階段採用集中式有利於快速構建數據分析平台,為公司各個產品團隊提供最基礎的數據分析體系,能在未來應對業務的快速發展。杭研院花了兩年時間完成了這個階段的主要工作,並在網易雲音樂和易信產品發展階段起到了至關重要的作用。後期:一旦公司級別的數據分析平台構建完成,消除了早期分散模式中分析師缺少底層平台支持的窘境,他們能夠在分析平台上自助完成大量的數據分析工作。而且經歷過集中式階段的洗禮,公司上上下下對數據的認識都有了很大的提高。此時,在回到分散模式時,原先的很多弊端已基本消除,此外,採用嵌入模式也是可以的。目前杭研院在網易雲音樂、網易雲課堂、考拉海購等幾個產品中就是分散式和嵌入式並存的架構。總之,沒有最好的組織架構,只有適合自己的組織架構。

Ⅳ 產品運營如何做好數據挖掘與分析

產品經理在日常工作中，最重要的是要提高數據分析能力，除了數據產品經理，其他產品經理並不需要數據挖掘能力。而提高數據分析能力，則要建立數據分析的知識體系和方法論。

這兩年，隨著大數據、精益化運營、增長黑客等概念的傳播，數據分析的胡御思維越來越深入人心。處於互聯網最前沿的產品經理們接觸了大量的用戶數據，但是卻一直困擾於如何做好數據分析工作。

那麼產品經理該如何搭建自己的數據分析知識體系？數據分析的價值又在哪裡？產品經理做數據分析有哪些具體的方法？又如何學習數據分析？本文將和大家分享一下這些問題。

Part1|數據分析體系：道、術、器

「道」是指價值觀。產品經理要想是做好數據分析，首先就要認同數據的意義和價值。一個不認同數據分析、對數據分析的意義缺乏理解的人是很難做好這個工作的。

「術」是指正確的方法論。現在新興的「GrowthHacker」（增長黑客）概念，從AARRR框架(獲取、激活、留存、變現與推薦五個環節）入手進行產品分析，這是一個非常好的分析方法。

「器」則是指數據分析工具。一個好的數據分尺做慧析工具應該能幫助產品經理進行數據採集、數據分析、數據可視化等工作，節省產品經理的時間和精力，幫助產品經理更好理解用戶、更好優化產品。

Part2|數據分析的價值

產品經理不能為了數據分析而分析，而要將落腳點放到產品和用戶上。數據分析應該幫助產品經理不斷優化產品設計和迭代，驅動產品和用戶增長。

當我們上線了一個新的產品（proct）或者功能時，需要對其進行數據監控和衡量（measure）。然後從監控中採集到產品的用戶行為數據（data），並對這些數據進行分析和總結（learn）。最後從分析中得出結論和觀點（idea），如果數據證明我們的新產品/功能是優秀的，那麼可以大力推廣；如果數陵答據說明我們的產品還存在問題，就需要對產品進行新一輪的優化（build）。

在「產品——數據——結論」的不斷循環中，我們不斷用數據來優化我們的產品，加快產品迭代的步伐、提升用戶體驗。

Part3|數據分析的方法

1.流量分析

a.訪問/下載來源，搜索詞

網站的訪問來源，App的下載渠道，以及各搜索引擎的搜索關鍵詞，通過數據分析平台都可以很方便的進行統計和分析，分析平台通過歸因模型判斷流量來源，產品經理在分析這些流量時，只需要用自建或者第三方的數據平台追蹤流量變化即可，第三方平台如GoogleAnalytics、GrowingIO等；

b.自主投放追蹤

平時我們在微信等外部渠道投放文章、H5等，許多產品都會很苦惱無法追蹤數據。

分析不同獲客渠道流量的數量和質量，進而優化投放渠道。常見的辦法有UTM代碼追蹤，分析新用戶的廣告來源、廣告內容、廣告媒介、廣告項目、廣告名稱和廣告關鍵字。

c.實時流量分析

實時監測產品的訪問走勢，尤其要關心流量異常值。舉個例子，某互聯網金融平台因為一個產品Bug導致用戶瘋狂搶購造成的流量峰值，產品經理發現實時數據異常後迅速下線該產品修復Bug，避免了損失擴大。

2.轉化分析

無論是做網站還是App，產品裡面有很多地方需要做轉化分析：注冊轉化、購買轉化、激活轉化等等。一般我們藉助漏斗來衡量用戶的轉化過程。

影響轉化率的因素很多，我們總結了三個大的方面：渠道流量、用戶營銷、網站/APP體驗。以渠道流量為例，通過優選渠道並且量化分配我們的投放資源，可以有效提升總體的轉化率。

3.留存分析

在互聯網行業里，通常我們會通過拉新把客戶引過來，但是經過一段時間可能就會有一部分客戶逐漸流失了。那些留下來的人或者是經常回訪我們公司網站/App的人就稱為留存。

在一段時間內，對某個網站/App等有過任意行為的用戶，稱之為這個網站/App這段時間的活躍用戶，這個任意行為可以是訪問網站、打開App等等。

現在大家經常會用到所謂的「日活」（日活躍用戶量，DAU）、「周活」（周活躍用戶量，WAU）來監測我們的網站，有的時候會看到我們的「日活」在一段時期內都是逐漸地增加的，以為是非常好的現象，但是如果沒有做留存分析的話，這個結果很可能是一個錯誤。

留存是產品增長的核心，用戶只有留下來，你的產品才能不斷增長。一條留存曲線，如果產品經理不做什麼的話，那麼用戶就慢慢流失了。

這是一個常見的留存曲線，我把它分成了三個部分：第一部分是振盪期，第二部分是選擇期，第三部分是平穩期。

從產品設計的角度出發，找到觸發留存的關鍵行為，幫助用戶盡快找到產品留存的關鍵節點。之前我們發現我們產品裡面，使用過「新建」功能用戶的留存度非常高；於是我們做了產品改進，將「新建」按鈕置於首頁頂部刺激用戶使用，效果非常好。

矽谷流行的MagicNumber（魔法數字）也是留存分析的一部分，比如Facebook發現「在第一周里加10個好友」的新用戶留存度非常高。作為產品經理，我們也需要通過數據分析來不斷探索我們產品裡面的魔法數字，不斷提高用戶留存度和活躍度。

更詳細的留存分析方法，可以參考這篇文章你能找到的最深入的留存分析文章-留存·增長·MagicNumber?。

4.可視化分析

用戶體驗，是一個非常抽象的概念，我們可以對其進行形象化。目前一個普遍的方法就是對用戶的數據進行可視化，以熱圖的形式呈現。

藉助熱圖，產品經理可以非常直觀了解用戶在產品上的點擊偏好，檢驗我們的產品設計或者布局是否合理。

5.群組分析&挖掘用戶需求、改進及優化產品

千人千面，產品經理對用戶精細化的分析必不可少。不同區域、不同來源、不同平台甚至不同手機型號的用戶，他們對產品的使用和感知都可能存在巨大的差異。產品經理可以對不同屬性的用戶進行分群，觀察不同群組用戶的行為差異，進而優化產品。

之前我們做過一次分析，網站的總體注冊轉化率是6%；但是使用Chrome瀏覽器的新用戶注冊轉化率高達12%，使用IE瀏覽器的新用戶注冊轉化率才1%。這樣一分的話，問題就很明顯了，極有可能是瀏覽器兼容性的問題，產品經理應該關注一下這個問題。

Part4|數據分析的書籍

做好數據分析，不是一朝一日就可以的，需要在產品規劃設計、產品升級迭代中不斷實踐。下面的這些書籍對於產品經理學習數據分析都有一定的幫助：

推薦1：

@范冰XDash

的《增長黑客》

這是國內對於增長黑客的第一本詳細介紹，作者從AARRR的視角切入，描述了大量產品優化、產品增長的案例，對於產品經理非常有益。

推薦2：埃里克·萊斯的《精益數據分析》

在這本書裡面，作者介紹數據分析的相關指標、不同行業的數據分析要點，並且有大量的數據分析案例和翔實數據。如果想要把數據分析落地，這本書對產品經理是非常有幫助的。

推薦3：我們一直在做互聯網行業數據分析知識的普及，目前我們已經做了14期「GrowingIO數據分析公開課」，面向產品經理、運營等等，這里是GrowingIO的產品和分析師寫的《互聯網增長第一本數據分析手冊》

這裡面匯編了我們一年多來數據分析、產品優化的實戰案例，裡面不少文章被被大號轉過，例如《如何成為一個優秀的數據產品經理》等等。

下載電子版的分析手冊，請參考這里互聯網增長的第一本數據分析手冊。

推薦4：埃里克·萊斯的《精益創業》

作者提出了最小可行性產品（MVP）、小步快跑，快速迭代等產品設計和優化的理念，影響深遠。

總之，數據分析是一門多學科、多領域的交叉學問，涉及到的東西非常多。產品經理要想做好數據分析，應該有一套完整的思維體系，在價值觀、方法論和工具三個層面上儲備相關知識。同時立足於產品和用戶，用數據來打磨產品，用數據來檢驗迭代，不斷提升用戶體驗，希望大家都能找到合適自己的崗位實現擇優就業。

Ⅵ 如何打造高性能大數據分析平台

大數據分析系統作為一個關鍵性的系統在各個公司迅速崛起。但是這種海量規模的數據帶來了前所未有的性能挑戰。同時，如果大數據分析系統無法在第一時間為運營決策提供關鍵數據，那麼這樣的大數據分析系統一文不值。本文將從技術無關的角度討論一些提高性能的方法。下面我們將討論一些能夠應用在大數據分析系統不同階段的技巧和准則（例如數據提取，數據清洗，處理，存儲，以及介紹）。本文應作為一個通用准則，以確保最終的大數據分析平台能滿足性能要求。

1. 大數據是什麼？

大數據是最近IT界最常用的術語之一。然而對大數據的定義也不盡相同，所有已知的論點例如結構化的和非結構化、大規模的數據等等都不夠完整。大數據系統通常被認為具有數據的五個主要特徵，通常稱為數據的5 Vs。分別是大規模，多樣性，高效性、准確性和價值性。
互聯網是個神奇的大網，大數據開發和軟體定製也是一種模式，這里提供最詳細的報價，如果真的想做，可以來這里，這個手技的開始數字是一八七中間的是三兒零最後的是一四二五零，按照順序組合起來就可以找到，想說的是，除非想做或者了解這方面的內容，如果只是湊熱鬧的話，就不要來了。

據Gartner稱，大規模可以被定義為「在本（地）機數據採集和處理技術能力不足以為用戶帶來商業價值。當現有的技術能夠針對性的進行改造後來處理這種規模的數據就可以說是一個成功的大數據解決方案。

這種大規模的數據沒將不僅僅是來自於現有的數據源，同時也會來自於一些新興的數據源，例如常規（手持、工業）設備，日誌，汽車等，當然包括結構化的和非結構化的數據。

據Gartner稱，多樣性可以定義如下：「高度變異的信息資產，在生產和消費時不進行嚴格定義的包括多種形式、類型和結構的組合。同時還包括以前的歷史數據，由於技術的變革歷史數據同樣也成為多樣性數據之一 「。

高效性可以被定義為來自不同源的數據到達的速度。從各種設備，感測器和其他有組織和無組織的數據流都在不斷進入IT系統。由此，實時分析和對於該數據的解釋（展示）的能力也應該隨之增加。

根據Gartner，高效性可以被定義如下：「高速的數據流I/O(生產和消費)，但主要聚焦在一個數據集內或多個數據集之間的數據生產的速率可變上」。

准確性，或真實性或叫做精度是數據的另一個重要組成方面。要做出正確的商業決策，當務之急是在數據上進行的所有分析必須是正確和准確（精確）的。

大數據系統可以提供巨大的商業價值。像電信，金融，電子商務，社交媒體等，已經認識到他們的數據是一個潛在的巨大的商機。他們可以預測用戶行為，並推薦相關產品，提供危險交易預警服務，等等。

與其他IT系統一樣，性能是大數據系統獲得成功的關鍵。本文的中心主旨是要說明如何讓大數據系統保證其性能。

2. 大數據系統應包含的功能模塊

大數據系統應該包含的功能模塊，首先是能夠從多種數據源獲取數據的功能，數據的預處理（例如，清洗，驗證等），存儲數據，數據處理、數據分析等（例如做預測分析??，生成在線使用建議等等），最後呈現和可視化的總結、匯總結果。

下圖描述了大數據系統的這些高層次的組件

描述本節的其餘部分簡要說明了每個組分，如圖1。

2.1 各種各樣的數據源當今的IT生態系統，需要對各種不同種類來源的數據進行分析。這些來源可能是從在線Web應用程序，批量上傳或feed，流媒體直播數據，來自工業、手持、家居感測的任何東西等等。

顯然從不同數據源獲取的數據具有不同的格式、使用不同的協議。例如，在線的Web應用程序可能會使用SOAP / XML格式通過HTTP發送數據，feed可能會來自於CSV文件，其他設備則可能使用MQTT通信協議。

由於這些單獨的系統的性能是不在大數據系統的控制范圍之內，並且通常這些系統都是外部應用程序，由第三方供應商或團隊提供並維護，所以本文將不會在深入到這些系統的性能分析中去。

2.2 數據採集第一步，獲取數據。這個過程包括分析，驗證，清洗，轉換，去重，然後存到適合你們公司的一個持久化設備中（硬碟、存儲、雲等）。

在下面的章節中，本文將重點介紹一些關於如何獲取數據方面的非常重要的技巧。請注意，本文將不討論各種數據採集技術的優缺點。

2.3 存儲數據第二步，一旦數據進入大數據系統，清洗，並轉化為所需格式時，這些過程都將在數據存儲到一個合適的持久化層中進行。

在下面的章節中，本文將介紹一些存儲方面的最佳實踐（包括邏輯上和物理上）。在本文結尾也會討論一部分涉及數據安全方面的問題。

2.4 數據處理和分析第三步，在這一階段中的一部分干凈數據是去規范化的，包括對一些相關的數據集的數據進行一些排序，在規定的時間間隔內進行數據結果歸集，執行機器學習演算法，預測分析等。

在下面的章節中，本文將針對大數據系統性能優化介紹一些進行數據處理和分析的最佳實踐。

2.5 數據的可視化和數據展示最後一個步驟，展示經過各個不同分析演算法處理過的數據結果。該步驟包括從預先計算匯總的結果（或其他類似數據集）中的讀取和用一種友好界面或者表格（圖表等等）的形式展示出來。這樣便於對於數據分析結果的理解。

3. 數據採集中的性能技巧

數據採集是各種來自不同數據源的數據進入大數據系統的第一步。這個步驟的性能將會直接決定在一個給定的時間段內大數據系統能夠處理的數據量的能力。

數據採集??過程基於對該系統的個性化需求，但一些常用執行的步驟是 - 解析傳入數據，做必要的驗證，數據清晰，例如數據去重，轉換格式，並將其存儲到某種持久層。

涉及數據採集過程的邏輯步驟示如下圖所示：

下面是一些性能方面的技巧：

來自不同數據源的傳輸應該是非同步的。可以使用文件來傳輸、或者使用面向消息的（MoM）中間件來實現。由於數據非同步傳輸，所以數據採集過程的吞吐量可以大大高於大數據系統的處理能力。 非同步數據傳輸同樣可以在大數據系統和不同的數據源之間進行解耦。大數據基礎架構設計使得其很容易進行動態伸縮，數據採集的峰值流量對於大數據系統來說算是安全的。

如果數據是直接從一些外部資料庫中抽取的，確保拉取數據是使用批量的方式。

如果數據是從feed file解析，請務必使用合適的解析器。例如，如果從一個XML文件中讀取也有不同的解析器像JDOM，SAX，DOM等。類似地，對於CSV，JSON和其它這樣的格式，多個解析器和API是可供選擇。選擇能夠符合需求的性能最好的。

優先使用內置的驗證解決方案。大多數解析/驗證工作流程的通常運行在伺服器環境（ESB /應用伺服器）中。大部分的場景基本上都有現成的標准校驗工具。在大多數的情況下，這些標準的現成的工具一般來說要比你自己開發的工具性能要好很多。

類似地，如果數據XML格式的，優先使用XML（XSD）用於驗證。

即使解析器或者校等流程使用自定義的腳本來完成，例如使用java優先還是應該使用內置的函數庫或者開發框架。在大多數的情況下通常會比你開發任何自定義代碼快得多。

盡量提前濾掉無效數據，以便後續的處理流程都不用在無效數據上浪費過多的計算能力。

大多數系統處理無效數據的做法通常是存放在一個專門的表中，請在系統建設之初考慮這部分的資料庫存儲和其他額外的存儲開銷。

如果來自數據源的數據需要清洗，例如去掉一些不需要的信息，盡量保持所有數據源的抽取程序版本一致，確保一次處理的是一個大批量的數據，而不是一條記錄一條記錄的來處理。一般來說數據清洗需要進行表關聯。數據清洗中需要用到的靜態數據關聯一次，並且一次處理一個很大的批量就能夠大幅提高數據處理效率。

數據去重非常重要這個過程決定了主鍵的是由哪些欄位構成。通常主鍵都是時間戳或者id等可以追加的類型。一般情況下，每條記錄都可能根據主鍵進行索引來更新，所以最好能夠讓主鍵簡單一些，以保證在更新的時候檢索的性能。

來自多個源接收的數據可以是不同的格式。有時，需要進行數據移植，使接收到的數據從多種格式轉化成一種或一組標准格式。

和解析過程一樣，我們建議使用內置的工具，相比於你自己從零開發的工具性能會提高很多。

數據移植的過程一般是數據處理過程中最復雜、最緊急、消耗資源最多的一步。因此，確保在這一過程中盡可能多的使用並行計算。

一旦所有的數據採集的上述活動完成後，轉換後的數據通常存儲在某些持久層，以便以後分析處理，綜述，聚合等使用。

多種技術解決方案的存在是為了處理這種持久（RDBMS，NoSQL的分布式文件系統，如Hadoop和等）。

謹慎選擇一個能夠最大限度的滿足需求的解決方案。

4. 數據存儲中的性能技巧

一旦所有的數據採集步驟完成後，數據將進入持久層。

在本節中將討論一些與數據數據存儲性能相關的技巧包括物理存儲優化和邏輯存儲結構（數據模型）。這些技巧適用於所有的數據處理過程，無論是一些解析函數生的或最終輸出的數據還是預計算的匯總數據等。

首先選擇數據範式。您對數據的建模方式對性能有直接的影響，例如像數據冗餘，磁碟存儲容量等方面。對於一些簡單的文件導入資料庫中的場景，你也許需要保持數據原始的格式，對於另外一些場景，如執行一些分析計算聚集等，你可能不需要將數據範式化。

大多數的大數據系統使用NoSQL資料庫替代RDBMS處理數據。

不同的NoSQL資料庫適用不同的場景，一部分在select時性能更好，有些是在插入或者更新性能更好。

資料庫分為行存儲和列存儲。

具體的資料庫選型依賴於你的具體需求（例如，你的應用程序的資料庫讀寫比）。

同樣每個資料庫都會根據不同的配置從而控制這些資料庫用於資料庫復制備份或者嚴格保持數據一致性?這些設置會直接影響資料庫性能。在資料庫技術選型前一定要注意。

壓縮率、緩沖池、超時的大小，和緩存的對於不同的NoSQL資料庫來說配置都是不同的，同時對資料庫性能的影響也是不一樣的。

數據Sharding和分區是這些資料庫的另一個非常重要的功能。數據Sharding的方式能夠對系統的性能產生巨大的影響，所以在數據Sharding和分區時請謹慎選擇。

並非所有的NoSQL資料庫都內置了支持連接，排序，匯總，過濾器，索引等。

如果有需要還是建議使用內置的類似功能，因為自己開發的還是不靈。

NoSQLs內置了壓縮、編解碼器和數據移植工具。如果這些可以滿足您的部分需求，那麼優先選擇使用這些內置的功能。這些工具可以執行各種各樣的任務，如格式轉換、壓縮數據等，使用內置的工具不僅能夠帶來更好的性能還可以降低網路的使用率。

許多NoSQL資料庫支持多種類型的文件系統。其中包括本地文件系統，分布式文件系統，甚至基於雲的存儲解決方案。

如果在互動式需求上有嚴格的要求，否則還是盡量嘗試使用NoSQL本地（內置）文件系統（例如HBase 使用HDFS）。

這是因為，如果使用一些外部文件系統/格式，則需要對數據進行相應的編解碼/數據移植。它將在整個讀/寫過程中增加原本不必要的冗餘處理。

大數據系統的數據模型一般來說需要根據需求用例來綜合設計。與此形成鮮明對比的是RDMBS數據建模技術基本都是設計成為一個通用的模型，用外鍵和表之間的關系用來描述數據實體與現實世界之間的交互。

在硬體一級，本地RAID模式也許不太適用。請考慮使用SAN存儲。

5. 數據處理分析中的性能技巧

數據處理和分析是一個大數據系統的核心。像聚合，預測，聚集，和其它這樣的邏輯操作都需要在這一步完成。

本節討論一些數據處理性能方面的技巧。需要注意的是大數據系統架構有兩個組成部分，實時數據流處理和批量數據處理。本節涵蓋數據處理的各個方面。

在細節評估和數據格式和模型後選擇適當的數據處理框架。

其中一些框架適用於批量數據處理，而另外一些適用於實時數據處理。

同樣一些框架使用內存模式，另外一些是基於磁碟io處理模式。

有些框架擅長高度並行計算，這樣能夠大大提高數據效率。

基於內存的框架性能明顯優於基於磁碟io的框架，但是同時成本也可想而知。

概括地說，當務之急是選擇一個能夠滿足需求的框架。否則就有可能既無法滿足功能需求也無法滿足非功能需求，當然也包括性能需求。

一些這些框架將數據劃分成較小的塊。這些小數據塊由各個作業獨立處理。協調器管理所有這些獨立的子作業?在數據分塊是需要當心。

該數據快越小，就會產生越多的作業，這樣就會增加系統初始化作業和清理作業的負擔。

如果數據快太大，數據傳輸可能需要很長時間才能完成。這也可能導致資源利用不均衡，長時間在一台伺服器上運行一個大作業，而其他伺服器就會等待。

不要忘了查看一個任務的作業總數。在必要時調整這個參數。

最好實時監控數據塊的傳輸。在本機機型io的效率會更高，這么做也會帶來一個副作用就是需要將數據塊的冗餘參數提高（一般hadoop默認是3份）這樣又會反作用使得系統性能下降。

此外，實時數據流需要與批量數據處理的結果進行合並。設計系統時盡量減少對其他作業的影響。

大多數情況下同一數據集需要經過多次計算。這種情況可能是由於數據抓取等初始步驟就有報錯，或者某些業務流程發生變化，值得一提的是舊數據也是如此。設計系統時需要注意這個地方的容錯。

這意味著你可能需要存儲原始數據的時間較長，因此需要更多的存儲。

數據結果輸出後應該保存成用戶期望看到的格式。例如，如果最終的結果是用戶要求按照每周的時間序列匯總輸出，那麼你就要將結果以周為單位進行匯總保存。

為了達到這個目標，大數據系統的資料庫建模就要在滿足用例的前提下進行。例如，大數據系統經常會輸出一些結構化的數據表，這樣在展示輸出上就有很大的優勢。

更常見的是，這可能會這將會讓用戶感覺到性能問題。例如用戶只需要上周的數據匯總結果，如果在數據規模較大的時候按照每周來匯總數據，這樣就會大大降低數據處理能力。

一些框架提供了大數據查詢懶評價功能。在數據沒有在其他地方被使用時效果不錯。

實時監控系統的性能，這樣能夠幫助你預估作業的完成時間。

6. 數據可視化和展示中的性能技巧

精心設計的高性能大數據系統通過對數據的深入分析，能夠提供有價值戰略指導。這就是可視化的用武之地。良好的可視化幫助用戶獲取數據的多維度透視視圖。

需要注意的是傳統的BI和報告工具，或用於構建自定義報表系統無法大規模擴展滿足大數據系統的可視化需求。同時，許多COTS可視化工具現已上市。

本文將不會對這些個別工具如何進行調節，而是聚焦在一些通用的技術，幫助您能打造可視化層。

確保可視化層顯示的數據都是從最後的匯總輸出表中取得的數據。這些總結表可以根據時間短進行匯總，建議使用分類或者用例進行匯總。這么做可以避免直接從可視化層讀取整個原始數據。

這不僅最大限度地減少數據傳輸，而且當用戶在線查看在報告時還有助於避免性能卡頓問題。

重分利用大化可視化工具的緩存。緩存可以對可視化層的整體性能產生非常不錯的影響。

物化視圖是可以提高性能的另一個重要的技術。

大部分可視化工具允許通過增加線程數來提高請求響應的速度。如果資源足夠、訪問量較大那麼這是提高系統性能的好辦法。

盡量提前將數據進行預處理，如果一些數據必須在運行時計算請將運行時計算簡化到最小。

可視化工具可以按照各種各樣的展示方法對應不同的讀取策略。其中一些是離線模式、提取模式或者在線連接模式。每種服務模式都是針對不同場景設計的。

同樣，一些工具可以進行增量數據同步。這最大限度地減少了數據傳輸，並將整個可視化過程固化下來。

保持像圖形，圖表等使用最小的尺寸。

大多數可視化框架和工具的使用可縮放矢量圖形（SVG）。使用SVG復雜的布局可能會產生嚴重的性能影響。

7. 數據安全以及對於性能的影響

像任何IT系統一樣安全性要求也對大數據系統的性能有很大的影響。在本節中，我們討論一下安全對大數據平台性能的影響。

- 首先確保所有的數據源都是經過認證的。即使所有的數據源都是安全的，並且沒有針對安全方面的需求，那麼你可以靈活設計一個安全模塊來配置實現。

- 數據進過一次認證，那麼就不要進行二次認證。如果實在需要進行二次認證，那麼使用一些類似於token的技術保存下來以便後續繼續使用。這將節省數據一遍遍認證的開銷。

- 您可能需要支持其他的認證方式，例如基於PKI解決方案或Kerberos。每一個都有不同的性能指標，在最終方案確定前需要將其考慮進去。

- 通常情況下數據壓縮後進入大數據處理系統。這么做好處非常明顯不細說。

- 針對不同演算法的效率、對cpu的使用量你需要進行比較來選出一個傳輸量、cpu使用量等方面均衡的壓縮演算法。

- 同樣，評估加密邏輯和演算法，然後再選擇。

- 明智的做法是敏感信息始終進行限制。

- 在審計跟蹤表或登錄時您可能需要維護記錄或類似的訪問，更新等不同的活動記錄。這可能需要根據不同的監管策略和用戶需求個性化的進行設計和修改。

- 注意，這種需求不僅增加了數據處理的復雜度，但會增加存儲成本。

- 盡量使用下層提供的安全技術，例如操作系統、資料庫等。這些安全解決方案會比你自己設計開發性能要好很多。

8. 總結

本文介紹了各種性能方面的技巧，這些技術性的知道可以作為打造大數據分析平台的一般准則。大數據分析平台非常復雜，為了滿足這種類型系統的性能需求，需要我們從開始建設的時候進行考量。

本文介紹的技術准則可以用在大數據平台建設的各個不同階段，包括安全如何影響大數據分析平台的性能。

Ⅶ 如何做一名優秀的數據產品經理

如何成為一名優秀的產品經理？
心裡要有 Ownership，就是要用心。
什麼叫用心？如果你千辛萬苦、嘔心瀝血攢下幾十萬做首付買了套房子，你每天花很多時間在網上搜索，每天到建材城和賣建材的人鬥智斗勇，用什麼瓷磚和燈具，裝什麼馬桶和傢具，價格、材質、種類等等，無所不曉。我敢肯定，用不了多久，你就能成為一個裝修專家，因為這是你自己的房子。只要心中有 Ownership，只要努力，哪怕是一個外行，也能夠成為專家。我相信，如果一個人能拿出這樣的精神來做產品，那麼他沒有理由不成為一個優秀的產品經理。
如果心中沒有 Ownership，就是把自己看成是一個打工的，給老闆打工，給領導打工，只要他們點頭就OK，那永遠都不可能成為一個優秀的產品經理。你可能會說，那我干別的，此處不養爺，自有養爺處。但只要抱著打工的心態做事，你到哪裡都只能是混，要想出類拔萃，那就只能等下一輩子。
優秀的產品經理心裡都有一個大我，他不是對老闆負責，而是對產品負責，對用戶負責，他甚至會把這個產品看成你自己的孩子。比如說，你如果是一個設計師，除了美化、潤色、做方案，是不是也用心地去了解這個產品怎麼回事？用戶是什麼樣的人？用戶為什麼用這個產品？他在什麼場景下用？這個產品給用戶創造什麼價值？如果說一個技術工程師只滿足於堆出一堆代碼實現了一個產品功能，但根本沒有想過自己在這個過程中通過積極參與可以讓產品得到很多改善，或者對於自己認為不對的地方，也不想提出自己反對意見，這樣的技術工程師就不要抱怨自己是 IT 民工，因為這樣思維方式就註定了他一定是一個 IT 民工。
將心比心，學會從用戶角度看問題。
一個優秀的產品經理，除了心裡有一個大我，敢於承擔責任，心裡還要有個小我，甚至忘我、無我，這就是說要將心比心，把自己當成用戶，從用戶的角度來看問題。用戶體驗這個詞這幾年很流行，但為什麼叫做用戶體驗，而不是叫產品經理體驗，或者叫老闆體驗？因為我們做產品，無論有多麼好的技術，有多麼好的設計，最終評價好還是不好的，是用戶，不是產品經理，更不是老闆。老闆、產品經理、行業專家選擇一個產品的理由，與用戶選擇一個產品的理由，很多時候是大相徑庭。你覺得好的產品，用戶不一定買賬。如何學會從用戶的角度出發，換位思考，說起來是一件很簡單的事，但是實際上很難做到。因為每個人不管成不成功，都會積累自己的人生閱歷和經驗，他的思維會越來越慣性，突破既有思維模式難度大。通俗地講，這就是自我太強大了。在這種強大的自我下做產品，產品做著做著就變成了給自己做。
要突破這種慣性思維，我的建議是，第一要多讀書、多看報、多與其他人交流，用外來的一個嶄新的思維力量來打破自己頭腦里的框框。我建議產品經理們看報紙雜志的時候，少看行業類高端雜志，多看面向普通用戶的雜志，類似《電腦迷》、《電腦愛好者》、《電腦軟體》等，上面的內容對於技術員來說，可能簡單得可笑，但這些內容真的是普通用戶遇到的問題。多讀這樣的刊物，就能幫助你從用戶的角度出發看問題，正如我2012年1月在極客公園的活動上所說的，只有這樣做，你才能從用戶需求中找到真正的創新。
第二要適度的患上精神分裂症。以我自己為例，按理說我是程序員出身，做過產品，懂技術，什麼軟體到我手裡都不在話下。但是，當我看360軟體的時候，我會不自覺地就像變了一個人，變成了一個不懂計算機也沒有耐心的普通用戶，稍微有地方覺得不順眼或者沒找到想要的功能，就要摔滑鼠、砸鍵盤，心裡有一種沖過去卸載的沖動。這是我多年練出來的寶貴經驗，我認為其實任何人都能夠做到。從用戶角度出發來考慮問題，這對很多人來說不是能力問題，也是一個心態問題。所以，我教育公司里的很多人，要「像白痴一樣去思考，像專家一樣去行動」。這就是要求360的產品經理，要從對計算機一無所知的普通用戶角度看問題，發現問題後，要像技術專家一樣迅速採取行動。
處處留心，尋找改善用戶體驗的機會。
對於優秀的產品經理來說，改善用戶體驗的機會無處不在。一個優秀的產品經理，他的頭腦是開放的，他的視野並不局限在自己的行業和產品上。前幾年，我不幸摔傷了腿，架著拐杖樓上樓下跑，什麼掛號、門診、劃價、繳費、拍片，要問很多人才能找到科室，要跑很多路才能把這些事兒辦完。還有北京著名的西直門立交橋，司機上橋就跟進了叢林一樣，等你知道走錯了，已經來不及了。可以說，這些都是糟糕的用戶體驗。在日常生活中，用戶體驗無處不在。我們是產品經理，但當我們走出辦公室，我們就是使用其他產品的用戶。但我們不要做一個抱怨的用戶，我們要提升一個層次，抱怨完了之後，想一想其他人是不是像我們一樣去抱怨，我們應該怎麼其改善。你可能會說，嗨，這些事又不是我管，說了也沒用。誰說的？你不去嘗試，怎麼知道不管用？而且，這是一種思維訓練，我相信如果你能看到道路、交通、遙控器、汽車駕駛面板等很多糟糕的地方，你肯定能找到自己產品需要改進的地方。
臉皮厚，不怕罵，沒心沒肺。
一個優秀的產品經理，最重要的一個素質就是具備強大的心理素質，不怕罵，而且善於從罵聲中找到改善產品的機會。最好的產品雖然能解決用戶問題，但它不是完美的。沒有缺點的產品並不存在。優秀的產品經理追求的是極致，而不是完美。這就是說，做產品一定在某些打動用戶的點上做到最好，做到連競爭對手都望塵莫及，甚至絕望到不再追了。這個時候，真正的用戶使用產品不爽了就會抱怨，會罵；競爭對手也會雇很多人，模仿用戶的口吻來罵。面對鋪天蓋地的罵聲，有些產品經理會產生恐懼心裡，覺得是不是產品在方向不對。這個時候，我會鼓勵團隊說，競爭對手是我們的磨刀石，負面的信息里，即使是對手的槍稿，也要找到可以改進產品的啟發點。我們一定要研究他們的罵聲，想想產品有什麼地方可以改進的，最後讓他罵不出。這樣，競爭對手就成了我們的磨刀石，把我們的刀磨得越來越鋒利，我們手起刀落，就能把敵人斬於馬下。
沒心沒肺的另一個含義，就是不怕失敗。因為好的產品是不斷打磨出來的，好的用戶體驗絕對不是一次到位的。真正創新的產品，在剛問世的時候一定是粗糙的、醜陋的，看一看第一代蘋果電腦、Windows的早期版本、蘋果的第一部手機等等，粗糙、醜陋不要緊，可以改進，關鍵是一定要解決用戶的問題。
一個產品最後能成功，靠的不是一招制敵，更不可能是一炮而紅，它至少經過三年五年不間斷的打磨、不間斷的失敗、不間斷的嘗試。沒有堅忍不拔的心態，一個產品經理很難做出來好產品。有人說，做產品應該像做藝術品一樣，但藝術品可以只展示給少數人看，甚至藝術品是藝術家孤芳自賞，做給自己看的。但是，判斷一個產品是否成功，終究還是要看它在商業上是否取得成功，因此它必須要獲得大眾的認同。因此，產品經理必須要跟大眾溝通，，要能忍受來自各種用戶建議，哪怕這種建議看起來多麼乖張；要能忍受競爭對手的罵聲，哪怕這種罵聲是謠言。《弟子規》裡面有句話說：「聞譽恐，聞過欣。」這么高的道德要求，咱們普通人很難達到。但是作為產品經理，我們可以抱著一種欣喜的心態來看待批評，因為我們都知道，批評存在著改進產品的機會。
所以，優秀的產品經理要有一顆粗糙的心，要能夠做到沒心沒肺。