作為產品經理，在公司沒有話語權，CTO掌控技術和產品的方向和計劃，運營已經默默的成為了市場部，需求都是運營提交，CTO決定做與不做，作為產品已闡明不做的理由，因為運營提出的需求只是針對一場活動有用處，也許下場活動一點用處都沒有，但是CTO說必須做，無數次的反對和反駁均無效，我該用什麼辦法可以扭轉這個局面，如此下去產品只有死亡，我也只是一個工具，急求，我該怎麼辦？

那就做唄

需求分兩種，大版本整體迭代需求，和零碎優化需求，只要有長遠的產品迭代戰略規劃，那麼這些零碎需求的能不能插入處理起來就很簡單了

當然很多需求會來自老闆、運營、技術等看似無理的需求，原則上只要不影響大的版本迭代，該妥協時就要妥協，如果一個公司沒有產品戰略規劃，那離死不遠了，可以考慮跳槽了~

謝邀

不在其位，不謀其政，既然所在機構有CTO且話語權比重大，那麼作為產品經理，協調好各部門認真推廣運營即可；個人理解，產品經理更多時候要較為客觀，不要帶入過度個人主觀理念，職位只是虛名，給機構帶來利潤才是能力體現，反之提出的方案可以降低風險同理。數據、包容、協調、客觀才是一個產品經理應該具備的基礎素質。

你的問題有兩個：

  1. 這種一次性的需求我們要不要做

說到一場活動，能比支付寶每年過年搶紅包更大的活動估計也不多了。支付寶搶紅包的活動從某種意義上也算是一次性的需求，每年搶紅包規則都在變。但是，因為這樣的一次一次性需求，讓支付斬獲了大量的活躍用戶。

所以是不是一次性需求，不能成為我們做不做需求的充分條件，而是看這個需求有沒有價值。

　2. 擔心產品會被這種需求搞亂

首先考慮這種需求能不能復用，把可復用部分和不可復用部分分離，做成一個可配置的活動管理系統，讓一次性需求變成多次需求。

如果確實是不可復用的需求，考慮通過版本管理的方式來處理。在活動版本開發前設置一個基線版本，在基線版本上開發一個活動版本。在活動結束後關閉入口，並在下一個版本迭代時回滾到基線版本上進行開發。乾乾淨淨地把這種需求回滾掉。

不過活動這種東西，在一個版本生命周期裡面是經常出現的了。不如想想產品怎麼給活動預留可開啟和關閉的活動入口。怎麼設計活動系統和產品的介面，然後活動系統更獨立的運行。

你都說了必須做啦，做唄。

但是問問自己以下幾個問題：

首先你再好好想想是不能做還是暫時沒法提供通用解決方案？

活動這種事，能不能做一種通用解決方案？每次針對具體活動具體出方案不累么？

你想不出方案？那你好好想想，相信會有方案的

除了方案告訴我做不到？OK這鍋就不是你的了，技術不夠怪誰？

既然CTO都管戰略了，與運營連縱交橫不好么？

暫且拋開你說的一次性需求要不要做的問題，就我在純電商公司工作了兩年，一年到頭都是圍繞著大促，活動做，沒有一次性需求那不用玩了。個人以為你說的核心問題放在公司任何崗位其實都在思考，我這個崗位究竟有沒有地位，有沒有價值。我幹了十年測試，想必比你們產品更沒地位，有多少公司的測試說，版本不合格，不能按時發布，然後就真的不發了？我猜你們產品對測試的要求是，我只要你告訴我這個產品質量可以了，按時上線，而不是告訴我這個東西質量不好不能上線。那麼地位這東西，我覺得吧，真的你的話說了沒人聽，那你就先讓他們干著，你收集數據，如果結果是好的，對你來說是一種學習，我覺得沒意義的事他們做成了。那如果結果不好，以後你拿出數據來說，我認為怎麼怎麼，之前的經驗告訴我們應該怎麼怎麼

那就做唄，為了工作，為了生活，再有節操有什麼用

最簡單有效的辦法-數據分析，用數據說服他們

最近剛好有在思考類似的問題。

這個問題從本質上來看，是產品框架的靈活性不足所引起的需求方與開發者的矛盾，造成了產品經理存在感稀薄、被動接需求的局面。

定義了問題之後，接下來拆解問題：

1、如何提升產品框架的靈活性？

2、如何保證產品經理在團隊中的話語權？

這兩個問題都不是三言兩語能夠說清楚的，也並不是能夠在短期內解決的，而是需要有一個比較長的周期。老實說目前的我也沒有能力提供特別可靠的答案，不過我還是在這裡列出我的思考框架，以求拋磚引玉。

我們進一步拆解問題1，從時間邏輯來看，產品框架可以從立項評審、0到1、1到N三個階段去優化，每個階段都有不同的側重點。具體來說，面對一個需求時：

1、不管處在什麼樣的時間節點，產品經理都應該對未來至少半年的產品規劃有一個大體的認識。舉例來說，運營過程中可能會產生哪些問題？這些問題會導致怎樣的需求？目前的產品框架是否能handle？如果不能應該如何解決？由產品發起的一個有效率的評審會能解決後面很多問題，多問自己和團隊類似的問題，並不斷優化產品框架。

2、Master運營的工作。一種行之有效的做法是自己實際參與到運營的工作中，從小事做起慢慢地積累同事的信任，直到最後能夠為運營的小夥伴提供多樣化的解決方案，也能夠對運營提出的需求有更深刻的認識。這樣在面對下一個需求時，能夠有理有據地判斷做還是不做，做的話如何與現有產品框架融合？不做的話是否有替代的非技術方案？

3、盡量去理解技術方案。作為產品經理應對當前技術方案的邊界有一個清楚的認識。這樣在和技術人員討論時，能夠不僅僅從需求方的角度闡述問題，就能大大增強說服力。

以上。衷心祝你能越做越好，就算最後無法扭轉局面，也能有底氣說這鍋LaoZi不背~儘力就好

只是一個打工者而已。

運營表示有需求，也就是能帶流量或者賺錢。技術還願意做，不能更好了。出個方案上線多棒吖。哪裡無理了？

你要做的是使得整個方案能復用吧。你的意思是有你認為更高優先順序的需求要處理嗎？看不懂吖。
產品經理在公司里的確是沒多大發言權的，產品經理有自己的思維，在力所能及的情況下提出意見，爭取自己的想法能實現。不過產品並不是自己的，是公司的，還是需要服從老闆的意思，乖乖去執行吧。等你熬到產品總監的時候，有了話語權會好很多

給產品經理有一句話：用心聽，但不要照著做

同情題主，產品經理的活兒都被技術和運營做了，那你的價值可能慢慢不復存在了。

產品經理是對整個產品負責人的人，你都認為了你只是一個工具，那麼你的自我定位都已經錯了！

做與不做，如何做，都是需要你來反覆思考權衡利弊，這關係到方方面面的東西，比如市場需求，性價比，公司願景與發展等等。

無理需求，通常是指「不認同、認為無效的需求」。

從問題描述中，似乎可以感覺到運營在主導著產品的走向，而CTO在決定是否做不做時，估計受到了運營團隊的壓力。而這種情況下，通常是運營壓力較大的產品。

因此如果我是產品經理，會先停止這樣的對抗，而是從運營的各種活動、各種需求中去思考，運營的核心訴求是什麼？他們的運營方案是不是有效的？我可以提出什麼樣的方法來更好地滿足核心訴求。

推薦閱讀：
相关文章