10月产品总结 | 全面复盘分析，开展规划Workshop

本月复盘内容简述

现状问题：司机拉不上来，没有司机货主的货就没有人拉。GMV就上不去。怎么解决？

解决目标：降低拉新司机门槛

产品提案：司机操作简化：下载APP、提交认证资料（用户中心）、运输中操作（司机端操作装卸货地点击手机）

Case1：能否不让司机下载APP？

Case2:  能否让司机提交资料后置？

Case3:  能否帮助司机提交资料？如：销售帮助司机提交（通过销售移动端）

分析及说明

Case1：是否可以用小程序替代APP？

Result：

与独立App相比，微信小程序更多的受限于微信体系。APP所具有的短信推送，站内推送等手段也会在一定程度受受制于微信规则。

微信小程序较App而言，运营自由度也会相对降低，运营难度更大。

其次，对于有支付强需求的产品而言，微信小程序内部设计支付功能，就很可能会产生被支付宝的屏蔽风险，在这一点上，App就显得得更加灵活性并拥有独特优势。

更多分析可参考《如何选择移动端？》

Case2：能否让司机提交资料后置？

Result：不能。

原因主要有两个：第一，接单签约时必须确保运输协议所关联的订单车辆和驾驶员一致；第二，司机在运输过程中，平台需要监控运输过程，并且在装卸货低获取驾驶员位置。那么前提就是能证明驾驶员就是注册的司机用户。

分析依据：《网络货运平台管理制度》中运输过程监控部分强调，网络货运平台应验证订单里的车辆和驾驶员一致，并且在装卸货地获取驾驶员位置。

因此，即便是司机提交资料后置，我们也必须限制司机在接单前就完成人和车辆的认证及绑定。所以，为了保证运输协议签订是真实的，现在产品是先完成驾驶员认证后接单的途径是唯一合规的方式。

Case3：能否帮助司机提交资料？

Result：能。

如：销售帮助司机提交（通过销售移动端）

从系统上线至今，我们从运营、业务都接收到这样的反馈：司机的注册认证基本是销售代劳。

既然如此，我们完全可以为销售提供拉新司机的移动端小工具，用户采集司机认证资料。并且通过我们的中台完成认证资料的审核及司机账号的激活。如果提供这样的销售小工具，销售拉新司机的方向就需要做微调。

首先，拉新司机变为采集司机资料并送审。这一项是需要销售团队提供考核标准给产品组做依据，先明确如何考核再考虑如何完成产品支撑。

其次，销售依然需要解决司机不愿意下载APP的问题，并且需要调整开拓司机的战略及话术。

从复盘到Workshop

产品经理对曾做过的产品，曾参与过的项目进行复盘是很自然的学习过程。学习-思考-实践-总结-再学习，这是一个个人能力长期迭代的过程。

作为产品经理，保持学习总结的态度和能力，是非常重要的。2C的产品经理学习的成本较2B的产品低，因为纯互联网的产品可参考的案例多，用户场景也雷同。B端的产品，业务属性强，线上线下结合紧密。因此，2B的产品经理，其学习的成本就很高。

2B的产品经理主要来源于三种场景：

带研发项目，项目逐步标准化为产品，转产品经理；

技术出生，带过几个初中级产品经理，变相是产品经理；

做解决方案写PPT的售前，接触客户多，能补充业务场景带队做产品，然后找技术负责人打配合。

从不同场景成长起来的产品经理，需要学习的方向和目标也是不同的。但是无论如何学习，复盘一定是必经之路。复盘过程是就专项问题做专项分析。

分析过程可能需要组织项目组成员完成多个Workshop，在Workshop中，我们需要完成对复盘内容及后期规划的出结论性产物。

结论性产物一般含四类：

项目组成员需要对业务关键流程及关键需求点再次达成决策；

产品经理负责评估复盘过程中，总结出的需求点的可行性；

项目经理+产品经理，需要识别并剔除不合理需求，特别是投入产出比低的需求要慎重处理；

会后，由产品经理形成清晰的会议纪要，并且在可控时间内完成需求文档。

总结

从复盘到Workshop的过程，我们需要对于简单需求形成各方满意的初步方案。通过描述Userstory的方式，从用户到场景，从场景到产品使用路径，全面的梳理复盘过程产生的新的需求点。

采集需求-分析需求-整合需求-再分析需求，是产品经理重要工作之一。需求挖掘的过程就产品了解用户，熟悉业务的过程。

特别是2B的产品经理，能从众多需求中，有效兼顾可行性、投入产出比、业务改善等复杂问题，是非常不容易的。多学习，多复盘，多思考，才能把B端产品做好。