“Google工作坊”后對B端產(chǎn)品日常工作的思考

1、 “Google工作坊”后對B端產(chǎn)品日常工作的思考 本文是筆者參加了“Google女性開發(fā)者大會”之后，對B端產(chǎn)品的日常工作的思考。文章講述的內(nèi)容包括：筆者對于B端產(chǎn)品需求搜集、B端產(chǎn)品需求提煉、B端產(chǎn)品工作心態(tài)等的思考。作為一個漢子，上上周（4月21日）有幸參與了“Google女性開發(fā)者大會”，參與活動當(dāng)然是學(xué)習(xí)知識啦（那位童鞋憋說話，順便看看小姐姐不行嘛_）。除了多位女性在臺上的分享讓我記憶猶新外，在“Designlab”工作坊（Google女性開發(fā)者大會分會場，關(guān)于B端產(chǎn)品設(shè)計的沙盤模擬）的活動也讓我收獲頗多。沙盤模擬的課題是“審批流程的重新設(shè)計”，當(dāng)Yvonne老師詢問是否用過“釘釘”

2、（辦公類型的即時通訊APP，支持線上審批的功能）時，大家都齊刷刷的舉起了手，并對接下來的課題信誓旦旦起來。這不，作為小組長的我就給起了個錯誤的頭，以至于在工作坊的沙盤模擬中，我所在的小組表現(xiàn)的并不突出?；顒咏Y(jié)束后，我在地鐵的車廂上復(fù)盤著活動中我們小組出現(xiàn)問題的同時，也思考起自己日常的工作。好久沒有寫產(chǎn)品相關(guān)的文章了，今天就借此機會寫下本文，歡迎各位看客老爺隨意拍磚工作坊中，我們小組大部分小伙伴使用過釘釘，日常工作中也有過人事申請的經(jīng)歷（如：請假），活動一開始我們就迅速在白板上整理我們的親和圖（以下來自百度百科：把大量收集到的事實、意見或構(gòu)思等語言資料，按其相互親和性（相近性）歸納整理這些資料，

3、使問題明確起來，求得統(tǒng)一認識和協(xié)調(diào)工作，以利于問題解決的一種方法）。當(dāng)我們小組粘貼活動親和圖上的便箋時，大家都發(fā)現(xiàn)了寫在便箋上的都是員工（申請人）相關(guān)的內(nèi)容，缺少主管（審批人）相關(guān)的內(nèi)容。就當(dāng)我們欣慰于在時間截止前完成第一階段任務(wù)時，大家從未思考過：審批人為什么這么煩呢？在哪些場景同時并存時會讓審批人不開心呢？從畢業(yè)到現(xiàn)在，我一直做B端的產(chǎn)品，Yvonne老師總結(jié)的好：“C端產(chǎn)品是自驅(qū)動，B端產(chǎn)品是商業(yè)驅(qū)動”，通俗地說B端產(chǎn)品就是能不能為企業(yè)高效地解決問題，并提高收益（C端的我還沒想好怎么概括）。與企業(yè)級、后臺業(yè)務(wù)打交道，很大一部分時間是在梳理業(yè)務(wù)流程，以及各個角色的權(quán)限與模塊功能，對底層邏輯

4、和架構(gòu)也有一定的涉及。沒錯，漸漸地我也有了工程師的思維。工程師思維當(dāng)然有益，讓一個人嚴(yán)謹、富有邏輯，追求流程、結(jié)果（如果你覺得我對工程師思維理解片面，歡迎在底部給我留言）。但在B端產(chǎn)品工作中，極容易被工程師思維帶偏，而忽視了用戶思維，所以做出的產(chǎn)品，邏輯上講得通，但用起來就會有種蹲在豪華廁所里拉不出屎的感覺。舉個簡單的小例子：我在做大數(shù)據(jù)可視化產(chǎn)品中，關(guān)于儀表板的存儲，在老版本文字描述為“權(quán)限歸屬”，一些新用戶初次用的時候會問我這個是什么意思。后來，我就在新版本把文字描述改為“存儲”，給很多新用戶演示后，他們都一致表明可以理解了。B端產(chǎn)品不像C端產(chǎn)品有很多第三方統(tǒng)計平臺，且不少產(chǎn)品都是私有化的

