做產(chǎn)品掉過很多坑，但重要的是一個坑不能掉兩次印屁。
▏思考問題的全面性
如果要對一個功能進(jìn)行改動循捺，一定要把功能前后的流程想清楚，要留意這些改動會不會影響到別的部門或團(tuán)隊（利益）雄人。比如有個功能叫「意見反饋」从橘，基本每個 App 都會有這個功能，如果把這個功能入口放的層級淺一點础钠，那么用戶反饋量會增加恰力，增大了處理這些反饋的同事的工作量；如果把入口放的層級深一點旗吁，那么用戶反饋量會減少踩萎，降低了處理這些反饋的同事的工作量。與之對應(yīng)的很钓，如果把意見反饋功能的體驗優(yōu)化得很好香府，則降低了用戶反饋問題的門檻，反饋量將增加码倦；如果體驗不做優(yōu)化企孩，用戶提交問題的門檻較高，反饋量減少袁稽。
說的再簡單一點勿璃，一個功能的改進(jìn)也許我們覺得對用戶的體驗會非常好，但是可能會遭到其他部門的反對。所以思考問題一定要全面：用戶輸入的信息最后會輸出到哪里补疑？輸出完后誰去對這些信息進(jìn)行處理闻葵？他們是怎么處理這些信息的？這些都要考慮清楚癣丧。
▏產(chǎn)出物的一致性
版本迭代槽畔，首先產(chǎn)品經(jīng)理產(chǎn)出 PRD，接著交互設(shè)計師產(chǎn)出交互稿胁编，然后視覺設(shè)計師產(chǎn)出視覺稿厢钧、標(biāo)注、切圖嬉橙。PRD里要寫清楚每個功能點早直，包括文案、標(biāo)點符號等細(xì)節(jié)市框，然后要保證交互稿的內(nèi)容是和功能點保持一致的霞扬，視覺稿的內(nèi)容要和交互稿保持一致。我們都知道一個很古老的游戲叫「COPY 不走樣」枫振，要求一個一個人往下傳的時候盡量不要出現(xiàn)「走樣」喻圃，這個游戲規(guī)則比較難，看了一兩遍就不能回頭繼續(xù)讓對方做動作了粪滤，但是產(chǎn)品不是斧拍，產(chǎn)出物就在那邊，沉下心來去比對杖小、去思考肆汹。
產(chǎn)出物的不一致，出現(xiàn)的問題就是在技術(shù)評審?fù)觊_始進(jìn)行開發(fā)時予权，工程師不知道該以哪個為標(biāo)準(zhǔn)昂勉，然后又要返工。當(dāng)然出現(xiàn)的問題不僅僅是這一個方面扫腺，還有很多其他問題岗照，不多展開。產(chǎn)品經(jīng)理要對整個流程負(fù)責(zé)斧账，交互稿的問題谴返，視覺稿的問題，都是產(chǎn)品經(jīng)理的問題咧织，是產(chǎn)品經(jīng)理的工作沒做到位嗓袱。產(chǎn)出物是否一致是衡量一個產(chǎn)品經(jīng)理有沒有入門或者說基本功是否扎實的重要因素之一。
▏需求PK的邏輯性
需求評審會上习绢，經(jīng)常會出現(xiàn)各種PK渠抹，一個人認(rèn)為這樣好蝙昙，另一個人認(rèn)為那樣好，然后互不退讓梧却，爭得面紅耳赤奇颠，這其實是不明智的。評審這個功能到底行不行放航，把你的道理擺出來烈拒，把你的方案拿出來，別人憑嘴撕逼广鳍，我們憑行動荆几。
回答一個功能需求到底如何，只要思考以下三個問題：做什么赊时？為什么做吨铸？怎么做？三個問題分別對應(yīng)著產(chǎn)品方向祖秒，用戶場景诞吱，解決方案。把這三個問題想透徹了竭缝，PK時可以多自信一點了房维。
需求評審會中需要保持獨立思考，不被帶到溝里去歌馍。因為難免會碰到一類人他們喜好使用強(qiáng)盜邏輯去說服別人握巢，這個時候要能快速分辨出來，然后進(jìn)行制止松却。比如二分式思維，認(rèn)為不是A就是B溅话；使用了什么類型的論據(jù)晓锻，是否有來源；有沒有在句子中使用帶有觀點傾向性的形容詞……這些都要千萬注意飞几。
