如何提升B端產(chǎn)品競爭力(下)——產(chǎn)品開發(fā)流程設(shè)計【萬字干貨】

1 評論 4017 瀏覽 64 收藏 41 分鐘

“好產(chǎn)品不是能力內(nèi)核,做好產(chǎn)品的流程才是”。這是劉潤曾提到過的觀點,本文作者也非常認同,而本篇文章就分了8個部分來講述做“好產(chǎn)品”需要怎樣的流程,一起來看看吧。

劉潤在一篇文章中提到過一個觀點,“好產(chǎn)品不是能力內(nèi)核,做好產(chǎn)品的流程才是”。我很認同這個觀點,本文主要分享我對做“好產(chǎn)品”的流程當前的一些認知。

全文共8個部分,總字數(shù)超過1萬,限于篇幅可能有些內(nèi)容談的還不夠深入,后續(xù)有時間會再做細化。這8個部分是:

  1. 建立需求池和需求反饋渠道
  2. 建立走進客戶現(xiàn)場機制
  3. 建立需求接納機制
  4. 建立優(yōu)先級決策原則
  5. 建立產(chǎn)品設(shè)計標準
  6. 建立產(chǎn)研協(xié)作保障
  7. 建立產(chǎn)品驗證機制
  8. 建立產(chǎn)品場景案例庫

一、建立需求池和需求反饋渠道

需求池管理是B端產(chǎn)品進化最重要的環(huán)節(jié),它的重要性遠超產(chǎn)品設(shè)計、開發(fā)等其他環(huán)節(jié)。

維護需求池有主動和被動兩種。

主動維護是產(chǎn)品經(jīng)理在參與售前、迭代、交付、售后、競品分析、老板溝通等活動時自己發(fā)掘、記錄需求,主動收集需求的渠道很多,但不同渠道收集到的需求質(zhì)量有差異。

通常而言,我認為重要度最高的是售后環(huán)節(jié),因為此時反饋的需求通常是讓客戶真正痛的地方;

其次是競品分析,友商決策并實現(xiàn)的能力通常意味著有真實的客戶和需求存在;

再次是售前和交付,這些環(huán)節(jié)有時候客戶期望過高,容易空想不一定真實存在的需求,要慎重接納;

最后是迭代時開發(fā)團隊想出來的需求或老板提出的概念性需求,這些需求的真實存在性相對更低。

當然,很多時候,從職業(yè)本身的角度,老板需求是重要度“最高”的需求。但一個對產(chǎn)品負責的產(chǎn)品經(jīng)理,應該通過發(fā)問挖掘需求,幫老板“想清楚”,或讓老板把自己“說明白”,最終找到真實需求或引導降低優(yōu)先級。判斷需求收集渠道重要度的原則是需求真實性概率,而需求真實性是指需求存在且有普遍性。

被動維護是建立起需求反饋渠道讓相關(guān)角色(售前、交付、客戶經(jīng)理、客戶響應中心等)可以“有效的提需求”。它包括兩方面:

  1. 要有集中化的業(yè)務需求電子流,讓相關(guān)角色明確的知道有需求在哪提、提給誰、怎樣提等;
  2. 要通過需求結(jié)構(gòu)化的方式提高業(yè)務需求反饋質(zhì)量,減少產(chǎn)品經(jīng)理和需求提出人之間低效溝通次數(shù)。

業(yè)務需求結(jié)構(gòu)化,除了產(chǎn)品、客戶、金額、姓名、時間等基本屬性之外,更重要的是對需求場景的挖掘。關(guān)于需求挖掘,我給售前、交付等職能提供過一個5W3H分析法,具體包括:

  • who,誰提的這個需求?最終影響的用戶角色是誰?
  • why,客戶該需求的業(yè)務背景是什么?由于什么原因產(chǎn)生了這個需求?
  • when,發(fā)生了什么事,造成了什么問題,所以有了這個需求?這個需求未實現(xiàn)時,客戶是怎么解決這個需求的?過程中有什么痛點(不方便的地方)?
  • what,初始需求提出人的原始需求描述是什么?主業(yè)務過程什么樣?業(yè)務過程有哪些異常場景?
  • where,如何有了這個功能,客戶會在什么場景(什么時候、什么條件)下使用這個功能?功能使用頻率有多高?
  • how,客戶期望產(chǎn)品在哪里做什么功能?功能長什么樣?為什么期望功能或交互做成這樣?友商是如何實現(xiàn)這個需求的?
  • how much,這個需求對客戶的業(yè)務價值是什么?實現(xiàn)后用戶可以得到什么好處?
  • how much,這個需求對在該行業(yè)或其他行業(yè)客戶是否需要?是不是個性化需求?

產(chǎn)品經(jīng)理應該把需求池維護作為自己最重要的工作,需求池決定了產(chǎn)品未來的方向。接到需求第一時間需要將原始需求記錄至需求池,定期對需求池中需求進行狀態(tài)更新。