5、，保持用戶思維就需要對一手的需求提出方、觀察。雖然數(shù)據(jù)可視化產(chǎn)品的用戶是分析師、業(yè)務(wù)方（其他事業(yè)部的產(chǎn)品、運營），但是需求提出方卻更多的是分析師。剛開始我還YY著分析師提出需求背后的場景去設(shè)計，慢慢的，新功能上線后還是會出現(xiàn)很多問題。接下來要說一下B端產(chǎn)品的另一個特點：想用即來，用完即走。通俗一點說，就是我遇到問題才找你，你把我問題解決了我就和你拜拜了。所以，業(yè)務(wù)方在使用數(shù)據(jù)可視化產(chǎn)品時，他們關(guān)注的其實是身上背的KPI，更多地會想“只要不影響我看數(shù)據(jù)，需求給不給你提，要看心情”，這就是業(yè)務(wù)方不會跟我這個產(chǎn)品經(jīng)理過多溝通的原因。一方面，業(yè)務(wù)方的儀表盤需求是分析師去操作完成的；另一方面，儀表盤關(guān)系

6、著業(yè)務(wù)方的KPI（業(yè)務(wù)方依靠儀表盤觀看功能、活動上線后效果，查看用戶數(shù)據(jù)等）。很“功利”地說：在數(shù)據(jù)可視化產(chǎn)品上，業(yè)務(wù)方和分析師的親密關(guān)系，遠大于業(yè)務(wù)方和我這個產(chǎn)品經(jīng)理的。如果沒有業(yè)務(wù)方的需求必須經(jīng)過產(chǎn)品經(jīng)理，那只能突破這個困境了。創(chuàng)建用戶群、只要有機會接觸到業(yè)務(wù)方就不停追問（比如：申請賬號、系統(tǒng)掛了，此時業(yè)務(wù)方才會和我交流）當(dāng)然，這些改善還遠遠不夠，就像Grace跟我說的：你需要成為一個分析師！這或許就是為什么數(shù)據(jù)產(chǎn)品經(jīng)理的招聘JD上會說明“需要掌握SQL查詢語句”的原因吧。這條我還在前行中，過程中還得面對重重困難，我相信未來會給大家?guī)砗孟ⅲㄊ〉慕?jīng)驗也未嘗不可，哈哈）！最后，再啰嗦一句

7、為什么業(yè)務(wù)方的需求（含數(shù)據(jù)需求）對數(shù)據(jù)可視化產(chǎn)品來說至關(guān)重要呢？因為數(shù)據(jù)可視化產(chǎn)品要做到智能化，就需要自動推薦圖表樣式，Tableau（國際知名數(shù)據(jù)可視化產(chǎn)品）這點做得就很贊。這個問題出現(xiàn)在本次工作坊另一個小組身上，或許他們對釘釘審批都很了解，就直接把審批流程設(shè)計好了：員工端、主管端、人事申請、人事審批接著他們就直接把便箋貼在了對應(yīng)的區(qū)域內(nèi)，因為先限定了流程、方案，編寫的“用戶情境”就成了使方案成立的“”。沒錯，Yvonne老師當(dāng)場就指出了這個小組的問題：需求、方案是在調(diào)研大量數(shù)據(jù)后逐漸清晰的，預(yù)先設(shè)定邊界會讓我們忽略潛在的其他細節(jié)。為了讓需求搜集建立在充分、客觀的基礎(chǔ)上，Yvonne老師提到

8、了一個工具：錄音筆。在提煉需求時，可以有效地查缺補漏，也可以驗證是否加入了自己的主觀色彩。這是和C端產(chǎn)品要求相同的一點?？v觀自己近三年的產(chǎn)品工作，不管是之前做倉儲機器人產(chǎn)品，需要到倉庫中駐場揀貨；還是現(xiàn)在做數(shù)據(jù)可視化產(chǎn)品，需要成為業(yè)務(wù)方和分析師（這次工作我有些后知后覺，前期都泡在學(xué)習(xí)后臺邏輯了）。一切都是為了成為用戶，讓產(chǎn)品真正地解決用戶的問題。但是，B端產(chǎn)品面臨的問題也發(fā)生在這里，B端產(chǎn)品不像C端產(chǎn)品有意思，更多都是結(jié)合業(yè)務(wù)，甚至還會涉及到技術(shù)。這個答案大家可以在下方給我留言（hi，這位程序員哥哥你先放下手，知道你要選擇打代碼，O(_)O）。在最初做數(shù)據(jù)可視化產(chǎn)品時，我曾想過轉(zhuǎn)崗，甚至離職。

