我的从 0 到 1 产品路

2016-12-08 10:29:00

“我之所以还能够对未来充满信心，是因为我相信从0到1是一件尽管艰难但是有意义的事情！”

不久前，我在日记本里记下这句话来鼓舞自己，从2015年开始到2016年底，为了实现产品从0到1，我几乎爬过了数不胜数的坑。我把它们记录下来，希望同行看到后引以为鉴，也希望能够从这些经历中总结出一套普适性强一些的方法论来。

如果你还没有准备好，请不要勉强答应

2014年8月，我来到现在的公司，以实习生的身份，公司成立刚好4个月。初来乍到，我的工作任务是打杂，没错，哪里需要我，我就去哪里。客服，项目助理，运营人员等等，3个月内，我基本上把公司里所有的能接触的活儿都做了一圈（那会儿体力真好）。当时还没有毕业，觉得自己是有无限可能性的，职业规划这个事情，那个时候是没有什么概念的。

转折点出现在2015年初，公司渐入佳境，准备要做一个APP产品，所以就开始满世界找合适的产品经理。如果大家有经历过，就应该知道一个又靠谱又便宜的产品经理有多难找，招人的工作非常难以进行，最后老板想了想，任性地决定让我顶这个缺。其实也不能说找我顶缺是件完全没有根据的事情，因为我大学是学计算机专业的，12年的时候有去实习写C++，14年初又去实习过需求分析师，不管怎么样，整个团队里，我的过往经历和产品经理的属性相对是最匹配的。

“这是个挑战，但是这种掌控不了的事情，听起来还不错”。我立刻就答应了，生怕老板反悔。

接下来我面临的尴尬境地就是，居然没有人可以指导我如何做产品。那个时候的产品开发是交给一个外包团队进行的，因此也没有开发人员可以来告诉我他们目前的项目进度。最可怕的事情是作为产品的负责人，一开始很多时候我对自己下的决定都表现出一种不肯定和不自信，身份的转变也并不能让我迅速适应这种转变带来的一系列其他影响。一个基础为0的产品经理和一个基础为0的团队以及一个基础为0的产品，我想这也是非常少见的吧。

我开始后悔接下这个活儿，但是这个自己给自己挖下的坑，含着泪也得往下跳啊。

产品从0到1，最需要判断力和执行力

产品经理要做什么，具体怎么做，那个时候我都不清楚，我唯一知道的是，整个产品是由我来负责的，有一句话说，明白许多道理但还是做不好自己，足以形容这种窘境。

由于外包团队在西安，而我在上海，很多时候沟通成了一个最大的问题，我往往很担心我提出来的改进到底执行了没有，到了哪个地步。一开始我会以一天一更新的方式来要求开发团队每天生成一个测试包发给我，但是很快发现一个问题，就是问题太多根本改不完，我加入的时候交付时间就已经非常紧张。有经验的产品经理其实已经看明白，这个其实就是需求管理，我们需要从数不清的坑中选一个最致命的来填。稍微明确了下现状后，我调整了一下沟通方式，每天晚上我会拿到最新的测试安装包，然后赶紧测试，测试结果写成excel表格，我暂时叫作buglist，这就是我的第一个需求管理文档了。我在buglist中规定了几个简单规则：1.写清楚bug；2.标明bug的优先级；3.规定交付截止日期。远方的开发团队拿到我这张buglist后，可以按照他们的分工来分别解决问题，每天交付给我的安装包，修复情况也是按照交付截止日期里的规定来执行的。这里面有一个无法被避免的问题，那就是有很多bug，我明明确确地知道，是无法在规定时间内修改完的，能做的只有砍掉它们，心无旁骛，把最核心的事情做好。

这段经历使得我一直认为，产品经理更多时候是一个承担责任的人，想要担得起这个责任，抛开专业性不说，判断力和执行力是最重要的。

身为产品要重视结果，但是身为经理要重视流程

产品如期上线，当然问题还是很多但有了喘息之机。经过前面的项目外包经历，老板也意识到，如果真的想要好好做一个产品，不能依赖于外包团队，所以开始自己招开发团队。几个月内我们组建了一个集UI／产品／IOS开发／安卓开发／后台开发为一体的小团队，可以说是麻雀虽小五脏俱全。

于是我们马不停蹄地开始对产品进行迭代，因为之前赶进度我砍掉了许多需求，现在我认为总算可以把这些缺憾弥补起来。我把我的想法和老板沟通后他表示同意，但是在和开发团队进行沟通时我却遇到了一些麻烦，因为团队刚组建，我们的很多工作都还是基于各自以往的经验，在相互沟通的过程中总有尴尬和不到位的地方。正是因为这些零零碎碎的磕磕碰碰，让我原以为可以很快执行好的需求，总是遇到延期和执行不下去的问题。

我深知自己的专业度是不够的，所以决定从两个方面来建立新流程，一是基于团队成员以往的工作习惯，二是参考目前常用的开发流程，当然，根据我们的实际情况，会有一些调整。

小团队，所有工种就坐在离你不超过5米的范围内，沟通基本靠吼，尽管如此，也还是得有自己的章程。为了方便大家理解，特地把我之前写的产品部门工作手册截图展示下。

产品部门工作手册截图

篇幅有限，所以简单介绍下流程：