二、建立走進客戶現(xiàn)場機制

在辦公室埋頭做設(shè)計交互的B端產(chǎn)品經(jīng)理是不合格的,脫離客戶現(xiàn)場做不好B端產(chǎn)品。設(shè)計交互對B端產(chǎn)品并不是最重要的,更重要的是業(yè)務目的、業(yè)務過程、使用場景、角色群體和替代解決方案等。

通過非直接用戶、客戶反饋的需求,通常會有信息過濾。產(chǎn)品經(jīng)理要走到客戶現(xiàn)場,感受用戶的情緒,傾聽用戶的怒罵或贊賞,對自己的產(chǎn)品有客觀的認知。傾聽用戶對功能的使用場景,把這些場景包裝成故事講給其他客戶,給客戶“懂我”的信任感。還可以驗證需求池中的需求,傾聽用戶對規(guī)劃中需求的期待和反饋,為后續(xù)優(yōu)先級規(guī)劃和產(chǎn)品設(shè)計做準備。做好B端產(chǎn)品不是跟隨友商,而是跟隨客戶。

但產(chǎn)品經(jīng)理的時間、精力是有限的,若出差客戶現(xiàn)場包含往返在途至少半周,每月也只能安排1~2個客戶拜訪。所以,拜訪客戶的選擇尤為重要。

選擇拜訪的客戶,應該是“天使客戶”。這些客戶的大概畫像是:屬于產(chǎn)品主打行業(yè),處于行業(yè)頭部地位;已購買且交付產(chǎn)品,在深度使用,愿意每年支付服務費用滾動續(xù)簽;客戶接口人懂業(yè)務,對產(chǎn)品有想法,有邏輯、講道理。當然,很多時候客戶不是我們能選擇的,只能盡可能選擇和產(chǎn)品目標客戶相似度高的客戶。

售前階段的客戶并不是適合產(chǎn)品經(jīng)理拜訪的客戶,一方面此階段的需求不一定是真實場景下產(chǎn)生的,存在過高期望或主觀臆想;另一方面如果客戶提了一堆需求,產(chǎn)品到底響應還是不響應,什么時候響應都是難題。但售前階段的招標文件,產(chǎn)品經(jīng)理可以作為重要需求收集渠道,有可能會發(fā)現(xiàn)影響產(chǎn)品新定位的需求。

“以客戶為中心,關(guān)注場景和痛點”,不應該只是口號,或依賴每個產(chǎn)品經(jīng)理自己的主動性,應該建立起機制和制度進行保障,讓產(chǎn)品經(jīng)理不要脫離客戶現(xiàn)場做產(chǎn)品。

三、建立需求接納機制

從多種渠道收集到的需求,并非所有都應該納入到產(chǎn)品規(guī)劃中的,畢竟開發(fā)人力總是稀缺的。明確需求接納決策人,建立決策依據(jù)原則對B端產(chǎn)品至關(guān)重要。

承擔需求接納決策人角色的人,至少應該滿足兩個要求:

  1. 他應該懂業(yè)務、懂客戶,不脫離一線客戶現(xiàn)場;
  2. 他應該對業(yè)績負責、對客戶滿意度負責,該產(chǎn)品業(yè)績對他的KPI有較大影響。

需求決策人通常是產(chǎn)品經(jīng)理,也可能是業(yè)務負責人。如果需求決策的權(quán)力,由脫離客戶一線,不對市場業(yè)績負責,缺乏產(chǎn)品管理經(jīng)驗的人負責,對產(chǎn)品會是一場災難。

需求接納原則,至少應該考慮3個問題,值不值做、該不該做、要不要做。

  1. 值不值做。需求實現(xiàn)能幫客戶解決多大的問題,能產(chǎn)生多大的價值收益,如果量化成貨幣是多少錢?作為一個商業(yè)化產(chǎn)品,每做一個功能都要思考,這個功能客戶是否愿意花錢買單?愿意花多少錢?市場上有多少客戶愿意為這個需求買單?
  2. 該不該做。需求是否在產(chǎn)品定位的邊界范圍內(nèi),是否該由這個產(chǎn)品來做,還是應該由其他產(chǎn)品做?如果跟產(chǎn)品組合中其他產(chǎn)品存在部分的功能重疊,那這個功能做還是不做?(對這個問題,我的理解是以客戶場景為中心,而非以產(chǎn)品為中心。如果客戶的場景需要這個功能,即使其他產(chǎn)品中存在,也應該在這個產(chǎn)品中進行實現(xiàn)。至于研發(fā)成本、重復開發(fā)的原則是次要的。研發(fā)的問題從研發(fā)的角度考慮解決,而不是讓客戶的需求來妥協(xié)。)
  3. 要不要做。功能實現(xiàn)在技術(shù)上是否可行?短期與長期投入產(chǎn)出比如何?標準化程度能做到多高?對比客戶當前方案能有多大收益?現(xiàn)在是否是做這個功能合適的時機?目前的解決方案是否足夠優(yōu)秀?

需求是否接納通常由產(chǎn)品經(jīng)理一個人決策,但這會過度依賴產(chǎn)品經(jīng)理自身能力。建議應該成立需求評審委員會,周期性對產(chǎn)品組合中各個產(chǎn)品經(jīng)理的決策依據(jù)進行評審。

需求評審委員會的成員應該包括產(chǎn)品總監(jiān)、售前解決方案總監(jiān)、售后客服總監(jiān)、研發(fā)總監(jiān)等角色,至少產(chǎn)品總監(jiān)和售前解決方案總監(jiān)需要參與。需求是否接納影響產(chǎn)品組合中各個產(chǎn)品未來進化方向,值得管理者參與決策過程。該會議無需對具體功能方案做溝通,只需要決策需求是否接納即可。

在需求接納管理的過程中,可能總存在一些人發(fā)出反對的聲音。每次產(chǎn)品經(jīng)理決策需求或設(shè)計方案時他總能找到反對的理由,但如果你讓他來提該做什么、怎么做,他又提不出有價值的想法,反問一句“這是產(chǎn)品經(jīng)理的事,你是產(chǎn)品經(jīng)理還是我是產(chǎn)品經(jīng)理”。

我們要知道,每一個決策都有利弊,我們只要追求當下能做出的最佳決策即可。如果因為懼怕決策風險,就停滯下來不做決策,做無意義的時間消耗,這才是最大的損失。對于有價值的聲音需要接納,對于沒價值的反對,只能練就一顆強大的內(nèi)心。微笑面對反對和質(zhì)疑,堅持自己的選擇,并能在失敗后平靜面對他們的嘲笑。

但行前路,無愧于心,足矣。

四、建立優(yōu)先級決策原則

研發(fā)人力和時間總是稀缺的,需求優(yōu)先級排序直接影響著市場業(yè)績和客戶滿意度,做好優(yōu)先級排序?qū)Ξa(chǎn)品非常重要。如果需求收集和接納決策是對產(chǎn)品經(jīng)理能力第一重要的考驗,那需求優(yōu)先級決策則是對產(chǎn)品經(jīng)理能力第二重要的考驗。

需求優(yōu)先級排序的方法論很多,但回歸本質(zhì)是ROI和對比排序。對比排序,即使沒有方法論也能做,但有方法論可以讓排序有據(jù)可依,標準相對清楚,更容易同其他人達成一致。

不同商業(yè)模式、不同產(chǎn)品、不同階段衡量ROI的標準不同,要根據(jù)自身產(chǎn)品選擇適合的一套或多套組合衡量方法,不要迷信特定理論

比如,對于內(nèi)部系統(tǒng)或大客戶定制項目,收益主要是關(guān)鍵角色的滿意度,其次是次要角色使用價值,更多使用提出人權(quán)力/影響矩陣做優(yōu)先級排序;對于處于0-1打造階段的產(chǎn)品,收益主要是MVP版本交付與反饋,更多使用KANO或MoSCoW做優(yōu)先級排序;對于處于1-n階段的商業(yè)B端產(chǎn)品,收益主要是短/長期市場收入,更多使用效益/緊急矩陣做優(yōu)先級排序。

對于1-n的商業(yè)B端產(chǎn)品,我推薦效益/緊急矩陣優(yōu)先級排序法。既然是商業(yè)產(chǎn)品,那就向錢看。效益高且緊急的需求優(yōu)先級最高,效益高不緊急的需求其次,效益低緊急的需求再次,最后考慮效益低不緊急的需求??此坪唵?,但如何定義效益呢?

效益是短期、長期經(jīng)濟收益的綜合評估,短期經(jīng)濟收益好評估,承諾或完成某個功能就能讓正在售前的客戶愿意付錢購買。但長期經(jīng)濟收益呢?在沒看到項目機會前,是否能絕對預測做了某個功能一定能夠帶來多少客戶、多少收入增長?這個很難,因為決定收入的因素很多。但可以確定的是功能解決的場景價值越大,則產(chǎn)品綜合價值越高,特定客戶購買概率也更高。

那如何評估場景價值大小呢?一種參考方法是大概估測,沒有這個功能時,客戶想達到業(yè)務目的需要投入多少人、多長時間,這些人需要的薪資是多少,這個事每年做幾次,最后大概能評估一個年度貨幣成本數(shù)量級即可。

這個評估不需要精確的數(shù)值,這種數(shù)值也沒有意義,可以拍腦袋估測,只需要能跟需求池中其他需求有個大致對比即可。做這個估測的意義不在于準確,核心是需要產(chǎn)品經(jīng)理建立起關(guān)注需求背后業(yè)務價值的意識,而不是關(guān)注在功能設(shè)計本身。

