做产品经理这么多年，我其实做的都是一些toB类产品，比如校园迎新、数据采集工具、校园可视化平台、数据中台等，校园迎新软件、数据中台算是用的比较多的，其他产品虽然实施的项目比较多，但实际上有些不能算真正用起来，另外也接手以及参与过一些别人做的半拉子工程，比如一站式办事大厅、人脸识别布控系统、OA等。
这些产品都是私有化部署类的toB软件产品，很多以支撑项目交付为目标，实现从能用到好用即可，多数情况下不像互联网/SaaS类产品，需要进行用户运营、追求用户的增长，通过获取用户>激发活跃>提高留存>增加收入>自传播这条路径实现产品的1到100成长等，交付类产品追求的是市场规模，复用或者卖的套数越多越好，但是到底应该如何定义这类产品的1到100，有想法的可以留言跟我交流。
这里主要讲讲，这类toB软件产品的从0到1。
我个人觉得可分为三个阶段：
（一） 决策期
决策期就是决定要不要做这个产品，做的话要做成什么样子、投入成本和收益如何、可能存在的风险等等，核心过程我总结为如下：
1. 市场分析：绝大部分情况下，这类产品都是先有商机/项目，通过项目孵化而来的，也可能是团队或者公司有想法做一个产品，基本都是领导、销售或者核心人员提出来的——因为他们见多识广、市场嗅觉是最灵敏的，然后会安排人力做前期的调研，市场分析这块儿，toB跟toC还是很不一样的，toC可以去做一些调研问卷、访谈，还可以去看竞对公司的产品，toB类很难做到这些，能做的就是研究行业的各类投资研究报告、各类协会行业分析、头部公司动态、核心市场竞对公司动态，还可以通过像百度指数这类产品观察关键词情况、从而了解热度趋势，如果是面向政府的产品，还可以通过政采网去看同类产品招标、采购趋势等。
2. 产品分析：通过上一步分析获取的数据、需求来看，如果证实产品确实存在市场空间，那么此时就要围绕产品本身来做思考，勾勒产品蓝图、竞争力、打造路径、目标市场、投入收益、生命周期等，尤其是竞争力和投入收益要想清楚，这个是开干的前提。
3. 研发立项：这步主要是对要研发产品这件事，做一个完整的盘点，进行可行性说明、产品打造说明、投入收益估算、可能存在风险说明等等，同时需要通过内部层层评审通过后，才能投入资源研发，当然每家公司不同，有的公司可能没有这个环节，核心人员讨论过后就开始干了。
（二） 构建期
成熟的公司在产品的构建流程上有严格的流程要求，如果你所在的团队没有，那么我建议产品经理及其他核心人员的输出关键方案等都要组织领导和团队进行评审。构建期我觉得主要可总结为如下：
1. 产品规划和设计：在产品蓝图的基础上，进行产品里程碑或产品路线图规划，进而在里程碑的基础上，再进行详细能力分解、版本排期和功能设计。如果对产品能力迷茫，不知道如何开始，可参考行业协会发布的白皮书，或者是借鉴竞品，或者自己找圈子去向大佬学习。这个环节的评审可包含产品功能架构设计评审、技术架构设计评审、里程碑/路线图评审、版本功能方案评审、功能设计及需求评审等，除技术架构外，其他都由产品经理组织，同时产品经理要输出原型、需求文档和流程图等辅助理解产品的材料，需要进行UI设计的，要推动UI团队进行界面美化，能力强的UI会根据内容给出配色、交互和排版建议等。
2. 产品开发和测试：基于产品设计，研发团队要进行技术方案设计，同时测试团队要进行测试用例设计，然后由研发经理和测试经理分别组织技术方案评审和测试用例评审，技术方案评审个人建议产品经理也参加，主要是在评审会议中消除需求信息不对称的情况；测试用例评审，产品经理是必须参加的，确保需求理解的准确性。这两项评审结束后，研发和测试人员要进行工时评估，团队一起决策功能完成时间，然后按排期进行研发和测试。开发结束后，产品经理要提供产品操作手册、功能清单等。
▼现在各个团队基本都采用的是敏捷开发，小版本快速迭代，所以版本设计、开发、测试是一直不断循环进行，直到完成目标为止。具体每个版本，产品经理要做的事情和输出，可参考我个人工作总结的一个图：
版本迭代过程中会涉及与领导、产品项目经理、研发团队、UI团队、测试团队、跨部门合作团队等角色的沟通、协调工作，如果版本要上线到具体项目上，还涉及与实施项目经理、客户、用户的沟通等。
3. 产品发布和推广：部分情况下，产品达到最小可运行，能发布和推广了，但是由于外界商机和公司策略的变化等会出现各种情况，比如公司宣传早于研发，也可能有个项目要交付、产品做到一定程度就要部署使用了等等。toB类的产品发布，可能会组织一场路演，请客户、厂家到场听宣讲，也可能就是发发新闻稿等。产品经理在这个环节需要提供或者协助提供产品白皮书、产品宣传物料、PPT或者是大屏等。
该环节会涉及与公司宣传部门、售前、销售等角色的沟通、协调。
（三） 优化期
这个阶段主要是产品相对稳定后，团队要根据外界反馈，对发现的问题进行修复、对收到的优化进行补充和修正等，实际上产品一般是一边研发一边优化的，这部分我单独放出来的原因是，这部分主要是由外部需求驱动来执行的，产品经理要做一些与外部沟通的管理工作：
1. 产品动态定期同步：保持定期与典型用户、售前、销售进行沟通，组织产品培训、产品宣讲、沟通会等，了解他们的诉求，以及让他们更好地了解产品。
2. 需求和问题池管理：记录问题和需求内容、影响范围、期待解决时间、提出人、提出时间，以及内部的安排，如接收人、需求确认情况、计划处理方案、当前状态、以及预期解决时间等，实现与外部高效沟通及沟通闭环。
3. 问题解决排期管理：到这个环节需求是非常有针对性的，需求的优先级也基本是非常明确的，但是有可做、可不做的决策，针对要做的可按构建期前两步执行，针对不做的需要将原因及时同步给提出人等。
产品从0到1是个非常复杂的过程，这里我只是根据自己经历和理解、按照正常推进过程、总结了概要和关键环节，实际操作中存在很多细枝末节的操作，同时也会存在很多问题，比如：
1. 产品根本没有决策期就开始构建了，你的领导也是拿到了一个笼统idea，也给不了你更多的想法，并且还给你定了一个期限，剩下的全靠你来思考
2. 研发资源不能保障，团队的人员三天两头被派去支撑这个支撑那个，甚至包括产品经理本身人员也不足
3. 跨部门合作不顺畅，产品可能存在与其他团队合作的部分，但是由于利益诉求不同，团队的节奏也是完全不同的，然后出现问题会互相扯皮甩锅
4. 没有深耕、产品很难有竞争力，单就技术而言没什么壁垒，规模化+长时间的积累才会产生差异化优势，但实际上除了一些一线大厂，很难有公司能长期坚持投入探索、研究新东西，大部分公司考虑的是存活和收益，需要短周期内快速迭代出来一个产品，尽快投入市场就赚钱，所以大多数产品都是同质化严重的。
不过我觉得无论如何，公司购买我们作为劳动的同时，也是提供了一个平台给我们，我们要尽量用好这个平台，发挥自己的最大价值、获取最快最大的成长空间，如果遇到困难，我建议还是有几个自己的处理事情的准则，比如我能想到的几个准则：
1. 所做事情围绕自己的职责范围和自己成长目标开展，优先做重要的事情。
2. 自己能力外的事情如果处理不了，及时向上或者向团队暴露风险，寻求帮助，或者让上级决策。
3. 保持所做事情及内容的记录和可追溯，比如重要不重要的沟通都要留下记录、会议要有会议纪要、文档备份留存日期标注等，这样复盘的时候可以明确地找点时间和内容线索。
网友评论