1.产品调研

2.产品立项&原型

3.UI设计&交互设计

4.UI效果图验收

5.技术方案设计&排期

6.产品功能开发

7.测试

8.产品打磨&验收

9.发布上线

10.数据跟踪&迭代

这里没办法和大家详细介绍每一个流程中的工作细节，因为那是因人而异各有所长的，就不在此献丑了，想给大家分享的一点是我们实际工作中的沟通方式。前面图中其实可以看到，产品定下需求后会出一个原型，务必强调核心功能点和逻辑合理性，画原型的工具有很多，一一尝试后我还是选择使用老牌的axure作为主要的工具（原因后面会讲到）。然后就是拉着技术和设计来开会讲解需求，我一直相信专业的UI和技术在很多时候可以给到很好的建议来避免一些坑，这个会开完以后，技术（后端／前端）基本上可以理解需求中涉及到的数据逻辑，而设计也可以明确原型背后的实际需求。

接下来做的这件事情，我认为非常重要，那就是做排期计划。

UI这边会按照低保真原型（如果团队有UI的话，尽量不要做高保真的原型，这样会限制UI的发挥）来出效果图，每个设计师习惯用的工具都不一样，photoshop和sketch都是不错的工具，其中sketch的使用门槛比较低，我建议产品经理也可以学习一下。一般来说，UI同学花1～2周的时间就可以完成一套完整的UI效果图。

技术这边，前后端的同事会分别按照需求提到的功能点做任务拆分和时间排期，这是负责后端的同事带来的方法，叫做时间片管理。把需求中的功能点尽可能拆分成一个个任务片段，给每个任务片段分配时间（story），一个story差不多是2个小时。开发的同事可以按照story来分配自己的工作时间，平均1天可以完成3～4个story是比较合理的速度。有了这个方法，所有人都可以量化自己的工作成果，做出来的排期也相对比较合理。

与此同时，我会着手撰写产品需求文档，将包括页面交互，全局变量，用例图，排期等都写到文档中以便团队成员共享。很多人喜欢用word来写需求文档，但是鉴于个人的使用习惯，我还是会用axure来写文档，一来方便共享和修改，二来也便于将前面画的原型直接写进来，大家就不需要存很多文档了，前前后后只用到这一个。使用axure画产品需求文档的方法比较多，也不在此多做介绍了，大家嫌麻烦的话可以直接找我要模板。

产品开发验收上线后，有一个特别考验产品功力的就是数据分析了，做数据分析肯定得要有数据来源。有的团队会自己在产品开发过程中就埋下一些监测点，建立数据模型，通过后台来观察。我们的情况是产品正常开发周期都已十分紧张，所以干脆接入了“友盟”来协助开发埋点和生成数据报表，好处是开发成本小且可视化效果好，缺陷是有时候不够准确（这是统计规则不同的原因）。

到底是产品成就运营，还是运营成就产品

作为一个自认有产品经理坚持的人，我始终相信产品内在的自发传播性，也就是说真正的好产品一定能在某个人群中找到它的存在价值。但是在现实中我也常常见到过很多内在品质不错的产品，但是奇怪的是身边都没有人在使用它们甚至不知道它们。这也是为什么这个命题会存在，如果产品不好，运营工作很难开展，如果运营不好，产品就很难找到用户，也很难存活下来，这叫“酒香也怕巷子深”。

对从0到1的产品来说，其实“活下来”是件比啥都重要的事情，这就决定了在产品设计之初，切入需求的时候，就得充分考虑产品存活难度，过度依赖运营规模的产品，其实严格来说不太适合资源不多的小团队来做。所以，认准一个核心需求点，排除万难，顺便排除掉一些不切实际的想法，从产品的角度考虑问题，还得从运营能力的角度来评估，这也是为什么产品经理不是一个所有人都能做的岗位。因为你不仅仅是一个产品经理，你还得是一个运营，因为如果连你自己都没有办法做好运营的话，也请不要指望其他高人能帮你把这件事想清楚，你的产品，没有人也不应该有人比你更清楚。

所以，如果你正在做一个产品从0到1的部署，我会诚挚地给一个建议：无论排期计划是多么紧张，无论人手有多么的不足，也请先将产品运营规划考虑到整个版图中，因为在大多数情况下，找到你的用户并用一个点子吸引他们，比完成你的产品更重要。

你可以不看书，但是你不能不学习

最后说一点，是关于产品经理的自我修养。大家都知道产品经理这个职业，属于自己个人的时间真的非常少，很闲的产品经理严格来说是不够称职的，因为一个产品要操心的事情真的很多。尽管如此，我希望大家可以养成不断学习的好习惯并将此作为自己职业生涯的技能之一。学习能力，很多人有，但是自我约束力大部分人没有，而产品经理如果不能很好的和时代潮流，市场环境保持一致甚至领先的步调的话，很快就会被其他更会学习的人超越。学习的方式，很多人都说要看书，我现在也开始恶补许多，是为了强化自己的系统性，但是从实用性来考虑，网上也还有许多碎片化的知识，善于归纳总结筛选信息的同行们也可以在网上找到适合自己的学习方法，互联网产品经理这个职业出现并不算久，很多东西也没有非常标准化，希望大家能够共同进步，思考，分享。