听过许多大道理，却不知怎么提一个好问题？
以前百度有个高管说过一句话，说搜索引擎改变了对人才能的一个判断标准，以前一个有才能的人，是学富五车，知识渊博；而在搜索引擎时代，知识已经全部被索引，被互联网化了，所以正确的提问是才能的一种价值体现。搜索引擎定律是：你想获得怎样的答案，取决于你提出了怎样的问题。
如果你听过许多大道理，却不知怎么提一个好问题，请参照如下几点。
做好足够的准备和思考，再去问问题
很多技术社区在发帖前都会有一个类似的提示，搜索引擎是最好的老师，在提问之前最好先搜索一下已有的问题和答案，以免耽误大家的时间。但事实上，还是有很多人会不断地重复提出非常低级的问题。
我读大学的时候，有一次去问老师一个数学问题，老师说：“这个题你怎么做的？”我说：“我不会啊，我不会才来问啊。”老师说：“你不会但是也必须有思路、有想法，你做错了我可以告诉你错在哪里了，你什么思路都没有我怎么给你答案。”这件事情都过去二十多年了，印象深刻。如果你没任何准备，没任何关于这个东西的调查和研究，你去问问题，希望别人从头到尾给你说清楚是不可取的。第一，没经过思考，你是吸收不了的；第二，别人也不欠你的，最基础的、到处都有资料的，你应该自己学会搜索，学会查询。
正确的搜索方法
程序出错了，将错误信息贴出去搜索，是程序员常喜欢用的一种搜索方式。但是你把完整信息贴出去搜索，里面很多是你的代码行数、你的文件名信息，这些从哪里搜？你当然要把某些个性特征屏蔽掉，再去搜索，才能看到别人类似的问题以及答案。是的，通常程序员没那么笨，但是不会正确组织关键词的还是比比皆是。你在搜索一个问题的时候，对关键词要用各种组合方式，如果无效的答案太多太杂，要学会增加限制性关键词过滤；如果搜索不到任何结果，或任何有价值的结果，要学会减少一些非关键的限制性关键词，来扩展搜索结果的多样性。其实就上面这两条，多尝试而已。
结构化的思维，排除法，层进法提问
我常用的一个培训情景测试（面试中不敢用，因为基本没人可以过关，但培训中经常用）是这样的。假设数据库服务器挂了，没反应了，假设我就是个菜鸟运维，什么都不会，就会基本操作，你是技术专家，你来帮我分析这个数据库挂的原因（当然，实际上我已经设定了一个原因，并会基于这个我设定的原因给测试者反馈）。现在你来提问，我来回答系统的反馈，一直到你找到答案。这个测试特别考验技术人员面对问题的思维方式，你是不是有一种整体的判断方式，能够用排除法快速找到方向，用层进的方式逐渐剥出真相。很多人一上来就开始猜答案，基于他们认定的答案来提问，这是特别坏的一个习惯，因为这样找问题几乎就只能凭运气了。
提出正确的问题，是找到答案最关键的因素。技术高手都知道，面对大部分问题，最难的是定位，定位到了，处理基本上都没什么难度。
敏感度，好奇心
提出有价值的问题，其价值不弱于找到有价值的答案，不仅仅对技术，对产品、对运营，也是如此。为什么说敏感度？做数据分析，做数据，不是技术活，而是一种理解力。理解力来自于哪里？来自于好奇心。而敏感度，为好奇心带来源源不断的灵感。然后你会去提问题，为什么这个渠道的转化率比这个渠道低？为什么这个产品的留存有这样的特征？提出问题，才会去思考下一步。下一步是什么呢？分解问题，这个渠道的转化率是不是可以再细分，比如根据地区、根据语言版本、根据投放策略，然后看是哪个地方出现了显著差异，还是说不同细分都体现完全一致的差异。这对你理解问题和寻找答案帮助特别大。比如留存，也要再细分，不断细分问题，不断层进，把好奇心变成经验值。
有的年轻人，工作很短的时间就会进步特别大，非常有想法，有能力，就是因为他们始终保持好奇，保持敏感，不断去提出新的问题，寻求答案。但有一些工作很多年的人，你说经验丰富？其实都是同样的经验重复，没有好奇，不敏感，各种麻木不仁，这样做事情再有经验又怎样？
反推，逆证
这就像我们上学时做数学题，我们通过题目得出一个结果后，在检验结果的时候，把结果带回题目，重新推算一下，是不是所有中间得到的数据和题目中的条件一致，这样才能判断我们得到结果是否正确。
在做分析和判断的时候，似是而非等干扰性的判断是经常出现的，特别是提问者带有明显目的性和诱导性的时候，更容易得到这样的结论。
如果我们觉得A是坏人，那么他的一切表象都是坏人的迹象，你怎么看都觉得他就是坏人。你提出了一个“A是坏人吗”的问题，然后给出了无数个A是坏人的证据。但突然有一天你发现B才是你要找的坏人，瞬间你发现A是坏人的所有证据其实都不成立。
尽量不要提出明显倾向性的问题，如果你提出了一个倾向性的问题，一定要对应提出一个反问，否则很可能被自己的问题带到沟里去。
归纳与总结
讲一种面试的方法，比如应届生，没有太多业内经验，我怎么知道这个孩子有没有前途，通常的问题是这样的，逐一递进提问。问题1：你在学校期间，觉得最能体现自己能力和价值的事情是什么？问题2：在这件事情上你遇到的最大困难和挑战是什么？问题3：你是怎么克服和处理的。这三个问题考的是什么呢？归纳和总结的能力，对自己从事过的事情、克服的问题，能不能有一个清晰的表达、有条理的描述，以及对自己是不是有一个正确的认识。其中，有精准的数字描述，会比定性的表达更具有意义。
非应届生也是这样问的。比如程序员A回答的是：“做过一次网站性能优化，效率提升很高，感觉自己棒棒哒。挑战就是并发一多，服务器负载很高，所以扛不住。解决方法是加了缓存，把数据库压力转到缓存上，所以负载降下来了，业务也增加了。”另一个程序员B的回答是：“做过一次网站性能优化，效率提升很高，感觉自己棒棒哒。挑战是并发达到200的时候，CPU占用100%，主要压力来自于数据库的查询，偶尔慢查询阻塞，数据库链接过多。解决办法是增加了缓存，缓存命中率达到了80%，也就是80%的查询请求不通过数据库，结果是当并发达到200的时候，CPU只占用了30%不到，后来业务增长并发展到400，CPU也只占用了50%。”现在，我相信你一定知道哪个程序员更值得用了。
我有一个习惯，分配工作的时候有些东西特意不会描述得特别具体，就是看看员工是不是有能力，有思维能力，来把这些地方做好。当然，这可能会付出一些时间成本甚至其他成本，但是对于培养新人来说，更宽松的环境更容易看到一个新人的潜质和能力。当然，后续人家没做好，没做对（常有的事情，不代表人不可用，只是没有惊喜而已），要给他讲一遍。如果前面很宽松，后面不给讲评，这个其实真就是偷懒了。
把大量的琐碎信息分类是特别考验思维能力的一种方法，首先你要有一个纬度的概念，比如按照业务的重要程度去分，按照功能或业务模块特性去分，按照体验的伤害程度去分，或者按照客户特征去分，等等。但是更有价值的可能是下面，多个纬度的组合，哪些纬度组合的投诉建议更有价值，优先级更高。
前段时间遇到一个梦幻创业团队，创业者是一个名校博士，大学教授，离职创业；团队技术核心都是ACM大赛的底子，来自于清华和上海交大ACM的骨干成员。那么面对这样的算法达人，从算法和技术上我肯定不敢班门弄斧，但是基于他们业务场景的用户引导优化我还是给他们上了一课。这一课说简单也简单，你们分析过用户的行为日志没？从中寻找过规律和特征没？只看了Google Analytic的漏斗模型，而没去看原始日志，没有去一条条体会用户的行为规律，你怎么能做好呢？一些他们以为需要很复杂算法实现的东西，其实可以基于行为日志，以不高的技术代价做成机器学习模型，思路一开对他们而言后面就没技术含量了。但这件事也提醒他们，很多看上去很基本的、很没有技术含量的事情，其实价值是很大的。
针对上述内容做一下总结。
1.对问题的描述，对解决方案的效果评估，要有条理、有逻辑，不但要定性，而且要定量，要精准描述，完整记录。
2.面临多个解决方案来处理的技术问题，要学会分辨评估每个解决方案的作用和效果，而不是说，反正把问题解决了就可以。
3.分类是一种能力，特别是涉及多个纬度的组合，非常考验对业务的理解能力，能够寻找正确的纬度组合，数据和信息的价值才能最优化。
4.从最原始的信息中寻找灵感和规律，这种看上去最没有技术含量的工作最能体现出你的思考能力。
5.培养新人和锻炼新人，对于非重要和非紧急工作，尽量给他们足够自由发挥的空间。
有些新人会觉得，这个公司管理真有问题，领导真烂，任务布置得一点都不清楚，怎么做啊。
布置得清清楚楚，你就是一个实现工具啊，你的能力体现在哪里啊！
取舍之道
优秀的产品经理，要学会做减法。
我们设计产品的时候，创业者点子都很多，把设计、策划书拿出来一看，产品这样这样，然后这样这样，以后还可以拓展为这样这样，聊天的时候突然灵光一现，对啊，我还可以把这个加上去，等等。可用户真的需要这么多吗？
很多时候，我们被自己创造的各种伪需求所麻痹，大家谈东西的时候往往流于自己的才能展示而忽略了事务的本质。比如公众号起名这个事情，很多人都有各种奇思妙想而忘记了最基本的诉求——容易识别和容易传播，所以很多特别有想法的名字其实识别度非常低，特别是一些认为用了谐音很有才华的那种名字，最不容易被人传播，因为大部分用户基于第一感都会输入错误。这就是创业者以及很多工作者最容易犯的错误，想太多，而忽视了最基本的东西。
那么，做产品设计的时候，我们要不断问自己一些问题。
用户的核心诉求是什么，这个功能点设计是否满足用户的核心诉求？
如果没有这个功能会怎样，用户还会不会使用这个产品？
想明白这俩问题，可能80%的功能都是没必要的。当然你说锦上添花好不好，但是，请别一上来就搞，时间成本是最大的成本，相信我，很多你以为精妙的设计可能毫无意义。
做一个新项目，一个创业公司，要知道一点，不可能讨好所有用户。即便有些需求是用户定义的，有些痛点是用户提出的，你也要甄别一下，这是不是你核心目标用户的需求，这是不是你核心目标用户的痛点。有时候，你甚至要为了让某些用户更满意，而伤害另一批用户，这个决定你敢不敢做！有没有价值！
我的观点是，如果为了发展更多的用户而伤害核心用户，是得不偿失的，很多公司犯过这样的错误；而为了核心用户去伤害一些其他用户，很多时候是正确的。比如说有人说要做高端社交平台，想法是让普通人也能参加高端社交，这需求听上去很不错啊，找一些资源以廉价的方式提供给普通人。但什么是高端社交？如果你认识门卫保安或者举办方，几个人私下靠关系凑进去了也就算了。但你想规模化商业化，就是开玩笑，高端社交一旦规模化肯定变味，高端用户一定会极反感。最后一定是高端用户见你就躲，只剩下一批普通用户自娱自乐。高端社交强调的是什么？私密性和准入门槛！
理解核心用户的诉求，理解核心产品诉求，再来理解项目管理。
我跟员工说，能不能启动个啥项目，员工说，需要做什么什么，工作量蛮大的，算算大概6个月。我说3个月我要它上线，别跟我说工作量多大，按照3个月上线给我做排期，也不难为你，你说的那些，不一定都要做，你自己研究一下，非核心的都扔后面去，做最基本的就能上线了。
什么思路呢？就是你先排工期，基于工期去优化产品设计，决定取舍。不追求第一个版本的完美度，但是追求效率，并且保证核心功能在第一个版本都能充分体现，线上再根据反馈快速迭代。大部分公司的研发都是先定需求后定工期，如果你先定工期后定需求，你会发现，其实很多东西并不是非做不可的。
这个思路历史上是来自日本的精益生产。在20世纪80年代的时候，Made In Japan以价廉质优产品快速打入北美，攻陷欧洲市场，那时候日本厂家如何思考的呢？北美和欧洲都是琢磨一个产品要做什么，再计算成本，然后按照利润率，计算售价，最后标价出去卖。日本人把这个颠覆了：我要打败你，我先计算这个东西准备卖多少钱，再计算利润率，回推成本，然后设计产品，基于这个成本，没用的砍掉，能裁剪的都裁剪，但保留强大的核心功能不能比你差，最后做出来产品的比对手便宜30%~50%。这是成本反推的设计思路，在互联网时代，时间成本是最大的成本，所以，我们要以工期来反推设计，裁剪需求。