AI時代的產品思維:如何打造具有商業可行性的AI產品? | 人人都是產品經理

編輯導語:當人工智慧逐漸被普及應用到更多場景時,產品+人工智慧也逐漸成為產品人們所要考慮的事情。那麼,如何挖掘AI產品需求、實現產品落地?我們又該如何定義智能服務和智能體驗?本文作者便結合其經驗向我們展示了他的看法。

如今越來越多的產品經理也在考慮為自己的產品添加AI功能,但是事實上並沒有那麼容易。作為產品經理我經常能收集到各種AI產品的idea,有些甚至過於科幻,每當我們迫不及待地去實施的時候,結果總是狀況百出。

該如何選擇更好的技術方案或許是演算法工程師關注的領域,但對AI產品來說,如何管理好AI產品需求也是一個重要挑戰,這也是AI產品經理的使命所在。

這兩年的實踐中,我先後做了「Get寫作」和「互鏈文檔」兩款智能寫作產品,前者是針對新媒體寫作場景,後者是針對於日常筆記場景。不管是哪個場景,擺在我們面前最大的問題並不是「我們可以用AI打造一款怎樣與眾不同的產品」,而是「我們該怎麼去定義智能體驗」。

一、如何定義智能體驗?

學術界對於AI智能已經有了一些定義,人們期望AI像人一樣,能合理地思考和行動(出自《人工智慧——一種現代化的方法》),如下圖。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

從用戶體驗角度來看,AI產品的智能體現就是能合理地做出行為決策,換句話說就是「機器能根據輸入條件作出合理判斷並輸出結果」,我們暫且稱之為「自動化決策」。

例如,Siri能夠合理地回答你問題,雖然有些回答聽起來很搞笑,但只要輸出的結果讓人覺得合理,就依然會被人接受,如下圖。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

但AI的輸出是否合理,這個取決於人的主觀評判。這也是數據標註工作所做的意義所在——儘可能通過標註讓模型更能貼近人的預期。

當我們把一連串「自動決策」串聯在一起了后,就變成了一個自動化的業務流程,幫助人類省心省力地完成業務目標,這也是AI產品的價值體現。

例如,掃地機器人通過良好的定址演算法,趁主人不在家的時候掃遍房間的每一個角落,讓人覺得省心又省力。但如果在掃地過程中不斷需要主人來處理各種狀況,如卷了電線和異物,就算這些狀況和演算法無關,那也會讓人覺得不智能。

因此,AI產品的體驗效果並不一定取決於演算法,而是在產品使用過程中是否能流暢地達到用戶預期的目標或價值。

綜上,最終決定產品的智能體驗感的核心還是在於經過AI的一系列自動決策后,能更好地滿足業務場景中的需求。

二、AI產品需求的挖掘與管理

根據前面的分析,所謂的AI產品需求管理,首先要挖掘那些能夠自動化決策的需求點。其次當這些需求點串聯在一起的時候,讓產品整體能達到較好的使用體驗。

前者和演算法有關,後者不僅僅局限於演算法,如下圖所示:

需要強調的是,不管技術手段如何變,產品經理始終都需要以實現商業價值為目標,以用戶體驗為中心,選取具有可行性的技術手段和方案。

但反觀目前市面上的一些AI產品經理的資料,通篇照搬AI技術的概念,而忽視了產品本質,這是一種舍本求末的表現。

在AI產品需求分析與整理的過程中,我們總結了以下四個關鍵步驟:

  1. 收集場景案例;
  2. 繪製決策流程;
  3. 篩選可行性用例;
  4. 制定AI產品路線圖。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

1. 收集場景案例

我們要教會AI決策,我們就要必須弄清楚人是怎樣做決策的。我們應當以實現業務價值為最終目標,專註分析業務場景中的問題。在項目早期,收集實際場景中的業務案例顯得尤為重要。

