1. 到处看看。和一帮创业者/投资人去了趟印度、带一家老小去了趟港澳、小家庭三口人去了趟日本，感受到一个国家的“年龄”，如果说中国是个青年，那印度还是个少年，而日本已经退休，你只需要站在各地的街头看一看即可感知。也有或公或私的原因，国内走了几圈“北上广深杭”，类似的，感受到“城市”的年龄，“北上广”就明显年长于“深杭”，宏观的从政府对待各类公司的政策，微观的从当地人广泛认可的“好工作”之中，可有体会。

2. 和包子一起成长。从坐/爬到站/走，从只喝奶到会自己拿个勺子吃几口，从撕书到愿意听你讲一会故事……至于我学到什么，嗯……比如带他上早教课，就学会了peekaboo这个单词，以及peekapeekaboo的说法。

3. 给大客户做培训/轻咨询。这块，重新优化了课程，客户广谱了很多，如蔚来汽车、科大讯飞、京东、中国平安、国泰君安、阿里云大学、创业邦、航天二院（军工）、字节跳动、蚂蚁金服、招商银行、中国银联、36kr、电信、广汽研究院、上汽通用、广联达（建筑）、华为……有意思的是，这又一次让我感受到“年龄”，公司的“年龄”，最简单的如培训时用的电脑，有的公司不能用外部电脑，有的只有VGA接口没有任何转接头，有的是HDMI、DP、USB-C信手拈来，有的已经有很成熟的无线投屏方案。

4. 图书的情况。《人人2.0》在豆瓣依然可以保持8.3分，还是不错的，几本书加在一起，今年也卖了小10万本，年底也做了个小周边（一副扑克，每张上都是一句产品相关的金句，非卖品，有缘者送）。

5. 公司的情况。良仓孵化器开出了第一个超过10000方的场地，求橙商学院办了第二期，当然，也感受到了创投环境的变冷，继续在为创业者服务的道路上探索吧。

2019的一些想法。

1. 体检有些小毛病，原因都指向体重的上升，所以要控制一下。

2. 从2018年开始，每年都要全家去一个没去过的国家/地区看看。

3. 个人的知识类产品，继续分2B、2C两条线，重点探索从“我懂了”到“让对方懂”要做哪些事，研究“认知”、“学习”、“教育”相关的知识。

4. 多读好书、多和牛人聊天、多总结提炼。

5. 公司方面，先“活下去，不亏钱”，其他再说，2019看样子，创投行业依然低迷。

就这样，祝大家新年快乐。

__________

iamsujie，前阿里产品经理，写过《人人都是产品经理》、《淘宝十年产品事》、《人人都是产品经理2.0》，现在做创业者服务，『良仓孵化器』创始合伙人。

挤一趟早/晚高峰，你能学到很多迭代的知识……敏捷|迭代的地铁模型

关于敏捷|迭代的形象化解释——

李宽在《B端产品经理必修课》里，提出了公交模型。

Marty在《启示录》提出了火车模型。

这篇，我再给出个地铁模型，也许能让大城市每日通勤的从业者们更有直观感受。

先复习一下相关类比。

火车模型发布模式：以固定的周期持续发布产品，如果某项既定功能未完成，就落到下个周期发布。

公交模型：出行线路–>需求管理流程；发车间隔–>需求管理周期；到站时刻–>需求时间。

然后，我再说说地铁模型。

一趟车：一个迭代。

起点和终点站：一个迭代的开始与结束。

站点：一趟车按照站点顺序依次停靠，好比迭代的阶段节点，比如评审完成、编码完成等，背后是一个相对固定的，有时序的需求管理流程。

发车间隔：迭代周期，乘客多的时候，调度会增加车次。

乘客：一个个的需求点。他们有优先级，比如老人孕妇，上车后有更大概率可以有座位（享受更多的资源支持）。

到站时刻：某个迭代，每个环节有固定的时间点，如果需求错过了时间，本班车不会等，但可以坐下一班车。如Scrum之类的敏捷方法，对时间会严格把控，比如每周的周一上午干什么、周五下午干什么，更像地铁而不是公交车。

车厢/座位：比如女性车厢、照顾专座、商务座（如深圳地跌7号线），这是资源的优先级，用来匹配需求的优先级，乘客根据其特性、票价等，可以获取的资源不同。

快车慢车：在一个大的研发组织里，不同迭代的优先级，比如日本的地铁，同一条线路有每站都停的，有快速、有特快。此外，必要的时候会出现让车的情况。

上下客：不是每个乘客都是从起点上车坐到终点的，各个环节，都可能有上有下，需求也有在各个环节搭车的和变更的。当然，临时上的，估计是没座了，只能站着。

早晚高峰：乘客比较多的时候，我们虽然及时赶到站，但依然有可能挤不上这班车。更可怕的是，还没到目的地的时候，可能会被中途下车的人连带着挤出去……

末班车和头班车：地跌每天夜里都会停运，而对于研发，春节前后，或者阿里的双11前后，会有封网的行为，于是会出现没车可坐的真空期。

你还能想到什么类比？

__________

从“PRD怎么写”说到产品思维

PRD怎么写？

这个问题可以算是困扰产品新人排名前三的问题之一了。

但我显然不会具体说应该怎么写，不会说模板、形式、原则这些落地的东西，而想和大家聊聊，怎么把产品思维反作用于回答这个问题，反作用于产品工作本身。

第一，问专家不如问用户。

如果我们把PRD也看做一个产品，那么用户就是开发、测试等人，除了问专家（可以得到方法论），更应该去问看你PRD的人，可以得到你要的具体答案。

第二，问How之前先想Why。

做产品的时候，要回答该怎么做，有一个前置条件，就是你要知道（用户）为什么要这么做，于是，你可以从“为什么要写PRD、写的目的是什么”这个层面出发，来思考“PRD怎么写”。

以一个角度为例，如果是为了项目过程中，团队中不同角色的沟通更加高效？那我们就会更加倾向于重口头、轻书面的模式，比如“原型图+标注”。如果是为了事后有个书面存档的长期考虑，那扎扎实实仔细写下来就必不可少。

延展开来，大家不妨留言说说你理解的“PRD的本质”是什么。

第三，思考用户动机。

我们做产品，希望用户用，必须要思考用户的动机，假设“用户是少一事不如多一事，那么他为什么要用”。PRD也是一样，相信很多人都会抱怨“写了那么多，评审的时候技术根本不看……然后开发的时候又跑过来问东问西，还说有很多功能实现不了……评审的时候都干嘛去了”。

如何让开发有动机仔细琢磨PRD？有些公司在动机层面给出了这样的解决方案——让开发写PRD，产品只写大逻辑，然后评审的时候，开发主讲给产品经理听。

好了，相信很多产品经理会对这个方案拍大腿叫好，而开发就要骂娘了。所以，实施起来没那么简单，需要一点自上而下的推动，考核方式的调整，也需要产品经理足够强、开发也懂一点业务。

以上，别忘了留言说说你理解的“PRD的本质”是什么。

__________