通常來講,處于售前關(guān)鍵時刻(客戶已完成預算申請且內(nèi)部立項,正處于確定招標參數(shù)階段)的大金額項目是經(jīng)濟效益最高的,畢竟“百鳥在林,不如一鳥在手”;其次是涉及客戶多、業(yè)務價值高的普適需求。

對于經(jīng)濟效益在相似量級的需求,可以引入成本作為第二優(yōu)先級排序考慮因素。成本越低,相對優(yōu)先級越高。

需求優(yōu)先級并不意味著絕對的開發(fā)迭代順序,在開發(fā)迭代排期時我們還需要兼顧每個開發(fā)周期內(nèi)大小需求的均衡性、市場響應及時性等。可能有些小需求經(jīng)濟效益不高,但成本極低,此時考慮到市場響應和客戶滿意度,也可以將這些小需求排入靠前的開發(fā)迭代。

對于經(jīng)濟效益高但難度大、成本高的需求,不能因為難就一直拖延著不做,我們需要勇于啃硬骨頭,在具體推進時可以把這類需求穿插在多個迭代中硬啃,做難而正確的事,我們才能拉開與競爭對手的差距。

五、建立產(chǎn)品設(shè)計標準

一個優(yōu)秀的B端產(chǎn)品除了功能,更應該靠場景打動客戶。B端產(chǎn)品設(shè)計不能狹義的理解為單純的功能交互設(shè)計,而應該圍繞客戶業(yè)務問題、場景來綜合考慮,我們的終極目的不只是做一個漂亮的界面、好用的交互,更是幫助客戶解決當前存在的問題。

根據(jù)經(jīng)驗,我將產(chǎn)品設(shè)計劃分為:業(yè)務背景澄清、業(yè)務過程梳理,流程與角色設(shè)計、角色任務設(shè)計、功能設(shè)計,架構(gòu)設(shè)計、交互設(shè)計,平面設(shè)計,視覺設(shè)計等一系列過程,這個劃分方法借鑒了《用戶體驗五要素》中戰(zhàn)略層、范圍層、結(jié)構(gòu)層、框架層、表現(xiàn)層的思路。

這些設(shè)計過程只是一種知識體系化的拆解維度,劃分并不精確,各個過程未完全遵循MECE原則,沒有嚴格的先后順序。在實際設(shè)計過程中,我們可以有意識的注意這些過程,針對具體場景來裁剪使用。以下將對每個過程簡略描述:

1. 業(yè)務背景澄清

將需求收集時5W3H問題和答案再確認一遍,回顧一下我們核心要解決的問題是什么,業(yè)務目的是什么,價值是什么。

2. 業(yè)務過程梳理

將客戶線下解決問題的方案搞清楚,都涉及哪些角色,每個角色做什么,角色間如何協(xié)作,業(yè)務涉及多少個環(huán)節(jié),每個環(huán)節(jié)具體做什么。我們要介入這個過程應該從哪些地方介入合適,哪些地方不適合軟件介入,軟件介入比原有方案增加了多少價值。

3. 流程與角色設(shè)計

流程與角色設(shè)計是基于原有業(yè)務過程,考慮轉(zhuǎn)化到軟件上該如何做,每個角色需要設(shè)計哪些任務。在設(shè)計時我們可能需要打破、調(diào)整原有業(yè)務過程,以線上更合適的方式來做。

4. 角色任務設(shè)計

是基于單個角色設(shè)計他的主任務、次任務,該角色在業(yè)務中的目的是什么,主任務需要幾個步驟,是否可簡化步驟,每個步驟具體做什么。

完成主任務涉及多少個核心頁面、多少個關(guān)鍵功能,如何保障主任務過程順暢。分支任務有哪些,如何即能讓分支任務為主任務提供便利,又能避免分支任務干擾主任務,分支任務應該有哪些入口,如何即易找又不喧賓奪主。任務過程中可能有哪些異常,哪些應該軟件來避免,哪些應該交給用戶自己判斷避免。

角色任務設(shè)計完成,需要什么頁面、什么功能基本已經(jīng)確定了。

5. 功能設(shè)計

是確定每個功能實現(xiàn)邏輯、方法,功能設(shè)計要基于業(yè)務問題和場景,如何設(shè)計能帶來最大的收益,再衡量如何降低成本獲取最大ROI,這個過程中可能功能設(shè)計需要做一些妥協(xié),但仍需保障功能的價值度,這個平衡并不容易做到。

另外一個很難平衡的問題是,“追求更完美的方案再開發(fā),還是先有一個簡單方案再持續(xù)迭代”。首先,我傾向于持續(xù)迭代。在實際使用中不斷反饋和迭代,要比一直憋方案,遲遲功能推不出來更好。

