2.3.9之后会改成2.4.0吗？产品版本号是如何确定的？什么时候再增加一个？每当产品更新时，您是否也有这样的疑问？本文作者根据工作中项目实践的思考，结合案例，分享了产品迭代过程中需要注意的要点，供大家参考和学习。

随着互联网行业发展越来越快，每隔几天大更新、一直小更新的产品越来越多。然而，我们经常看到一些公司的版本管理混乱。有一次，我的一个程序员朋友告诉我，他工作的公司根本不明白什么是版本。修复bug、更新弹窗都算版本更新。上线1个月后，APP版本更新至2.3.0。

刚开始听说这件事的时候，我以为是个笑话，但后来发现，这种情况其实并不少见。

常识类概念

常见的版本号命名规则

这里我跟大家简单说一下常见的命名规则和版本类型。

大多数情况下，常见的版本号由三部分组成，即X.Y.Z。我们使用1。当X为0时，我们默认进入开发或测试阶段。当X增加1时，我们将清除后面的Y.Z。我们用Y来表示功能更新。同样，当Y增加1时，我们也会清除后面的Z。Z表示小修改。例如，如果我们修复错误或更改页面的UI 布局，则会添加Z。然而，当Z等于10时，我们不将其增加为Y，而是写成X.Y.10，后续更新将是X.Y.11。

不同的项目也会有不同的命名规则。这里只分享一种通用的命名规则，并不代表全部。

除了版本号之外，还会有一些修饰词，如： alpha：内部版本beta：测试版本rc：即将作为正式版本发布lts：长期维护

作为一个产品，我经常希望每个人都使用名词并用人性化的语言说话。然而我身边总有一些人会说缩写，从不说中文，以表明自己是互联网老手。为了防止新人被这些俚语吓到，我们简单扩展一下。

思考阶段

首先，作为一个产品，我们往往要负责功能和项目的调度。当大家都在小步快跑地打造产品时，如果一个产品对版本管理有深入的了解，可以省去很多麻烦。

在版本开发之前，我们需要计划好这个版本要做什么。这将使我们知道需要多少人力以及完成该计划需要多长时间。

在开发一个版本的时候，我们需要明确这个版本要重点解决哪些问题，要达到什么目标。这将使我们有一个共同的目标和明确的重点。

版本开发完成后，我们需要明确需要关注哪些数据，上一个版本出现了哪些问题。这对于我们验证需求会有很大的帮助。我们必须开始思考下一阶段我们应该做什么。

很多时候，作为产品经理，我们习惯把产品当作自己的孩子来对待。这是一个好的心态。那么作为父母的我们应该更多地了解我们的孩子在成长的哪个阶段应该是什么样子。我们不能要求一个小学生学物理、化学，也不应该过度，推翻潜力。

这里我提出几个问题供大家思考：

一款电商新产品上线一个月了。有操作同学提出需要通过用户登录获取优惠券。计划在一星期内推出。这合适吗？

该电商产品后台工作人员提出要求，表示上传图片时的操作流程有点繁琐。他们希望能够一键上传多张图片，并希望能够尽快解决。在开发人力不足的情况下，是否应该尽快将其列为重中之重？解决？

有一天，你的老板告诉你，一款竞品最近发布了电商直播功能。他希望我们研究一下，尽快拿出来。我们是否应该抓紧时间实施这个项目？

1. 版本目标

这些情况可能很常见。作为产品，我们每天都面临着来自四面八方的需求。每个提出需求的人都希望自己的需求能够尽快得到解决。这时，我们就会感到左右为难。我们觉得我们不是在主导这个产品，而是成为了一个需求工具。大多数成长起来的产品经理都会经历这个阶段，并摆脱困境。做了很多需求之后，形成了自己的需求分析方法论，也解决了和老板、团队的沟通问题，从而取得了更好的效果。执行能力。大多数产品都陷入了两难境地。他们大多在方法和沟通上都或多或少存在问题。

