下面结合上图豆瓣时间功能的版本更新记录对上述4点方法论进行一一说明。上图中罗列出了从豆瓣时间功能上线至今的所有版本更新日志(更新日志只选择了豆瓣时间的更新内容，并未对豆瓣其他功能的更新进行说明)。

　　1.核心功能优先

　　可以看到，豆瓣时间上线的第一个版本主要做了知识产品的展现、购买支付和专栏内容学习，完成了用户选择、支付、学习的主要业务流程。同时，产品在第一个版本并没有做专栏内容的下载功能，并且在后续才加入了图文类型的专栏内容，早期版本仅上线了音频类的付费专栏产品。

　　2.辅助功能完善

　　在完成核心业务流程对应的功能后，豆瓣时间开始加入辅助功能，如支持专栏内容下载、上线图文专栏产品，支持专栏下留言。同时针对产品的运营需求还上线了专栏赠送功能。

　　辅助核心功能的相关功能以及周边功能，都是在产品核心功能上线并且打磨出具成效后迭代上线，在早期产品版本中优先打磨核心功能。

　　3.业务流程优化

　　通过版本更新日志的分析发现，豆瓣时间功能上线后主要对音频播放、支付流程进行了优化，其他细节的优化内容并没有在更新日志中体现，所以这里也不得而知。但是通过分析可以发现，功能上线后，产品团队一直在对业务流程以及对应的功能进行优化，逐渐打磨成用户满意的功能。

　　4.用户反馈跟进

　　通过对版本号以及版本更新日志的分析发现一件有趣的事情，首先我们都知道产品经理在做版本规划时如果涉及功能或大的更新，会使用如4.14.0,4.15.0的跨度，涉及bug修复或者小功能更新时会使用如4.14.0,4.14.1这样的小跨度。

　　在豆瓣时间上线短短五个月，出现了5次bugfix，每一次都在新版本刚上线不久就紧急发布了下一个版本。通过对对应时间段的用户负向评分评分反馈分析发现，豆瓣的每一次紧急版本更新都伴随着大规模的用户闪退反馈。

　　从这一点可以看出，版本更新频繁出现bug，不能仅仅怪罪于程序员，这与产品、测试和研发都有关，对于团队的协作模式也需要进行一定的反思和复盘，减少bug出现而造成的版本更新。

　　四、豆瓣时间的一点思考

　　借助现有核心功能，打通豆瓣生态

　　通过对豆瓣时间的需求、功能、版本规划复盘以及对豆瓣产品的体验，豆瓣时间这一功能上线时间较短，还有很多发展方向可以探索。这里仅仅是笔者的一点思考，就是借助豆瓣自有生态，将现有核心功能与豆瓣时间打通，形成更大的生态体系。

　　1.豆瓣时间+豆瓣小组

　　豆瓣小组是豆瓣用户群聚集地，用户在豆瓣小组通过一个个专题小组进行发帖、回复和评论进行用户互动。如果豆瓣时间可以像得到APP一样，将豆瓣时间上的专栏与对应的豆瓣小组之间建立通道，相信可以提升订阅专栏用户的活跃率，同时通过豆瓣小组进行一定程度的拉新。

　　2.豆瓣时间针对影音乐细分和链接

　　在文章开头就提到了豆瓣的核心功能就是影音乐内容：豆瓣图书，豆瓣电影以及豆瓣音乐三大主要模块。如果豆瓣时间的付费专栏可以细分到三大类别，并且在与三大模块的内容进行链接，那么相信会有一定的发展。如在豆瓣读书模块中，用户在寻找想读的书籍时，可以发现豆瓣时间中的读书专栏，通过订阅达到读书提高认知能力的目的。

　　这里可以开一个脑洞，如果你是豆瓣时间的产品经理，你会如何设计，让豆瓣时间这个功能更好的在豆瓣体系当中发展?

　　文/记小忆，产品壹佰专栏作者，野蛮生长的产品经理，运营商大数据产品实践者，擅长从0-1搭建产品经理知识体系。公众号：PM龙门阵。