在開發產品功能的時候，Product人最常問自己也被別人問的就是：這個重要嗎？有很緊急嗎？大家都知道事情可以用重要度與緊急度來劃分到底要不要優化某功能，但是PM怎麼更清楚的溝通開發效益呢？我想不廢話地談談過去這九年產品經理的職涯裡，我大概怎麼去排優先順序以及坊間上提到的常用規則，供所有開發者與產品團隊的一員參考。
產品目標
首先，PM要先確定公司上下對於產品的(1)目標跟 (2) 關注指標是什麼。
這可以是你自己仔細思忖得來的，也可以是與管理階層討論後設定的。幾乎每家公司的企業目標都是獲利或增加收益，所以我們這裡在談的是並不是這個最高層級的目的，而是產品的目標可以設定為什麼，我們又可以訂定什麼指標，來賺取期待的收益？
我現在的公司是一間一年多的新公司，在財務金融app的世界裡有一點點能見度。在獲得正收益的之前，我們更在意的是用戶使用某功能的成長，因為我們可以藉此得到用戶數據、匿名化機敏資料、提供業界跟我們有重疊用戶的各種企業分析，讓他們更了解他們的用戶的消費行為。
所以我們把2022年的年度目標訂為三個：
- 增長A功能使用者（每日新增/減少使用者數量）
- 增加A功能使用比例（使用A功能/總用戶比例）
- 增長黏著度（DAU/MAU)
評估
這樣下來，PM所討論所決定的功能，都可以初步使用以上目標篩選。每一次我在思考新功能時，會想以下兩件事：
- 這個功能是否會讓我們往訂定目標邁進(提升我們的指標性數字）？
- 我們要開發的功能，是否夠獨特且不易被模仿？
- 大致上我們現有技術是否可以開發這個服務或這項功能（從沒做過區塊鏈的公司突然做相關功能，就不會是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記得要提醒自己團隊：我們提出的優先序是基於各種假設，而團隊需要一起合作的，是驗證這些假設，不斷學習，進而優化本身的執行力，進而讓我們可以更有效的驗證更多的創意想法。
Product Design 
發表迴響