2B软件产品从0-1之路

撰稿人|江大侠

这是产品荣耀公众号的第40篇原创文章

今天给带来干货分享，是本人之前实际工作当中负责的一款2B软件产品，出于人道主义，对内容做了些许处理，敏感信息剔除。

适合做B端产品经理、制药信息化行业、想入行的人员进行参考，希望能有所启发。

此产品为制药研发实验室信息化产品，主要通过电子化实验记录，将实验过程的实验方案、实验物料、实验设备、实验流程、实验报告等信息集于一身，提高一线实验科学家的实验效率，提高文档质量，并帮助QA、项目经理管理项目、任务、实验进度。

同时，出于行业特殊性，做了审计追踪，对于实验过程中的所有记录，都有追踪，包含人员、时间、事件等记录，方便药监局核查。

接下来，我基于自己总结的产品方法论我的产品方法论，以一个项目的管理阶段，立项（启动、规划）、执行、监控、收尾，来分别介绍该产品的0-1过程。

#1 立项

“一定”就是产品定位。就是要搞清楚产品的目标用户、为其解决什么问题，应用场景有哪些，带来什么价值。

基于基本的商业思维，在做一款产品之前，我们需要搞清楚下面三个内容。

一、我们要做什么

二、为什么是我们

三、我们的盈利模式

第一条就是商业战略，我们要取舍。结合华为的“五看三定”方法来分析，看市场、看行业、看客户、看竞品、看自己，然后基于这些信息来定战略、目标和策略。

当时契机点在于“长生疫苗事件”，国家出台了一系列政策，也有很多资本相继涌入，尤其是在生物医药版块。

创业成功与否，很大程度上靠的是运气，天时很重要，很多伟大的成功的公司，都是时代造就的产物。

所以当时的老板，看准了这个机会，瞄准制药智能制造，聚焦制药赛道，那么当时制定的公司战略是做一家集制药研发信息化、生产、仓储一条龙的数字化转型服务商。

我负责制药研发信息化这个版块的业务，瞄准的就是研发实验室这块，然后去进行市场调研。

市场调研、竞品分析的方法这里不再赘述，文末有相关的原文链接，大家自行阅读。

得出的结论就是，总体的市场份额大概是50亿美金左右，但整体呈上升趋势，因为随着资本涌入，做制药以及周边的公司越来越多，需求也就越来越大。

临床的部分太专业，国外有很多厂家做的很成熟，国内的厂家还不是很明朗，临床前的部分，国外也有一些（可见下面清单），国外的玩家有几家，基本情况已经摸清楚。

第二条，为什么是我们，或者说我们能做什么，优势是什么。说实话，大家都是半路出家，没有专业的队伍，都是摸着石头过河，有的是学习能力，原先的软件开发团队技术实力，再就是一股拼劲。

这个时候没得挑，也没有优势，如何在1-2年内将东西做出来，甚至赶超竞争对手，是个苦活。

好在商务上、技术上的配合，拿到一家天使客户的项目机会，团队活下来的希望有了，而且获取真实需求的渠道有了。

在做这个之前，我们对友商的产品策略、盈利模式也做了分析，一家是主打轻量化，将项目管理和实验室数据记录结合在一起，但是都没做的很深入，主要是体现集成、统一的理念，价格相对便宜。

另一家，创始人有医学背景，笼络了一帮技术人才，自主研发了自己的产品，主打的商业策略是，通过自己工具，卖耗材，有自己类似电商管理系统，在实验过程中，或者备料过程中，发现有缺料的情况，可以在其平台进行请购。

看好了市场、看清了竞争对手，以及我们自己，然后是客户，我们要瞄准的是哪些B端客户群？

细分下来，有小分子、大分子，又可以分仿制药、创新药，中药、化药，生物制药等，学科有制剂、合成、分析等。

经过多轮调研、结合当时的天使客户业务情况，最终我们把产品定位成给小分子细分赛道的，一线实验员、科学家使用，以解决其日常实验过程中的一些繁琐记录、数据遗漏、数据查询困难等问题，提高实验效率、避免错误风险，提高文档质量。

第三条，我们的盈利模式，这里面包含了成本管理、产品定价策略。需要懂一些财务的基本知识，比如利润表、现金流、负债表等，这里不深入介绍。

当时研究了很多，最终借鉴了SaaS系统的定价方式，感兴趣的可以参考书籍《SaaS创业路线图》这本书。

报价组成包含了基础软件+定制化部分+实施费用，主要根据用户数量，按年进行收费。

我们瞄准的是头部客户，先做灯塔项目，打造企业的品牌影响力，之所以没有根据“长尾理论”，打尾部客户，以数量取胜，是因为创业初期，盘子拉的很大，如果体量太小，不足以支撑当前的成本，这跟老板的商业规划有关系。

总结一下，我们当时的战略就是要服务制药行业的细分领域，走制药研发信息化、生产数字化、仓储智能化三条业务线，目标是1-2年内自主研发出产品上线，力争在行业内站住脚跟，策略就是先拿下一些头部客户，以质量取胜，打造品牌影响力。

#2 执行

制定好了产品战略、产品定位，搞清楚我们要做什么，以及目标和策略后，就要开始执行。

强大的执行力和统筹能力，是保障产品成功的关键。这里要提到“二排”，排需求、排计划。