而且,我們很難預知能設(shè)計出一個完美方案,也很難預知我們認為的完美會被客戶認可。對于創(chuàng)新型功能設(shè)計,有改進、有價值即可,不過度設(shè)計、夠用即可。

但同時,又需要平衡最低設(shè)計標準,不要讓產(chǎn)品掉檔次,讓客戶感覺草率、粗糙。起碼應該達到讓產(chǎn)品經(jīng)理自己愿意承認,這個設(shè)計是出自我手的程度。否則,產(chǎn)品經(jīng)理就應該有所堅持,不能因老板或大項目壓力而妥協(xié),要盡可能在有限時間內(nèi)追求更好的方案,對自己的產(chǎn)品負責。我們不是為了做功能而做功能,最起碼應該保障功能在場景中能解決問題,否則絕不將就。

功能設(shè)計推薦4個原則,按重要性排序是,有用、好用、靈活、簡單

  1. 有用是指功能設(shè)計要能解決業(yè)務問題,在設(shè)計過程中由于要平衡考慮靈活性、易用性、成本等,方案可能會不斷調(diào)整,所以在設(shè)計的過程中要不斷回顧是否偏離“有用”原則。
  2. 好用是指功能的用戶體驗,涉及架構(gòu)、交互、UI等,下文會繼續(xù)展開,此處需要注意的是,有些客戶會對功能設(shè)計提出自己的方案,產(chǎn)品經(jīng)理要認真聽,但不可照做,對客戶建議的功能設(shè)計要綜合考慮,而不是做一個傳話筒。
  3. 靈活是指功能設(shè)計時要考慮在不同行業(yè)、不同規(guī)??蛻籼?,有哪些差異性,如何通過設(shè)計兼容這些差異性;以及未來需求若出現(xiàn)變化,如何通過設(shè)計進行兼容。靈活性可能會造成用戶體驗下降,開發(fā)成本提升,所以需要進行平衡,沒必要追求過度靈活性。
  4. 簡單包括多方面,設(shè)計方案要盡可能簡單,可以清楚的傳達給開發(fā)團隊;開發(fā)方案要盡可能簡單,避免復雜度帶來的Bug、維護成本、升級不便性等;用戶理解認知要盡可能簡單,避免造成用戶不會用、不愿用。

功能設(shè)計完成后,產(chǎn)品經(jīng)理的核心工作基本完成。UI/UE設(shè)計是專業(yè)領(lǐng)域,專業(yè)的事情應該交給專業(yè)的人做,產(chǎn)品經(jīng)理更多是配合UX設(shè)計師。但公司如果沒有專職的UX設(shè)計師,則需要產(chǎn)品經(jīng)理主導設(shè)計。

不建議產(chǎn)品經(jīng)理拍腦袋創(chuàng)新,最好直接向那些有UX設(shè)計師的友商“借鑒”(抄襲)。如果友商做的也不好,可以向一些優(yōu)秀作品學習,如騰訊系的產(chǎn)品,但抄的過程中也需要有自己的選擇和判斷標準,不行無腦全抄。B端產(chǎn)品最重要的是功能設(shè)計之前戰(zhàn)略層、范圍層的事,產(chǎn)品經(jīng)理若花過多時間在框架層、表現(xiàn)層則有些本末倒置。

6. 架構(gòu)設(shè)計

是確定不同功能具體在哪個頁面,以及用戶完成任務需要按順序使用哪些頁面,各頁面之間如何跳轉(zhuǎn)。常見手段如:面包屑導航、高級搜索、首頁快捷入口、列表或詳情頁超鏈接、彈窗、抽屜、返回等。

跳轉(zhuǎn)設(shè)計時要結(jié)合任務場景來設(shè)計,比如,在運維管理的資源設(shè)備添加時,如果添加成功應該自動跳轉(zhuǎn)至列表頁,因為用戶的主任務已經(jīng)完成,下一個主任務是再新增一個資源或者使用其他功能菜單,所以要自動跳轉(zhuǎn)至列表頁;

而如果資源添加失敗,則應該停留在本頁面,因為大概率是由于賬號密碼錯誤造成連接測試失敗,這個場景下用戶會走入賬號密碼修改的分支任務,而該分支任務就是在詳情頁完成,所以不能讓用戶跳轉(zhuǎn)至列表頁,而是留在當前頁面增加用戶修改的便利性。

7. 交互設(shè)計

廣義上講包括了架構(gòu)、交互、平面、視覺等,狹隘上講是一組觸發(fā)點、觸發(fā)動作和動作反饋,包括控件選擇、控件交互及用戶操作聯(lián)動等??丶唤ㄗh自己開發(fā),直接采用開源控件庫,如element、iview、antd等,這些控件大多數(shù)情況下夠用了,但也有些需求場景下這些控件無法滿足,有人力可以二次開發(fā)或新設(shè)計。

