產品心得：你拿什麼換這個 Feature
「你拿什麼換什麼？」我在公司會議上常常會聽到別人被如此提醒，但直到這句話是對著自己時，才知道它在問些什麼。
這可能是個常見的經營產品的情境：
為了萬聖節的活動想改版官方首頁、宣傳活動的好處，原本預期首頁只要企劃一人天、工程師一人天就能做上去。
結果企劃寫了首頁內文，才想起需要請翻譯翻成多國語言；首頁又剛好沒有適合的庫存圖片，需要設計師花一人天設計；設計師認為這張圖應該要有實物拍攝才能達到最佳的宣傳效果，所以需要發包請攝影師來製作。
「這邊要不要做到多國翻譯，讓更多人看到？」當然好。
「這邊沒有好用的圖，要不要請設計師撥點時間來做？」真是幫大忙了。
「設計師說實物拍攝效果更好，要不要外包一下？」聽起來也很棒。
同事們都想為了「達到最好的促購效果」而努力，在自己的崗位做到最好，但產品經理應該要在這一連串的改動中嗅到問題——如果過去沒有建立專案的邊界，無限同意投入的成本堆疊起來，漸漸會大於效益。
更糟糕的是資源有限，當一群人在一個小點上投注心力，就會有另一邊疏於照顧，這可能是另一個 feature、另一個還沒解的 issue、或未見的商業機會。這就是過去可能在不求回報的學生專案、side-project 未曾強調的：trade-off。
これから
老實說，意識到自己工作缺乏成本效益觀時還是滿挫折的，主要是對自己浪費了公司資源而愧疚，希望下次表現會更好。因此，我得用「從今以後」去思考下次該怎麼管理 feature：
提案前：評估效益，以回推合理的成本規模
在評估產品解法時，都應該要先計算出預期的效益規模。預期 USD400/mth 跟 USD40000/mth 的票，絕對值得不一樣規模的開發方法。
- 這解法預期的效益是什麼？能否量化？
可以有很多評估維度。revenue-cost 是其中一個客觀明顯的計算角度，但也可能包含提升品牌價值、想減少使用者負面感受等等，端看個案情形。如果是在提案中預期增長的數值，要特別注意用成長幅度而非絕對值計算才更合理。
- 這解法預期會用多久？
如果官網為了萬聖節改圖，那最多就是持續整個 10 月的事；但是相比下來，官網配合品牌重塑所做的改動是更長遠、會持續 2 年以上的，那它才應該被投注更多心力。
- 有產品過去、或市面的 benchmark 可以幫助增加計算的信心嗎？
可以回頭搭配公司內部測試的成功案例，當作提案的樂觀結果；也可找市面 benchmark，但通常很難找到、或難以直接挪用，例如案例公司的 user 規模是我方的 1000 倍大，那麼開發某 feature 帶來的商業效益想必可觀，那這時應該乘以某個常數，使案例套用在公司上有合理的數字表現。
提案中：提供充足的資訊，讓眾人思考是否分配資源
在會議上，眾人要以公司角度思考如何分配資源來做這件事，因此企劃需要足夠完整，至少包含上述假設與預期效益、提案內容：流程圖、mockup，幫助大眾想像出還有哪些企劃未盤點到的成本、如何實作。
在這個階段，已經不是「我有個點子，想請大家看看要不要做」而是應該問：
我預計要做這件事，它的預期效益跟成本如下。那我們值得停止其他人正在做的事，改來做這件事嗎？
實作中：建立專案界線，阻止無止盡地投入
回到最開始的官網案例，其實 PM 也不一定一開始就能洞燭先機，提前想到要花錢送翻譯、聘請外部攝影師拍景；但若已經踩穩這個專案合理的成本投入，自然就會在每個熱心同事提出更佳的方案時，清楚地說出 Agree 或 Disagree。
老闆在 1 on 1 提了個比喻，說專案的一開始應該先想像個大架構，隨著時間從模糊看到細節；但不應該是順著架構逐漸旁外生枝，變成更大的一張地圖。我覺得就像薩爾達地圖把一個地區走深，而不是一直去開地圖吧（咦）
「大家喜歡幫助別人，讓工作變得忙碌，讓自己看起來很有生產力。」
在這次的經驗裡學到，調動人力是產品經理工作的一環，阻止同事們無謂的投入也是職責所在。
