从用户到场景,从场景到产品使用路径,全面的梳理复盘过程产生的新的需求点,对于简单需求形成各方满意的初步方案。 本月复盘内容简述 现状问题:司机拉不上来,没有司机货主的货就没有人拉。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端产品做好。