開放平台的產品經理應該多注意哪方面的東西呢？

01-08

開放平台的產品經理，關注的核心點和平台的產品經理有比較大的差異。

最重要的是宏觀上了解用戶、平台、開發者三者的需求，並協調搞定各方。最常見的場景是，開發者需要一個 API，平台方覺得這個 API 沒必要，或者暫時不適合提供。此時開放平台的產品經理就需要在中間處理好各方需求。
開放平台的產品經理需要更了解圍繞 API 產生的「生態系統」，比平台本身的產品經理看得更遠一些。要能夠和開發者打成一片，開放平台的真正「用戶」是這些開發者，而不是最終的個人用戶。因此了解開發者的痛點和需求，最為重要。
其它基本要求。比如對文檔和 API 熟悉，自己動手開發過 App 更好。了解平台方在想什麼。

首先，有技術功底會更適合做開放平台，因為這確實是一個偏技術的產品。你只有親身使用過各家的開放平台，即基於其他的平台開發過應用，才能明白什麼樣的地方設計的好什麼樣的設計不好。至於有什麼要注意的地方，我節選一下我以前的PPT：

盲目複製國外的設計，沒有仔細理解開放API的設計思想；
WIKI與相關文檔撰寫不夠規範與細緻，讓新的開發者難以下手；
沒有形成好的生態圈與正向循環，沒有給予第三方充分的技術與運營支持，第三方難以從開放平台上獲得他們想要的效果；
設計開放API之前要考慮周全，對於第三方來說任何修改都是難以接受的，隨著第三方數量的增加，API的歷史遺留問題會越來越難以解決：
一定要為開放平台配備一名專門的測試人員，以及自動化測試工具，保障每個介面的可用性；
對第三方反饋的問題要給予及時的響應，避免傷害第三方的開發熱情；
文檔和WIKI要不停的維護更新，讓新的開發者能夠通過WIKI順利上手；
對第三方要給予一定上的運營支持，第三方繁榮你的開放平台才能繁榮。

不請自來

換個思路說說

開放平台類產品，就是把服務開放，給到用戶（開發者等）。難點在於平衡自家業務和用戶之間的利益點，另外開放平台的重點在用戶手機、業務多樣性、營收等等方面。作為合格的產品經理要找準的第一訴求點，用戶、營收等，如果能更進一步思考公司層面的商業故事，作為開放平台類產品，有很多可以講的故事，也有很多可以運作的點，這一點就是見仁見智了。

沒做過平台產品經理，但是深入接觸過開發平台方面pm，個人認為至少需要注意以下幾方面：

1、技術型pm是基礎，開發平台產品經理涉及很多底層技術架構方面的東西，技術出身可以更好理解需求；

2、雖然具體開放性和大方向是由大boss定的，但是開發平台的產品經理相對於具體產品線pm需要有更開闊的眼界，才能更好的規劃平台線產品；

3、良好的需求整合能力，各個產品線以及廣大開發者都會提出各種各樣的需求，平台pm需要整合好這些需求，以開發出更高性價比的api；

暫時想到這些...

開放平台的產品設計無非是圍繞下面幾點

開放平台的之初是在國外開始掀起的，從FACEBOOK開始推出圍繞自身數據和服務提供的開發API，慢慢的國內BAT等擁有大量數據服務的平台看到了互聯網潮流的方向，紛紛推出開放平台。不僅僅增加了自身用戶數據交換的量級。與C端產品設計不同的是，開放平台圍繞的是3者之間的關係。

平台-平台服務商-用戶

並且平台產品設計因為是B端產品，其需要與公司業務方向緊緊相聯，其商業模式需要圍繞著平台生態鏈、平台服務對象、以及之後的平台運營之路。

但雖然以BAT為首的開放平台都是以提供API介面的產品設計，產品設計過程中需要考慮開發者用戶的實用性，並且開放平台並不是只有提供API，在這裡開放平台也可以解釋為支持某種服務或應用。

開放平台產品體系

作為開放平台的產品經理，首先會有習慣調研用戶需求和競品分析。但遺憾的告訴你的是，作為開放平台產品設計，是很少有競品調研對比的。通常針對開發平台，其產品生態會有以下3個

開放平台

開放平台運營管理系統

用戶使用平台

開放平台顧名思義就是給予B端用戶使用的平台，在這裡可以通過鏈接相應API以及選擇相應平台提供的應用服務。

開放平台運營管理系統，針對開放平台建立的平台反饋機制和數據收集，收集用戶的需求進行更新完善，並且利於運營同學去運營。

至於開放平台運營，這裡不得不說他的特殊化運營。開放平台的運營既要保持平台的收益又要保持使用開放平台用戶的收益。

