2018-2019,盖个时间戳

2019第一个工作日,连续第12年的个人小结,不为别人,只是写给自己。

 

先回顾一下之前的小结:

2007的写在msn的space上,可惜这个产品已经死了好几年了,也没留底;

2008~2013的写在北京快乐八彩票开奖查询 www.gcsbk.com上;

2014年开始写在微信公众号里。

它们的标题如下。

2007总结?2008展望

2008年小结,我想,我就从这里开始

2010年1月2日晚:我的2009

新年快乐,2010年小结

2011的最后一天

2012过去了

我的2013

2014完(个人年终小结)

2015小结,2016,继续向前

2016-2017,盖个时间戳

2017-2018,盖个时间戳

转眼2019,感觉这个时间戳会一直盖下去。

2018回顾。

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

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

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

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

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

2019的一些想法。

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

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

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

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

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

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

__________

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

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

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

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

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

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

先复习一下相关类比。

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

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

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

一趟车:一个迭代。

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

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

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

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

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

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

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

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

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

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

你还能想到什么类比?

__________

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

 

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

PRD怎么写?

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

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

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

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

第二,问How之前先想Why。

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

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

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

第三,思考用户动机。

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

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

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

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

__________

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