在版本管理中，我们在进行版本更新的时候，应该尽可能明确更新的目的，建立一个共同的目标。

数据分析中有一个很常见的模型叫做AARRR模型，也就是我们常说的盗版模型。它由五部分组成，获取用户（Acquisition）、激活用户（Activation）、提高留存（Retention）、获取收入（Revenue）、自我传播（Referral）。在互联网思维越来越成熟的今天，这种方法适合大多数人。场景。

在这个经典的数据模型中，我们将整个目标分为五个部分，这五个部分相互依赖，形成一个循环。这些吸引新用户、促进活跃度、留住人的概念似乎是运营方向的问题。这里我们仅根据数据来讨论它们。成功的产品往往有两个特点：不脱离用户需求、不脱离数据迭代。

这里我们简单提出一下盗版模型中需要关注的一些数据以及这些数据将如何指导我们的迭代。

（1）获取用户就是我们常说的吸引新用户，通常涉及用户注册、下载、关注等行为。我们经常将新用户的数据作为考虑因素。任何产品推出时都无法避免这一步，新产品将持续伴随整个产品生命周期。一般我们在核心功能刚刚推出并满足之后，就会重点关注和优化用户的注册路径，甚至通过不断的挖掘来获得数据优化需求。

案例：回顾一下新浪微博最初的注册流程，我们需要绑定手机号、身份证，首次注册时需要输入账号密码和保密邮箱地址等，不难发现在隐藏在后台的数据中。由于这些信息比较繁琐，很多用户注册到一半就跳出了页面。随着版本的不断迭代，今天我们只需要输入账号和密码即可注册。只有当我们需要使用核心功能时，才需要绑定手机号、身份证等相关信息。此次更新无疑大大降低了用户的运营成本，更容易获取用户。

（2）激活用户也可以理解为我们常说的激活，一般是根据用户的在线时间、与其他用户互动的频率等数据来考虑的。在以内容为核心的社区产品中，初始用户活跃度至关重要，甚至可能对产品未来的发展产生长期影响。

案例：抖音最初版本上线时，吸引了很多大学生通过各种渠道录制作品。其中大部分是音乐学院、表演系等颜值出众的年轻人，这些用户的活跃和推广，给抖音在用户心目中留下了高颜值用户群体的印象。

回顾我们前面提到的第一个问题，一般情况下，新产品上线一个月左右，运营的重点一般都会集中在吸引新用户上。签到功能通常会提高我们的保留率。效果可能没有那么强。

(3)留存是指一段时间后有多少用户留存。一般用户还是以月、周、日的时间维度作为数据考量，也就是我们常说的DAU、WAU、MAU。

案例：留存在一些社区和游戏行业是一个非常重要的指标。当一款产品的用户留存率越来越低时，即使引入了新用户，仍然很难摆脱冷清的局面。据王者荣耀数据显示，非长假期间用户留存率会下降。为了抢占用户时间，促进留存，经常会发布签到获取皮肤、钻石币等任务活动。

(4)获得收入一般理解为变现。我对这一步的理解是，不仅开发者可以实现收益，用户也可以在这一步获得收益。

案例：为了更好地促进用户创作优质内容，知乎新增了付费问答等功能。这些功能让用户有更强的动力继续输出内容，也给平台带来了一些收入。

（5）自传播是指用户可以自发地向周围的用户推荐我们的产品。

案例：拼多多采用团购模式，让用户获得折扣和优惠，同时进一步激发用户与周围人分享的动力，增强产品本身的传播力和用户贡献度。

明确了版本更新的目的和目标后，我们应该清楚大部分功能的优先级。

2. 版本中的需求优先级

在做版本管理的时候，我习惯把需求分为5种。

（一）关键需求

一般情况下，我们会把这个需求优先考虑为P0。未能完成这个要求将导致整个版本无法正常上线，或者前功尽弃。

这里以一个全新的电商产品为例。一般来说，电商购物APP一般的关键需求包括支付和订单需求。

（二）跟进重点需求

