经手了很多0-1的上线项目，但是发现很多创业者，特别是跨行创业者在开始都规划的很美好，但是在产品上线之后却没有任何所对应的准备，以为产品上线了就完成了工作了，最后发现产品没有用户使用，然后项目关闭。所以今天本篇文章就和大家讨论下当产品上线之后我们需要做哪些工作。
1. 验证需求（场景、使用频率、数据埋点、是否解决痛点）
当我们做某个产品的时候肯定是考虑清楚了用户在某个场景下遇到某个问题，然后使用我们的产品来解决某个场景下的问题，当我们产品上线之后我们第一个需要验证的就是我们的产品是否真实的解决了用户的问题，如果真实的解决了用户的问题那么是否还可以进行优化？如果未解决问题，那么问题出在哪里？因为我们的产品存在的意义就是解决在某个场景下遇到的问题，如果我们的产品并没有帮助到用户解决问题，那没有存在的意义，我们这个产品基本等于没有，用户肯定是不会使用的。
当我们产品解决了用户的问题之后我们还需要查看用户的使用频率，查看用户的使用频率是否和我们的预期是一致的，若一致则证明我们的产品思路是正确的，但是若不一致则需要考虑在那个环节出现了问题，用户的使用频率降低是因为什么，是因为使用成本？还是学习成本？或者是其他方面？然后我们考虑怎么去解决这些问题是通过优化产品？还是运营手段？而这些是需要通过数据埋点来进行实现的。
数据埋点在初期有很多需求发起者是不在乎的，认为没有这个必要，用户就这么少，直接就能看出来了，不用这么麻烦。但是，没有数据的看和有数据的看是有很大的偏差的，甚至可能造成方向上的问题。因为没有数据的看是夹杂着个人主观或者集体主观意识的，大多根据经验和自身利益的出发点来感知。而有数据的看是客观的，是通过产品的使用用户真实的操作反馈，然后进行分析，更加的准确。我们每一次的运营动作，每一次的文案引导动作通过数据都能够真实的反馈。用户在使用我们产品的时候在哪一个环节遇到了问题然后跳出流失，在哪一个页面停留时间长但是没有进行设想中的操作，通过一个个数据和操作反馈很清晰的得到我们的产品真实的使用情况，然后有针对性的解决问题并作出版本迭代规划。
关于需求验证部分，我们产品存在的价值就是解决用户问题，当我们产品无法解决用户的问题，也就不用考虑商业变现，快速增长等问题。如果我们上线不能快速验证是否解决用户的问题，那么有极大概率给我们造成损失，如果能及早发现问题，我们也可以快速止损，避免用户流失。
2. 收集反馈（被动收集（应用自带入口、微信入口收集、邮件收集）主动收集（用户调查问卷、电话访谈、面谈））
刚上一条说到了使用数据埋点来进行收集数据从而加以分析埋点数据是通过用户的无感知的操作来进行收集，范围广，但是也会有一些缺陷，就是当用户量过于少的情况下，收集上来的数据不具有代表性，所以这个时候需要结合用户的主动反馈来辅助分析。
用户反馈的收集渠道有很多，从广义上分为了被动收集和主动收集。
2.1被动收集
通过应用上自带的“用户反馈”来使用户主动填写，该入口有很大的劣势和优势，通过该入口反馈的信息大多具有较强的主观意识存在，需要花费较多的精力进行晒别，这是劣势。优势是通过该入口给予反馈的用户基本是我们的种子用户，他们乐于给我们提出建议，使我们更好的解决他们的问题，当我们解决了他们的问题之后他们会成我们产品忠实用户，帮助我们宣传产品。
微信上的反馈入口我们也可以利用起来，这个入口是很多人所忽视的，例如通过微信公众号留言或者微信客服账号，因为微信基本是用户最经常使用的产品，用户通过微信来给我们反馈会让他降低陌生感，给予最真实的感受反馈。同时用户关注我们公众号或加我们的客服微信也便于我们后续做用户运营，我们可以通过多种手段来触达我们的用户，加强用户感知，提升用户粘度。
邮件反馈更多针对的是有海外用户群体的产品，毕竟海外用户使用更多的邮件，通过邮件反馈内容也会更加清晰，我们也可以更高的和我们的用户进行沟通。
2.2 主动收集
用户调查问卷，我们可以通过产品内部的宣传位置来进行主动的用户调查问卷，调查问卷首先要预设好我们调查的目的，然后罗列出达到该目的需要询问那些问题才能获取，最后发出该问卷进行收集，必要的情况下或者涉及到用户抵触的例如用户隐私信息的可以设置一些小的奖励促使更好的用户完成该调研。
电话访谈是最直接有效的，目前大多产品的用户注册验证策略都是通过手机号短信验证，我们可以直接获取到用户的手机号，但是该方式会有一个很大问题就是对用户产生骚扰，有很大的可能使用户产生不安全感，从而造成用户流失。
约用户当面访谈，约用户当面访谈是很讲究方法的，大多是通过组织线下活动的方式来进行，约一批用户参加线下活动然后增加用户的忠诚度，但是当面访谈的时候需要注意避免从众心态，尽可能的进行一对一访谈或一对二的访谈，这样可以避免集体访谈的时候有的用户盲从或者有想法但是与其他用户的想法相反，导致没有反馈。集体访谈收集上来的反馈有很多是伪需求和不真实的反馈，需要仔细斟酌和分析，避免造成损失。
关于用户反馈收集的方式方法和需要注意的事项，用户反馈是公司需要一直做的事情，一线的互联网公司无论多大规模用户反馈的收集一直都在收集，不会间断，这样尽可能的避免闭门造车，也可以通过用户来驱动我们的产品进行迭代。
3. 排列版本迭代优先级（功能流程性问题严重影响使用、重要且轻需求可以快速验证、重要但重需求、页面优化、非重要且重需求）
我们验证了需求，查看的数据，收集了反馈，会发现会有一堆的事情需要去做，那么如何去进行迭代优先级排序是一个很讲究的事情，很多公司就因为迭代优先级排序错误从而造成了极大的损失，有用户流失，有数据暴跌，有停止增长等等，而造成这些问题的大多是因为公司内部部门互相争抢或者产品方向不明确。本节阐述下个人在实际产品工作中关于迭代优先级排序上的一些理解，版本迭代优先级有一个前置条件就是首先我们的产品可以解决用户的需求痛点，如果我们的产品无法解决用户的需求痛点，那么也没有存在的价值，建议尽早关闭或调整方向，越早关闭或调整越早减少损失。
3.1 最高优先级 功能流程性问题严重影响使用
最高优先级就是我们产品功能流程出现严重的问题，当产品出现功能流程问题的时候需要立即进行规划和修正，因为如果不尽快的进行修正用户会发现使用起来难度很高，或者根本无法使用，从而放弃，造成用户流程，且挽回成本巨高。
一般当出现功能流程问题，建议3天内解决，若3天内无法解决那么将再次进行拆分，快速的有针对性的迭代验证，让你的用户能够感知到你在优化，对产品保持希望。
3.2 高优先级 重要且轻需求可以快速验证
当我们收集了大量的用户反馈后，肯定会有用户提出一些核心诉求之外的其他需求，当我们产品主流程没有出现问题的时候，这个时候因为产品刚刚上线，正在快速验证期，方向并不固定，所以当出现多个用户反馈同一个诉求的时候，然后该诉求复杂程度不高，验证起来成本极低，那我们我们可以快速的有针对性的对该需求进行规划开发和验证，这样极有可能发现一个新的产品增长点，从而拉动产品增长，再不济也可以使提出该需求的用户群体提升忠诚度。
关于轻需求的验证我们各个公司和团队的标准不一致，我之前定义的标准是3天内可完成开发上线的需求为轻需求，0.5天产品规划，0.5天评审，1天设计，1天开发然后上线，根据团队的配置不同可最多延长至一周，但是不能超出一周。
3.3 中高优先级 页面优化
页面优化这一部分根据产品的有着很大的关系，如果你的产品定位是高端用户，那么建议该条优先级提升至高优先级，这样可以聚拢用户，契合用户的风格。但是大多的产品定位并不是高端用户，那么建议该就优先级为中优先级，团队的核心还是围绕着主功能流程来进行，当主功能流程没有问题之后在回头优化页面和打磨产品。在解决用户核心问题的同时增加新鲜感，保持用户的活跃度。
3.4 中优先级 重要但重需求
与3.2一样，在我们完成用户反馈收集之后，里边也会掺杂这一些新的需求，但是该需求实现起来特别复杂，投入成本过高，那么建议先不要做，我们产品刚刚上线，需要做的是所有资源尽可能的围绕着主核心功能流程来进行倾斜，其他的新需求都可以暂时记起来，等到后续主核心功能流程没有问题之后在进行考虑，避免团队精力分散，导致产品成了大而全，但是没有核心特点和重心。
3.5 轻优先级 非重要且重需求
该条恰恰与3.4相反，但是该点是很多公司和团队遇到问题，把极少部分用户的反馈当成了重需求，然后花了很大精力和成本进行了验证，但是上线后发现没多少用户使用。所以遇到该类需求需要验证的有多少用户使用，如果只有2%的用户进行使用那么就不做或者等到整个产品趋于稳定后在考虑该需求，我们的产品只需要满足98%的用户就足够了，不可能存在100%满足所有用户需求的产品存在，极少部分的用户群体我们还是需要暂时放弃的。
关于在实际的产品规划工作中所用到的版本迭代优先级的排序具体定义，只有我们定义好了版本迭代优先级之后我们的团队才会更有方向感，可以以更小的资源来做更多的事情，当我们团队和产品做的够细致，够认真，用户是真切能够感受到的，他们会一直伴随着我们成长，我们的产品也会更有希望。
4. 发起迭代计划
当我们完成数据调研，反馈收集，优先级排序之后也就完成了我们版本迭代计划，就可以发起内部评审，然后树立我们下一个版本的版本目标，用户遇到了什么样的问题，我们准备怎么解决，可以给我们带来什么样的价值。随后就可以发动团队进行开动，快速按照版本计划完成既定目标，然后上线进行验证。
以上就是关于我个人在产品上线之后关于围绕着我们产品还需要做的一些事情，希望能够对你有所帮助，也欢迎留言沟通。
