团队最近几个月都在给产品做减法，作为一款2B的SaaS产品，想要删减功能实在是不容易。每当团队讨论是否应该删除某项功能时，头脑里总会有一些声音：
然后某些功能又会安然无恙地回到产品中。正好最近读到 简约至上 这本书，其介绍了四种设计简单用户体验的策略：
作者经常思考如何简化其他设备和体验，会时不时地应用上述四个策略，它们不仅适用于简化功能，也适用于简化内容。而且，无论项目大小，这四个策略都同样适用。接下来，我根据自己的理解为你详细说说这四个策略。
继续阅读最近开始断断续续的听万维钢的「精英日课」第5季，刚听完他讲的第一本书，内容还挺丰富的，简单地做做笔记，也聊聊自己的理解。
什么是领导力？
瓦德瓦讲过这样一个故事。
他有个女学生，13岁的时候得了一场重病，在医院里等待手术。有一天医生将她的父亲叫到病房外，说了两个坏消息。第一，你女儿的病情已经非常严重，原计划一星期之后的手术必须得提前到今天晚上。第二，医院出现了一个状况，没法给孩子提供麻醉，手术只能在没有麻醉的情况下进行。
没有哪个父亲受得了这样的消息……但是父亲回到病房，带给女儿的，却是两个好消息。
第一，医生说今天就可以做手术了，不用再等一星期，这意味着三天之后你就能出院回家了！第二，医生们一直在观察你，他们认为你是最勇敢的少年，所以手术甚至不需要麻醉！
继续阅读前段时间在网上看到一个讨论，就是目前很多业务和产研同学会习惯直接通过修改数据的方式来解决一些问题，比如修改订单状态、修改用户状态等。提出问题的同学觉得这不合适，他提出的理由是：
很多数据变更的操作都有时效性要求，比如功能不完善引起的数据错误需要及时修正，这时候客户不可能等你完善产品功能。还有些数据变更，比如修改某个字段的默认值，就是临时性的操作，也不可能开发相应的功能来支持。提出问题的同学也承认，当出现这些情况时，直接修改数据库确实是最方便、最有效的手段。那么我们是否应该把它作为常规手段呢？还有更妥善的解决方案吗？如果有其他方案，有什么好的流程/方式能避免大家通过更改数据库解决问题的？
继续阅读《文思泉涌》是一本关于如何成为一名深思熟虑且训练有素的写作者的书，虽然这是一本写给学术研究人员看的写作实用指南。它教你如何干净利落的写文章，你教你如何高效写作，甚至帮你克服写作拖延症，但它又不会讨论新的技能，只是尽可能的改变你对写作的态度和习惯，让写作过程变得很有趣，变得更容易。
这里挑选出我最喜欢的一段分享给你。
继续阅读