經驗的邊界
昨天載母親第二次去醫院做檢查。第一次去的時候，需要做一項檢查但是當天排不上隊，因此預約昨天做。做完這項檢查之後還要預約給醫生查看檢查結果。
昨晚回到家，聽到父親大發雷霆，說去了兩次什麼都沒查出來，還要再去一次，要是得了什麼重病，現在早都死翹翹了。
言語混雜著粗俗的詞。
試過說明情況，但是無果。
於是不再理會，專心吃飯。
吃的時候，還是一直在想，為什麼會這麼生氣，慢慢地，想明白了，父親一直都在用經驗來判斷問題的本質，也是利用經驗來解決問題，他以為，同一家醫院看了兩次沒結果早就該換一家醫院看，換做早十年，這套理論或許有用，因為那時候的醫療水平與現在還有差距，一個醫生診斷不出的病換一個醫生說不定立馬就有結果。
殊不知，現在的看診流程，基本都是檢查根據結果給出診斷結果，只要不是什麼難症，基本都是一個流程。
想到這一點，內心也就釋懷了，完全不需要和一個只會依賴經驗處理問題的人較真嘛。
有些事，靠經驗可以解決，例如農耕的人，看到火燒雲知道快下雨；有些事，例如今日頭條，抖音，趣頭條，怎麼根據經驗看？
能力的邊界
今天在聊天提到關於處理需求應該使用什麼樣的思維模型，很自然地就想到樊登的課程，發現樊登對於工具層面的書解讀的很好，很容易去按圖索驥，應用到生活中，但是對於那類強調「道」的內容，就顯得力不從心了。
其實也好理解，工具型的書，只要知道應用的步驟，應用的背景，基本就可以上手。但是關於更深層的內容，需要個人自己去領悟。
瞭解這個之後，對樊登提供的知識，能應用的範圍心理大概就有底了。
思考的邊界
下午開會，運營提到，喚醒沉默用戶的方案。
他根據用戶3日流失、七日流失分別做推送方案。然後詢問我是否有其他補充。恰巧近期在追36氪產品總監的文章，文章字裡行間時不時會提到要以更高視角去看待問題。也就是說，一個功能，初級產品只注重如何實現，更高階產品應該要關注當前功能的上下左右，即業務上下游的影響，對同級功能的影響。
這應該也是衛哲提出的《需求三加一》的主要內容之一。
回到喚醒沉默用戶的例子。 當時被問道的時候，下意思問了自己，為什麼要對3日流失，7日流失做喚醒，這個緯度是怎麼思考的。
然後我發現，這些用戶已經是流失用戶了，如果要喚醒，是不是還可以進一步，在未流失之前就去做喚醒？也就是當我們發現用戶做了某些行為沒有滿足需求的時候，我們做一些手段讓用戶留存。
如果我們只關注要喚醒這件事，很容易就會陷入思維的泥潭，即對誰喚醒，怎麼喚醒。拔高我們的思維，用所謂的「上帝視角」、「閱卷者視角」去看待，會有不一樣的收穫。
瞭解了「邊界」這個詞，對很多不確定的事心裡自然有了「譜」，我是這麼思考的。你呢？
