首页 - 娱乐资讯 - 需求的终点是什么?(带销售流程示例)

需求的终点是什么?(带销售流程示例)

发布时间:2022-05-06  分类:娱乐资讯  作者:seo  浏览:9617

编辑导读:需求需求,戴在每个产品经理头上的紧箍咒。当我们处理完一个又一个需求的时候,我们不禁要问,需求的尽头是什么?对于这个问题,作者给出了自己的答案。让我们看一看。

产品经理的工作和需求是密不可分的,所以你有没有想过一个问题:需求的终点是什么?

快来和我一起寻找答案吧!

假设你是R企业销售平台的产品经理,A是R企业的产品,在你负责的平台上销售。现在,A的产品经理找到了你,向你提出了一个需求:用户1通过销售平台购买了产品A。无论用户1是否离职,都不会影响订单的升级更新或a的使用。

首先,确定是否是虚假需求。

首先,我们需要了解产品a的定位和销售模式。

a是一种项目协作软件,在销售平台上有两种销售方式:个人和企业。

单个订单,只有采购人员有权查看操作订单。

订单、采购员、同一企业的会员都有操作按钮,也可以正常使用。

由此,我们可以得出一个结论:这是一个伪需求!

但是你真的觉得这样合理吗?我们还是从两个销售方案的角度来分析。

我们分析软件A本身,它是一种项目协作软件,使用场景是多人协作。所以即使是个人购买,实际上是公司或者项目在用,那么也可能会出现人员流动的情况。所以对于个人订单来说,周转转账是一个真实的需求。

有操作按钮就一定能正常使用吗?正常使用的定义是什么?前面背景提到过,销售平台和A是两个系统,涉及两个系统,所以底层数据能否互通尤为重要。对于两个系统来说,正常使用是在销售平台上操作后,数据也要传输到a,实际操作后发现企业订单中只有买方操作有效!也就是说,由非购买者操作的订单信息不被传输到A的数据库。

结果,我们发现了这是一个真需求!.

第二,查看竞品游戏。

确定需求后,需要看看头部企业同类产品的销售模式,拓宽思路。

1.阿里云-云效应

在阿里云平台购买云效果时,用企业id代替用户id确认订单信息。因此,如果购买了云效果的用户离职,后续企业人员仍可使用企业id升级续费,从根本上避免了离职人员交接的需要。

2.华为云-软件开发平台

软件开发平台不强制买家是企业,而是用用户id来确认订单信息。

看购买记录和软件开发平台页面,没有找到订单转发的按钮。提交工单查询后得知,个人购买软件开发平台为主体的,离职后订单无法升级续签,企业将无法使用软件开发平台。只有个人账号可以由企业认证,也可以由企业直接购买。你走不走都不会影响秩序或者使用。很明显,华为云是通过角色来控制权限的,并没有做离职的逻辑。

class="content-picture" src="https://inews.gtimg.com/newsapp_bt/0/14859141006/1000">

三、梳理解决方案

我们了解了竞品玩法后,提出以下三种解决方案。

1. 利用企业id确认订单信息

在看完竞品-阿里云的销售模式后,你是否觉得醍醐灌顶?我们从起点开始就错了:既然A是一款项目协作的软件,对于此类软件,支持个人购买明显不合理。

有了质疑,我们再结合个人购买和企业购买的场景,仔细分析区别。

S企的采购部购买了产品,但是企业购买需要上传公司的营业执照在销售平台认证,财务部不愿提供信息或很麻烦。

个人工作室买了产品A想二开,无法提供营业执照等信息。

这个平台和产品已经运行一段时间了,之前存在一些真实的订单,我们不方便更改软件的购买方式。

结合上述场景,若我们把购买方式贸然限制为企业购买,会失去(1)(2)类客户,并且导致(3)类用户出问题。华为并未限制个人购买软件开发平台应该也是出于这三点的考量。

oh,此路不通!

2. 修复bug,使企业内非购买人的订单操作生效

这个方案和软件开发平台的销售模式相似,即个人订单个人使用,企业订单管理员均可操作。但若A仍保留个人购买的模式,那么个人订单中,离职后仍可正常使用或升级续费的需求无法被满足。

此方案的优势在于改动少,但是不能满足个人订单的场景需求。因此也不会采纳。

3. 新增个人和企业订单的离职人转交功能

优点:更贴合用户习惯,符合认知

缺点:销售平台中不仅销售这一个产品,需要A做特殊的逻辑,销售平台的开发工作量重

优点:销售平台无需做特殊逻辑,仅提供修改接口即可

缺点:A的开发工作量重

两种方案都各有利弊,根据实际的项目情况,A较之销售平台可提供更多的技术资源,因此选择方式(2)。

四、冰山露出来的只是一角,潜伏在冰山下的才是一个优秀的产品经理需要看到的

到现在为止,你是否发现了流程的不合理处?

1. 企业订单中,所有成员都有操作权限?

显然不合理,应该限制企业管理员才能以企业方式购买,如非企业管理员的用户只支持个人购买。

但,真的这么简单吗?

结合离职人转交的功能,若企业管理员将订单转交给了企业成员,那么就存在非企业管理员可以再次以企业方式购买产品。因此,我们不仅需要在购买时做角色校验,还需在再次购买和升级续费时校验。

2. 个人订单和企业订单的续费问题

但,真的这么简单吗?

首先,如何定义已购买的用户?是提交订单后,还是付款后算购买。如果提交订单后就算购买,那么用户发现购买方式选择错误取消订单后,却发现无法修改购买方式;如果付款后算购买,那么用户先提交一个个人订单不付款,再提交一个企业订单后,接着支付两个订单。那么就会存在一个用户既有个人订单又有企业订单,限制无效。好像走进了一个死胡同。不妨跳出这两个方案来看,加一些别的限制组成方案C:付款后就算购买,但是用户若有未付款订单,则不允许再提交新的订单。

其次,结合离职人转交的功能,针对同一款产品,可能存在一个用户既有个人订单又有企业订单的情况。比如,用户1以个人方式购买了A,后续用户2将企业订单转交给用户1。因此,再转交前还需加被转交人的校验逻辑。

五、总结启发

需求的尽头是什么?还是需求,不过这个需求是从冰山下挖出来的更深层次的需求。

所以我们思考一个需求,他不应是一个点,而是一条线,更复杂的时候是一个面或多个面。

以销售平台为例,对于用户来说,只是在A上增加了一个转交的按钮,但是销售平台的功能一环扣一环,关联性非常强,需要产品看到更多,以下两种方法可以辅助我们思考。

1. 流程图思考法

当我们在设计离职转交时,可以画一个简单的流程图来帮助我们梳理上游和下游,关键的节点标注所需的数据。

比如,订单结算需要用户信息,那么需要销售平台和A做用户打通或用户绑定,才能支持离职转交操作;订单结算需要个人/企业实名信息,若A未提供,则销售平台需要在每一次提交订单时做实名校验,增加去实名的跳转引导;转交后可能涉及到退款,而退款仅支持原路退回,那么我们需要在用户支付时或转交时添加提示。

2. 权限矩阵思考法

只考虑订单数据流转过程是远远不够的,因为订单还涉及到多个角色,多种状态。

不同角色在订单的不同状态下,可操作的按钮不一致,例如企业成员仅能在订单状态为生效中时使用产品而无法查看订单详情,而企业管理员应从未授权时就能够查看订单详情了。

本文由 @玛卡巴卡 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

标签: 产品经理  离职  软件开发  伪需求 

快捷导航
最新发布
标签列表