第一性原理（First Principles Thinking）简单说就是：不要用他人的经验、舆论的惯性来思考问题，而是把一个问题拆到最基本的、不可再拆的事实，然后从这些事实重新推导解决方案。
这是客观事实，还是大家都是这么想的？
例如❌：冬天一定天气是冷的、高薪的工作一定不稳定、产品经理一定要加班
而是拆解为最基本的颗粒来提问思考：
冬天的气温由什么因素来决定？什么因素决定收入？什么因素决定工作压力与时长？有没有可能把他们拆开？
我们可以拆解为三个步骤来运用第一性原理：
- 把默认前提揪出来：为什么一定要这样？
- 区分事实和假设：这是客观事实，还是只是大家都是这么想的？
- 从底层约束重新组合：如果只保留这些不可改变的事实，我还能怎么解决？
用一个很简单的问题来练习第一性原理思考方式：
“一个产品上线后用户使用率很低，你作为产品经理应该怎么办？”
不着急马上思考提升用户使用率的问题，我想先搞清楚以下几个问题：
- 这个产品的目标用户是哪些？
- 目标用户是否本来就是少数用户，如果是，是否需要重新思考扩大目标用户？还是说这个使用率低根本不是问题？（例如我以前做的效能度量，就是面向管理者一周看一两次）
- 产品是要解决目标用户什么场景下的什么问题？
- 使用场景是否本来就狭窄？如果是，那我们是不是要更改目标为更通用的使用场景？
- 针对解决的问题是否具有普遍性？如果否，那是不是要更改设计目标？
- 是怎么解决的？
- 初次使用高，留存率低的情况，思考产品解决问题的路径是否过长？产品教育是否友好？体验是否可以优化？产品是否有效地解决了问题？
- 用户如何触达产品？
- 如果产品以上都没有问题，我们才去思考产品的广告投放、销售渠道、商业模式是否可以有优化空间
如果这个时候追问一个更狠的问题：
“很好，现在你只有一周时间、只有一个开发、一个设计师，而且老板明确要求你把使用率提高20%，你会先做什么？”
我一开始可能会觉得这个问题很离谱，但是想想还真有可能现实世界里发生的这么离谱的情况
面对这种不确定的问题，我的脑子里可能有无限个疑问，例如用户是谁？产品是什么？使用率是怎么算的？为什么要提升20%？期限真的只有一个星期吗？老板想坑我？……😂
但是解决不确定性问题的出口在于，先把无数个问题收束为几个决定性的关键问题：
- 使用率具体是怎么计算的？——— 指标定义
- 使用率低是不是一个真实的业务问题？是否作为业务指标值得优化？——— 问题定义
- 老板想把使用率提高20% 背后真正的目的是？——— 明确核心目标
这三个关键问题决定了后面怎么做的方向，所以从无限的问题中提取关键问题是很重要的。
确定了这几个关键问题后，就可以开始思考是否可以根据这几个关键信息行动，比起追求全部问题的解答，在有限的已知中先前进更为重要。
下面的几个练习，只允许向自己提问三个关键问题，只弄清事实：
一、工作事故版
你负责的一个项目上线后出现了严重问题。
老板很生气，要求你：
“明天之前给我一个完整的解决方案，而且以后绝对不能再发生。”
现在你知道：
你只能问三个问题。
不准解决问题，不准甩锅，不准解释。
这种事故最忌讳就是情绪上头开始甩锅，而是必须先马上弄清楚关键事实，处理事故：
- 严重问题具体是指发生了什么？—— 把“严重问题”变成具体事实
- 此次事故造成的影响规模是怎样的？—— 是否还在发生？影响谁？影响多大？
- 需要马上做什么来止血？—— 回滚版本 / 关闭功能 / 限流 / 临时绕过？先恢复业务而不是彻底解决问题
二、“老板说用户不买账”
你负责一款 B2B SaaS 产品。
最近老板突然找你：
“这个产品用户根本不买账，你看看怎么解决。下季度必须把产品收入提升 30%。”你目前能拿到的信息只有：
上一题的重点是“事实 → 影响 → 止血”，而这一题的重点在 “目标 → 结构 → 瓶颈 → 杠杆 → 资源”
- 产品的收入来源与结构是怎么样的？—— 哪些客户、哪些产品/套餐、哪些收入类型贡献最大？
- 具体是哪一类用户、在哪个购买/使用环节出现了问题？—— 目前业务真正增长的瓶颈是新客获取、转化、客单价、续费，还是扩容？
- 哪个瓶颈最有可能在3个月内被改变？—— “3个月+2开发+1设计”，意味着老板要求你不要寻找“理论上最优”的方案，而要寻找“资源约束下最值得做”的方案。