產品經理需要具備哪些技能?
例如:
工作內容:1解構產品 2寫競品分析報告 3寫BRD、PRD 4繪製原型圖
工作技能:1掌握axure、思維導圖的使用 2溝通能力 3數據分析能力
入門及提高:關注產品方面的自媒體、網站 等等
希望各位前輩能夠給後生指條明路!
========前言========
這幾天一個朋友問我關於互聯網產品經理到底是如何工作的,需要什麼樣的專業技能,索性就聊開了。
從教條式的1.2.3.4點工作步驟;應該遵循的各類原則;到現在流行的大數據分析、數據驅動產品;再到如何打造完美的產品原型等等。然而我聽到這些東西後,覺得除了可以在外行面忽悠一下對方之外,其實並沒有什麼卵用。
同時我也發現在這個互聯網信息爆炸的時代,如果一個人在攝取信息的同時若不加以思考的話,結果很可能就是出現茫茫多的自以為是的大牛,而這些自以為是的大牛又會在互聯網上散布更多的教條式的、未經思考過的信息來坑害更多的人,這就造成了一個惡性循環,其結果就是指數性的增加這些滿口教條卻不知其所以然的大牛們。反應到我們所在的互聯網上則是各類自我感覺良好的奇葩產品,以及讓投資方的錢打水漂。
寫到這裡,我其實建議我身邊所有的人在有可能的情況下都去涉及一下哲學,其目的的在於提高自身獨立思考的能力,儘可能的擺脫教條、思維固化以及烏合之眾的角色。有這樣的基礎可以說在任何領域都是非常有價值的,而對於接下來所要談論的互聯網產品經理這個角色來說,也同樣如此。
========正文========
首先,我們須要明確一點:任何一個產品的出現,其目的都是為了解決目標用戶的問題,解決這些問題之後也就對用戶產生了價值,而對用戶所產生的價值是產品的價值。
產品經理需要創造出這樣的產品,也就不難理解其工作就是:在當前所擁有資源的情況下,找到用戶問題的最優解,並且高效的將其執行落地。
同時我們可以將其分為【找最優解】與【執行落地】這2個方面進行闡述。
【找最優解:懂用戶】
如果要找最優解,首先就需要懂用戶。懂用戶最好的方式就是成為用戶。有什麼人會比用戶本身更了解自己的痛點呢?有多少經典的產品最初不就是解決了其開創者自己的一個痛點嗎?
市場調查,大數據分析,用戶行為分析等,這些都是用戶的行為與其表達。可用戶的行為並不能完全代表其意圖,用戶的表達則可能有更大的偏差,所以都不及成為用戶有效。這就是為什麼我認為如果有一個產品,自己人都不喜歡使用它,那麼這個產品基本會很拙劣的原因;這也是為什麼我非常唾棄現在吹噓的所謂數據驅動產品,以及過分誇大數據分析重要性的原因。
數據在大多數情況下,僅能作為產品驗證的工具,並且是不是好的驗證工具,還得看我們怎麼去讀它,至於數據驅動產品、大數據分析等,大多數的情況也只是看起來很美。
這裡我舉一個例子:
某商戶分類網站,做用戶行為分析與統計,發現「XX01」「XX02」等類別是用戶點擊率最高的類別,所以認為按其點擊率來進行分類排序是更好的選擇,這樣可以讓用戶更快速的找到其類別,於是按此執行下去;新版本發布後用戶開始吐槽了:「為什麼我平時用的多的XX03類別被放在了那麼不起眼的位置?我不服!」;PM發現了其問題,原來每個用戶的喜好是不一樣的,之前的決策存在問題,所以改變了策略:分別按每個用戶的點擊率來做統計,動態調整每個用戶的類別展現方式,這樣就避免了每個用戶喜好不一樣的問題,產品按照其策略執行下去;新版本發布後用戶又開始吐槽了:「為什麼老是發現分類位置在變?我每次都要去找我需要的類別,而不能憑經驗位置來使用,我不服!」;PM又發現了問題,原來用戶還有使用習慣,不能時刻改變其類別按鈕的位置,所以為了解決這個問題,馬上提出了這個問題的「最優解」:讓每個用戶可以根據自己的喜好,來調整類別按鈕的位置,這樣就解決了以上所有問題,於是再次執行下去。這次沒有用戶抱怨了,PM額外開心,感嘆找到「最優解」真不容易,可好景不長,當再次統計這個新功能的用戶使用情況時,發現使用率低得可憐,做了這麼多數據分析,用數據驅動產品,花這麼多時間做出來沒幾個人用的無關痛癢的功能,真是日了狗了!
也許你覺得這樣的事十分可笑:「這類常識性的問題居然要做用戶行為分析與統計?」但這些東西都是我們身邊時時刻刻在發生的,其原因不由我說。這就是為什麼我認為常識與慎密的邏輯性是一個產品經理必備(當然還有智商與品味),並唾棄教條的原因。每個成功的產品就好比一件藝術品,是獨一無二的,沒有太多規矩可循。
我們繼續回到懂用戶這個話題上來,成為用戶是最好的了解用戶的方式,那麼誰都可以做,但並不是誰都可以做的好。做的好不好在於了解其用戶的深度,而深度就需要理解其用戶痛點背後最為深層次的根本問題,而這就是我建議大家都去涉獵一下哲學的原因之一。對於這點,想要做得好也沒有什麼方式可以快速學習,這得依靠個人的生活經驗、常識、品味等綜合軟實力,所以你會發現世面上好的產品,有品質有品味的產品,往往其產品經理也是有品質有品味的,他們的氣質有著驚人的相似。
所以在懂用戶這一點上,需要的是:智商、常識、慎密的邏輯性與品味這類軟技能。
【找最優解:解決方案】
在懂用戶後,接下來就是想辦法解決這些問題了,並且是在當前所擁有資源的情況下來解決這些問題。
這裡也衍生出一個大家經常問的問題:產品經理是不是需要懂技術?這裡我也給出一個非常明確的回答:必須懂!
我們是在用所擁有的資源以及工具來解決問題,互聯網產品中這些資源很大部分就是計算機技術本身,試想如果連這些解決問題所使用的工具資源都不懂,又如何可以保證能夠找到最佳的解決方案呢?這從最基本的邏輯上都是說不通的。無論綜合實力如何強,如果不知其所以然,到頂也就是一個超級用戶。
即便勉強找到解決方案,也是在其他人的建議、人云亦云,或者「別人這麼做,所以我們也這麼做」的邏輯下找到的。那麼這樣的解決方案對產品經理來說是完全沒有底氣與立足點的,因為其本身也不知道為什麼這樣是最好的方案,特別是當其他人的建議存在異議或頻繁發生變化時,只能憑藉對人的信任度來做判斷,無法做到知其所以然,就更為混亂了。所以這樣的產品往往都存在很大的技術與邏輯漏洞,甚至是可笑的常識問題。
當然這裡的懂技術並不是要成為領域專家,而是要懂得技術原理,知道其所以然即可。
找解決方案並不是一個簡單的過程。在你使用現有資源解決了用戶問題之後,很多時候會衍生出一個新的問題;而新的問題如果不解決,又可能導致之前解決原有問題的方法完全無效;為了解決新的問題,又可能會衍生出另一個新的問題,非常容易牽一髮而動全身;這樣就會需要把無數個問題一起放在腦子裡做各種各樣的排列組合,做各種權衡,最後才能給出一個相對合理的解決方案。
這樣的例子太多了,我隨便舉幾個:
很多網路產品在做內容推薦時,往往面臨幾種選擇:自動化推薦,這樣效果不好;人工介入,又會需要考慮到人工成本。新的成本會涉及到公司現有產品預算問題,超預算又要考慮到融資等一連串問題就來了。那麼這個時候就需要做權衡,人工介入到什麼度可以達到能夠接受的推薦效果而成本也是可以接受的,像這樣的權衡問題在一個產品中實在是太多了,只是靠譜的PM會憑藉其經驗與直覺來快速的做判斷。
再來看一個我們平時都知道的房產網站。為了吸引中介與房產出售/出租的賣方,豐富其信息資源,那麼相對來說就要放寬對賣方的限制,但這樣就容易導致虛假信息問題。這個問題不解決,就會導致平台對買方價值降低;買方減少,從而影響平台對賣方價值,惡性循環開始。所以會需要通過賣方實名認真,買方用戶評價與舉報等方式制衡賣方,消除虛假信息。但這同時需要一個度,循序漸進,過度控制還可能導致賣放流失問題等等,這些問題就像是多米諾骨牌,需要小心的去呵護它們。(不要和我聊當今的房產網站,我不想吐槽!) 接下來聊聊社交產品,許多社交類產品中都有關注用戶的關係形信息與探索新的信息功能,孰重孰輕就還需要考慮到產品所處的階段。如果所處早期階段,用戶本身不多,更不用說已經相互建立聯繫的用戶,那麼這個時候就需要突出探索新的信息功能,把精選、推薦等放置在一個相對顯眼且重要的位置,讓用戶更容易建立新關係的同時,使得整個產品的內容不那麼空洞;而如果所處在一個比較成熟的階段,則相反需要突出關係形的內容,從而強調其社交性與加強粘性。 最後再看一個平時被人問得多的問題:APP產品中,底部菜單欄是否需要文字說明?如果仔細思考,會發現各自都有優勢:有文字可以提高功能識別度,而沒有文字則讓應用設計更為簡潔、品質更高。這其實就是在「識別度」與「簡潔的產品品質」上做選擇,如何選擇就需要考慮到現有的具體產品與具體受眾了。如果是電商類的產品,比較大眾化,那麼識別度會相對更為重要。如果是社交類的產品,定位相對高端,那麼產品品質會更為重要。當然這裡的例子其實是一個設計上的抉擇問題,之所以列舉是想要說明在做這些權衡與抉擇時,具體的產品類型與受眾是需要充分考慮的一個點。
一個產品,幾乎不可能在一開始就十全十美,否則過長的研發時間會導致錯過市場機會,這就同樣需要做取捨,同時還需要擁有對現有問題的容忍度,例如:早期項目可以不去考慮高並發的問題,用戶不會有那麼多;不用過份考慮安全問題,沒火的產品遭遇攻擊的可能性非常小;甚至不用去考慮效率問題,提早上線比什麼都重要。但容忍問題並不是忽視問題,而是知道這個問題應該在什麼時候去解決它。隨著產品不斷的迭代,有節奏的將其逐個解決掉。
所以在找解決方案這一點上,需的是:了解技術原理,擁有考慮問題的全面性,遇到問題做權衡與抉擇的能力。
【找最優解:方案文檔】
如果通過種種權衡與抉擇,最後方案在腦子有概念了,這個時候就需要藉助工具來將其表達出來。工具的作用就是將方案用最簡單明了的方式表達給接下來所需要讀懂他們的人:設計師、前端工程師、後端工程師,老闆等等。
如果需要全面的控制產品,以及讓這些人都能夠明白產品的邏輯,需要3個文檔即可:原型文檔、API文檔、資料庫文檔。原型文檔決定了產品頁面邏輯,API文檔決定了頁面對應的數據邏輯,資料庫文檔決定了最終的產品數據如何存儲。這是一個產品最為核心的幾個部分,可以說這3個文檔定下來,產品基本就定了,再怎麼跑也跑不遠,如果需要把控好產品,就把控好這幾個文檔,保證其邏輯通暢且沒有問題。
原型文檔的工具有很多:Axure、Visio、AI、PS、OmniGraffle等等都可以做。當然不要忘了工具是為了表達,不要迷信工具本身。所以我一般會建議會什麼用什麼,什麼簡單用什麼,我個人一直都用OmniGraffle就是由於其簡單且快速,一個下午就可以把腦子裡的東西全表達出來。同時我對那些把原型做到特別精緻,交互效果等全整上的原型無感,不是說這樣的原型不好,而是在原型上用大量的時間去做一個一句話就能表達清楚的內容是得不償失的,細節應該交給設計師。
API文檔的話,最好是用WIKI來做,這樣容易溝通與做升級變更。前後端開發之間可以依此來界定工作上的權責問題。
資料庫文檔的工具就更多了,從UML工具到簡單的Numbers表格都可以,原則就是簡單順手,可以表達清楚。
關於這幾個文檔,一定一定要保證其邏輯通暢。這幾個文檔相輔相成,相互影響,所以我主張由產品經理統一來完成,即便某些文檔不做也需要對其進行審核。否則很可能會出現例如:頁面上需要展現一個數據,但API中沒有,想要修改API卻發現資料庫中沒有數據,資料庫需要做調整,但又有可能影響到其它方面,等等這類的邏輯問題。這些問題的出現會造成大量的工作時間被消耗掉,也是產品經理工作不合格最顯著的體現。如果一個產品幾個月還不見蹤影,每天大家都在扯皮,功能需求改來改去,如果老闆沒有強制性干預,那麼這裡的產品經理就是不合格的,靠譜的產品經理會很少出現這類產品邏輯性問題。
所以落到實處的方案,需要的是:擁有產品表達能力以及會使用基本的產品表達工具。
【執行與管理】
現在方案已定,終於到了執行階段,那麼接下來的問題就相對簡單多了,需要考慮的就是權責界定以及執行順序與計劃等問題。
如果之前的三份文檔沒有問題,那麼在執行過程中的權責界定就完全不是問題,文檔其本身已經把項目中的角色非常明確的劃分了出來。
在執行順序上會有一點講究。
首先,需要按照產品的邏輯關係來調整執行順序。例如需要先做用戶註冊登錄功能,才能保證用戶詳情頁的數據是可測的這類邏輯順序。
另外,需要注意各個角色之間的無縫配合,保證整個開發流水不被阻塞。例如我計劃今天要把首頁完工,那麼在昨天我就需要保證首頁的設計與切圖、以及對應的API完工,並且是沒有問題的,如果有問題就需要相關的人員在今天的工作開始前將問題解決掉,否則會阻礙到當天前端的開發進度。
這類項目管理的技巧在任何有好的管理經驗的人中基本都懂,所以這裡也不做過多的闡述,總之管理的根本在於權責明確。
當然我們方案也不太可能是十全十美的,在具體執行過程中也會遇到一些之前沒有考慮到的問題,那麼就請繼續參照之前找最優解的方式循環處理。如果問題不是特別嚴重,也可以選擇忽略,把問題放到下一個迭代中。這裡需要著重強調的是:在執行過程中,千萬不要頻繁的修改產品。這不僅僅是影響到產品進度,增加無意義的工作,最主要的是朝令夕改會造成整個執行團隊像無頭蒼蠅一般亂串,做無意義的加班,並且對其產品經理的能力產生質疑,團隊士氣降低。 在執行過程中才發現的問題其本質上都是產品經理在產品設計過程中的本職工作失誤,如果這個問題大到不得不做修復,當前無法忽略的話,那隻說明能力不夠,還得先磨練與學習。如果你發現一個團隊每天加班加點,但產品質量不僅達不到標準,而且進度也十分緩慢,團隊中也沒有一人身兼多職的情況,那麼問題的根源在哪就顯而易見了。
最後就是執行團隊的氣氛與士氣問題了。平時忽悠下項目前景如何美好,我們的工作如何偉大,我們每天都朝著偉大的目標邁進著,我們是偉大的,是的,我們看好我們自己!這些東西的作用是有的,但是在現在到處充滿著雞湯的互聯網世界,可別指望有多大用。
最為有效的做法則是在執行階段作為一個服務者的角色,來幫助執行團隊解決問題,有一個團隊是在幫我完成工作的心態。一個產品成功了,大家都會說這個公司的老闆很厲害,其次是產品經理能力很強。並沒有多少人會關注其執行團隊,更不會說這個產品的關鍵在於執行團隊中的某某某,即使真的是這樣。所以還有什麼理由不去作為一個服務者的角色來服務好大家呢?還有什麼理由在產品獲取成功的同時不把功勞歸結於團隊呢?
所以在執行階段,需要的是:項目管理技巧與服務者心態。
========總結========
產品經理需要的技能包括:
良好的智商、常識、慎密的邏輯性與品味這類軟技能;了解技術實現原理,擁有考慮問題的全面性,遇到問題做權衡與抉擇的能力;擁有產品表達能力以及會使用基本的產品表達工具;最後需要擁有項目管理技巧與服務者心態。
========關於運營問題========
很多同學會有疑問,為什麼整篇文章中沒有運營的部分?是不是遺漏了?其實不然。
首先,我想大家必須要去掉「產品必須要有運營」的固態思維。因為並不是所有的產品都需要做內容運營。我們所有工作的目的都是為解決目標用戶的問題而服務,而不是為了運營而運營。
如果有需要做內容運營的產品,其運營本身就是對產品解決方案的一種支撐,其目的是為了解決目標用戶問題的,細心的人也會發現這些部分已經包含在了前文的解決方案中,而具體的運營執行工作,則會由專門的運營人員來處理,這就不在本文所要闡述的範圍之中了。
而對於平日所說的「產品本身的運營」其實就是產品迭代的過程,也就是根據產品所處的階段,對以上步驟的循環迭代。
========轉載請註明出處========
產品經理應具備的四個設計技能
首先我們必須指出的是,根據公司的規模,一個產品所需要的設計技能是會有所差別的。在一個小而緊湊的初創企業裡面,產品經理和用戶體驗設計師(UXD)這兩個角色通常是由同一個人扮演的。但是,隨著團隊的壯大,你作為產品經理的的職責就會慢慢發生變化(來自UXPin的這篇文章對此有更詳盡的描述)。
所以,在考慮以下技能的時候,請注意要把團隊的規模納入到考慮範圍之內。
技能一:高級用戶研究技能
頂級的產品經理能夠真正的了解他們的用戶,並能為團隊的其他成員正確的點出用戶的痛點,慾望和需求(通常是以描繪及設計人物角色(personas)或者故事板(Storyboards)的形式呈現)。
這意味著一個產品經理需要擁有很強的調研能力和同理心 --
他必須能夠和客戶進行深入的面談並進行相關的調研,綜合運用獲得的數據,並從跟客戶的對話中對問題進行透徹的洞察。無論你所身處的團隊規模是大是小,這一點都是非常重要的
-- 產品經理必須能真正成為客戶的喉舌,這樣才能對產品的發展方向進行掌舵。
設計技能要點:現場調研,可用性測試,人物角色設計,故事板,客戶旅程地圖(即customerjourneymap,簡寫CJM,這是一種描述客戶在使用產品或者服務時的體驗,主觀反應和感受的技術)。
技能二:交互設計技能基礎
一個好的產品經理應該能夠清晰的描述用戶的目的,並根據用戶的這些目的來定義好產品的功能點。除此之外,產品經理還應該能理清楚產品的架構,並能清楚的勾畫出用戶訪問每一個頁面和功能點的路徑。
隨著你的團隊逐漸壯大,也許用戶體驗設計師將來會幫你分擔這些責任,但是你自己作為產品經理還是必須擁有這些領域知識的,這樣你才能與客戶和設計師等作更深入的分享和互動。
在一個小點的團隊裡面,線框圖和用戶流程圖是產品經理和團隊其他成員進行溝通的非常有效的工具。如果你還身兼用戶體驗設計師這個職位的話,去熟悉一些通用的設計樣式(普羅大眾都能接受的常見的用戶場景的布局方案,如搜索、登錄框、設置等場景)也是很有必要的。此外,掌握一些交互設計領域的易用性原則也是很有用的,這樣你就不用做重新發明輪子的事情,也就不用擔心會搞出一個讓你的用戶飽受挫敗的設計出來了。
設計技能要點:草圖,線框圖,用戶流程圖,站點地圖(site maps),用戶故事,設計樣式。
技能三:品位
這個技能說起來可能會存在爭議,但是我覺得還是必須提出來 --
頂級的產品經理都會有著不可言傳的品位。作為產品經理,你自身並不需要是一個可視化設計師,但是,你必須能夠辨識出什麼是偉大的設計。
品位這個東西不是與生俱來的,你必須要涉獵大量的設計,包括好的設計和差的設計,並認真的進行對比,仔細分析為什麼這些就是好設計,而那些就是壞設計。通過大量的練習,最終你就會將你的品位提升上去,從而能夠引領你的產品團隊往正確的方向邁進。
之所以說品位這個技能存在爭議,是因為品位這個東西是很難去定義的,且如果你的品位不能獲得別人的認同的話,這種主觀性的觀點可能會讓你的團隊產生讓人氣餒的無謂爭執。
但無論如何,作為一個產品經理,擁有你自己的品位無容置疑是一件很好的事情。作為產品的「所有者」,如果大家都信服你的品位的話,你自身就在整個團隊中充當著一名值得信賴的產品質量判官,這就能大大的提高產品的質量以及避免掉一些沒必要的妨礙開發往前發展的爭執。有時如果你對自己的品位產生懷疑的話,你可以多去看看iPhone的設計,它就是品位很好的衡量標準。
技能四:可視化設計的基本概念
除了上面提到的品位,一個產品經理還應該知道可視化設計常用的辭彙。這樣你才能用設計師的語言來和對方進行溝通,從而才能搞清楚設計師之所以採取該設計方案的利弊權衡以及為什麼要這樣設計的深層原因。
你要知道,當你和設計師進行討論的時候,你用「對比度」,「層次」,「顏色深度」這些術語來跟他們溝通,比你簡單的跟他們說「把那個logo給弄大點吧」來得高效。
敏捷產品管理的「幻想」、現實與實踐【大型講座】
推薦閱讀:
※可否拿華為和阿里巴巴進行比較,你怎麼看?
※在知乎這個平台的討論中,應如何看待「維基百科」的正確性和權威性?
※初階產品經理,如何在繁雜的日常工作中,提高自身產品能力?
※中國政府有多大可能承認比特幣(BitCoin)為合法貨幣?