開放平台與假開放平台這裡有一個典型的說法：當用戶在你這裡其實不能獲得足夠的開發權益，那麼這個開發平台能力其實只是掛著開放平台的名義進行商業化變現。

開發平台在產品設計中，PM都需要考慮開發平台的固定流程

資格註冊——資格審核——測試通過——正常適用

針對於開放平台中，除了應用服務之外，其介面需要PM與開發一起定義如何完成說明

其中以下幾點，是產品經理需要注意的幾個介面關鍵值

介面地址——請求的網址。
請求方法——一般採用的是HTTP協議的POST和GET請求。
請求參數——你傳過去是什麼內容。
返回內容——就是你傳參數過去之後得到返回的內容，返回內容的格式一般為json或xml格式
錯誤代碼——也是返回內容的一部分，當介面發生一些意外情況時，錯誤代碼會告訴你原因。

在開放平台中，需要對於當前的介面正常顯示、錯誤顯示進行說明。或者提供相關WIKI給予用戶。

開放平台基於微信

開放平台提供的是給予開發者或B端用戶的一項基本服務，比如你做了一個酒店訂購的應用。但是沒有酒店數據，UI和UE以及商業模式再好，也沒用戶使用。

但常見面向C端用戶最多的開放平台基本服務是基於微信公眾號的基本服務。那麼針對微信公眾號的開放平台，我們對於介面可以直接使用微信公眾平台提供的介面。

以上為微信介面的截圖，可以根據賬戶體系的不同，平台給予公眾號的介面許可權是不同的。

因此開放平台除了產品與業務本身之外，其賬戶體系與許可權的產品設計需要與運營同學一起考慮。

通常常用的開放平台計費模式：按流量計費、按調用次數或使用服務多少收費

除此之外，開放平台的消息通知也需要面面俱到。能夠讓開放平台使用者隨時知道介面的變化和平台服務的變化。以下為微博平台之前的平台API變更通知

一、對待開放系統的現狀要了解清楚：

1、需要對系統自身的業務進行全面了解

2、需要對系統的用戶群和他們的喜好進行全面的分析

3、要知道哪些能開放，哪些不能開放

最忌諱對現有系統什麼都不了解就開始進行開放平台的工作，這樣真成了為了開放而開放了！

二、應該更關心技術、架構之外的東東

1、需要對開放的策略、原則進行分析

2、需要對開放平台的合作夥伴的合作和管理方式進行分析及落地（我覺得開放平台上的開發者管理模塊還是挺重要的）。

個人認為開放雖然是純技術層面的問題，但是最重要的關注點還應該是在怎麼合作、怎麼管理等這些策略等方面，只有這些東西梳理好了，才能保證開放帶來的雙贏,否則開放只能是一紙空談而已。

我沒有做過開放平台的項目，只是自己的一些想法而已，不知道對不對，請大家可勁的拍我啊！

任何產品的成功，均在於產品明確的定義了產品與服務對象的關係，並在設計時，確定了產品對服務對象的貢獻和影響力。

服務誰，就要讓誰覺得舒服，覺得值！

同理，開放平台如果想取得成功，要告訴我們平台的服務對象是誰？他需要什麼？他的難題是什麼？他獲取你的服務是不是很容易，很直接？瀏覽到你的服務內容但還未體驗時，是否第一感覺很心動？……

首先要清楚開放平台主要的用戶群是其他開發人員，因此要結合這個開放平台的主要目標領域，關注這些開發人員所關注的內容，構建良好的外圍環境很重要。

其次，作為開放平台本身來講主要是在設計並實現一整套開放API，不論這種API結構是多層次的還是單層的，都要儘可能的考慮細緻，極力的簡化第三方應用開發的複雜度和難度，叫開發人員專註於自己的業務邏輯，而不是開發API本身。

最後，無論是開發手冊、支持文檔、代碼樣例都要齊備，有些人喜歡step by step方式的說明，而另一部分人喜歡通過一個完整的例子學習，要對這兩部分人區別對待。

還有的就是針對各方反應的問題及新的需求一定要及時反饋和處理，不斷提高開放平台的整合能力，將原本複雜的問題做簡單了，這就是開放平台的魅力。

做開放平台對產品經理要求很高，有全局觀，開放思維，用過別人的開放平台API，熟悉開發者生態是基本要求了

說的都挺宏大的。說不定就是個制訂和維護API。有問題反饋推動給相應產品經理的人。夾在中間的人。

作為一個API產品經理的知識技能需要具備哪些？

又能雙贏, 又能賺錢, 又能不被別人反超!

生態~

推廣模式~

再沒有了，這兩個能摸明白的也不只能做好開放平台PM

請緊緊抓住，開放平台解決的的是一件由繁至簡的事情！