产品经理从零到一做新产品必备套路

最初入行做产品时，在某个门户网站做已经做了7年历史的新闻客户端，成熟的产品同时也是集团公司的门面，自是被集团内各大佬虎视眈眈，更多是集团CEO直接拍板各种跨部门合作的需求，与其说是产品经理倒不如说是需求分析师，拿过老板的需求，分析成可落地的方案并去开发跟进上线。

需求分析师与真正的产品经理最大的差别，便是一个被动承接外部的需求，一个主动引领产品发展方向。后者含金量显然比前者高太多。正是基于个人职业生涯良性发展考虑。当年果断离开门户公司，拥抱人工智能落地应用，并成为一名人工智能（AI）产品经理，先后经历着多个人工智能产品从零到一的搭建。下面分享给大家从零到一搭建产品，产品经理常用的工作套路。

寻找内测用户

这里讲的从零到一做产品，默认是需求已经被验证有市场，基于对市场和客户的了解，开始做MVP版本产品。MVP版本可以完成基础功能，但并不是MVP版本开发出来，我们就能大范围投放到市场上，而是需要有一个内测阶段。

内测阶段通常是一个快速验证产品和打磨产品的阶段，在这个阶段通常会找一些对产品特别感兴趣或者有些许极客精神的用户做内测用户，将MVP产品提供给这些用户，由这些用户实际使用，并将使用过程中遇到的问题，快速地反馈给我们，我们再根据客户反馈做评估，快速调整和优化产品。将产品打磨到没有明显“硬伤”状态，就是进一步扩大推广范围的开始。否则，将一个带有“硬伤”的产品推广到市场上，人力和市场费用都投入了，客户使用一下就不再使用了，用户“用完即走”，得不偿失。

很多公司都会运营一些内测用户，将产品最新功能给内测用户抢先体验。譬如搜狗浏览器就有相应内测群，内测群中都是一群对各种浏览器感兴趣的极客用户，这群用户以抢先获得带有新功能新版本包而自豪，不仅不会因为bug不再使用，还会以将bug提交给官方为荣。搜狗浏览器团队也会投桃报李，逢年过节或举办官方活动，通常都会给内测用户一些实物的实惠，维系住内测用户。甚至某个内测用户大专毕业后，还成了搜狗浏览器的工作人员。

性能问题最高优

我们设计的产品无论是面向C端还是B端，都需要将我们的产品最终推广出去给用户或客户使用。而客户承载产品的设备秉赋各不相同。譬如PC客户端产品有不同硬件性能和实际使用限制，手机APP客户端则受限于手机本身硬件配置、操作系统、手机安装的app，web产品则受限于浏览器引擎、浏览器版本和已打开网页情况。特别是“年久失修”的硬件环境和“杂草丛生”的安装软件列表，即便产品做的非常轻型，仍然会存在一安装产品，设备卡死，用户或客户只能头疼医头，将产品关闭或卸载，从而导致留存率无法保证，卸载率异常高。

当年做新闻客户端时，为了提升留存，花了很长时间优化安装包的大小，诸如删除不必要的插件，将部分非核心的插件采用云端异步加载。这一切都来自于渠道反馈包体太大，会导致用户卸载影响留存。

为什么包体大会导致用户卸载呢？原因就出在渠道团队为了低成本快速铺量，将产品预装在一些山寨机和低端品牌机上，这些山寨机和低端品牌机本身硬件性能有限，连同Android机不断的内存泄漏问题，最终导致用户会优先为了手机可用，将安装包大的app卸载掉，最终影响到新闻客户端的留存率。

当然影响性能问题的原因绝不仅限于包体大小，但产品导致客户终端性能问题，一定会导致产品功能和能力做的再好，都无法保证产品可用的问题。就好比地基被台风吹的晃动，无论高楼做的有多华丽都是徒劳。在从零到一的阶段，影响普遍的性能问题必须最高优先级解决。

产品自debug能力

产品从零到一发布或者成熟期发布后，我们总能听到用户或客户反馈各种问题，但产品一旦发布产品运行在用户或客户的设备上，定位问题就变得困难。

假如是To B业务直接技术和技术之间的对接，再难的问题只要投入精力，总归是有解决办法的，如果对方没有技术能力或者直接是C端小白用户，那么对方是如何不会懂抓包看日志的。

在这种情况下，通常的办法是自己动手丰衣足食，在产品出现异常时，就要上报日志。如果用户含糊不清上报问题时，大可以给用户在产品上留有某些触发器，便于定位用户和产品状态。再极端点，不妨留有后门，可以访问客户问题的关键信息，但安全措施还是要做好的。

当年做新闻客户端时，新闻这类产品是没有强登录需求的，因此大部分用户都不会登录，但一旦出了问题，程序员又必须定位和查问题，为了快速定位问题，在“关于”页面留有debug后门，可以快速定位到用户，并上报相关信息。

debug能力在产品从零到一阶段极其重要，在前期的研发中，主要关注已知晓的问题，未暴露的问题和实际用户使用情况都是未知的，当问题出现时，debug能力可以大大缩短问题定位的路径和时间，相应地，硬伤能够越早地被解决，产品也就越早地能够通过内测阶段，不断走向更大范围的测试，最终全面推向市场。