Vol.20200531:如何给未来的自己,储备今日的知识

本周杭州一直下雨,主题曲都和雨有关:

少楠说:其实一直对于投资一直有一些误解,认为投资只和钱有关。最近突然明白了,最大的投资是时间,甚至不是全部时间,而是自己可控的那一小段时间而已。把时间放在哪里,就是对什么事情的投资。在狭义投资中犯的错误和经验,在日常中也屡屡出现,比如爱频繁做决策而决策筹码太小的毛病等等 。

想起欧文 · 费雪在《利息理论》中关于投资和消费的小故事:

一个人买了一篮水果在一个钟头内就吃掉了,确是将钱用于吃水果的享受。但是,他若在秋季买一桶苹果而留到冬季吃时,他是将钱用于消费还是用于延迟享受的投资?在理论上,这一桶苹果是投资,相当于房屋或其他耐久财货的投资。在实际上,它是划做消费的,虽然这是属于两可的情形。消费与投资只有程度上的不同,它决定于花费与享受间时间间隔的长短。消费是花钱于很快就要来到的享受。投资是花钱于延迟到日后的享受。

所以当你打开这封信的时候,我希望对你来说是一份投资,而非消费。希望这些内容的半衰期足够长,长到三五年后还值得你再来翻翻,我也会作为园丁,不断地耕耘这块土地。

所以从时间的角度来看,本期的内容就很有趣了。「渐进式总结」是教你如何给未来的自己储备今日学到(但还用不上)的知识;「领域驱动架构」是教你如何从整个生命周期来看业务该如何架构;以及「人总有一刻,开始思考死亡」。

从另一个角度来看时间也很有趣,许多产品的生死,和占用别人的时间也有关系。宁可占据一小部分人的绝大多数时间(比如 Notion,Sketch),也不要让多数人使用一点时间(比如 Xmind,Wunderlist)。因为任何一个新的平台,都是由少数人用得多,然后这个少数人变成了多数人而形成的。

想起熊培云的一首小诗:如果三月播种,九月将有收获,焦虑的人啊,请你不要守着四月的土地哭泣。土地已经平整,种子已经发芽,剩下的事情交给时间来完成。

另,日常许多碎碎念都是更新在 Jellow,但鉴于 Jellow 并不是完全公开的产品,所以我又申请了一个小号,日常会同步一些发在 Jellow 上关于产品的思考,有兴趣交流的朋友请添加微信「ProductThinking2017」

隐藏内容,您需要满足以下条件方可查看

何谓渐进式总结:Progressive Summarization

少楠说:本文作者是Tiago Forte @fortelabs,也是之前 个人信息组织系统:P.A.R.A 这套组织系统的作者。这个系列有六章,这是翻译完的前三章。感谢 @Mona Chang 协助翻译和 @YaoXing Liu 的监督催促。

这篇内容主要解决的是,当我们建立好信息组织系统之后,开始向系统内添加内容的时候,该如何确保几年后的我们,能理解今日我们存下来的只言片语呢?

为此我特地打开了用了十年的 evernote,发现除了我记下来的个别关键词搜索能出来一些内容外,整个笔记结构散乱不说,除了少数几次要做分享之外认真整理了几个主题,其他内容基本上就和草稿纸一样无法辨认了。

渐进式总结试图给这种情况一个解决方案。这个系列吸引我的并非是具体的执行方案,而是作者分析问题和提出问题的角度 —— 功不唐捐,但许多时候我们都是在错误的时间学习了正确的知识,并且没有把这些将来可能会用到的知识打包存好发给未来,要么变成了阅后即焚没有归档,要么变成了缺乏上下文无法辨识,要么就是原文存储造成再次检索的成本更高。

隐藏内容,您需要满足以下条件方可查看

领域驱动架构(DDD)建模中的模型到底是什么?

少楠说:本文是 @YaoXing Liu 压箱底的珍藏。但别担心,我也不懂技术,这一篇里面也没有太多的技术术语 —— 其实我对技术的态度,就像看英文小说一样,能听懂别人讲这个小说多么精妙,剧情结构多么好,甚至可以应用在自己的中文小说中,只是我很难用英语去写出句法优雅的英文小说。

之前 @Light 在 向 AI 学习解决问题 中也提到,毕竟许多发明技术的人都是这个星球上顶尖的聪明人,我们即使不去学习具体的实践,其设计思路也是值得借鉴的

曾经我的导师告诉我,优秀的产品经理都需要自己设计数据库结构,当时我还是懵懂。后来懂了一些数据库原理之后,才意识到他的意思是,你应该懂得如何设计业务模型,而不是每次都从前端的界面开始设计。所以今日为何经常说程序员要干掉产品经理呢?是因为多数时候产品经理只承担了沟通和部分交互、用研工作,而在业务模型的设计上,却希望依赖于技术同学搞定 —— 尴尬的是,技术的同学往往由于这种琐碎的 Case 太多工期太紧,导致根本没空去仔细揣摩和理解业务,这就形成了一个恶性循环,直到有一天系统过于复杂而突然崩溃。

