你做產品入門時都遇到了那些坑？

說到這些坑那就是一句話：滿紙荒唐言，一把辛酸淚。

作為一個從事產品行業4年的菜雞，我短短的就業經歷就跟沒帶真眼和掃描的脆皮進入了蘑菇陣一樣，一腳一個坑，太多了我都有些不知道從何開始說起。

1. 需求確認只跟提出者確認，沒有跟老板確認

每個公司的“司情”不同，想當初業務給我提了需求在綜合評估后可做，把對應解決方案告訴業務同意后我就屁顛屁顛的告訴開發開始排期開發了，然后上線了，老板看到了這個功能覺得此事不妥，未得到老板授權就動功能，然后業務直接倒戈，我被叫進了辦公室，在進行一番教育后，我知道了下一次更新功能得向老板知會一聲，哪怕是他也給不了任何建議，但是權利這種東西就是很奇妙。

2. 需求來源被中間商“賺差價”

可能我一直在小公司，小公司的崗位是很模糊不明確的，產品=測試+客服+售后+項目經理。一般都是客戶OR業務直接告訴我需求，有一次客戶通過銷售，然后銷售告訴我了一個需求，一般情況下我都會用公司的微信去加上客戶直接面談一下問題，但是那一次我可能是懵逼了，得知了需求評估后就放到了下一個迭代版本中，上線反饋給客戶后客戶很懵逼自己并沒有提出這個需求，深入了解后得知，人就是想改一個列表的展示名稱，但是在銷售的轉述下我們新增了一個字段。雖然很小且不影響業務，但是這種行為很容易讓你在非常忙排期的時候走彎路。

3. 需求排期，功能堆積，誰誰都急。

就有那么一段時間好像都商量好了突然就出現了很多的需求，溝通后都是說自己的很急，都說這個影響公司業務，開了需求評審會各個部門也堅持自己的需求是非常緊急的，這個鍋最終還是放在了我面前，那先做誰的呢？于是我召集了開發，評估了一下各個需求的時間，人數有限不能并行，怎么都得有個主次，拿著開發計劃表就找老板去了，因為各個部門長都說自己最忙，我就只能找到更高級別的老板去商量了，然后帶著老板的答復我發了個郵件告訴給各個部門排期情況。這個只試用公司人少的小公司，大公司層層領導，估計就行不通了吧。

4. 規劃的需求引來了各方的質疑

這太正常了，因為有時候有些人提出的需求本來就是一些偽需求，但是提出的人太厲害不敢反駁也只能硬著頭皮上，做產品心理上一定要強大，需求首先自己的搞明白，反復推敲沒毛病，不管別人怎么說只要你確定你這個需求滿足提出人的問題，那你就堅持堅守，每天默念100遍我的需求沒問題。但是也需要聽取別人的意見，如果真的是邏輯有漏洞虛心接受，其他的小地方堅決不動搖！

5. 開發說需求做不了，太難了。

被開發拒絕需求是每個產品每天都會經歷的事情，好在我當年還是搞過開發，日常也喜歡看看前端框架，最近在了解Redis，做產品不指望我們能開發就是遵守一些基本的開發常識，純軟件開發就別整一些嵌入式需求，還好我有男朋友開發，日常我拿不定的功能都會去問問他，如果能明確功能名稱可以去百度搜索，或者去CSDN去里面搜索一下看有沒有同樣解決的方案的。如果有就直接把鏈接丟給開發，就是告訴他有相同案例可以去研究一下。

我一時間也就只想到這幾點，帶薪拉屎回答一下，希望對你有幫助。