PM 痛點4:我要怎麼排開發優先序?- 不廢話

在開發產品功能的時候,Product人最常問自己也被別人問的就是:這個重要嗎?有很緊急嗎?大家都知道事情可以用重要度緊急度來劃分到底要不要優化某功能,但是PM怎麼更清楚的溝通開發效益呢?我想不廢話地談談過去這九年產品經理的職涯裡,我大概怎麼去排優先順序以及坊間上提到的常用規則,供所有開發者與產品團隊的一員參考。

產品目標

首先,PM要先確定公司上下對於產品的(1)目標跟 (2) 關注指標是什麼。

這可以是你自己仔細思忖得來的,也可以是與管理階層討論後設定的。幾乎每家公司的企業目標都是獲利或增加收益,所以我們這裡在談的是並不是這個最高層級的目的,而是產品的目標可以設定為什麼,我們又可以訂定什麼指標,來賺取期待的收益?

我現在的公司是一間一年多的新公司,在財務金融app的世界裡有一點點能見度。在獲得正收益的之前,我們更在意的是用戶使用某功能的成長,因為我們可以藉此得到用戶數據、匿名化機敏資料、提供業界跟我們有重疊用戶的各種企業分析,讓他們更了解他們的用戶的消費行為。

所以我們把2022年的年度目標訂為三個:

  • 增長A功能使用者(每日新增/減少使用者數量)
  • 增加A功能使用比例(使用A功能/總用戶比例)
  • 增長黏著度(DAU/MAU)

評估

這樣下來,PM所討論所決定的功能,都可以初步使用以上目標篩選。每一次我在思考新功能時,會想以下兩件事:

  1. 這個功能是否會讓我們往訂定目標邁進(提升我們的指標性數字)?
  2. 我們要開發的功能,是否夠獨特且不易被模仿?
  3. 大致上我們現有技術是否可以開發這個服務或這項功能(從沒做過區塊鏈的公司突然做相關功能,就不會是PM一拍板定案後,團隊立刻可以做的事)?

價值Value

再來,PM就要考慮功能可行性相對效益,並以此決定什麼先做,什麼該做。

Value,是第一個要考量的點,指的是該服務可以帶給客戶與公司的價值,可以是很簡單的量級1到5,也可以是估算過的數字如預期獲利。

不過,考量價值時必須考慮用戶(或者用戶與客戶)與公司兩方的利益,不能只是思考單方面獲利。

老闆們最常做的事(犯的錯誤)是:當用戶數夠多,公司稍微有些知名度以後,他們往往會請PM或是行銷團隊多放一點廣告、多收一點費用,等等,好讓「我們」的KPI提升。

而使用者得到的是非常難用的介面、無用的訊息、或是衝動購物後的挫敗感。

當然,用戶是得到了一些好做,但是若公司稍微換位思考的話,就可以看出那些只為公司利益的功能的背後,有數據分析上看不到的負面品牌形象、用戶觀感等等標籤被貼在公司的背後。

其他公司沒有注意到的用戶價值如:退換貨的簡易性(公司可能增加物流成本)、貼心的小幫助、操作的便利性的,都是PM 可以努力推動的。

平衡用戶與企業所得到的利益,應該是每間公司常常掛在嘴邊,但是實際上口是心非的地方。

我們應該前進的方向,就是那些價值很高,開發成頗低,且不容易被複製的那些功能與改善。

花費Effort

Effort,指的是產品團隊為了提供該服務或功能所需耗費的資源與時間

如果是軟體開發,大多指開發與維護的所需時間。如果是較廣義的服務,可能還會另外計算物流、行銷等等成本。我管理的是軟體,所以常常考慮的是純軟體開發與維護成本。

PM可以簡單將Effort 分為1到5五個數字,數字越大,實作難度與不確定性越高。

Value 除以 Effort

當Value 與Effort 相除的時候,我們可以得到一個數字。數字越大,就是我們預期效益會很高的功能。我們應該前進的方向,就是那些數字大(價值很高)但是開發成頗低,且不容易被複製的那些事項。當整個團隊一起討論value 與effort,並且將所討論的事情以便利貼攤開、貼在牆上時,往往會發現:我們為何把某高優先序的功能,排在那麼後面?

更完整的優先序設定框架:RICE

我傾向不使用太複雜的框架來描述我自己如何排定優先順序,所以使用最簡單的Value 除以Effort,兩個數字都是整數1到5。只要記得整數除法的夥伴們,都可以快速得知我的思考方式。因為PM的責任是清楚溝通自己的思考,而100%準確估計未來,更何況未來並不可知。

不過許多PM會使用稍微複雜一點的公式來統一自己的思考方法:RICE

R = Reach = 影響用戶或顧客數

I= Impact = 影響程度

C = Confidence = 信心指數(你或整個產品團隊對這次評估的信心)

E = Effort (花費,開發時間)

Product Plan 描述了其中一個使用方法:開新視窗閱讀

無法衡量的事

一種無法衡量的事是品牌價值與形象:例如使用A產品就是地位或品味的象徵。

形象的建立,需要的是團隊的理念透徹在實際的行動中與如出一徹的宣傳:如果公司想要創造有趣又專業的形象,產品設計、行銷、甚至在開發過程中,都要朝「有趣」和「專業」的方針走。

劃時代的產品也無法被衡量,而是需要靠PM的直覺,決定團隊可以挑戰這件事。

這直覺來自於對終端用戶或是重要客戶的熟悉度:知道他們會被什麼功能「嚇瘋」(我的老闆的口頭禪之一)。在這種情況下,PM 需要的是政治力,用故事,用清楚的說明,引起所有團隊願意孤竹一直的決心,哪怕汰換既有技術。

在使用上述框架時,PM記得要提醒自己團隊:我們提出的優先序是基於各種假設,而團隊需要一起合作的,是驗證這些假設,不斷學習,進而優化本身的執行力,進而讓我們可以更有效的驗證更多的創意想法。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

%d 位部落客按了讚: