尤其讓我印象深刻地是，他還特別準備了問題清單，結構層次也很清晰，而我們都知道：問題清單，往往就是指向答案路徑的機會清單。

因此，今天熬夜復盤下溝通內容，發現對我們產品經理最有啟發，也是很多產品新人最容易陷入的兩個認知陷阱：「弱思考」與「憑直覺」。

嚴格來說，「弱思考」與「憑直覺」有著內在的強關聯，很多時候都是有機的統一：「弱思考」往往催生「憑直覺」，「憑直覺」也往往受制于「弱思考」。

其實在職業發展中，我們有很多產品工作做得不夠完美，背后的底層邏輯往往都是懶于思考、弱于思考，因為，在這樣的背景下，即便是有成熟的產品方法論做行動指南，也無濟于事。

而關于憑直覺，鏡同學則認為這是最常見的產品認知錯誤，比如，我們在很多產品需求調研時，往往會“自以為是”的憑直覺為需求設定自我標簽，俗稱閉門造車。

我記得，之前給大家也分享過37 signals關于“正確決策”的38條鐵律，其中就明確提到“正確決策要基于數據，而不是憑直覺”，對了，37 signals還出版了一本暢銷書，就是我反復推薦大家閱讀的那本《Rework》。

不妨試著回憶下，你們之前的公司決策，是不是有不少是“憑直覺”，而非基于數據呢？

不妨試著回憶下，你們之前的個人決策，是不是有不少是“憑直覺”，而非基于深思呢？

因此，鏡同學想結合上周的兩個產品案例，分享一些關于向上發展的思考，希望能帶給你一些啟發和參考。

01 運營反饋需求：用戶想要刪除系統數據

上周我們產品運營同學向我們提交反饋了一個需求：企業用戶想要刪除掉系統中“待辦”、“整改”的系統數據，請我們產品經理設計需求，研發同學執行下開發任務。

這個需求背景是：企業使用我們的信息管理系統，他們的上級監管部門要檢查企業的信息化使用情況，但他們系統上存在很多待辦數據、整改數據等，這些數據暴露出企業安全生產管理的執行不力，因此，這個企業就想要我們幫忙刪除掉這些數據。

鏡同學相信，應該有不少B端產品同學都遇到過類似問題，當時我們一個產品經理在群里收到該需求后，不假思索地就答應了，還憑直覺承諾當天就會完成產品設計，當然，這類技術性需求本身并不復雜，只要定義描述好需求后，開發同學分分鐘就可以搞定。

聽完該產品同學的反饋匯報后，我有兩點清晰的感受，一是該同學工作很積極，響應很快；二是，該同學掉入了“弱思考陷阱”，越是簡單的事越容易憑本能、按感覺去做事。

我便引導著問他，在正常的產品設計流程中，收集到需求之后應該做什么？他回答說，應該先做需求調研，論證需求。

是的，他很清楚需求流程，也具備方法論，只是忘記了思考，由本能主宰了理性，憑直覺做出了行動決策。

那我們多維度論證下這個需求：從技術實現上來說，并沒有任何難度，但從公司價值來說，我們作為技術服務的供應商，我們竟然能刪除用戶數據，幫助用戶“造假”，既違反用戶隱私，也有損公司口碑。

從需求調研本身上來說，這就是典型的“偽需求”，既沒必要做，也不能做，更是技術性公司應該堅持的底線，而從產品同學的思考邏輯來看，他并非不知道需求調研的方法論，也不是沒有能力識別，而是，在這個小需求面前，忽略了“思考”的必要和價值。

所以你看，弱思考，往往會導致流程性的錯誤。

02 客戶提出需求：想要批量開通用戶

大家都知道，在日常工作中，產品經理與客戶溝通需求的場景非常普遍，用戶往往也會反饋很多有價值的真實需求，而有些需求通常很著急，做完整的產品設計則會耽誤用戶使用。

比如，上周我們的機構客戶就提出一個需求，他們在使用我們的一款SaaS產品，其中有個功能是可以添加自己所服務的企業，當時，他們臨時有個集中匯報會，需要快速為即將要服務的200多家企業開通賬號。

不過，按照現有的功能，他們需要逐一去添加賬號，為服務的企業開通系統，這樣很慢、效率很低，我們系統又沒有批量導入功能，他們就希望我們通過技術手段后臺為這些企業用戶批量開通下賬號。

這個需求不同于上面刪除用戶數據的案例，該需求是有真實價值的，只是我們產品暫時沒有該功能，因此，我覺得這樣沒有問題，就沒再深度思考，作為產品研發中心負責人，我就準備隨后安排后臺開發人員進行技術處理。

剛好我們要開周總結會，我就順便把該事情給總裁匯報了一下，領導當時就強調：先不要直接答應客戶，讓客戶提交一個書面申請，授權我們為他們批量開通賬號，這樣既能解決客戶問題，還能避免后續扯皮，更能對外表現我們的技術張力和專業正規性。

果然，客戶并沒有反感，也沒有認為我們的“多此一舉”，反正發來信息贊賞我們的技術管理很專業，也很配合地提交了“授權申請”。

事后我總結，我在這件事情處理上認知有偏差，單純認為是缺乏經驗也不準確，事實上，我當時深度思考不足，也在憑直覺來處理新事物，至少沒有尋求多方溝通的主動意識。

是的，往往越是簡單的新事務，越容易陷入“直覺”陷阱。

03 產品同學需要寫《產品操作說明書》嗎？

上周還有一件事，有個產品同學詢問我產品經理需要寫《產品操作說明書》嗎？那不是測試或者運營的工作嗎？和他溝通后對我的啟發也是：面對問題，我們的本能不應該是回答答案，而應該先深度思考。

我當時也在小報童「鏡同學的產品驛站」做了分享，在這里也給大家做下簡單的復盤：

首先，有問題就會有答案，這對很多人來說，都是本能認知、也是基本常識，所以你看，這句標語甚至成了“知乎”的slogan。

但是，據鏡同學觀察，很多產品同學在面對職場問題時總顯得缺乏定力和靜氣，難以周全的兼顧，本能的直接回復，生怕答案過期，而且，越是簡單的問題就越是輕敵。

那么，面對問題，我們的本能反應既然不是“回答答案”，那應該是什么呢？

很簡單，是思考。

底層認知邏輯也很樸素：問題→思考→答案。

思考是催生答案的必備過程，面對問題我們最重要的便是深度思考：思考功能定義、思考問題要點、思考本質解。

我們說回這個問題，我當時并沒有直接回答，因為我深知定義問題是找到答案前提，而且，我過往也踩過類似的坑，遇到過類似事情，比如，我們之前公司的《產品操作說明書》就不需要產品經理來編寫，于是，我和他做了溝通交流，解題思路如下：

1）定義清楚《產品操作說明書》

你們公司對《產品操作說明書》的定義是什么？

產品生命周期后半程會有很多文檔，如，《產品手冊》、《產品說明書》、《產品操作說明書》、《產品培訓手冊》、《用戶使用指南》等等，這些文件在不同公司語境下作用不同，承建崗位也各異。

而《產品操作說明書》顧名思義，主要是對現有的產品功能、操作步驟進行解釋說明，以便用戶更快地理解產品、上手使用產品。

2）搞清楚該文檔的目標用戶

那么，這個文檔是給公司內部人員（如，業務、運營）使用還是給外部客戶使用？

當時，我們之前公司定義的《產品操作說明書》是外部文檔，因此，這個不需要由產品經理來寫，而是由客戶成功部門來編寫，他們是直接面客的。

但是，產品經理需要編寫《產品手冊》，客戶成功同事會依此為基礎編寫《產品操作說明書》。

3）以價值重新理解

好了，明白了該文檔的內部價值，我們就更好理解為何我們當時公司沒有定義產品經理來寫的原因：

之所以這樣安排，一是客戶成功需要深度了解產品；二是很多客戶關注的產品功能尚在研發中，但客戶成功部門可以提前劇透，他們會結合市場動態進行放大表述；

而產品經理所寫的《產品手冊》更多只是從產品角度對現有產品功能進行的內部分析，以便公司其他部門人員學習了解。

我們再次回到問題本身：《產品操作說明書》這個小問題，似乎很好回答，我相信一定有不少產品同學會說，肯定是產品經理來寫啊，不用懷疑的，甚至會列出網上答案，或者，ChatGPT的回復，以證自己說得對。

誠然，絕大多數情況下《產品操作說明書》由產品經理來編制并無不妥，但總有例外，本能回答并非最優解，正確的解題思路應該先進行深度思考。

其實，這多復雜問題的正確的答案都不是從書面上可以直接回答的，而是在不斷互動、碰撞過程中修正完善的。

問題→思考→答案，面對問題先不要急著回答。

這個認知習慣也許能幫助你從問題中積蓄成長的力量。

最后，鏡同學想說的是，產品經理本質上是設計崗位，是創造性的工作，華為曾說過，創新是最大的護城河，對產品同學也一樣，核心競爭力來源于對新事物的達成效率。

因此，我們再強調總結下，在產品工作中應該要竭力避免「弱思考」和「憑直覺」的錯誤認知，想把「問題清單」轉化為「解決方案」更應牢記：深度思考、基于理性。