落地的前提是先搞定需求，搞定产品路线，迭代规划，然后根据需求、资源、时间节点，来安排开发计划。

我们当时做需求调研，有定性、定量的方式，比如用户访谈、调查问卷，售前、销售去跟客户交流的过程中，会依照我们给出的调查问卷，进行询问，然后反馈到我们这边。

另外，我们跟客户面对面沟通，陪着一线实验员、科学家，看他们日常工作状态、流程，发现和挖掘过程中的困难点，痛点，了解其核心诉求。

然后，收集整理成需求池，再根据基本功能、核心业务、用户体验、稳定性、可靠性等几个维度进行分类，在再各个分类中进行优先级排序。

排序的依据也有很多，根据我们自己的产品迭代节奏，客户的实际应用场景、核心业务，关键流程。

比如，实验室数据记录，最基础的就是原始数据记录，包含了人员、天气、所用物料、设备、计算式、结构式、实验步骤等，最起码得让实验员能用得起来，流程走得通才行。

所以产品的基础版本的功能就出来了，应用场景明晰，需求优先级排好，接下来就是根据资源、时间来安排开发计划。

之前的模式是敏捷开发，内部的沟通机制是用JIRA来管理整个需求、前后端的工作任务、工作量评估，燃尽图等报表来管理进度与成果。

这里面涉及到几个岗位的沟通，前端、后端、UI设计、测试人员、产品等。对于产品来说更重要的是统筹全局，保障方向是对的，认真执行下去。

当时是双周迭代节奏，一般需求要领先一个迭代，即产品经理在前一个迭代快结束的下半周，将下个迭代的需求理清楚后，跟团队进行讲解，包含了需求规格、原型设计、业务逻辑、业务背景等，旨在帮助开发、UI、测试人员了解需求。

双周迭代有利有弊。好处是10人左右的小团队，可以快速跟进，对于单个迭代的功能需求，可以控制的很好，因为在开发过程中，一般是不允许插入新的需求，可以很好的控制范围。

不好的地方就是，单个需求可能相对较大，或者前期评估工作量没有很仔细，导致开发过程中，发现这个版本根本做不完，导致变更或延期的可能。

#3 监控

一切准备就绪，开发过程中，产品经理会随时跟进开发的进度，比如某个功能需求之前理解不到位，程序员会继续询问，那此时需要产品经理进行澄清。

在开发的第一周，提交测试之前，可以让程序员在研发环境开账号，产品经理先自己测试一下，确认效果，如果主流程走不通，太多BUG，那也没必要提测，避免来回提测，导致测试打回，对团队信任降低的风险。

在这个过程中，产品跟测试也需要配合，比如测试用例的评审，对于业务逻辑、交互、功能需求点，作为产品经理，我会及时对测试提交的测试用例进行评审，给出评审意见。

这个过程中，需要做的就是“三管”，即管理时间、成本、质量。需要开发进度把控、人员工作量、加班情况统计，以及开发效果确认。

对于进度的把控，主要是看前后端的任务是否按时完成，是否存在技术难点，是否需要协助。

当时用的是进度看板，每天晨会以站会的方式，每人几分钟的时间，回顾昨天做的事情，把任务状态进行更新，要求的是每天下班前在JIRA上把昨晚的任务关闭。

同时，说一下今天要做的事情，是否需要协助，让团队人员都清楚项目的进展，保持同步。

当时我们团队都奔着把产品开发出来，尽快上线，目标为导向，所以在上线节点，出现BUG较多，或部署问题时，即使通宵，我们也会按时提交上线，不欺瞒、不辜负客户。

所以，成本管控主要是统计加班情况，对于考勤，相对比较扁平，大事讲原则，小事随风格的方式来进行。

版本上线到客户环境，我会第一时间进行确认效果，避免因环境不同导致的系统差异，从而影响客户体验。

#4 收尾

产品第一个正式版本上线交付，那时我们是忐忑的，因为我们是半路出道，没有行业背景，庆幸的是我们对竞品研究的比较透彻，客户对我们提供了足够的理解与支持。

在最后通过确认“四看”，就是看效果、指标、收益、客户满意度。

事后，我们也做了复盘总结工作，对于0-1的过程中，踩过的坑，处理方式形成经验资料，供团队、甚至其他部门学习。

另外，对于流程的建立、过程优化，沟通机制协同等方面，产品管理包括需求调研、分析、文档输出、文档管理等工作沉淀。

对于行业的了解，背景知识，核心业务面也有了积累，提炼行业共性需求，打造通用标准功能，为后续产品优化打下基础。

同时，整个团队对于CSV系统验证流程，CMMI3认证流程，以及V模型开发模式，IPD流程，敏捷开发模式，双周迭代形式都有了很深刻的理解。

总结，在此产品的0-1过程中，团队迅速成长，配合更默契，提升了团队凝聚力。

就我个人而言，承担了售前技术支持、产品规划设计、产品管理、团队沟通协作、项目统筹、客户管理、市场支持的工作内容，对产品的认知、商业的理解、沟通等方面的能力得到极大提升。

如果你有所感悟，关注我，找我聊聊。

产品壹佰网站所提供的内容均来源于用户提供或网络搜集，由本站编辑整理，仅供个人研究、交流学习使用。如涉及版权问题，请联系本站管理员予以更改或删除。