推荐设备MORE

個人銷售案例分享産品案例産

個人銷售案例分享産品案例産

产品案例

産品案例怎麽做産品介紹案例産品案例608彩票a

日期:2019-10-29
我要分享

  從業時間相同,優秀的産品經理總是能比別人注意到更多的小細節,換句話說,以下一些點是産品經理或者産品負責人會經常忽略的。

  對産品經理來說,想出牛逼的點子只是副業,怎麽把産品流程的設計順利圓滿沒有遺漏地完成才是天職。

  比如,作爲電商産品經理,除了正常購買流程,每個環節的錯誤頁面有補全嗎?每種問題的處理情況想到了嗎?遇到網絡信號不好時界面會是如何的?用戶沒登錄、沒綁定支付、沒支付成功的時候交互如何?用戶登錄失敗、綁定失敗、支付失敗的交互又是如何?

  産品經理很多時候是需求承接方,有時需求來自老板,有時需求來自同事,有時需求來自用戶。這時候,一定要分清一件事情,這件事情是非常非常容易被搞混的,就是:他們給你的是明確無誤的需求還是只有實際的方案!

  比如,老板的需求可能是這樣的:給我做個客戶端實時記錄美甲師 GPS 的功能來。

  作爲忠貞不二的員工你可能就落實去了。但實際上,你需要搞明白老板爲什麽這麽做。在再三的追問下,老板可能就告訴你他的原因是:因爲美甲師經常會爲了獎勵刷單,也就是不出門讓朋友來下單。GPS 用來幫助判斷這個。

  所以你理解了老板的需求,那麽下一步做的時候就清楚了:要查美甲師是不是刷單,沒有必要實時做記錄,這樣增加美甲師端的流量消耗,也增加了服務器的負擔。

  正常的接單時間都會大于半小時,因此完全可以將功能改成:每半小時記錄一次美甲師的 GPS。

  任何人(包括用戶,嚴格說尤其是用戶)給你提需求時,有時候只是根據自己的需求拍腦袋想了一個方案建議你做,但作爲産品經理,要做的是理解其背後真正的原因或者原理,轉化爲更合適的産品方案。

  @張博遠:産品經理的工作有很多:求開發,撕運營,挑UI,瞻領導,看競品,問用戶,回郵件,寫PPT,如果這些事情占據了你全部的時間,你可能會忽視兩個非常重要的問題:開發前的「效度預估」和上線後的「效果複盤」。

  效度(Validity)即有效性,它是指測量工具或手段能夠准確測出所需測量的事物的程度。

  用在産品經理工作中,一個新功能、一次版本優化的效度是指本次開發的東西多大程度上指向了需求、完成了目標。在具體的工作中,又可以細分成以下幾個問題:

  2、對方給到的是需求還是方案?如果是方案,這個方案背後的需求和目的是什麽?針對這個需求/目的,這個方案是最有效的嗎?

  3、這項新功能,與現有産品形態的關系是什麽?可能會對現在産品産生什麽負面影響?

  4、這項新功能解決什麽具體問題,爲哪些用戶解決問題?會不會影響到其他用戶的體驗?

  如果沒有充分考慮以上的問題,可能的後果是:PM做無用功,RD浪費時間,産品在兜圈子。舉一個負面的案例:

  有段時間大量用戶反饋說評論區的質量下降了,于是小組討論出了一個方案:給每一位用戶一項能力,發現 “垃圾評論” 時把評論者指認出來,被指認次數達到一定量級時會被禁止評論。這個方案兩個月後上線了。但效果很差,甚至幫了倒忙,其中一個原因是:

  指認“垃圾評論” 時用的標簽太好看了,有人被禁言時,頭像旁邊多出來的東西就跟徽章似的,大家開始羨慕他,爭著搶著也要“徽章” ,這就像在上世紀的中國,犯了投機倒把罪的罪犯遊街示衆時頭上戴的不是高帽而是紅花,那豈不是大家爭當罪犯了?

  這表面上是UI設計的問題,UI設計有一項原則,即形式追隨功能。更確切地說是:形式追隨功能背後的目的和意義,當産品經理沒有把這項方案背後的意義和目的十分明確的提出來時,當這項功能的目的和意義沒有有效傳達給UI設計師時,UI的問題也有産品經理的責任。

  第一、明確本次叠代/優化/新功能的目的、意義,越明確越好。第二、每向前推進一步,都要用目的和意義來審視一下,如有必要及時調整。

  如果不做效度預估,就像如下左圖,目標模糊籠統,向前推進時方向跑偏也不知道。

  産品經理在做進度規劃的時候,很少把「效果複盤」算進去,再加上上線時間往往延遲,一個功能上線後恨不得馬上推進第二個,有時候我會跟同事討論說:

  既然咱們公司不是爲了賺短線的錢,如果一個功能模塊上線天之後,沒有一個人用,那這個功能模塊有必要做嗎?

  其實有時候産品經理很無奈,因爲他的leader甚至整個工作氛圍都是這樣,就算有心,也只能擠時間做複盤。

  某次工作中,商務提出一個需求,在客戶端裏加入一個H5頁面來宣傳某客戶的新産品,由于是銷售談下來的付費客戶,優先級比較高,608彩票app下載因此我積極響應,迅速協調相應的交互、UI、開發按要求上線了。期間前端開發頗有微詞,我除了好言相勸無我他法,他手頭的活兒實在太多,但這個事情必須有人來做。

  過了一段時間,那位商務同學又來提需求了,我隨口問了她一句:上次那個H5頁面客戶那邊的錢到賬了嗎?她說不知道。“能幫我問一下當時負責的銷售嗎?” ,“行吧,我一會兒去問問,咱們先來談談新需求吧”。

  到了第三天,我見她沒有任何反饋,又去問她,我才知道:客戶沒給錢!客戶沒給錢!客戶沒給錢!

  幾翻討論之後,我們達成一個協議:對于銷售提過來的類似需求,需要同時提供客戶的首付款憑證。會後我又想到了幾點:

  爲了應對銷售需求的而開發的頁面和功能,因爲其目的是賣錢,所以複盤效果的方式很直接,就是看結款情況。但是在我負責那條産品線之前的三年裏,一直沒人考慮過這個問題,大家一直奉行著銷售需求優先排期的原則,還有許多其他産品線也同樣如此。

  還有,對于運營提過來的需求,我也時常會拒掉,理由很簡單,一項活動最理想的效果,無論對于品牌的提升,還是對于用戶量的提升,還是對于日活的提升,全都加起來還不夠兩個RD一周的工資錢(p.s.如何換算是另一個話題),而這項需求僅僅開發就至少兩周時間,有時候運營氣急了就罵我是神經病。

  也不怪運營同學,有時候部門根據需求設立了一個崗位,根據崗位招了一名員工,但是三個月後,當初的需求變小了,進而這名員工的工作量減小了,他甚至他的leader就會覺得不要讓其他人覺得閑的慌,就得找活幹,就得提方案,提需求,sigh~

  「效度預估」和「效果複盤」這兩項工作很重要,但是受到的重視程度遠遠不夠,有時候我會想兩個問題:

  「效度預估」和「效果複盤」都屬于重要性高但緊急性低的事情,這樣的事情很容易在忙的時候被忽略掉,萬一再碰上有員工離職,這時候可能需要一個人幹兩個人的活,稍有一點空隙時間了,也只是靜坐在那裏,發呆放空休息一下,久而久之,沒有人覺得需要預估,需要複盤。事實上,這件事情是需要産品負責人寫到工作原則中去的。

  總之,對于以廣告爲贏利模式的C端産品,當用戶達到一定量級之後,很多數據的變化和波動是綜合因素導致的,很難說數據上升或下降是由某個特定的新功能的導致的。而且很多功能上線後,往往有非預期後果,非預期是指不知道什麽時候産生。

  後果可能是正外部效應,也可能是負外部效應,但正因爲此,才更需要産品經理們刻意練習「效度預估」和「效果複盤」的能力,從錯綜複雜的表象背後深挖出真正的邏輯關系,才能逐步把産品量級提到新的高度。

  相反,如果始終不留出時間做「效度預估」和「效果複盤」,你可能最終于成爲一名渾渾噩噩的産品經理。