即使采用標準開源控件,仍需產(chǎn)品經(jīng)理參與設(shè)計。產(chǎn)品經(jīng)理需要根據(jù)需求場景選擇最適合的控件、確定控件默認值、確定控件之間的聯(lián)動邏輯、設(shè)計用戶視覺及鼠標鍵盤操作動作、路徑等。

交互設(shè)計推薦3個原則,少想、少看、少動

  1. 少想是降低用戶認知負荷,如貼合用戶習慣(設(shè)計跟用戶線下認知保持一致、跟行業(yè)通用設(shè)計保持一致、產(chǎn)品組合中設(shè)計保持一致)、UI設(shè)計、簡化設(shè)計、漸進式任務設(shè)計、文案設(shè)計等。
  2. 少看是減少用戶視覺負荷,如縮短眼動路徑,將用戶一次任務需要的內(nèi)容放在相近的位置;簡化頁面內(nèi)容,使用對比、組合、隱藏等UI設(shè)計、簡化設(shè)計技巧。
  3. 少動是減少用戶操作動作,如鼠標移動總距離、鼠標點擊總次數(shù)、鼠標鍵盤任務切換總次數(shù)等。

簡化設(shè)計推薦4個原則,刪除、組織、隱藏、轉(zhuǎn)移

  1. 刪除是將極少使用的功能刪掉,僅保留不可刪除的功能;
  2. 組織是按功能邏輯進行分組、分塊、分層;
  3. 隱藏是將不常用又不能刪除的功能隱藏的路徑深一些,用戶使用時能找到即可;
  4. 轉(zhuǎn)移是將功能轉(zhuǎn)移到其他載體上(用戶自己、其他產(chǎn)品模塊)。

平面設(shè)計推薦4個原則,親密、對齊、對比、重復

  1. 親密是將邏輯上相關(guān)的內(nèi)容組織在一起,讓物理位置靠近,相反,將邏輯上相關(guān)性低的內(nèi)容增加物理距離;
  2. 對齊是讓物理布局整齊,明確對齊線,讓頁面內(nèi)容顯得有條理,增加可讀性;
  3. 對比是通過明顯的視覺反差效果,將不同的內(nèi)容區(qū)分開;
  4. 重復是在整個產(chǎn)品設(shè)計中相同目的保持相同設(shè)計,如圖標、顏色、樣式等,增加產(chǎn)品統(tǒng)一性,另外,也盡可能跟用戶日常認知保持一致性重復。

視覺設(shè)計需要審美,我的直男審美相對差一些,所以更多追求簡單、簡潔,在配色、比例、鈍銳角、線條、對稱、平衡等因素上較多依賴于借鑒(抄襲)優(yōu)秀友商作品。

最后,在產(chǎn)品設(shè)計上我想強調(diào)的是,設(shè)計只是解決問題的手段而已,最核心的還是理解并解決業(yè)務問題。

六、建立產(chǎn)研協(xié)作保障

通常情況下,產(chǎn)品經(jīng)理和研發(fā)歸屬同一個大部門,辦公距離相近,迭代過程中有問題可以及時溝通解決,產(chǎn)品經(jīng)理只需要保持正常的節(jié)奏參與迭代規(guī)劃會、迭代驗收會等即可。產(chǎn)研利益一致,協(xié)作高效,溝通基本不會出現(xiàn)問題。

但在有些大公司,產(chǎn)品經(jīng)理和研發(fā)可能跨了大事業(yè)部,位置也可能分布在不同城市,產(chǎn)品經(jīng)理的核心工作是市場商業(yè),極難保證跟研發(fā)溝通的時間。這種情況下,會出現(xiàn)很多問題,想把產(chǎn)品做好很難。

比如,因組織架構(gòu)原因,產(chǎn)研利益不一致,產(chǎn)品經(jīng)理推動力不足;產(chǎn)品經(jīng)理跟研發(fā)溝通時間較少,關(guān)系融洽度較難維持,相互信任度低,容易產(chǎn)生嫌隙;迭代中研發(fā)有問題很難隨時跟產(chǎn)品經(jīng)理確認,問題被拖延影響開發(fā)效率等。

我的應對思路是:

  • 懼怕沖突,堅守產(chǎn)品規(guī)劃不退縮;
  • 工作公開透明,把事情擺到桌面上;
  • 借助多個相關(guān)方力量,共同影響研發(fā)接納需求;
  • 多方位影響高層管理者注意到問題,為產(chǎn)品經(jīng)理爭取時間;
  • 至少保證迭代計劃會、演示會和研發(fā)團隊有交流;
  • 盡量保障定期線上會議幫研發(fā)解答疑問。

