研究一款产品的版本迭代路线其实是学习一个产品团队节奏的最佳方式，通过对产品迭代路线的分析可以发现产品生命周期中的规划和设计，通过对优秀的产品的复盘有利于产品经理自己在独立负责一款产品时有更多的思路和方向做产品的版本规划。

　　这里先给出豆瓣时间的版本规划方法论：

　　核心功能优先

　　辅助功能完善

　　业务流程优化

　　用户反馈跟进

　　下面结合上图豆瓣时间功能的版本更新记录对上述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. 豆瓣时间针对影音乐细分和链接

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

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