因为这些设计被扣钱,到底冤不冤?

2 评论 1240 浏览 1 收藏 14 分钟

本文从产品设计的角度出发,探讨了在逆周期中,产品人员应如何提升自我,避免因低级错误被扣绩效,甚至面临失业的风险。文章通过实际案例分析,指出了产品人员在工作中常见的几个问题,如产品语言与用户语言的差异、设计断层以及缺乏商业化思维等,并提供了相应的解决思路。

消费降级的当下,没有谁不可替代。

经济下行的压力逐渐传导至末端,身边一两个月还没找到合适的工作的小伙伴越来越多了,最近找镜同学咨询和面试辅导的同学也骤增。

即使如此,我却劝说每一个同学:先苟住、等等看。

也许有同学反驳,是金子到哪里都会发光,不用过于焦虑和担心,干的不爽就换下一家,哪怕多等一个月呢?

但现实往往事与人违,这个逻辑也很简单,当你一两个月没有合适的机会下,大多数人都会撑不住压力而仓促决策,但人生就这么几个重要的十字路口,要遵循规划而不能赌概率。

从这个意义上来说,逆周期下的随意择业就很像用博弈心态来买股票,你很难坚持初心、长线持有,轻易购入之后往往就是快速换手。

前段时间去北京出差,顺便拜访了百度的产品同学,他向我讲解了百度对AI的布局和投入,一句话:外界认为百度所谓押中的AI风口,其实是等来的,是靠早期坚持的投入。

图 -↑ 百度参访有感

其实,人和组织一样,都需要求之于势,不可强求。

镜同学认为,在这个逆周期之下,最好的姿态就是储蓄,不只是现金账户的储蓄,更包括心理账户、技术账户,这也是近期和团队交流最多的话题。

我们团队不少同学也面临被优化的压力,但我并没有直接遵循公司的要求,强制考核而后逼退,没必要,同是打工人、相煎何太急。

曾仕强老师讲的《易经》,镜同学反复听了很多遍,在我看来,轻易裁人其实也是改变某个人命运,这并不是咱们这些凡夫俗子所能驾驭的。

当然,在其位也要对公司负责,所以我悄悄对优化的定义做了优化:优化不等于裁人,而是等于“升级”+“裁人”。

所以,对于名单里的同学,我首先给定个更高目标,比如初级升中级、中级升高级,如若两个月达成,升职加薪;如果达成不了,江湖再见。

而我需要做的就很简单:只需要找准对象、定好目标、全力培养即可。

但是,在这个深度培训过程中,我也发现不少初级同学所缺甚多,尤其是综合专业能力的确差距很大,不仅产品体验设计薄弱,就连业务功能的理解也有很大不足。

说实话,很多设计不符合规范,有些设计不完整,甚至有些设计是错误的,严格来说,有些同学的设计是应该被扣绩效的。

其实,对于咱们产品同学来说,个人的产品力就是核心竞争力,而在这个逆周期的当下,如果不有意弥补、抓紧提升,被汰换出局的风险就很大。

基于此,我也分享几个产品产品常见的低级错误,供大家参考学习。

1、产品语言 ≠ 用户语言

相信大家都听过这句话:产品设计不能盲目自嗨。

产品自嗨有很多典型特征,如,不去做市场调研、用户洞察,只是躲在实验室里自行推演;再如,固执地应用某个局限方法论,试图逆转用户的真实需求。

而反映在产品设计上,最常见的就是未把产品语言转化为用户语言。

随便举个例子:

团队有产品同学在菜单按钮命名时完全是产品视角,用户压根就看不懂,比如,二级菜单包括“资金账户”、“发票管理”、“账号管理”、“运营管理”,结果一级菜单命名为“办公管理”,结果每次向客户演示时都被询问什么是“办公管理”。

起初,该同学还沾沾自喜,认为自己很好地创造了一个高大上的新名词,但这就是典型的产品自嗨,因为用户压根就看不明白,抛开业务领域的错误不说,你哪怕叫做“综合管理”也好理解吧?

为此,我们还收到了投诉,反馈系统升级后不好用,很多菜单命名看不懂啥意思,按照管理制度要求,客户投诉我们是要被扣绩效的,该同学也被扣了绩效。

从表面看,他好像很冤枉,但咱们要明白,产品是业务的载体,不是功能的堆砌,我们的价值是让用户高效理解产品,而不仅仅是自我视角的盲目自嗨。

我早些年还见过,有同学在客户系统里的菜单命名为“用户字典”,我天,难不成客户也都是IT专家么?你就是叫做“配置管理”可能用户还能看懂,可字典是什么鬼?

所以,咱们在进行产品设计时一定要把产品语言转化为业务语言,转化为用户语言,让用户更高效地理解。

2、设计断层,业务不闭环

在产品设计过程中,确保业务闭环是基本常识,因为这直接影响到产品的市场接受度、用户满意度、商业转化效率以及可持续性。

但有一说一,现实中很多同学确实还停留在堆砌产品功能的阶段,表现在对业务场景理解不深刻,设计同业务存在割裂、断层,从而犯一些常识性错误。