我們可以將收集的案例整理成一個個表格或者卡片,包含要素有:場景概述、業務目標、業務流程、關鍵決策點、業務痛點、過往案例。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

  • 場景概述:用最簡潔的一句話說明該場景中的業務要點「誰——做什麼——為什麼做」,這類似於敏捷開發中的「用戶故事」;
  • 業務目標:用於明確業務要達成的最終結果,並為自動決策獲得一個可衡量標準。我們可以尋找業務中一些量化的KPI,這不僅是對人的考核也是對AI的考核;
  • 主要業務流程:主要是為了弄清楚當前的系統運行情況,比如在原有的人工的業務流程是怎麼樣的?現有的業務流程中有哪些優點或者缺點?
  • 關鍵決策點:找到關鍵邏輯決策點,在流程中人是如何做決策的?判斷的效率怎麼樣?判斷規則是什麼?要輸出怎樣的結果?
  • 業務痛點:找到產品能夠發揮價值的地方,有哪些痛點?有哪些抱怨?
  • 過往的成功與失敗的案例:主要是為了弄清楚一些真實情況。能否舉出一個或者多個成功的案例?能否舉出一個或者多個失敗的案例?失敗的原因是什麼?會怎麼樣處理?

在我接觸過的項目中,一些業務方對錶格中的問題會表現得一臉懵逼,原因很簡單,自己都沒有弄清楚自己業務的SOP(標準作業程序),就期望AI來幫他們解決問題。

這種情況,還是需要由人類先摸索出有價值的SOP,因為人做不好的,AI肯定也做不好。

如下圖,CRM客戶挖掘的業務場景案例。每天,客服人員需要撥打大量的電話,找到對產品感興趣的客戶,以便於銷售人員跟進。對於客服人員來說,工作量大而且重複,容易讓人煩躁。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

通過這樣的收集和整理,讓我們對要解決的問題和場景有一個直觀的感知,但隨著調查的深入我們還可能會發現新的問題。

為了不遺漏有價值的信息,這個階段我們收集的案例,應該有更多發散性。

2. 繪製決策流程圖

通過業務案例的收集,我們可以梳理出一個業務流程圖,我們可以使用「UML活動圖」來繪製,並且我們還要重點標識出決策的判斷點。如下圖:

如圖所示,起點是挑選客戶資料,結束點是標記出有意願的A類的客戶。

為了更加明確,我們將主流程(Happy path)放到主軸上面,代表決策的菱形節點放在兩邊,我們可以一目了然,看到那些通向「幸福Happy」的關鍵決策。

先不考慮任何實現手段,我們需要先弄清楚,每一個決策點的輸入、輸出和規則是什麼。我們可將這些決策點整理成一份「決策用例清單」,然後再綜合考慮是否合適AI自動化決策。

註:用例(Use Case)是UML中術語,一個用例代表一個完整的系統功能單元,但不考慮該系統的內部實現細節。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

另外,我們還可以將此清單整理成UML用例圖,這個系統參與者有三個:客服、客戶、AI。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

3. 篩選可行性用例

根據上面的用例,AI該如何與人類一起工作呢?

並不是所有「決策」都是適合機器做,機器做決策的特點是效率高速度快,但應變性弱。人類做決策的特點是靈活性高,但是容易產生疏忽和遺漏等問題。我們可以用場景決策矩陣判斷,如下圖:

按照場景和決策兩個維度進行拆分,分成四個象限:

  • 常規性場景+信息性決策:對細節要求不高,學習案例多,AI學習效果較好,AI只提供信息建議,輔助人類決策,出錯的風險很低,特別適合AI來做;
  • 細膩性場景+信息性決策:對細節要求極高,學習案例少,AI做出正確判斷有難度,AI提供信息建議,由人類為主導AI輔助做決策,出錯風險低;
  • 常規性場景+行動性決策:對細節要求不高,學習案例多,AI學習效果較好,AI代替人類做行動決策,出錯有一定風險性,適合人類為主導AI做輔助;
  • 細膩性場景+行動性決策:對細節要求極高,學習案例少,AI做出正確判斷有難度,讓AI代替人類做行動決策有很大風險,建議人來做。

我們可以將上面的決策用例做一個基礎的判定。排布在場景決策矩陣如下:

通過這樣的分類方法,我們能很清楚的知道機器和人類應該怎樣分工,案例中大部分決策用例都可以交給機器,但「詢問進一步溝通的意圖」是很關鍵的一步,如果全權交給機器,效果將大打折扣。

這樣,我們就有了一張人與AI的分工圖:

AI時代的產品思維:如何打造具有商業可行性的AI產品?

這時我們有了兩條思路:

  1. 第一條思路,如果AI效果好的話,那麼全權負責整條鏈路,讓人在最後一步把關,這樣的好處是效率高;
  2. 第二條思路,AI作為一個輔助工具,幫助客服自動化篩選客戶信息,做好通話情況記錄和打分,一定程度有效提升客服效率,而且結果也可控。