9、因為這不是我擅長的業(yè)務(wù)（要涉及技術(shù)），也不是我做過的產(chǎn)品。面對不可掌控的局面，我開始起來，聽起來這像極了“巨嬰”（特點之一，全能自戀，一旦掌控不了局面就會崩潰）。屬蛇的屬相婚配表最后，我用了2個月的時間調(diào)整自己心態(tài)，最終朝著良性的道發(fā)生了很大的變化（這段經(jīng)歷，我會在以后分享給大家）。從零慢慢學(xué)習(xí)，成為用戶，現(xiàn)在我依舊在上在工作坊中，我們組在提煉需求時，遇到了另一個問題，甚至出現(xiàn)了分歧。因為大家在展開用戶場景的同時，范圍也慢慢擴大。有人說“做病假審批，并結(jié)合財務(wù)計算規(guī)則設(shè)計”，可是財務(wù)計算規(guī)則是什么樣的，組內(nèi)的小伙伴又無人知曉了，且“員工-主管-財務(wù)”的審批本來也是個復(fù)雜的模型。我又想起2016

10、年老高跟我說的“第一范式”，他說做需求和建數(shù)據(jù)表一樣，要拆分到最小的顆粒度。當(dāng)然工作中的時間還是比活動中的時間要充足的，我并不認為“病假申請”就是人事申請中優(yōu)先級、ROI最高的需求。所以在真實的產(chǎn)品設(shè)計中決定做哪個需求時，就要考慮需求頻率、商業(yè)價值、開發(fā)成本、可拓展性、高層授權(quán)最后一個問題就是時間，這次工作坊中雖然每個組都有個人專門計時，但有一個環(huán)節(jié)我們組的這個專人也忘記計時了，這聽起來有些糟糕的。在我工作中也遇到過，特別是做一些對內(nèi)、不打算做商業(yè)化的產(chǎn)品時，可能公司項目管理團隊也不會關(guān)心這個項目了。加上B端產(chǎn)品面向企業(yè)級用戶，快速迭代式的敏捷開發(fā)，在某些B端產(chǎn)品項目中就行不通了。因為一些B端

11、產(chǎn)品每次升級會消耗很大的資源，所以一次版本迭代就會堆上很多功能，項目周期也就拉長了。戰(zhàn)線一拉長，人的疲勞值也會升高，各方面就不，開發(fā)也會懈怠下來（偷懶），這樣就會進入一個惡性循環(huán)“周期長-偷懶-周期長”。這時候“人人都是產(chǎn)品經(jīng)理”就要改成“人人都是項目經(jīng)理”，每個人都對截止時間有的意識，才能夠按期交付產(chǎn)品。當(dāng)然，這畢竟是個理想模型。每周的周會匯報，每天定時催問開發(fā)進度這些就必須在B端產(chǎn)品項目中執(zhí)行起來。所以貌似開發(fā)小哥對B端產(chǎn)品的抱怨超過了C端產(chǎn)品，畢竟少了一個項目經(jīng)理來吐槽_這個問題我在之前的文章中也略有討論過，特別是一些既有C端業(yè)務(wù)又有B端業(yè)務(wù)的公司里，那B端產(chǎn)品產(chǎn)品可能就會脫離產(chǎn)品大部隊

12、，孤獨地面對各種問題。好在，身邊有一群可愛的開發(fā)哥哥，共同面對用戶的問題，一起討論需求（好開森）。我經(jīng)常和身邊的朋友這樣調(diào)侃“C端產(chǎn)品經(jīng)理和B端產(chǎn)品經(jīng)理”的區(qū)別：做C端產(chǎn)品像演偶像劇，做B端產(chǎn)品像演話劇，話劇的關(guān)注人數(shù)當(dāng)然沒有偶像劇多，但我們都需要好好演戲，認真對待劇本，認真對待觀眾這一點也和Yvonne老師在工作坊中說的不謀而合，B端產(chǎn)品和C端產(chǎn)品都需要用戶與產(chǎn)品調(diào)研、定位核心問題、產(chǎn)品規(guī)劃和開發(fā)、推廣上線與運維最后，按照慣例我得發(fā)雞湯了，送給B端、后臺業(yè)務(wù)從業(yè)者（包括我自己，嘻嘻）一段陳道明在傳承者節(jié)目中的講話：我在天津人藝，我有七年的時間，在臺上一句臺詞沒有。這一場演匪軍，下一場演偽軍，再演，再下一場演八。我在想，就是人在各種職業(yè)當(dāng)中，要有一種甘于寂寞的準(zhǔn)備你們要努力，但是不要著急，凡事都應(yīng)該有過程PS：關(guān)于產(chǎn)品設(shè)計的思考在以往以及未來的產(chǎn)品文章中都會有體現(xiàn)，歡迎大家關(guān)注我不定期更新的產(chǎn)品相關(guān)文章兮兮，微信號：孤身旅人（ID：gushenlvren），人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注人工智能、toB產(chǎn)品、大文娛等領(lǐng)域。