其实如果跳脱 DDD 在技术领域的应用来看,在日常工作中我们也是用得到的:首先需要定义一套「通用名词」,确保业务上下游都用这个名词。曾经我们就出现过「快速开药」「快速图文」「开药问诊」「续方开药」「去开药」来描述一类产品功能,可想而知我们自己内部每次都要讨论半天「我们究竟在做什么」,更遑论医生用户看到这些名词更会头大 —— 好的命名是成功的一半,所言非虚。

隐藏内容,您需要满足以下条件方可查看

软件吃软件,编程工作会越来越多吗?

少楠说:上周和一个投资人朋友聊天,国内做 Notion Like 和 Airtable Like 的创业公司越来越多,大家都笃定下一波 2B 工具的机会即将迸发,而这一波工具的核心其实都是围绕着 NoCode 和 LowCode 作为卖点,提高小微企业和个人的效率。

从积极地角度来看,以后创业「只差一个程序员」的情况会有所缓解,更多创造力的事情将会出现;而从悲观的角度来看,更多人将会失去职业 —— 因为越来越完善的基础架构,会导致许多人从创造者变成了组装者 —— 因为太多完善的组件和素材可以使用,并且这些东西足够优秀,已经鲜有机会从零来经历这些东西创造出来的过程了。当有一天系统足够强大的时候,这些维护系统的人就不需要了。

从这个角度来看,产品经理会越来越多还是会越来越少?这取决于软件自动化的程度。而我认为没有一个叫「医生」的岗位,他只是相关岗位的集合,我们经常开玩笑说 —— 一个皮肤科医生和美妆博主的距离,或许比神经内科的距离还近一些。许多产品人(尤其是新人)都认为有一个叫「产品经理」的岗位,其实最终来看,他应该是电商产品经理、IM 产品经理、交易平台产品经理等。试图学习一套通用性的思路来解决问题,就像用一套开源框架解决已经被人解决的问题一样,这个过程中自己增加的附加值很少,那么对于公司来说这种人就不重要。

隐藏内容,您需要满足以下条件方可查看

Persona 的起源

少楠说:虽然现在 Persona (用户画像)似乎被说烂了,但是真正会用的人也不多,能不断地更新画像的团队就更为稀少了。这个技能之所以知易行难是因为,你交谈的对象是一个活生生的人,有丰富的背景,**你需要从海量的信息中捕捉到,哪些背景是影响他决策的因素,**以及他在使用你的产品时,处于一种什么样的情境 —— 这也是我一直说解决问题要到现场去的原因,在办公室里面是无法 YY 出来用户所在的环境的。

而之所以 Product Thinking 产品沉思录精选 开篇就是关于认知和思维,一方面是让我们更好地理解我们自己,另一方面是为了更好的理解他人。

这是 2017 年初翻译的一篇关于 Persona 的起源,最近整理笔记的时候又发现了,似乎没在这里发过,所以重新整理了下。知道过去,才能更好地设计未来。

当时正在帮许多公司做产品咨询,发现许多公司并不知道自己的用户是谁,沟通起来效率也很低,就额外增加了 Persona 这堂课和这个调研部分。不过当时也激起了自己的好奇心,想知道用户画像到底是怎么来的,便有了此文。Persona 不是什么玄学,文中 Alan Cooper 当时想法也很朴素,为了让团队都知道典型用户的样子。当时虽然没有成熟的理论,但也已经够用了。所以如果你现在对你的用户画像模糊,不如开始做起来访谈吧。

隐藏内容,您需要满足以下条件方可查看

温故知新:人生总有一刻,我们会开始思考死亡

摘录时间:january 2017

少楠说:当时摘录这篇文章的时候,还没有「少楠说」这个部分。我记得我开始思考死亡,是有一次从老家回上海,在火车上看《最好的告别》,那时候才理解什么是死亡,以及我们该以什么样的方式面对。前年一周内,先后送走了姥姥和爷爷,在火葬场看着青烟升起的时候,我也在思考我们活着的意义是什么呢?

我一度很沮丧,沮丧于始终没有找到自己所热爱的东西,或者说曾经有过热爱的东西,被我自己搞丢了。又会非常焦虑,焦虑于已经过了而立之年,依旧一事无成。或者当年年轻气盛的时候很容易找到意义 —— 只需要和你们不一样就好了,大不了重新来过。而站在今天的时间和空间,能选择的范围其实更多,但是 load 的次数却变少了。

我大概明白了,茨威格在《人类的群星闪耀时》所说的那种幸运是什么 —— 「最大的幸运,莫过于在年富力强的时候,发现了自己的使命」

隐藏内容,您需要满足以下条件方可查看
Mail Weekly

Vol.20200524:判断时距

2020-5-25 17:15:41

Mail Weekly

Vol.20200607:地图不是疆域,但我们还需要有指南针

2020-6-7 13:35:00

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
有新私信 私信列表
有新消息 消息中心
搜索