这个要求一般不会影响之前项目的进度，但如果不满足，后续版本将无法正常上线。

案例：电商购物产品计划在1.1.0版本推出用户积分，用户根据消费金额累积积分。那么在1.0.0中，用户完成的订单记录是一个关键的后续需求。如果没有这些记录，我们将无法计算用户获得了多少积分。

（三）后续重要要求

这种需求一般会影响用户体验或者项目人员的工作价值。如果不满足，就会导致用户“逃跑”或者同事去逛街。

案例：该电商产品1.1.0版本如期上线用户积分。运营商原本计划让用户用积分兑换优惠券。此时的需求是后续的重要需求。但在此版本中不可用。看到积分没办法消耗，用户觉得产品在“耍猴戏”，于是纷纷逃离。运营商因为无法完成KPI而与产品发生争执。

(4) 改进需求

这个需求一般不会影响现有功能的使用，如果实现的话就更好了。如果不这样做，可能会导致用户满意度下降或同事的成就感下降。

案例：经过运营同学与产品的一次亲密会面，优惠券功能的开发紧急完成并上线。因为当时需求太迫切，UI同学觉得之前的设计有点粗糙，所以优化了积分和优惠券的交互，精心设计了一个更加美观的页面。这时，更漂亮的页面、更好的交互体验就是改进要求。

（五）可选要求

这个需求一般是一个想法或者是一个需要验证的需求。大多数情况下是探索和实验，或者是个别客户的需求。

案例：在优惠券上线后的用户调查中，一位核心用户表示希望增加优惠券的获取方式。此时，该要求是可选的。

回顾我们谈到的第二个问题，这是新产品常常感到困难的地方。在同理心模式下，我们考虑到目前后台人员的工作确实有点繁琐，会影响后台学员的工作效率，是一个应该解决的需求。另一方面，开发人力不足，各种需求和进度让我们不堪重负。前台、后台的需求源源不断地涌进来，看到开发同学的头发稀疏，实在是让人难以忍受。这种情况是一个比较复杂的事情。我们会从几个角度来考虑这个问题的优先顺序。首先是背景学生在当前情况下能否保质保量完成任务。该需求是现阶段的关键需求还是后续需求之一？

3. 快速迭代

前面我们讲了产品经理的各种技能，我们也讲一下产品经理的道。很多成功的产品往往被称为有灵魂的产品，比如乔布斯的iPhone、张小龙的微信、雷军的小米、罗永浩的锤子、王时木的网易云。这些产品在一些细节上都付出了努力，甚至展现了他们对产品乃至人性的思考。

很多时候我们的需求方可能不仅仅只是用户和运营，有时也来自于老板。既然如此，我们也必须把老板视为我们的用户之一。面对这个用户的时候，我们也要思考用户需求背后的动机和更深层次的需求。比如老板会对这件事有更多的资源或者长远的规划吗？

关于如何解决老板的需求，网上有各种讨论，这里不再赘述。综上所述，大多数方法都是采用MVP模型来进行产品开发。 MVP模型是指可用的最小产品模型，旨在以最低的成本满足核心功能，进行市场试用。说到这里，大家都有一个熟悉的产品迭代记录——微信。

今天打开微信，我们发现一切都可以在微信上完成。我们可以订机票、酒店，给女朋友报销，不用和女朋友一起逛街，甚至可以拉黑女朋友，让朋友帮忙推荐新女朋友……回想微信的第一个版本，那是当时很简单，只有两个功能，发送消息和图片。

今天讨论的是微信的各个版本。这背后，我想提醒大家，不要忘记时间。微信第一版发布于2011年，经历过移动互联网从2.5G到3G甚至4G的老前辈一定还记得那个互联网竞相圈地的时代，只要推出一款产品，就会有用户。

