常聽人說,PM要處理的事包山包海,還真的所言不假,舉凡老闆、業務、行銷、工程師、設計師,甚至財務法務,通通都得是你的老相好。
以遊戲來說,我覺得聖騎士是一個很適合描述PM的角色定位,有一些力量、會一些治療、還可以開啟靈氣給隊友們上Buff!
離題了。讓我們回到正道上。
其實對產品團隊來說,一個好的PM有三大核心價值,包括
商業敏銳度、
開發技術,以及
使用者體驗。Martin Eriksson在2011年就已經提出這個概念,作為一個想成為PM的人,我們試著依照這個框架,套入現場的工作狀況來瞧瞧。
商業敏銳度 (Business)
除了特殊案例,絕大多數的商用軟體,最終的目的都在賺錢。舉凡銷售人員、行銷,乃至於整個開發團隊,還有站在你身後的大老闆,其實都是為此在努力。
俗話說「生意囝歹生」,要能對商業目標提出洞察,絕不是件容易的事。從對客群的了解、付款的習慣、口袋的深度,到銷售流程、潛在市場規模、產業脈動,只有你能對這些了然於心,才有機會提出有效的改進計畫。多跟業務、行銷人員聊聊天,去知道他們怎麼銷售你的產品,過程中遇到哪些問題、需要什麼幫助。
例如我目前負責的產品,是透過AI來分析專利有效性的軟體,由於當初定價混亂,加上在同一個訴訟案中也可能必須參酌多份報告的內容,來做為決策依據,一篇篇的購買報告對客戶來說就像是在下注一樣。
因此,前陣子我們做了大幅度的更新,將整個服務轉變為訂閱制,讓客戶可以不限次數的瀏覽報告,隨著賣出的帳號數量也越來越多,不僅在商業目標上獲得更多成長(而且來了好多大客戶),更為我們帶來更豐富的使用者數據可供分析。
一舉兩得!
開發技術 (Tech)
作為產品經理,不可避免的需要和偉大的工程師們打打交道,都說了程式語言是另一種語言,如果你就是不會寫,也看不懂Code,又該怎麼辦呢?
千萬不要嘗試觀落陰,或說一些怪話!
你可以不用看懂他們寫了什麼,但至少得知道他們怎麼把這些東西組合起來,以及該用什麼方式把你想要的東西描述出來,讓他們可以照著做出不走鐘的功能。
若是不知道該怎麼開始,可以先偷偷跟幾場開發或SCRUM會議,了解團隊的開發流程;或是在開規格的時候,多與工程師或技術經理溝通,看看每次缺漏的地方是什麼?哪邊需要更詳細的說明?可以的話,去學學怎麼畫流程圖(Draw, Whimscal都是不錯的工具),遇到哪邊需要做判斷,判斷後分別要導向哪裡,久而久之,你的規格肯定會越來越像樣。
使用者體驗 (User Experience)
設計師們最討厭的溝通方式,千萬別這樣叫他們改圖...
如果說前面提到的商業敏銳度是針對客戶,使用者體驗自然就是聚焦在使用者身上了。以B2B軟體來說付錢的是客戶,但真正在用你產品的才是使用者,只有這些人用了你的產品,提高了他的生產力,老闆才會滿意的下單。因此,持續優化使用者體驗絕對是必要的一環。
按鈕找不到、按下去等好久,使用者從一接觸你的產品,就開始了他的使用者旅程。他可能沿途風景亮麗,相當滿意,卻在快抵達終點時,因為踩了個小水坑對你破口大罵,氣得連旅費都不付就走了…
所以你得多跟使用者交談,或是藉由Full Story這類的工具,看看這些人到底都是如何粗殘的對待你的產品。產品經理不一定要是個UI/UX設計師(雖然我是滿喜歡畫的啦),但你一定要意識到,只有這些人一路上都開開心心,產品才有機會成功!
去看點基本的使用者體驗書籍、在設計師交稿前多跟他們談談心,了解一下介面配置安排背後的用意,如此一來,下次你也能在正式完稿前說上幾句,讓整個介面設計與使用者體驗更趨近你所了解到的使用現場。
若是這篇文章對你有點幫助,請不要吝嗇拍個手!
或是有任何有興趣了解的主題,也歡迎留言告訴我!