作為產品經理,我們努力的方向究竟對不對?
產品經理之路,漫漫而修遠。這條路上,會有鮮花掌聲,會有荊棘坎坷,愿你萬里歸來,仍是少年。
最近接到了很多同學的困惑:有的是應屆畢業生,希望畢業之后從事產品崗位,但是不知道從何下手;有的是想由別的崗位轉崗到產品崗,但是不知道從何學起;有的是已經在產品崗有過幾年經驗的產品汪,但是慢慢的發現摸到了天花板,卡在了職業發展的瓶頸處,不知道應該何去何從。接下來,我們以幾個常見問題為切入點,聊一聊在產品經理這個崗位上,我們努力的方向到底在哪兒?
產品經理需不需要非常精通原型工具?
有些同學跟我說,自己剛剛轉行產品經理,正在自學axure與墨刀。我問,為什么要同時學習兩個工具?
很多剛剛入行的產品經理并不知道產品經理這個崗位的核心價值與核心競爭力是什么,因此不知從何處下手開始學習,只是知道產品經理會用到原型工具。
顯然,工具類的技能學習,是入門最簡單的,也是最沒有門檻的,于是很多同學們抓住了這根救命稻草,找到了唯一可見的一個努力方向,拼命的學習了起來。網上搜各種教程、各種書籍、各種貼吧、求助各種大神,耗費了巨大的精力去學習動態面板甚至是中繼器這樣的比較晦澀難懂的高階組件。但是現在學完了之后,發現在實際的產品設計的過程中,輸出原型的效率依然很低。
今天我們不談論如何提高Axure使用效率與高階使用技巧,既然很多人如此的執著于Axure高階使用技巧,我們就要先知道,原型圖真正的作用是什么?
原型圖在產品研發的過程中,是用來與研發同學進行需求評審與溝通用的,是用來給UI同學提供高保真輸出的基本參照的。
那么,研發與設計師這二位同學需不需要一個精度極高、添加了所有復雜交互的原型呢?
答案是,都不需要。
研發同學的需求是:在需求評審的時候,能夠看明白你這個頁面有哪些字段、元素,這些字段與元素有哪些狀態,頁面哪些地方是熱區,點擊熱區之后激發的下一步相應是什么,頁面與頁面之間的跳轉邏輯是什么,能夠這些講清楚,就足夠了。
而UI 同學的需求更簡單:能按照原型圖的樣式輸出高保真設計稿,就可以了。
在高保真的設計過程中,UI同學是有一定的自主權的,往往不會嚴格按照原型圖的樣式進行設計,甚至有的時候跟原型圖的出入還會比較大。因此,即使你輸出的是“像素級”的原型圖,在UI同學眼里,只是一個樣式而已。當然,顯而易見的是:一份清晰、整潔、條理清晰的原型圖,是一定能夠加分的。畢竟,向往美好是所有人的本能。
原型工具,說白了只是一個工具而已。對很多人來講,花20%的精力就可以學會Axure80%的功能,而這些功能,在實際應用中就足夠了。但是花費180%的精力不一定能夠學會Axure剩下的20%功能,而往往剩下的20%的功能在真正的產品設計的過程中完全用不上。因為互聯網本身就是快速迭代的領域,上線速度的快慢往往就是生與死的差別,等你剛剛出完原型并用中繼器加上了所有的高階交互的時候,扭過頭一看,隔壁友商已經上線了,這時候你猜大領導會不會讓你去財務室領這個月的工資?
你想完全駕馭Axure這個工具,醉心于把Axure十八般高階組件全都耍的有模有樣,但是在這個過程中之中,你其實已經被Axure所控制。跟各位同學分享一句話:
你想控制的,最后往往都控制了你。
產品經理需不需要懂技術
有一位轉行沒多久同學跟我說,他剛剛入行產品經理,正在自學Python,很顯然這位同學是認同這個觀點的。我問他你為什么要自學Python,是想轉研發嗎?這位同學同學的回答也許道出了很對產品同學的心聲:
我學技術是為了能更好的跟研發溝通啊。
產品經理需不需要懂技術,其實這個問題很籠統很模糊;要回答好這個問題,就需要定義好什么叫“懂技術”。懂多少算懂?只有明晰了這個邊界,這個問題才有意義。
接下來,我們用一個具體案例去明確這個懂與不懂的邊界到底在哪里。
案例:你設計了一套會員體系,有M個會員,每一個會員的標簽或者維度有N個,需要研發同學在數據庫中進行數據存儲,那么對于數據庫的同學來講復雜度是以乘積的形式增長的,即M*N。
數據庫同學可能會跟你吐槽:你知不知道什么是笛卡爾積???那么大的數據量要不要用CDN?要不要做分布式存儲呢?聽到這里你可能已經一臉絕望了,臉皮厚點的可能會問下開發,什么是笛卡爾積、CDN、分布式存儲?臉皮要是薄一點可能直接就捂臉跑開了。
在這個案例當中,產品與研發兩位同學明顯就是因為領域認知差異而導致了溝通障礙。研發同學這種一言不合就甩專業名詞的行為,有可能是因為研發同學深諳溝通技巧與心理博弈技巧,希望通過這種甩對方不懂的專業名詞的方式,來建立溝通優勢與心理優勢,以便最大程度的爭取后續溝通的主動性;也有可能單純的研發同學只是想炫一下自己的專業性,看著產品經理同學的完全聽不同的樣子,小小的虛榮心得到了滿足;也有可能研發同學只是形成了口語習慣,順口就說出來了。總而言之,如果說是一位完全不懂技術的產品同學,那么在此次溝通中就已經處于劣勢了,后續的溝通就可能比預想中困難,需要調整、甚至推翻之前的整個方案。如果說這是一位懂技術的產品同學,就可以直接回應:
我最初已經考慮過SQL中笛卡爾積表的這個問題了,因此在最初進行標簽選擇的過程中,已經進行了最大程度的標簽刪減,既能夠滿足需求,又能夠給你們減輕工作量。會員體系的存儲就采用分布式存儲,已經確認過公司現有服務器的數量,完全可以支撐此次分布式存儲的需求。
當這位懂技術的產品同學說出這樣一番話之后,原本已經傾斜的溝通天平指針,就已經被產品同學成功的拉回來了。
說讓產品經理懂技術,并不是要求產品經理能夠親力親為的寫代碼,而是要懂得產品設計上某些功能的實現邏輯是什么,以便在最初的產品設計中就能夠站在研發同學的立場去考慮產品;能夠在與研發同學溝通的過程中處于平等的位置,以便雙方溝通沒有大的障礙,保證高效順暢的進行。
那么在這個案例里面,需要產品經理懂的,就是會員體系的存儲方式是什么,笛卡爾表是什么,分布式存儲是什么,分布式存儲的前置條件是什么;不需要產品經理懂的,就是笛卡爾表在SQL中如何實現,每一個字段如何存儲,分布式存儲在服務器上如何實現,調取數據的實現邏輯是什么。當然,這個邊界有可能會隨著不同的公司、不同地團隊而略有調整,需要每一位產品同學在日常工作中與研發同學不斷相互適應、相互磨合,才能夠找到產品&研發這兩只刺猬之間的最佳距離。
笛卡爾積在SQL中示意
分布式管理:是將數據分散存儲在多臺獨立的設備上。傳統的網絡存儲系統采用集中的存儲服務器存放所有數據,存儲服務器成為系統性能的瓶頸,也是可靠性和安全性的焦點,不能滿足大規模存儲應用的需要。分布式網絡存儲系統采用可擴展的系統結構,利用多臺存儲服務器分擔存儲負荷,利用位置服務器定位存儲信息,它不但提高了系統的可靠性、可用性和存取效率,還易于擴展。
CDN的全稱是Content Delivery Network,即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節,使內容傳輸的更快、更穩定。其目的是使用戶可就近取得所需內容,解決 Internet網絡擁擠的狀況,提高用戶訪問網站的響應速度。
屬于產品經理的“工匠精神”
最后要跟大家分享的,是這幾年一直很火的一個詞,叫做工匠精神。那么,什么是屬于產品經理的工匠精神?
接下來,還是拿一個案例來解釋,而這次的案例,是我的親身經歷。
那是N年前,在我剛剛開始做產品不久的一次產品評審會議上,公司的CEO參加了這此評審。當時有一個功能是:用戶提交給運營后臺審核,要顯示一個倒計時。
在倒計時的時間設置上,我當時沒有進行過多的思考,直接設置成了48小時。
這時CEO直接問我:為什么是48小時?我問你,47小時可不可以?49小時可不可以?差1分鐘48小時可不可以?48小時零1分鐘可不可以?
這一連串的問題問下來,問我的啞口無言。接著CEO又說:你有沒有考慮過用戶提交運營審核的流程是什么?我們內部審核的流程是什么?你沒有想清楚整個流程,所以你的倒計時時間就的制定就是沒有依據的。
案例結束。
誠然,運營部門處理用戶的流程也許確實不應該由產品經理來定,應該由運營部門內部去制定,而且倒計時的時間也不會真的苛刻到精確到秒。但是這種凡事追求極致的思路,極其深刻的影響著我之后所有的產品設計工作。
比如,我設計的toast提示,無特殊情況的話,toast顯示時間都定為1.5秒,需求評審時,部分研發同學可能會問(但是不問的占大多數),為什么是1.5秒?這個時候我可以告訴研發同學:
1.5秒是人眼視覺暫留達到最大效應的最短時間,即:0秒—1.4秒這一段時間視覺暫留效應會隨著時間的增加而增加,并在1.5秒達到頂峰,從1.6秒往后視覺暫留效應不會隨著顯示時間的延長而增加,并且如果時間再長,toast就會打擾用戶操作。少0.1秒還未達到最佳提示效果,多0.1秒會打擾用戶操作,1.5秒,是這么來的。
(toast顯示時間可以隨著toast實際應用場景的變化而相應調整,這里指討論最常見的場景)
視覺暫留效應與時間關系圖 僅作為示意,在視覺暫留效應實際強化過程為非線性。
再舉幾個小例子:
- 電商產品中,商品名稱的字數上限閾值,如果你定了30個字,問問自己,29個字行不行?31個字行不行?為什么偏偏是30?(要結合字號大小與頁面展示效果考慮)
- 購物車中每一個SKU可添加進購物車的數量上限閾值,如果你定了99個,問問自己,98個行不行,100個行不行?為什么偏偏是99?(要結合后臺數據考慮)
- UGC社區限制用戶每天最多發帖量上限閾值,如果定了是3篇,問問自己,2篇行不行?4篇行不行?為什么偏偏是3篇?(要結合后臺數據考慮)
如果你問自己的那些問題,自己也模棱兩可,覺得加一、減一好像都可以接受,沒有想清楚就給一個大約的數據,覺得“差不多”就可以了,那么你的方案就是經不起推敲的,其實是不負責任的表現。那么,我把我老領導的那句話送給你:
你就是沒有想清楚。
思考:為什么新浪微博發文字微博的時候字數設定的是140字?139字行不行?141字行不行?
作者:譚小超(微信號:tanchao594460) ,北大心理學碩士,擅長心理分析&電商領域。
本文由 @譚小超 原創發布于人人都是產品經理。未經許可,禁止轉載。
受教了
最后那段寫的很對。經不起推敲就是那么一句話:你就是沒有想清楚 ??
寫的挺不錯的
寫得很好,對于剛入門的PM來說,可以少犯一些錯
受教了