需求評審,是“懟你”還是“愛你”
需求評審被boss、開發、測試、運營、設計圍攻,要不就是需求不靠譜;要不就是需求邏輯、技術實現沒有考慮清楚。那么我們如何避免這種情況發生?
需求評審時由整體到部分的介紹,由總到分
比如:先講整體的需求背景、需求目的,頁面邏輯,再一步步沉浸到細節的邏輯設計上。
(1)業務場景
不要一上來先就看流程看原型。對于研發,他們職能的視野局限著他們對業務的了解,產品不把場景講清楚,上來就是方案,懵逼了。比如:購物流程太繁瑣,數據顯示很多用戶第二步、第三部就放棄支付,最終成交率才10%。(購物車銷售漏斗)
(2)目標、目的
比如:轉化率提升3倍,公司收益,用戶體驗吧啦吧啦。
(3)方案
打算怎么做?目前方式是否可行?還有沒有更好的方案?
幾點必須要注意:
- 需求背景需求目的必須是建立在理解公司的目標和發展愿景之上;
- 能清晰地告知團隊,達成目標和完成產品指標,將會如何增強公司的整體戰略部署;
- 把團隊看作為公司服務,以及連接其他團隊的力量。
需求評審不是讓PM去說服程序去編碼的而是就某個問題搞出一個最優的方案出來,能完美解決問題,且投入少(人力、時間、費用等資源),收益符合預期。
我們不可能就每個目標(每個功能都應該有目標),把需求方、開發等職能召集在一起頭腦風暴,而是委派產品經理用自己的專業知識、經驗、調研就這個問題先提出一套方案(產品經理存在的價值就是為了解決問題),這并不是說PRD(or MRD)就是唯一可行的且必要要執行的方案。
產品經理應該通過鼓勵每個團隊成員發表看法、暴露分歧、再調節沖突,來最終形成有團隊共識的決策。也就是說,盡力確保每個成員都同意執行當前計劃。產品經理自己可以有好的創意,但重點不應該是讓團隊盲目地執行產品經理的想法。恰恰相反,
搭建一個流程,和團隊一起在充分的認同下,做好協同決策。保證團隊在交付產品給用戶的工作中不會踩坑。
?此外,表達更需要結構化的表達。
什么是邏輯化結構化表達?
大家在講一件事情的時候比較容易有代入感,當我們在描述一個非常復雜的話題的時候通??梢圆扇煞N結構去描述,Inductive和Deductive,這兩種不一樣的描述方式,可能會帶來一些差異。
(1)歸納講述
比如說,假設大家都知道普華永道是全球頂尖的會計師事務所,接下來就要描述它業務如何如何、為什么是業內第一,那最好的溝通邏輯結構最好就是將結論放前面。
(2)演繹講述
如果要講一個大家都不知道的事情,比如說:RPA如何應用在財務共享中心里面,讓財務共享中心發揮最大的實際價值。像這樣的問題呢,即便把結論放到前面,大家也不知道是什么意思。所以,要采用演繹講述:就是從什么是RPA、什么是財務共享中心、到他們一般的應用場景再到如何使用,再到最后,點出最想點出的重點。這樣會讓大家更好地去理解。
完善產品本身的業務邏輯、頁面邏輯
我們常常發生爭論的其實不是目標,而是做法上的分歧。
(1)產品做法應該要有一套“理論”支撐,
可能是成熟優秀的競品、可能是調研或者數據分析等,總之得找東西支撐觀點和方案,在做方案的時候其實就是一個論證的過程,跟寫作文一樣,自己覺得寫得很好,論據充分,中心明確,邏輯順暢,別人看的時候可能就看出來問題。
如果在需求評審中,冒出其它方案來,看起來也能解決問題,有時候往往PM會不知所措,這種情況下更容易讓現場失控。撕逼的時候,瞳孔放大,汗毛豎起,毛細血管擴展,是很難沉著冷靜思考的。
所以,我建議PM有方案底稿后,先找更高階的產品看看,指點下,也建議找找有經驗的研發、測試、運營,特別是參與評審的領導(這個不用講了吧)也問問他們的意見,爭取把分歧消除在開會前,這樣產品辛苦點,會議效率高一點。
(2)另外一點就是你應該想到別人可能發問的點在哪兒
別問為什么,因為我們是產品,我們要有從10種方案中論證出一種最優方案的本事。
寫在最后
我覺得產品方案在評審的時候被人噴,是極好的,實打實的提升自己的產品能力。一懟二懟三懟的來回批斗和不斷完善中,產品方案才能逐步完美,產出才能保證效果。
一個產品在想清楚的情況下,實現中還會因為這樣那樣的問題而無法達到預期狀態,一個沒有想清楚,懟一下就蔫兒回去的產品方案,又如何能保證線上的成功呢?
責任心的開發和UED才能如此以owner精神懟產品。而遇到這樣的懟,是打是親罵是愛的懟,遇到這樣的虐,是虐戀的虐是打鐵成鋼的虐,應該開心有人幫忙發現這些問題,評審完馬上針對這些漏洞找各種方法完善自己的產品方案和產品邏輯。
這樣的過程才能真正做出好的產品,也才能真正建立自己在其它團隊的影響力。而回過頭來,當產品上線并有效果時,只能感謝這樣虐的過程。
埃爾曼強調,沒有任何一個產品會滿足所有人。對的產品的誕生,都是一個不斷調優和迭代的持續過程。產品需要擼起袖子幫助他的團隊一起走過這場旅程。
總結一下被懟被虐不是一件壞事,如果有一天,需求實現方在評審上面對有問題的需求一句話也不說的時候,也許是內心深度對這個產品徹底失望的時候。而此刻作為產品才應該覺得悲哀。
產品經理既要有良好的直覺來判斷對與錯,也要擅長傾聽早期測試人員或用戶的反饋。同時,也要善于獲得創始人或其他領導層的感受,來保證產品是在正確的方向上。
作者:次小吉,本職為一只產品汪、輔線運營。愛好廣而雜,偶爾神經病,希望能與大家分享產品成長路上的血淚汗。
本文由 @次小吉 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖作者提供
很多時候,方法論我們已經知道了,但是實現的過程中總是忽略掉這些細節,或者不注重這些細節,如果可能的話,做產品還是得按部就班,按圖索驥
看的出來平時沒少吃苦,都是痛過的感悟,加油。任重而道遠。
最后的總結很人頭~這需要產品有超強的心理素質和開放的工作態度……