這是 30 天寫作挑戰的第 27 天。今天要來回答臉書留言的提問：
以 RD 角度，怎麼看待一位 PM 應該具備的特質
30 天寫作挑戰：連續 30 天，每天都會從 ChatGPT 、生活中的靈感或是網友提問中，選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你／妳的問題，可以問我一個跟工程師、技術產品經理、產品經理有關的問題。
秉持著一樣米養百樣人的原則，每個職位都不應該只有某一種特質，但的確會有些特質特別容易在特定職位中被凸顯出來。今天我們就稍微刻板印象和主觀一點，講講我身為工程師，看到 PM 具備哪些特質時，會對跟 PM 的合作上有加分。
需求論述清楚
論述清楚是指：不管是文字還是表達上，能夠將「為什麼要做這件事」解釋完整，包含為什麼要做、做什麼、有沒有其他戰略目的……可以回去看看《思考產品功能時，能提升思考品質的 Checklist》系列文章，當 PM 能夠解釋清楚這些問題給工程師的時候，就已經是很專業的 PM 了。
至於需求要「怎麼做」，那可以是 SA、技術主管、工程師等技術職位的人討論的範圍，PM 沒辦法回答並不會有扣分。如果有工程師覺得 PM 回答不出怎麼做就覺得這個 PM 不行，那是工程師太嬌生慣養了。
有自己的原則
立場，可以是一個工作者的工作觀。需求變更、隕石砸下來是在所難免的事，但在變更的需求面前，PM 是否有自己的立場和規劃，知道怎麼判別哪些需求是真的有承接的必要、哪些是需求單位的任性妄為、而哪些又是對產品或團隊有害的。當面對四面八方的需求，當面對到與自己價值觀或原則相牴觸的事情時，能不能夠保有自己的原則，又是考驗每個人的智慧了。
有時也需要辨別，自己堅持的原則是不是必要的。為了一個英文單字要不要加上 s，而延遲了報紙送印的時間，只因為公司的報紙代表著這個國家的標準英文；為了讓整體的設計風格一致、程式碼簡潔，讓客戶多等一個月……坦白說我也沒有比較好的判斷方式可以辨別哪些原則是必須要堅持的，畢竟這也是每個人的特色嘛。
資訊整理和紀錄
各位有沒有遇過一個情境：曾經跟同事有過一段對話，是在解釋某個功能為什麼做某邏輯、不做某邏輯，但相關的資訊不是散落在對話工具中，就是根本沒有紀錄。
不管是 PRD（Product Requirement Document，產品需求規劃書）的撰寫、在會議中整理各方提出的意見和需求、甚至是在 Slack/Teams/Discord 裡將大家的資訊利用語言、文字、超連結的方式，讓接收訊息的人不管是在現在還是在三個月後，都能夠迅速地掌握到資訊的脈絡，我覺得這是非常不容易也值得敬佩的事。
我相信人是健忘的，人腦也不是拿來記事情，而是拿來下判斷的。過了一段時間後會忘記曾經有過的討論、忘記曾經做過的決定，都是很正常的事情。但若能夠在決定發生的當下就記錄下來，幫未來的自己跟同事一把，除了節省掉回想枝微末節的時間，也可以讓過去的決策保持著足夠的連貫性。
今日寫作觀察
今天有點標題殺人兼說教意味️🙇♂️，儘管這篇文章分享了三個 PM 的特質，但我遇過沒有這些特質也很優秀的 PM，因此看完文章的讀者們，千萬不要覺得一定要有這三個特質才是好 PM，應該是要找到 PM 需要的技能中，有哪些技能是跟自己的個性比較契合、容易發揮的，加以磨練之後就可以變成自己作為 PM 的招牌特質。
