產品思維：從技術思考走向用戶思考

這個材料是2018年底，DevCloud內部的大咖說活動約稿，深感當時看到的一些問題，希望能夠通過自己微博的力量能夠影響一些人、至少推動問題改善一些，于是決定分享這個《產品思維：從技術思考走向用戶思考》的議題，最后是在2019年1月10日做的分享。此文中分享的材料主體沒有做改動，主要是替換了少量圖片，補充了一些圖片來源的說明，然后最后一頁的自我介紹，把最新的信息刷新上去了。

產品思維

從技術思考走向用戶思考

我覺得咱們沒有啥2C思維，所以專門先用第一頁講2B和2C的一些區別。不過現在來看，其實咱們還不是2B思維，咱們是2O或者叫2超大B思維，因為運營商實際上是一種特殊的B。一般的2B是指面向廣大的中小企業，和超大的NA企業，這兩個群體是有區別的。不過在此也不贅述了，還是回到當時材料里面的內容吧。簡單來說，2B業務，通常客戶企業真正的用戶是不直接跟我們廠商接觸的，而是客戶內部通常會有個代言人，比如IT部門的某個人，或者跟我們談項目的客戶側項目經理，會去收集需求，然后轉述給廠商這邊的BA（業務分析師）或PM（項目經理），但這個問題就在于，客戶側接口人可能并不是我們產品的使用者，可能無法準確理解真正用戶反饋的需求，進而導致表述失真，以及廠商側自身的傳遞失真，從而導致廠商側產品團隊接收到的信息與真正用戶發出的信息出現大偏差。而客戶側決策者往往不是真正用戶，所以在2B模式下，一家企業也只需要搞定少數幾個決策者或有能力影響決策的人即可，對于廣大的真正用戶，反而是不需要太關心的。但在2C模式下，每個用戶都是客戶，他們自己決定自己的錢包，而且由于數量眾多，廠商不可能有那么多的客戶經理、業務分析師、項目經理的資源，所以只能采取產品經理主導的模式，由產品經理通過面攻擊而非點攻擊或線攻擊的方式方法去理解用戶/客戶需求、解決問題，而團隊和產品經理是密切配合的關系，不是傳遞關系。

我基本上只用工行的卡和服務，所以用了工行來舉例，銀行基于自己的App提供的轉賬功能如下第一張圖，而且還需要用U盾，日常轉賬非常麻煩。當然，時至今日已經有了很多改變，比如說一定額度以下，使用工銀e支付可以直接免密支付，也變得更方便了，不過這不影響我們材料的主體思想，因為工銀e支付的這些功能恰恰就是他們開始擁抱2C思維的結果。第二張圖是我用了微信做例子，方便很多，也簡單很多，現在有了二維碼掃碼支付，就更便捷了。

我認為關鍵在于，在我們心目中，是否認為“用戶可以選擇”，用戶是否可以用腳投票。之前在IBM時候輔導過工行的研發中心，包括他們的網上銀行和手機銀行團隊。我發現他們的問題就在于業務方給研發的要求，基本上可以總結為，凡是柜臺有的業務，都要盡可能地全部在網上銀行提供，凡是網上銀行有的功能，也都要在手機銀行上提供。但是，我的天啦，柜臺、Web、手機，是三種完全不同的場景，用戶的行為和需求等各方面都是有很大的不同的，而且片面強調手機銀行上功能的全面性，而不顧用戶實際的使用情況，包括頻率和體驗等，是無法帶來好的效果的。前些年至今，支付領域的發展情況，大家也都看見了，用戶用腳投票的結果，哪種思路是有效的。

我們應該怎么做呢？就是要換位思考，轉變關注點，從關注供給側廠商自身的系統和技術，轉向關注另一側消費側的用戶和他們的體驗。

用戶到底想要什么？

那么，用戶到底想要什么呢？如下這張圖來自于《用戶思維+》這本書，我覺得非常棒，而且這個小測驗當時把我也給羞辱了一頓，所以我特別喜歡拿出來做例子。圖片就無法體現PPT的動畫效果了，大家可以先看圖片的左邊部分，你寧愿用戶有哪種感受？哪種場景更有可能成為預測可持續成功的標志？哪種場景可以激發更多誠實的口碑傳播？

A：這個產品棒極了！

B：這家公司棒極了！

C：這個品牌棒極了！

但實際上，正確答案是秘密選項D“我棒極了！”。這與我們的產品、我們的公司、我們的品牌無關。這與用戶對我們的感覺無關。與之有關的是用戶對自己的感受，也就是我們的產品或服務幫助他們做了什么或稱為什么樣子。

