編輯導讀：對產品經理來說，學會做有效的競品分析并撰寫易讀的競品分析報告是必備技能之一。但在實際工作中，大部分人的報告都停留在套用模板和堆砌信息的階段，看似框架完整、五臟俱全，實則重點不清、價值不高。具體該怎么做呢？本文作者從自身實踐出發，分享了撰寫競品分析報告的相關方法經驗，供大家一同參考學習。

小白也能夠寫出一篇就說服力的競品分析報告嗎？讓你地位提升，不在被指手畫腳，只能畫原型圖，只會被讓做功能，開會說話被無視！做一個有說服力的產品，不是da（打）成一致，優質的競品分析報告就是武器，讓弱勢的PM們站起來~

如何做一篇競品分析報告？我想每個人都有自己的那一套方法，在這里我做一下自己的分享，資深運營人員養成的習慣下，是怎么去做一個競品分析報告的。

一、運營轉產品和純產品出身思維路徑的主要區別

運營出身讓我思維會從對方、商業化、用戶、未來運營角度去思考產品，是我核心競爭力之一，也是讓我面向領導和開發們能夠做出最具說服力的產品設計的原因。

1.1 每個人的性格、工作經歷、學習習慣決定了思維上最大化的差異來源

思維方式上的差異，在之前并沒有深度去思考，其實筆者和一般純產品/技術出身產品最大的差異是思維的廣度，筆者最主要的缺陷在于純產品方向的，思維方式差異都是有跡可循的。運營出身的重視商業化和運營需求，UI出身重視界面和視覺體驗，技術出身可能注意產品邏輯和實現上難度，純產品出身基于個人學習路徑會導致重心差異。

筆者是基于用戶和運營多維度思考比較多，為什么呢？因為平時比較喜歡去收集和整理產品運營知識，盤感興趣行業的商業模式，看行業研究報告，關注最新動態及頭部公司調整思考運營方式和組織結構的變化等。

知識和信息獲取渠道比較復雜，但是以市場、運營和商業相關的比較多。

1.2 運營的思維路徑

（1）商業模式是什么？

做產品的開始，是基于我公司商業模式的理解，在我看來所有一切產品及功能都是圍繞著商業模式展開的，商業模式不同會導致產品設計思路、風格、注重點完全不同；商業模式不一樣，產品的設計內容，

支付寶主要以支付為核心，掃一掃、付錢/收錢為核心，其他的應用和服務，都是為了圍繞著創造更多的支付場景和環境，提高使用頻次和誕生的，甚至政務類型的都完全不賺錢的。

微信以社交為核心，最難的不是現在，而是在12-16年間形成用戶社交網絡那段時間，現在已經無法顛覆，現在微信的產品設計思維就是讓更多的用戶使用，并且在這個流量池子里不停地孵化各類型服務。

（2）設計的功能是為了解決什么問題？

在我看來，設計產品一定是基于某一個目的展開的，銷售、用戶增長、凈利潤、用戶體驗、用戶活躍等目的，基于目的展開進一步思考；

（3）功能的價值

長期做運營管理后的習慣，設計的功能會對運營有什么好處，整體價值是什么，只是為了解決功能性問題，基于用戶的運營需求，還是銷售額增長；

（4）業務路徑是什么？轉化為產品路徑？

業務路徑可以理解為怎么去賺錢，產品路徑其實是用戶整條線上的操作路徑和體驗流程，在這個流程里會涉及到的信息字段和數據，完成信息結構圖；

（5）產出信息結構圖、體驗路徑和原型

對照行業類似的產品，凝練和理解后產出體驗流程圖、信息結構圖、原型等；如果沒有類似的，就尋找框架非常像的來參照；

（6）產出PRD文檔完成設計

之前的思考，已經足夠完成PRD文檔；

1.3 產品的思維路徑

（1）產品類型什么？

產品的類型基本決定了產品設計風格和大致功能，純產品出身的PM思考的會不一樣，就是這是什么類型產品，并非說產品經理不會基于商業模式思考，而是第一時間想到的是產品類型，確認風格后，再進行用戶畫像、競品調研、產品設計等工作；

（2）為什么樣的用戶設計這款產品

即使是很簡單的一個功能設計，那首先也是需要理解整個產品面向的用戶是什么，有什么特性。就是刻畫用戶畫像出來，明白的他們有什么特性，那基于功能設計，細節上的要點自然會注意到。

（3）競品是怎么做的？

這里是需要做常規的那一套競品調研，即使時間來不及，也需要去理解競爭對手的產品邏輯是什么，才能讓自己快速有思路，做得更好。

（4）產品路徑是什么？哪些地方可以有更好的體驗？

C端產品，有一個原則就是讓用戶使用的更加舒服，B端是滿足用戶們的商業化需求；產品是怎么一步一步操作，實現功能需求的？

（5）產出信息結構圖、體驗路徑和原型

基于競品調研和產品的路徑分析以后，對產品整體和信息結構有一個整體的思考，在這個基礎上已經能夠完整的形成信息結構圖、

（6）產出PRD文檔完成設計

到這一步，都一樣的；

二、如何去寫一篇競品調研報告？

產出或者寫一篇競品調研報告，本身并不復雜，很多萌新在一開始的時候主要很可能缺乏框架性的思維，缺乏一個套路，一個模板。初期模仿別人寫的去寫，到后期其實不必完全拘泥于別人的模板或者套路，可以有自己的一些思考，然后添加自己需要的內容。