產(chǎn)研溝通存在障礙不可怕,可怕的是接納這種狀態(tài)不做改變。做好產(chǎn)品我們要保障產(chǎn)品經(jīng)理和研發(fā)利益一致、溝通順暢,讓產(chǎn)品經(jīng)理對產(chǎn)品規(guī)劃有主導權(quán),有充足的時間完成需求分析、及時解答研發(fā)疑問。

七、建立產(chǎn)品驗證機制

產(chǎn)品設(shè)計不能閉門造車,為避免功能不被客戶認可,要頻繁驗證。尤其B端產(chǎn)品,上線一個功能容易,但下線一個功能很難,需要在很長一段時間承受壓力(客戶質(zhì)疑售前時有的功能,為何交付時沒有了,這種情況處理很棘手)。

客戶定制或內(nèi)部自研產(chǎn)品需求方明確,相對容易驗證。但標準化商業(yè)產(chǎn)品的需求方來自多行業(yè)、不同規(guī)??蛻?,相對驗證困難。

對于客戶定制或內(nèi)部自研產(chǎn)品可以秉持”最低成本驗證“的原則驗證功能設(shè)計是否滿足客戶需求,必須完成的驗證包括:業(yè)務背景確認(會議)、核心業(yè)務流程確認(Visio)、核心功能確認(Xmind)。

若需求較大,驗證手段按成本從小至大包括:紙面線框圖、低保真原型、需求概要說明書、高保真原型、需求詳細設(shè)計說明書。需求驗證的交付物并沒有實際價值,所以應該根據(jù)客戶和場景盡量選擇成本最低的方式。

對于標準化商業(yè)產(chǎn)品我沒很好的方法,目前的思路包括:

  • 借助PPT跟售前、客戶經(jīng)理等團隊做概念宣講,驗證需求普遍性及價值度;
  • 借助重大項目售前/售后交流機會做概念宣講,驗證需求期望度;
  • 借助交付中典型行業(yè)客戶,對功能設(shè)計方案進行驗證;
  • 借助公司內(nèi)部交付專家,對功能交互/UI設(shè)計方案進行驗證;
  • 由產(chǎn)品經(jīng)理/測試人員把自己想象成小白用戶,模擬用戶完整業(yè)務過程使用體驗。

在我管理的產(chǎn)品組合中,有幾個需求推動很久了卻一直未被研發(fā)接納,但今年通過重大項目完成了一舉多得。這些項目金額達到數(shù)百萬級,售前申請了產(chǎn)線產(chǎn)品經(jīng)理直接參與。

在跟大客戶溝通過程中,我提及了幾個功能設(shè)計理念(未承諾,以規(guī)劃中引導),很切中他們的實際痛點,在會議上客戶大加贊賞,直言“你們的產(chǎn)品是我看過的所有國內(nèi)外產(chǎn)品中,做的最好的”。最終,我們既完成了需求驗證,又拿下了多個數(shù)百萬級項目,還成功讓研發(fā)接納了需求,提升了產(chǎn)品未來競爭力,一舉多得。

當然,標準化商業(yè)產(chǎn)品的功能驗證并不容易,有很多要考慮的因素,比如:客戶過度期望風險、功能交付時間風險、技術(shù)方案風險、通用度不足風險等,但我們不能因為有風險就停下腳步,產(chǎn)品經(jīng)理要有敢承擔風險的魄力。

八、建立產(chǎn)品場景案例庫

項目成交的關(guān)鍵是客戶對產(chǎn)品的認可和信任,產(chǎn)品功能是重要因素。但單純的功能介紹不易讓客戶感受到產(chǎn)品的價值以及我們和競爭對手的差異性,所以,我們需要借助客戶實際工作的場景故事,讓客戶更容易感受到價值和我們在領(lǐng)域內(nèi)的專業(yè)性。

通常來講,優(yōu)秀的解決方案專家應該對產(chǎn)品特定功能使用場景和價值很清楚,產(chǎn)品案例庫也應該由售前解決方案團隊來維護。但若解決方案崗位由于各種原因出現(xiàn)缺位,如負責多個產(chǎn)品線精力不足、人員流動率高、工作經(jīng)驗不足等,產(chǎn)品經(jīng)理需要在這個關(guān)鍵之處做補位,反向培訓解決方案專家。

幫助客戶發(fā)現(xiàn)產(chǎn)品功能更多的使用場景,也是產(chǎn)品經(jīng)理需要關(guān)注的事。因為增加功能的目的是增加產(chǎn)品價值,發(fā)掘原有功能更多使用場景也能幫助客戶增加產(chǎn)品價值。從場景中來,到場景中去。

坦白講在產(chǎn)品場景庫建設(shè)上我目前做的并不好,曾經(jīng)推動體系化的做行業(yè)場景案例庫,只輸出了一篇,后續(xù)由于相關(guān)角色配合度不高,自己做又缺少時間,就擱置了。