那具體我們應該怎么去成就卓越用戶呢？以及怎么讓用戶選擇我們來成就卓越的他們，而不是其他廠商呢？這就需要我們做好自己的價值主張設計。價值主張設計包括用戶群體是誰、他們要完成什么工作任務（JTBD，Job-to-be-DONE）以及他們對結果的期望、過程中的風險和阻礙，也即一般說的痛點；我們作為一家廠商，要怎么去幫助用戶解決問題、達成JTBD。注意，這個時候，還沒有到具體的產品功能或服務內容，而是先在方案層面，也即我們要提供什么樣的方案去確保用戶可以達成期望（得到他們想要的）、緩解痛點（應對風險、移除障礙）。例子有很多，網上隨便搜，比如最常被用來舉例的愛彼迎的價值主張設計圖。

如果你認可，那么，接下來的問題就是：你產品/服務的價值主張是什么？可以一句話說清楚嗎？

確保安全無憂、穩定可靠，只要找對了場景，也是一種價值主張哈。這方面可以參考KANO模型來分析，魅力因素可以認為就是業界說的爽點，期望因素可能算作癢點，必備因素應該就是痛點。

具體怎么做，我認為需要應用設計思維的方法，大家可以搜一搜斯坦福設計思維圖、IBM設計思維原則圖，公司內我印象中iLearning上面也有了課程，大家有很多資源可以學習了解，我這里就不再復述了。

創造產品的本質就是要創造英雄

讓用戶在使用我們產品和服務的過程中，能夠在我們的幫助下攻堅克難、達成所愿，成為更好的自己，這就是一個優秀產品的特點。而且時機很重要，在開場的時候，你想要去動員這個“未來的英雄”，基本上只可能會吃閉門羹，因為激勵事件還沒有發生，用戶對這個未來還沒有認知。

而且明確了故事線之后，我們就可以順著故事線去設計數據埋點，進而通過結果數據監控，來反向檢測我們的用戶體驗路徑設計是否合理，是否能夠產生我們預期的結果，并可以圍繞這個已明確的故事線進行復盤改進。

這跟業界流行的AARRR海盜指標思路也是吻合的。AARRR是一個具體的數據模型，適合SaaS類業務，但我們可以根據自己的業務特點，擬定出自己的轉化漏斗模型。而模型的每一個指標，都是我們故事線中能夠體現業務關鍵節點的關鍵指標。而每個指標都來自于對用戶關鍵行為的監控和度量，而這些關鍵行為就是用戶順著故事線不斷前進會產生出來的。所以，邏輯完美吻合。

故事線也非常有助于凝聚團隊共識，甚至直接用來管理開發進度。它可以明確我們廠商圍繞故事線各個節點，需要給用戶提供的產品功能和服務，每一張卡片就是一個Story（故事卡），所有人就都能夠很清楚，我們所做的功能對用戶行為所產生的價值，也都能夠明白我們工作的意義，不只是完成某些代碼的開發，而是為了成就卓越的用戶。而這種意義，正是《驅動力》書中指出的三大驅動力自主（Autonomy）、專精（Mastery）和目的（Purpose）其中之一。多嘴一句，其實我認為這個Purpose翻譯成“使命”或“使命感”更加貼切，也即是我記得公司一些高層領導曾經講過的，我們心中要有殿堂，這個殿堂其實也是一種使命感。

細節方面，設計要有人性。具體來說，就是要重視產品的UX設計（不等于UI設計；或稱UCD，但核心不是叫什么，核心是實質上是要聚焦于用戶體驗去設計產品的功能和使用與操作方式），我相信大家一定有吐槽過很多產品。在如下圖的這幾本書里，你會找到同感，我極力推薦大家閱讀。

然后是商業模式畫布，也不多說了。

精益擴張，這里也只是展示一下，還是推薦大家有時間可以看看這本書，我覺得非常棒。其中有個點很關鍵，就是我們要關注關鍵指標，而不是虛榮指標。當然，做到這一點，其實至少有兩方面的要求：一是要能夠真正理解業務，甚至是理解這個業務背后的時代背景，才能夠真正地識別和制定出關鍵指標；二是說如果我們知道什么是關鍵指標、什么是虛榮指標，然后還需要我們能夠克制，要堅定信念，去追求關鍵指標，而不要為了表面繁榮去追求虛榮指標。

其他一些對我們有幫助的理念和書籍。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。