到底哪個方案好呢?

一方面需要根據實際的業務需求判斷。例如,針對高端人群的產品,獲取客資成本高,對於這些高端客戶來說冷冰冰的機器人電話顯得沒有誠意,但是普通話不標準的銷售人員也可能讓人覺得是山寨推銷。

另外一方面,我們需要將需求對應到不同的技術模塊上,因為演算法產品有一定不確定性,貿然使用不成熟的技術,也承擔著巨大風險。作為產品經理,我們應積極與數據科學家和工程師溝通,或許他們也有更好的建議,對於產品經理來說,溝通永遠都是第一要務。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

4. 制定AI產品路線圖

AI和人一樣,需要一個成長過程,這個過程中需要不斷的積累數據和調整演算法策略。一個好的AI產品路線圖,需要給我們的產品規劃一個學徒期,從簡單的決策開始,再逐漸演變為更複雜的決策。

我們可以根據前面的演算法模塊的拆解,挑選出哪些需要優先做的模塊,我們可以從影響、努力、風險三個維度考慮。

我們優先選性價比高和風險較低的模塊,如果是一些通用性的演算法模塊也可以考慮使用大廠提供的服務。這樣保證產品功能完整性的同時,也降低了不確定性帶來的問題。

AI時代的產品思維:如何打造具有商業可行性的AI產品?

AI產品相比傳統產品更需要大量數據,我們需要提前做好數據埋點和反饋機制,確保產品上線后,能夠收集足夠的數據,充分了解各種決策及其完整上下文。這樣便於演算法工程師,持續的優化模型和演算法。

另外,為了更早的發現真實場景中的問題,我們需要讓用戶儘早地使用我們的產品。但是由於產品還在學徒期,功能不完善、體驗不確定,並不適宜大規模推廣。我們可以考慮通過邀請制,讓願意嘗鮮的用戶先體驗,這些用戶往往比普通用戶包容性更強也更加積極,願意提更多的意見和想法。

基於上面的幾點考慮,我將路線圖中的需求分成應用層需求和演算法層需求兩類。

應用層主要是指直接與用戶打交道的需求,這部分是偏傳統的軟體開發內容。

細分下去包含:決定產品使用體驗的功能性需求;和運營節奏息息相關的增長性需求,如邀請、裂變、積分等;還有用戶看不到的但能讓產品和服務變得更好的支持性需求,如產品後台、數據統計平台等。

演算法層是指與自動化決策息息相關的需求。

應用層與演算法層通過演算法服務提供API打交道,這些API需要根據應用層場景進行調整和優化。但演算法只有API是不夠的,還需要一些支持性的模塊,例如網路爬蟲和一些基礎演算法模型。

在產品早期,我們需要迅速驗證我們的業務方向和價值。所以,我們首先需要為用戶做好基礎場景的建設,並為AI的嶄露頭角預留出更多的空間,於此同時我們也需要做好演算法層的技術建設,然後再逐步引入種子用戶不斷優化產品。

而中期,我們需要提供更多的業務數據反哺演算法,做到人無我有的極致體驗。

最終,我們整理出我們的AI產品路線,讓我們的AI產品能夠從學徒期慢慢走向成熟。

三、結語

在這兩年的AI產品實踐中,我在產品經理、設計師、工程師之間來回切換角色,不僅僅是為了打造心中所想的產品,也是為了探尋心中的一個答案:AI時代,產品經理應該如何做產品。

過去一年,可謂一路狂奔,將原本寫產品需求的時間放到了寫代碼上,不知不覺中,我的github瓦片圖也快要被綠色佔滿。但值得慶幸的是,通過親手打造的產品,團隊也成功拿到了融資。

AI產品其實並不神奇,任何產品的商業價值都在於其對人類的價值。

只是不同的技術方案需要考慮的側重點會有所不同。

對於產品經理來說,科技在進步,思維方式需要迭代更新,但也不能全部捨棄,用「進化」這個詞來形容我們AI時代的產品經理可能更為貼切。

#專欄作家#

PM熊叔,微信公眾號:PM熊叔,人人都是產品經理專欄作家。教育類產品產品經理出身,學過設計,做過開發,做過運營的產品經理。

本文原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

給作者打賞,鼓勵TA抓緊創作!

1人打賞