產品方法論：如何衡量一個功能點是否值得開發？

功能開發成本評估的最終決策權，屬于團隊核心成員組成的需求評審團。

如果身處成熟的產品體系內，自身已經存在疑慮，優先擱置。

初創公司

對于沒有戰略框架的初創公司，遇到這種問題，多半是產品還沒有建立明顯調性，目標用戶不明確的情況下，同時該功能就是核心功能。此時，如果沒有更好的選擇，最好用MVP做最快的驗證較為合理。

成型公司

而對于具備成熟體系的產品，首先羅列收集整合好的需求，看當前戰略節點的重心在哪里，圍繞重心做優先級排序。再對需求進行細化整理（一些團隊會使用用戶故事地圖這種協作方式來完成），然后再進入具體的需求評審環節，最后是團隊核心一起決策執行哪些需求。

只有在產品有充分理由，但團隊其他成員不給予支持的時候，才會有值不值得這種說法。

但通常情況下，這種事情上，一般都是產品對需求拿捏出現了問題，或是完全跳出了戰略框架，風險成本過大。

第一種情況下，可以認為無法斷定，你也沒有強烈的勸說動機，一般都是建議擱置需求，回爐需求池。

第二種情況，很多創新功能也都由此誕生。你認為從戰略上，對公司有很大幫助，值得冒險一試，可以找機會游說掌握最終決定權的老大，建議使用灰度測試的方式進行嘗試（常用套路），如果老大不同意，其實就沒有討論的再必要了。

一個功能點是否值得開發？換一個詞估計大家更容易了解，

那就是如何判斷這個需求是否有價值？以及優先度。

需求評估，需求評審，就算列入需求池，優先度也要排隊、

打個比方，我跟人人的產品經理吐槽說，APP的秒聘網，連招聘公司的地圖都沒有，就一個文字的地址，難道我還特意復制文字，然后打開地圖APP，再看下位置么？這不是增加用戶的成本么？

又打個比方，41群的伙伴也在聊這個天天問，為什么不能在右下方發表回復上面新增“ctel+回車快捷回復的提示”

-----------------------

套用在你的這個問題，其實也很簡單的事情，這是一個個案，還是很多人反映過的問題？發生的頻率高不高？客戶的意見是否合理？

如果不合理，否決

合理，則看頻率和優先度進行衡量迭代的內容，