不過,在特定行業(yè)解決方案PPT輸出時,我有意識的采用了以場景為線索組織結(jié)構(gòu),跟客戶交流時效果很好,我認為這種模式對今年幾個數(shù)百萬級大項目中標有很大的正面效果。

我組織場景有兩個思路:

第一個思路是從用戶的實際工作角度出發(fā),拆分多個場景,然后把產(chǎn)品組合中各個產(chǎn)品的功能打散進每個場景中,告訴客戶在不同的工作領(lǐng)域中,我能幫你解決什么問題,我是如何解決的。比如:

在講整體網(wǎng)絡自動化解決方案中,我拆分了設(shè)備入網(wǎng)、服務請求實施、日常監(jiān)控與管理、故障響應4類大場景,然后每個大場景再具體細化拆分成4個具體小場景,然后每個小場景采用幾頁PPT詳細介紹我的產(chǎn)品功能是如何在這些場景中發(fā)揮作用的。

在單獨的IP地址管理解決方案中,我按IP管理全生命周期拆分了IP規(guī)劃、IP收集、IP展示查詢、IP分配、IP審計、IP回收6大場景,然后針對每個場景分析客戶現(xiàn)狀最大的3個問題,提出針對性的3個解決思路,然后每個解決思路用幾頁PPT詳細介紹我的產(chǎn)品功能是如何一步步使用來解決這些問題的。

這樣按場景來組織的解決方案,會給客戶“懂我”的信任感。同時,也通過在場景中的功能演示,增強了客戶對產(chǎn)品實際落地的信心。

第二個思路是從產(chǎn)品功能角度出發(fā),挖掘功能可以響應的特定場景。

比如,對于IP地址管理查詢列表頁,我會跟客戶講的場景是,“在交換機故障或報廢下線時,需要確定該交換機影響的具體業(yè)務或IP,此時,可以通過該設(shè)備IP可以直接查詢到所有接入IP,大幅減少了人工確認工作量”,“在對一個IP地址做故障分析或安全回溯時,通過IP地址可以快速查詢到這個IP是通過哪個交換機、哪個端口入網(wǎng)的,具體使用人是誰、用途是什么、近期有哪些安全告警等信息,輔助快速定位故障、審計使用記錄”。

你看,僅僅一個列表頁,就可以講出很多使用場景。

另外,一些高價值場景比如,“投入上百萬建設(shè)CMDB,但仍不敢保證IP不遺漏,此時,可以通過IP地址管理的CMDB校驗能力,幫助發(fā)現(xiàn)CMDB中缺失的IP地址”;

“安全準入系統(tǒng)只能管已經(jīng)安裝了客戶端的終端,但真正的非安全終端沒有安裝客戶端難以發(fā)現(xiàn),此時,可以通過IP地址管理對終端準入系統(tǒng)中IP進行校驗,輔助發(fā)現(xiàn)那些安全威脅”;

“網(wǎng)絡中IP沖突可能會造成關(guān)鍵業(yè)務斷網(wǎng),此時,可以通過IP地址管理做IP分配集中歸口,減少IP沖突風險出現(xiàn)”;

“每年要做業(yè)務擴容時,哪些業(yè)務需要新采設(shè)備很多時候靠人拍腦袋,此時,可以通過IP地址管理自動查詢各業(yè)務設(shè)備接口使用率情況,通過數(shù)據(jù)很快就可以確定具體擴容業(yè)務和設(shè)備量”。

類似場景故事還有很多,正是這些貼合客戶業(yè)務的真實場景,會讓客戶更有體感,也更容易體會到產(chǎn)品的價值。

最后,我想說,一個優(yōu)秀的產(chǎn)品經(jīng)理非常重要。在業(yè)務上,他可以給客戶創(chuàng)造很大價值,給公司帶來長期收益;在產(chǎn)研協(xié)同上,他可以幫助研發(fā)少走很多彎路,大幅提升研發(fā)產(chǎn)出效率。

但是,好的產(chǎn)品經(jīng)理可遇不可求,從公司角度需要有一套機制來保障產(chǎn)品經(jīng)理不至于做的太差,才能保障公司正常發(fā)展。正如亞馬遜貝佐斯所說,“仰仗別人的善意來完成工作不是長遠之計,公司的運作需要依靠完善的機制”。

作者:李曉杰;微信公眾號:產(chǎn)品曉說(ID:pmxiaosi)。10年以上產(chǎn)品、項目管理實戰(zhàn)經(jīng)驗,近7年服務大B端客戶運營商(移動、聯(lián)通),核心產(chǎn)品為企業(yè)信息化與協(xié)同,包括研發(fā)管理、財務管理、辦公自動化OA、數(shù)據(jù)可視化等。喜歡讀書、分享,希望與同路人共同探索產(chǎn)品經(jīng)理成長之路。

本文由 @產(chǎn)品曉說 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 學習了~ 感謝分享~

    來自福建 回復