產品需求的可行性分析報告，是產品經理崗位職責範疇內的工作。作為交流探討，說說自己的看法吧。

一、產品需求是老闆提出來的，說明這個產品經理的工作是沒有做到位。產品需求提出應該由產品經理調研市場、關注同行以及品牌市場定位主動提出並向老闆彙報，由老闆拍板決定做還是不做的這麼一個過程，所以老闆反而向產品經理丟擲產品需求是不正常的工作，暗示老闆對這個產品經理有不滿的情緒了。

二、可行性方案的分析。產品作為載體滿足消費者需求、為企業獲取規模利潤，那產品經理該怎麼去分析呢？

1、充分的市場調研，比如說產品適銷的市場在哪裡、規模有多大、消費人群及品牌價格定位等等；

2、增加產品功能的分析，增加的功能是所有競品都有還是自己產品獨特的呢；

3、在原有產品的基礎上迭代升級，減少模具變更投入，例如BMW1 Series到BMW7 Series的迭代升級；

4、制定詳細的上市培訓、推廣計劃；

5、預估增加功能後產品的預計銷售規模，在哪些地方試銷、哪些地方主銷、哪些地方壓根就不銷；達成這個規模後能為公司帶來多少利潤；這個產品銷售後對品牌的影響力是否有提升。

總之，有功能性的產品是現在大眾消費者的需求，也是企業、社會進步發展的需求，做產品經理一定要貼近市場需求去建議產品升級，不要閉門造車或者是等老闆向你提出增加產品功能需求。

產品經理收到需求反饋後，首先要對需求進行分析，評估需求是否合理。如何進行需求分析？可以透過下面三個問題來進行

需求三問

第一問，需求從哪裡來，到哪裡去

需求是誰提的，要實現什麼效果，真正需求是什麼？

接到需求後，首先要搞清楚需求的來龍去脈，問清楚具體要做什麼，找到使用者的真正需求

第二問，需求有沒有問題，有沒有更好的解決方案

使用者反饋的需求，是使用者遇到問題時，自己想到的解決方案。但使用者的想法可能不是最優的，甚至是錯的。

產品經理需思考使用者需求是否合理，有沒有其他更好的解決方案。

試想如果在馬車時代，我們找使用者調研需求，使用者會反饋需要跑的更快的馬，跑的更持久的馬，更舒適的馬鞍，是調研不出來汽車的需求的。

第三問，需求上線後，有哪些影響，可能引起哪些問題

最後一問，需要我們想清楚需求上線後有哪些影響，可能引起哪些問題。

對於這些問題和影響，需要提前想好應對策略，做好預案，必要時作為需求點，放到原需求裡面一塊實現，整體上線。管理好各方預期，避免屆時被動。

案例

案例一

使用者找到產品經理，說我想要一把錘子和一顆釘子。

需求第一問，為什麼要錘子和釘子，是為了做什麼？

使用者說自己買了一副畫，我想把它掛到牆上

透過分析，可以發現使用者的真正需求是“把畫掛到牆上”。

需求第二問，有沒有更好的解決方案

使用者希望用錘子和釘子把畫釘上去，這個方式真的是最好的嗎？我給使用者一些膠帶，貼上上去是不是更好？我給使用者一些圖釘，是不是更容易把畫掛上去？

需求第三問，當前的方案實施後可能會有哪些問題，需不需要提前準備

如果最終採取了膠帶貼上的方案，膠帶貼上可能不夠牢固，需要提醒使用者把畫的四角都貼上一下。

至此，使用者需求方解。

案例二

這是筆者實際工作當中遇到的一個真實案例。

運營H同事：我們想讓研發做幾個活動模板，以後做活動時，配置下模板，就能上線活動

思考：需求第一問，為什麼要做模板，希望解決什麼問題，達到什麼效果

產品經理：為什麼要做模板，是為了解決什麼問題

運營H同事：我們經常做活動，比如品牌日、熱點專題、促銷、秒殺等，幾乎每天都要做新的活動。每次做活動，都需要技術排期開發，週期比較長，而且研發資源就那幾個人，經常有些活動想做但排不上期。

思考：運營同事提出做模板，是為了解決日常活動與研發週期長的矛盾，這是使用者的真正需求。

需求第二問，做模板能解決使用者的問題嗎？

產品經理：你現在想做哪些模板

運營H同事開啟電腦，把想做的模板展示了出來，有熱點專題模板、秒殺模板、全球好點模板、鎮店之寶模板等

產品經理：你們最近半年都做了哪些活動，活動頁面還有嗎？能發我看看嗎？

運營H同事找了下歷史活動資料，把歷史上的活動頁面發了出來

思考：透過對比使用者要做的模板，和歷史上的活動頁面，我發現一個問題，多數情況下，同一個型別的活動頁面，每次都不是完全相同的，每次都有一些小差異，樣式上都有一些小調整，有時候還會出現完全不同的新頁面。如果做了模板，以後運營人員可能會經常要求修改模板樣式，或者做一套新的模板出來，技術可能會陷入無盡的模板修改中，這個方案不能徹底解決“運營做活動與研發排期”的矛盾。

本次需求溝通結束，產品經理已經拿到了使用者需求，先散會，產品經理後面再想想解決方案。

會後我想到了自己以前在京東做開放平臺時，遇到的店鋪裝修專案。京東把店鋪頁面開放出來，商戶可以自己定義店鋪頁面。透過調研，我發現這個方式可行，於是決定採取這個方案。

後續又和運營、技術溝通了下這個方案，最終發現這個方案比較複雜，研發週期比較長，但是業務方很著急，馬上要搞大促了，於是決定採取一個簡化的方案。把頁面元素抽象成各個元件，元件分為資料、樣式兩部分，讓運營人員像搭積木一樣，自行搭建活動頁面。和運營、技術溝通後，發現這個方案既操作簡單，研發週期也比較短，最終決定採取這個方案。

需求第三問，當前的方案實施後可能會有哪些問題，需不需要提前準備

於是，提前和業務運營同事反饋清楚，為了在你們期望的時間內上線，排序操作只能先這樣，可能用起來會麻煩些，一期上線後，立即啟動最佳化（後面也確實印證了這個問題，一期上線後，運營妹紙多次跑到我面前說“哪天我們眼睛瞎了就賴你”，逐個點選上下移動，確實太費眼力了）。

至此，使用者需求有了比較完善的解決方案。

系統上線後，運營人員平均每個工作日建立30多個活動頁面。該系統不僅有效的釋放了研發資源，還解決了日常運營做活動的瓶頸。獲得了運營人員的高度稱讚，多次受到COO的嘉獎。