有很多老产品都会告诉新人不要等到产品完美了才推出。从来没有完美的产品。我完全同意这一点，但是我们需要正确理解一个产品在什么情况下是完美的？我们知道产品经理行业并不是一个很古老的职业，尤其是在当今的互联网环境下，每个人的学习路径都不一样。我曾经询问过几位新产品开发人员，发现他们读过的书都出奇的一致，掌握的方法和理论也非常相似。这可能是一种非常安全的制作产品的方式，但是好的产品确实需要创新，制作产品的方法也需要与时俱进不断迭代。

4. 精益迭代

过去10年，我们见证了互联网的快速发展。用户习惯越来越成熟，用户品味也越来越精致。试想一下，如果你今天看到朋友发布的照片或视频，但此时你无法点赞或评论，你还会认可这个产品吗？

MVP 模式是尝试市场的合理方式，但它可能并不适合当今的所有产品。比如Twitter刚推出的时候，用户体验就已经很完善了。近年来涌现出不少黑马产品。随着淘宝场景的升级，拼多多找到了渗透下沉用户市场的方法。在播放器软件成熟的时代，网易云以极致的用户体验走出了一条路。这些实际上都是长尾市场的创新。

我们再回顾一下第三个问题。当老板看到竞争产品具有某种功能时，他本能地回去分析商业模式。这是一个老板的责任。但在电商发展了十几年、直播行业已经非常成熟的今天，大部分用户的需求已经几乎解决了，给我们留下了长尾需求。两个成熟体系和行业的联合创新能否真正通过极简的产品模式来运行，还有待商榷。

随着互联网环境的成熟，互联网产品在各行各业已经形成先发效应。留给我们创造新产品的机会大部分是整合或者差异化创新。

尤其是两个行业融合的时候，我们不能忘记用户的心理路径需要形成一个闭环。比如我们做这个电商直播产品，我们需要知道我们针对的用户是双向的，既包括主播，也包括粉丝。我们的功能也是双重的，即直播和电商。对于直播来说，主播的向上之路极其重要。粉丝打赏、关注和互动功能也是这个产品的基础。

当用户的操作流程已经成为一种习惯，用户的心智模型已经建立起来的时候，即使是极简的，我们仍然需要为用户提供完整的入口和出口。

5. 趣事分享

这里还有一个有趣的事情我想和大家分析一下。说到版本和迭代，肯定还有一件事情困扰着产品。当我们推出体验更好的新版本时，如果用户不愿意下载更新怎么办？

你还记得微信上的飞机大战吗？

2013年8月，微信更新版本至5.0版本。该版本增加了绑定银行卡、表情商店等重要更新，这也意味着微信正式开放了一些与支付、充电相关的功能。为了尽快测试版本的一些重要目标数据和用户反馈，产品一定非常希望用户尽快将版本更新到最新版本。

回望那个时代，我们经常遇到的应用版本更新有哪些？当时几乎都是更新完就立即关闭，甚至后来的更新也很少见。在不更新就崩溃的时代，微信用极其优雅的姿态说服用户主动完成更新——飞机大战。

微信作为一款社交产品，当时拥有巨大的用户优势。微信利用了社交产品中用户的求胜欲、好奇心等心理，巧妙地让用户帮忙推广了本次版本的更新。

还记得那天，朋友圈里突然出现了无数人发布了自己的飞机战斗记录，于是大家就因为这种用户交流而主动更新。

同样，微信在更新小程序时也推出了跳一条，再次引发朋友圈和更新热潮。

最后的一点思考

迭代产品需要考虑的因素有很多，比如当前的互联网环境、用户习惯和口味、用户群体的特点、自身的技术实力等等诸多因素。在产品本身根据时代和环境不断迭代的今天，产品经理自身的方法和思维也需要不断更新和迭代。

如何快速推动需求，是产品之间永恒的话题。这里我总结了一些经常导致我们项目进度缓慢的原因。

接受任何需求

未能正确确定需求的优先顺序

与需求方或开发商没有良好的沟通。

未能安排好版本的重点

不确定产品何时推出

对于新产品来说，上述问题可能很常见。希望大家提出一些建议，少走弯路、少走坑。最后附上这篇文章的笔记。