以往寫了很多跟產品經理職能與溝通相關的文章，前陣子有朋友來問我之前做產品改版的經驗，想了解如何從零開始完成（浩大的）產品改版專案。一聊之後才發現，目前好像沒有寫過相關的文章，就趁著這次與朋友討論的過程，好好地把這些細節記錄下來。
這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
PM 該從哪些管道收集意見？
從上面的圖看來，步驟雖多，且其實是一個無限循環，但姑且就先把第一部當作「收集反饋」，畢竟總是得先知道使用者的想法，才知道產品到底好在哪、不好在哪。
使用者怎麼跟產品互動（如何使用產品）？使用後有哪些問題？在哪裡卡關？喜歡哪些功能？這些功能幫他們完成什麼事？了解他們如何使用、收集到他們的意見後，才知道如何對症下藥、發想解法。
不管是做內部產品、to C 或 to B 的產品，都一定有「用戶」，只是用戶的身份與使用情境不同而已。一般來說，PM 不太會直接接觸到用戶，中間都會有一層業務、客服、Account Manager 等橋樑，這些「橋樑」會轉達用戶需求，再交由產品團隊去做後續處理。
但有時，正是因為這些「二手資訊」可能會被轉譯錯誤或省略，為了聽到用戶的第一手意見，有些產品團隊也會做一些用戶的一對一訪談、焦點團體訪談或問卷調查，甚至有的團隊是做跨國產品，還會到當地直接找人做訪問。雖然成本高，但也能更細緻地了解用戶需求。
💡 順帶一提，一個產品不只有外部用戶，也可能有內部用戶。比如 Facebook 有廣告平台，外部用戶就是各種中小型企業主，但一定也有負責服務這些企業主的 Account Manager，他們在操作平台時，可能也會有些需求。
又或者像各大新聞網站，對外是服務各種讀者，但對內也需要提供一個讓記者上傳文章、編輯下標或處理稿件的地方，那他們一定也會有對應的需求。
PM 自己也可以提意見嗎？
一般來說，PM 越了解產品後，應該也會有更多想法和目標。又或者，有些極端案例是 PM 閒閒沒事做，每天只能彙整 bug 請工程修，或者處理很多跟專案相關、跟產品無關的瑣事。碰到這情況，PM 可能就會覺得有點無聊，進而會思考：「我可以為產品做什麼？」
但也可能 PM 真的對於產品真的沒什麼想法，或者剛接手而不太熟悉。不管是什麼原因而導致沒想法，建議可以先好好認識產品，在認識的過程中，慢慢會熟悉與此產品相關的人、產品的操作邏輯、設計過程、主要指標等，詳細的內容之前寫過，可以參考：
產品團隊的意見也很重要！
除了用戶和 PM 本身，產品團隊（泛指做這個產品的所有人，包含但不限於設計師、前後端、測試等）本身也可能有一些想法，畢竟大家職能不同，關注的點也不一樣。比如 QA 可能會抓到一些小 bug，雖不影響體驗，但終究是個 bug；UI 可能看到畫面上的微微跑版、工程師可能留了一些技術上需要更完善的地方。
畢竟產品部門有時是個很尷尬的存在，大家都有想做的事情，但產品團隊人力有限，大家就得「排隊」等待需求實現，有時就難免會給人一種「產品團隊好大牌」的感覺。
但如果平常多交流，一來至少讓其他部門知道產品團隊的工作性質與內容，互相更了解後，通常也會有更多體諒；二來也能在交流過程中，更理解各部門的業務目標和平時的工作流程和挑戰，有時候，甚至能從中發現一些原本對方沒提到、但其實產品可以協助改善或增進效率的地方！
💡 所以，所謂的收集「意見」，不只是用戶的意見，內部團隊如果有想法，作為 PM 也可以多主動了解細節；不一定是真正要做什麼功能或改版時，才去找其他部門討論。
結語
最後，想特別提醒的是，PM 不要因為業務端表達不夠清楚，就轉而引導他們回答。比如「你剛說覺得結帳流程卡卡的，那我如果增加一些提示文字會比較好嗎？」就不是一個太好的說法。PM 的角色應該是協助業務端「聚焦問題」、「將問題具體化」，而不是直接幫問題找解法。
所以若要修正，可以進一步詢問業務端：「你剛說覺得結帳流程卡卡的，是哪裡卡呢？你可以實際操作一次或螢幕錄影給我看嗎？」比起直接給解法，可以先請對方操作一次現有流程，PM 能藉此了解對方真正的使用情境與方式，搞不好會從中發現更多新東西。
更多細節可以參考〈身為 PM，該怎麼評估一項新需求？身為需求端，又該怎麼跟 PM 提需求？〉，下一篇文章也會再仔細說明「該如何（幫助需求端）定義問題」。