2.1 一個思維導圖——競品調研報告的大綱或框架

Why？因為，沒有框架，你的個人工作從哪里展開都不知道，沒有思路甚至無法思考。因此，一開始的時候，去人人都是產品經理或者天天問上去扒一下大佬們，或者擁有成熟競品調研會寫一些什么。

對于我來說，可能會非常簡單，在做產品后，因為以前寫BP和公司內部商業分析的時候積累了很多經驗。

2.2 互聯網醫療相關的商業模式

設計的是一個互聯網醫療的掛號功能的競品調研報告，互聯網+醫療產品的大部分服務，都是基于掛號+在線問診展開的，并且最早互聯網+醫療的商業模式就是基于掛號獲取流量，在通過其他方式變現，開始的。

互聯網預約掛號服務是指運用互聯網和移動互聯網技術，由醫院/第三方服務機構向患者提供的掛號、手術、住院、專家團隊和合作機構的預約服務，很好地解決了就醫壓力的問題。

而且是可以拿到掛號行業里對應功能的數據，并且該功能對于互聯網醫療產品來說，就是基礎是開始，圍繞著用戶需求、平臺運營、醫生需求和醫生的運營管理，基本可以囊括所有面向C端的互聯網+醫療的產品需求。，

三、解讀競品調研報告的內容

3.1 調研背景

公司內部基于什么情況下做的競品調研

3.2 調研目的

從競品調研中發現功能最佳優化和迭代方向，產品路徑設計到原型設計等；

3.3 行業分析

行業背景可以從艾瑞咨詢、易觀智庫和行業新聞上去獲??；行業情況，需要看目前行業發展階段做展開，上升期和成熟期的行業，側重點會有一些區別；

3.4 市場分析

目前市場情況，競爭格局，類似和已有的玩家一般商業模式如何？自己公司在這樣關環境里，哪些地方還有機會？（市場、運營、用戶等多維度）

3.5 競品分析

競品概述、競品分析，從流程、體驗、界面等展開，需要具象到每一款產品，分別詳細的描述缺乏（缺了詳細描述）；

（1）競品概述

簡要概述競爭對手的情況，從經營情況、商業模式、規模、運營等一切能夠想象到的維度去描述，然后進行對比，可以輔助自己決策，也可以快速讓領導理解競品經營現狀大致是什么樣的。

（2）競品分析

這里需要很具體，就是從操作體驗、流程、界面設計、特殊的細節等，一切是為了對比相同和不同，獲取最佳的產品路徑、原型、用戶體驗方案。

3.6 用戶調研和分析

調研和分析是為了產出結論，沒有結論只是描述，還不如不做了；主要集中于用戶畫像、用戶行為分析，設計問卷進行問卷調查差等；

（1）用戶畫像框架

（2）問卷調查設計框架

四、后競品調研的工作簡述

4.1 有說服力的產品經理——產出競品調研報告和PPT

（1）競品調研報告word文件

當時基于功能寫了一個18頁的word文件，詳細地把整個框架下的東西都寫出來了，給自己看也是未來產品內部迭代的核心依據，作為向領導匯報的基礎。為了說服領導、開發和公司。

（2）競品調研PPT

寫PPT目的只有一個——給領導匯報，當時寫了46頁的匯報PPT，然后向領導從頭講到尾去描述行業市場情況什么樣子的、競爭對手在做什么、從哪些方面去做、為什么這么做、最后產品方案是什么。

4.2 扎實的產品經理——產品之外的細節和技能

（1）細節——（字段、數據、流程、特殊用例… ）

完成競品調研報告后，信息結構圖、用戶體驗流程圖、PRD文檔和原型后，將會開始內部評審，在這個過程中需要重點考慮細節（字段、數據、流程、特殊用例），不然開發后就會有坑，而且該動起來很麻煩。

（2）溝通——基于公司需求、業務、用戶等去說服

寫的再好的PPT只是PPT，最后還是需要去和UI、開發溝通，最后把產品開發出來，這個時候他們可能會有很多問題，說服他們進行工作排期和未來開發最大的依據就是為什么要這么做？而且，注意技巧，大家是合作方式，如果別人不愿意，那就需要從對方工作的角度去和對方溝通，否則… …記住了，產品經理是整體的弱勢方，不要成為背鍋俠，也不要讓別人背鍋。

五、后記

這是自己第n次進行產品競品調研的分析，運營時期是分析了為了寫BP和戰略，所有的技能基礎都是一樣的，冰山模型下很多可遷移技能，善用他們并且不斷強化他們，才會是未來每一個人最大的核心競爭力之一。

已經快3個月沒有進行更新了，自己換工作的事、事業、夢想和現實各種摻雜在一起，導致精力沒那么多，現在恢復更新了，計劃年底產一篇行業分析，關于VR社交/Facebook等的，也請大家期待一下吧。

六、免責聲明

大家如需交流或者侵權等，請發郵箱：aigbert.li@qq.com，或者加微信Aigbert-Aquarius，歡迎各位指正和交流。

#專欄作家#

LS邋遢道人，公眾號：LS邋遢道人，人人都是產品經理專欄作家。資深運營和產品，連續創業者，現任某公司產品負責人。關注虛擬現實、虛擬增強、電商、新零售和生鮮領域，擅長運營分析、行業分析和產品分析。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議