举个例子:

前两年,我们后台管理系统有个功能是配置SaaS产品的SKU,可以设置B端企业客户中允许使用该系统的最大人员数,如,设置为100人,则该企业最多允许100名员工使用该系统。

这是很常见的设计。

可我们产品同学在设计时却未深刻考虑业务场景,没有把产品和业务做融合,更没有贯彻产品服务业务的设计常识,只是完全被动照搬了运营同学的政策,需求方咋写就咋做,坚决不多动脑筋思考用户场景。

因为业务策略上暂时就给了5类套餐,所以他设计的“最大人员数”这个选项值也是5个,即:10人、20人、30人、50人、100人。

某次业务同学对新客户进行系统演示,客户当场要求150名员工都加入,结果业务在配置时发现该选项竟然没有“不限”这个字段,还需要研发同学改代码,研发领导对该设计表示很震惊、很愤怒,坚决要求复盘追责、罚款扣钱。

后来我们组织复盘,起初该同学还没意识到自己的错误,认为自己没错,还理直气壮地说是按运营政策设计的,因为运营政策就是这5个类型。

但作为产品经理,如果但凡对该业务场景多思考一步,都不可能会犯这样的错误,更何况该需求设计本身就不符合闭环的基本逻辑。

咱们是设计师,不是需求方的翻译器,更何况内部需求方(业务、运营等)未必专业,他们提出的需求有太多需要推敲,有些甚至就是伪需求、错需求。

所谓“反正我是按业务方需求做的”、“市场需求就是这么写的”、“有问题也追责不到我头上”,等等,这些话千万不要成为设计懒惰的借口。

任何时候咱们都要牢记:产品同学最重要的价值就是业务价值。

所以,我们必须基于对应用场景的洞察与分析,缝合业务与需求的断层,应用闭环思维来设计,做出符合用户真实需求的产品。

3、堆砌功能,未考虑商业化

众所周知,产品同学对商业化思维的深度应用非常重要,越是高段位越是如此,因为这可能会直接影响产品的市场接受度、用户满意度以及最终的商业效益。

优秀的商业化设计不仅是高效增长的支点,往往也是可持续的关键。

对此,镜同学的经验是:设计之初便同步思考对公司怎么盈利,而对运营相关的产品设计要足够敏感且始终绷着一根弦。

但有一说一,现实中很多同学还停留在堆砌产品功能的阶段,表现为缺乏对业务场景的洞察,对用户需求的理解并不深刻,对业务模式也只是被动地浅尝辄止。

他们往往习惯把领导对商业模式的诠释当做着手设计的基准线,但却从未思考为何如此。

而这不仅影响商业达成,甚至可能会为公司带来损失。

举个例子:

上个月,某产品同学和我咨询交流时提到一个案例,当时他们有一个“团队分佣”的运营需求,因为平台刚起步,所以运营提出对平台抽取的佣金进行二次补贴,即把平台抽佣的钱再补贴给平台的分销员。

于是,他们运营人员就提出对商品的交易额进行抽佣补贴,如,平台抽取10%的佣金,并计划将这10%拿出来补贴给相应的分销员。

不过,他们平台对不同商品的抽佣比例不一样,而这个平台的抽佣比例是根据品类而进行后台单独配置的。

可产品经理并没有对分销员的佣金比例同步做限制,没有设计“不得大于平台分佣比例”的判断条件,在页面元素上只是一个输入框,运营人员可以在0-100%之间随意输入。

但是,这种设计实际上存在很大漏洞的。

比如,如果某款商品平台抽佣比例5%,可运营人员却可以配置大于5%的佣金,比如,配置了30%,而这多出来的25%的钱却需要由公司承担。

而更要命的是,如果商家发现这个活动漏洞时,就可以自导自演,同时扮演“商家”、“购买者”双重角色,疯狂套取这25%的活动补贴。

事实上,类似的案例并不少见,本质上还是产品同学对商业化需求设计缺乏经验,尤其是对于涉及运营费用类设计不敏感,从而输出逆商业化的设计,还让公司蒙受损失。

其实,说了这么多,产品同学在设计之路上可能会犯各种各样的错误,甚至自己也会因此要承受被扣绩效等处罚,但往往越是低级的产品错误越是显微镜、越是放大镜,越能描绘产品人的能力画像。

当然,除了本文提到的这三点,其实还有很多设计错误需要改正和提升,比如在用户体验上相关的设计深度,可谓是永无止境。

但是,我们对此要有认知,并且要勇于、乐于下沉和修正,正如前面所讲的,在整个大环境都在消费降级的时候,没有谁是不可被替代的!

所以,目光和行动都得下探。

本文由人人都是产品经理作者【产品大峡谷】,微信公众号:【产品大峡谷】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 在追求设计创新与美观的同时,更需注重设计过程的严谨性与沟通的有效性,以确保产品能够真正满足用户需求,实现商业价值与社会价值的双赢。

    来自广东 回复
  2. 所以文章所举的案例,本质上是产品同学对商业化需求设计缺乏经验导致的,输出逆商业化的设计,让公司蒙受损失了。

    来自广东 回复