2021-3-1 資深UI設計者
產品經理經常會面對來自四面八方的需求，例如來自公司高層、業務方、用戶調研反饋等等。如何評判哪些創意點子值得投入開發資源，通常PM會借助MRD來完成這個工作，也就是評估產品機會。其實很像我工作中遇到的「需求來源分析」。
在評估并確定好產品機會后，還要探索產品的解決方案，包括不僅限于產品設計重點、產品流程、交互體驗等，也就是「定義要開發的產品」。
通過我會采用敏捷開發的方式，也就是小步快跑，快速迭代，先尋找MVP方案即明確產品的核心價值，一個版本迭代一個核心價值的內容。這需要PM在基于公司業務的基礎上，了解用戶想要什么，再去對需求進行本質的思考（目的、價值、行動、驗證）。
這里對于產品新人，我總結出來的一個經驗是：時刻保持對需求的思考而非項目管理。也就是不要花過多時間在和開發一起奔東奔西解決問題，而是多花去思考需求本身。我剛做產品經理的那個月，經常會把自己當成「項目經理」。
很典型的就是自己的需求小，但總是推這個推那個，對需求的思考不夠。
因為人總是會沉溺于「能夠解決問題的興奮感」里，例如一起和開發找到了用戶的問題所在，一起和開發把問題解決了，很開心的那種感覺。我記得當時在梳理轉介紹口徑，一起和測試花了整個下午找到口徑不對的問題點并解決，當時覺得「好開心啊解決了一個問題」。
但是當導師問我整個下午做了什么，我回答這個時，她問我「你是不是覺得挺開心和興奮的？但是你學到了什么呢？」似乎并沒有。
因此不要沉浸在這種興奮感里面，初當PM，就應該踏實地、一步一步地去把每個需求思考透：思考場景、用戶的需求怎么來、怎么滿足、哪種方式更合適、如何自洽…盡管和「跟開發一起解決問題」相比真的很難，但是也要讓自己跳出舒適圈，逐步克服，3-5個月之后，就會發現一個不一樣的自己！
在我看來，這些問題不涉及具體的解決方案，只是幫助我更好地明確待解決的問題是什么以及問什么，類似于黃金圈法則的「why/how」。
在接業務方的需求時，難免會聽到他們一上來就和PM討論解決方案，這時PM就需要幫助業務方思考清楚產品要解決什么問題，為什么要解決這個問題，目標是什么。
盡量避免將評估產品機會留到和解決方案一起考慮，因為當解決方案遇到困難時，這樣的做法會讓自己把產品機會也一并放棄，這可能就是典型的「沒有思考好為什么做」的現象。
在上述10條「如何評估的問題」里，私以為最難回答的就是第一個問題——產品要解決什么問題（產品價值）。
解決什么問題，背后就是在問：這個需求，解決了什么用戶在什么時候的什么場景下，遇到的什么問題，并且能夠獲得什么結果，也就是自己一直反復練習的「用戶場景」。這個問題，不光是PM需要思考清楚，產品運營也同樣很重要。
上個月接到運營側一個需求，是希望讓產品側支持一個活動玩法，讓剛購買體驗課的用戶分享邀請海報，然后給予金幣獎勵，以下對話（非原話，大概意思）：
因此可見，我們去梳理剛購買體驗課的用戶的場景，根據自己體驗來說，會是「我剛購買了體驗課，怎么上課啊？有沒有老師來服務我？幾點上課啊？上課前要準備好什么嗎？上完課作業遇到問題該找誰？」這類的場景問題。
對于這批用戶，最早讓他們做轉介紹的時機，可能是出現在「上完體驗課」那一刻。比起和他人談論解決方案，一開始就需要明確目的和場景。
Marty Cagan 對產品原則的定義是：是對團隊信仰和價值艦的總結，用來指導產品團隊做出正確的決策和取舍。它體現了產品團隊的目標和愿景，是產品戰略的重要組成部分。
在團隊內，產品原則是整個產品團隊的戰略指南，一般是產品負責人帶頭制定。所以通過觀察和學習，也可以了解公司的企業文化和團隊的價值觀，讓團隊在認知上保持一致。
或許在某些時候，會因為方向不一致導致沖突，產品原則所制定的優先級和目標就可以幫助團隊成員達成一致。
例如，團隊首先應該確定哪個目標對用戶最重要，是易用性、響應速度、功能、成本、安全性，還是用戶隱私？只有先統一對產品目標和目標優先級的認識，大家才能在此共識上進一步討論各種方案的合理性與可行性。
一些產品團隊對自己的產品往往過于自信，只顧埋頭開發，總想等到公開測試的時候再收集反饋意見，但總是亡羊補牢為時已晚。這樣的做法可能會導致產品在上線時與達成目標相差較遠。
作者提出的三方面測試，第一點是可行性測試。這點完全可以在產品方案ing（產品邏輯輸出過程中）時去和開發討論。
對于小需求，直接詢問即可；對于大需求，開發需要提前進行技術預研，討論哪種技術方案對需求的實現更合適，兼容性和后續需求的拓展性更包容，有何技術障礙，是否需要跨部門的開發聯動等等。
對于產品新人，切忌因「不好意思、這樣問會不會很蠢等胡思亂想」而不去詢問。因為等到需求文檔寫完、需求評審過程中發現技術障礙的代價遠比起初大得多。
或者是在產品設計過程中，可以自己去百度一下某些問題的技術方案，拿捏不準再去問開發，這樣做一來會讓開發覺得你比較有「誠意」（因為你是已經帶著自己的思考和解決方案去和開發溝通了）；二來自己也能掌握基本的技術知識，能比較理解開發在說什么。
第二點是可用性測試。對于作者提到的「真實的用戶、目標的用戶」，或許不是在每家公司都能頻繁地直接地接觸用戶，但是也可以這么解決：如果我的需求是forB端，那拿著原型去問班主任、業務主管（目標用戶）的意見，了解他們的使用習慣即可。
但如果我的需求是forC端（可能是學員、家長），一種方案是在電話調研時順便詢問；一種方案還是去問班主任，因為他們是離家長最近的人；還有一種方案是加一位家長作為微信好友，長期保持電話聯系，向朋友一樣詢問意見。
雖然作為產品需要向張小龍學習，10s內變成產品白癡地去體驗一款產品，但產品經理終究不能代替真實用戶的反饋意見，如果實在無法接觸用戶，或許身邊的開發、測試都是值得一試的「真實用戶」呢~
導師在我剛成為產品的時候，反復和我強調「向上管理」。
或許上司對產品新人來說，像是一種權威、嚴肅、面無表情的「怪獸」哈哈，比較幸運是能遇到像朋友一樣的導師，但是我們更應該去思考，如何做好「向上管理，積極反饋」。
我的做法是：
在這本書的最后，Marty Cagan給出了一份產品經理的反省清單。從產品價值、產品設計、到產品管理、團隊管理，都是我們每個人都需要去思考的問題。所以其實雖然人人都是產品經理，但做出好產品真的是難于登天呀！
最后我認為作者在「尋找出色的產品經理」中說的很對的一點，也是給自己今后從初級到高級產品的掌握能力，如下所述：最寶貴的經驗不是行業知識或技術(這些都可能過時)，而是打造優秀產品的流程、領導產品團隊的能力、應對產品擴張的經驗、個人對自己的認知，以及自我激勵的能力。
文章來源：人人都是產品經理 作者：莫琳
藍藍設計( paul-jarrel.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務