在谈一个产品的从0到1之前，我们时常提起“1的分类”。本文从“1”的客户需求与内部自研两大分类出发，着重介绍了公司内部的自研产品时，产品经理对这个新产品完整的发展规划和线路布局思路。不失为一份优秀的参考指南，推荐各位产品人阅读交流～

在谈一个产品的从0到1之前，我觉得有必要先谈一下“1”的分类，“1”通常分为两个大类：

一类是客户已经明确的描述了产品所有的需求和功能，产品经理必须按照客户的需求按步开发，也就是我们说的定制/外包项目；

还有一类是公司内部的自研产品，产品经理需要对这个新产品有一个完整的发展规划和线路布局。

如果是第一类的情况下，产品经理只需要在产品的前期中期后期多和客户保持沟通即可。

是的，没错，在做定制/外包项目时最重要的就是和客户保持沟通，前期需要明确整个项目的所有功能以及功能交付阶段，并梳理成文字发给客户盖章确认；中期产品经理需要提前与客户确认产品原型图或设计图，在确认过程中，最好也要以文档的形式进行盖章确认，以避免后期的技术返工；当有独立可使用的模块开发完成后也需要及时让客户进行验收；在后期把整个项目开发完成后，产品经理需要跟进客户进行项目验收，以保障尽快拿到项目尾款。

下面我们主要讨论一下第二类的情况。

一、0的诞生

toB不像toC一样，可以凭空想象出一个点子，然后就能进行下一步了，toB一定是需要先找到一个行业并用心观察和发现这个行业的痛点，然后从这个行业中找到一个目标客户进行原始需求调研，进而验证我们发现的痛点是否是真痛点。在一个产品的从0到1中，“0”作为起步点是最为重要的，直接决定了一个产品的未来。

能不能不用找某个具体的行业直接做跨行业的通用痛点？当然能，只是难度不可相同而语。

二、梳理业务流程

当我们验证确定了上面发现的痛点确实为行业之痛后，也就明确了我们产品的目标及产品方向，那么接下来要做的就是梳理业务流程。

在梳理业务流程时，我们需要将所有的业务流程全部梳理出来（允许遗漏，但主流程不能遗漏），具体的梳理方法是先将业务的主线梳理出来，然后再拆分支线流程，这里拿外贸行业举个例，主线是：

基础配置 -> 商品 -> 采购-> 仓库 -> 销售 -> 财务 -> 报表

然后主线的大模块又会细分出很多支线，如仓库：

仓库管理 -> 商品入库 -> 商品出库 -> 商品调拨 -> 商品盘点

支线也会细分更小的支线，如商品盘点：

商品盘点 -> 盘赢/盘亏 -> 盘赢操作/盘亏操作

这里推荐一个梳理业务流程的物理看板法（即便利贴法），将主线流程贴到最上方，支线任务贴到对应主线任务的下方，在中后期，当有目标任务完成时可用3M的小贴纸标注一下（记得贴在全团队每天进出公司的必经之处）。

（图片源自本人之前负责的一个项目的物理看板，黄色为主线/蓝色为MVP/红色为以后的迭代）

为什么要推荐物理看板，首先全团队/全公司都能看见这个目标，让整个产品的目标和进度透明化；其次是可以刺激团队，让团队来把握产品进度。（当然只用电子看板也是可以的）。

将所有的业务梳理成小任务后，产品经理们还可以做一件事，那就是头脑风暴，风暴的内容就是除了以上任务，我们还可以新增哪些功能？只要合理即可写到便利贴上，不管是否是天马行空，只要是与我们的产品目标有关联即可，往往这个环节可以给用户创造很多“阿哈时刻”。

头脑风暴后，那我们的“1”也基本上成型了，我们需要做的下一步就是叫上研发团队一起评估工时，给每一个任务评估工时需要多少人天（不需要太精确，估大概即可），这一步很关键，因为没有老板会愿意做一个不知道需要多久周期才能完成的产品。

三、提取产品MVP

（图片源自网络）

将所有的任务评估完工时后，可能需要1年或2年完成，很显然我们的客户和老板是不愿意等待这么久的时间，至少市场不会等你这么久，所以接下来我们需要对这些全任务进行MVP提取（注：MVP为最小可行性产品（Minimum Viable Product））

MVP的作用就是让产品尽快的面向市场，尽早的给到客户使用，以便于提早发现问题并及时调整。

在提取产品MVP时，需要注意以下几点：

1. 要保证MVP可用（如果不可用，那就是虾扯蛋）
2. 要保证MVP为痛点中的痛点（否则上线后也无法打动用户）
3. 要保证MVP的用户体验良好（否则试用客户就永久说拜拜了）
4. 要保证MVP足够小，一定要砍掉非必要功能（否则就不叫MVP）

在砍功能时，是比较痛苦的，这里推荐一个方法，就是问团队一个问题：

如果砍掉这个功能，MVP是否能完整正常且友好的使用？

在砍掉大部分功能成功提取MVP后，就会发现此时再上线给客户使用只需要几个月的时间了，说明一下，被砍掉的功能不是直接就丢弃了，而是放到了下一个迭代或以后的迭代再升级。

四、产品持续更新

产品MVP上线后，首先产品经理需要积极地与我们的目标客户保持沟通，促进对方使用产品并获得反馈；其次产品经理需要提前规划下一个迭代要升级的内容，这里要注意每次升级的内容都必须为完整可用的功能，不能将未完成的半截功能上线，那是致命的。

因此在后期迭代升级中，也要遵循提取MVP原则，永远保证团队所做的是优先级最高的，所以不用每个迭代都更新大功能，大功能可以拉伸到多个迭代中完成，但可以在每个迭代升级中，尽量安排一些“阿哈功能”。

随着产品的客户群体增大，客户的需求建议会越来越多，此时产品经理需要注意一点，不要客户说什么就做什么，因为我们做的是自研产品，所以客户的需求反馈仅作为市场对该产品本身规划的校正。

五、产品1生2

随着产品的完善，客户量也会越来越多，终究一天产品的增量会抵达天花板，在此之前产品经理就需要准备开拓新的产品了，可能会开启一个新的从0到1，也可能会在这个“1” 的基础上1生2，2生4……

总之，不管是从0到1，还是从1到N，请记住产品是为人服务的，请把产品设计的人性化一点，永远要做自己产品的第一个用户。

最后，以上仅是本人从自己负责过的多个从0到1的产品设计中的经验之谈，欢迎各位读者交流、斧正。

本文由 @易小勇 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议