因为这些设计被扣钱,到底冤不冤?
消费降级的当下,没有谁不可替代。
经济下行的压力逐渐传导至末端,身边一两个月还没找到合适的工作的小伙伴越来越多了,最近找镜同学咨询和面试辅导的同学也骤增。
即使如此,我却劝说每一个同学:先苟住、等等看。
也许有同学反驳,是金子到哪里都会发光,不用过于焦虑和担心,干的不爽就换下一家,哪怕多等一个月呢?
但现实往往事与人违,这个逻辑也很简单,当你一两个月没有合适的机会下,大多数人都会撑不住压力而仓促决策,但人生就这么几个重要的十字路口,要遵循规划而不能赌概率。
从这个意义上来说,逆周期下的随意择业就很像用博弈心态来买股票,你很难坚持初心、长线持有,轻易购入之后往往就是快速换手。
前段时间去北京出差,顺便拜访了百度的产品同学,他向我讲解了百度对AI的布局和投入,一句话:外界认为百度所谓押中的AI风口,其实是等来的,是靠早期坚持的投入。
图 -↑ 百度参访有感
其实,人和组织一样,都需要求之于势,不可强求。
镜同学认为,在这个逆周期之下,最好的姿态就是储蓄,不只是现金账户的储蓄,更包括心理账户、技术账户,这也是近期和团队交流最多的话题。
我们团队不少同学也面临被优化的压力,但我并没有直接遵循公司的要求,强制考核而后逼退,没必要,同是打工人、相煎何太急。
曾仕强老师讲的《易经》,镜同学反复听了很多遍,在我看来,轻易裁人其实也是改变某个人命运,这并不是咱们这些凡夫俗子所能驾驭的。
当然,在其位也要对公司负责,所以我悄悄对优化的定义做了优化:优化不等于裁人,而是等于“升级”+“裁人”。
所以,对于名单里的同学,我首先给定个更高目标,比如初级升中级、中级升高级,如若两个月达成,升职加薪;如果达成不了,江湖再见。
而我需要做的就很简单:只需要找准对象、定好目标、全力培养即可。
但是,在这个深度培训过程中,我也发现不少初级同学所缺甚多,尤其是综合专业能力的确差距很大,不仅产品体验设计薄弱,就连业务功能的理解也有很大不足。
说实话,很多设计不符合规范,有些设计不完整,甚至有些设计是错误的,严格来说,有些同学的设计是应该被扣绩效的。
其实,对于咱们产品同学来说,个人的产品力就是核心竞争力,而在这个逆周期的当下,如果不有意弥补、抓紧提升,被汰换出局的风险就很大。
基于此,我也分享几个产品产品常见的低级错误,供大家参考学习。
1、产品语言 ≠ 用户语言
相信大家都听过这句话:产品设计不能盲目自嗨。
产品自嗨有很多典型特征,如,不去做市场调研、用户洞察,只是躲在实验室里自行推演;再如,固执地应用某个局限方法论,试图逆转用户的真实需求。
而反映在产品设计上,最常见的就是未把产品语言转化为用户语言。
随便举个例子:
团队有产品同学在菜单按钮命名时完全是产品视角,用户压根就看不懂,比如,二级菜单包括“资金账户”、“发票管理”、“账号管理”、“运营管理”,结果一级菜单命名为“办公管理”,结果每次向客户演示时都被询问什么是“办公管理”。
起初,该同学还沾沾自喜,认为自己很好地创造了一个高大上的新名词,但这就是典型的产品自嗨,因为用户压根就看不明白,抛开业务领域的错误不说,你哪怕叫做“综合管理”也好理解吧?
为此,我们还收到了投诉,反馈系统升级后不好用,很多菜单命名看不懂啥意思,按照管理制度要求,客户投诉我们是要被扣绩效的,该同学也被扣了绩效。
从表面看,他好像很冤枉,但咱们要明白,产品是业务的载体,不是功能的堆砌,我们的价值是让用户高效理解产品,而不仅仅是自我视角的盲目自嗨。
我早些年还见过,有同学在客户系统里的菜单命名为“用户字典”,我天,难不成客户也都是IT专家么?你就是叫做“配置管理”可能用户还能看懂,可字典是什么鬼?
所以,咱们在进行产品设计时一定要把产品语言转化为业务语言,转化为用户语言,让用户更高效地理解。
2、设计断层,业务不闭环
在产品设计过程中,确保业务闭环是基本常识,因为这直接影响到产品的市场接受度、用户满意度、商业转化效率以及可持续性。
但有一说一,现实中很多同学确实还停留在堆砌产品功能的阶段,表现在对业务场景理解不深刻,设计同业务存在割裂、断层,从而犯一些常识性错误。
举个例子:
前两年,我们后台管理系统有个功能是配置SaaS产品的SKU,可以设置B端企业客户中允许使用该系统的最大人员数,如,设置为100人,则该企业最多允许100名员工使用该系统。
这是很常见的设计。
可我们产品同学在设计时却未深刻考虑业务场景,没有把产品和业务做融合,更没有贯彻产品服务业务的设计常识,只是完全被动照搬了运营同学的政策,需求方咋写就咋做,坚决不多动脑筋思考用户场景。
因为业务策略上暂时就给了5类套餐,所以他设计的“最大人员数”这个选项值也是5个,即:10人、20人、30人、50人、100人。
某次业务同学对新客户进行系统演示,客户当场要求150名员工都加入,结果业务在配置时发现该选项竟然没有“不限”这个字段,还需要研发同学改代码,研发领导对该设计表示很震惊、很愤怒,坚决要求复盘追责、罚款扣钱。
后来我们组织复盘,起初该同学还没意识到自己的错误,认为自己没错,还理直气壮地说是按运营政策设计的,因为运营政策就是这5个类型。
但作为产品经理,如果但凡对该业务场景多思考一步,都不可能会犯这样的错误,更何况该需求设计本身就不符合闭环的基本逻辑。
咱们是设计师,不是需求方的翻译器,更何况内部需求方(业务、运营等)未必专业,他们提出的需求有太多需要推敲,有些甚至就是伪需求、错需求。
所谓“反正我是按业务方需求做的”、“市场需求就是这么写的”、“有问题也追责不到我头上”,等等,这些话千万不要成为设计懒惰的借口。
任何时候咱们都要牢记:产品同学最重要的价值就是业务价值。
所以,我们必须基于对应用场景的洞察与分析,缝合业务与需求的断层,应用闭环思维来设计,做出符合用户真实需求的产品。
众所周知,产品同学对商业化思维的深度应用非常重要,越是高段位越是如此,因为这可能会直接影响产品的市场接受度、用户满意度以及最终的商业效益。
优秀的商业化设计不仅是高效增长的支点,往往也是可持续的关键。
对此,镜同学的经验是:设计之初便同步思考对公司怎么盈利,而对运营相关的产品设计要足够敏感且始终绷着一根弦。
但有一说一,现实中很多同学还停留在堆砌产品功能的阶段,表现为缺乏对业务场景的洞察,对用户需求的理解并不深刻,对业务模式也只是被动地浅尝辄止。
他们往往习惯把领导对商业模式的诠释当做着手设计的基准线,但却从未思考为何如此。
而这不仅影响商业达成,甚至可能会为公司带来损失。
举个例子:
上个月,某产品同学和我咨询交流时提到一个案例,当时他们有一个“团队分佣”的运营需求,因为平台刚起步,所以运营提出对平台抽取的佣金进行二次补贴,即把平台抽佣的钱再补贴给平台的分销员。
于是,他们运营人员就提出对商品的交易额进行抽佣补贴,如,平台抽取10%的佣金,并计划将这10%拿出来补贴给相应的分销员。
不过,他们平台对不同商品的抽佣比例不一样,而这个平台的抽佣比例是根据品类而进行后台单独配置的。
可产品经理并没有对分销员的佣金比例同步做限制,没有设计“不得大于平台分佣比例”的判断条件,在页面元素上只是一个输入框,运营人员可以在0-100%之间随意输入。
但是,这种设计实际上存在很大漏洞的。
比如,如果某款商品平台抽佣比例5%,可运营人员却可以配置大于5%的佣金,比如,配置了30%,而这多出来的25%的钱却需要由公司承担。
而更要命的是,如果商家发现这个活动漏洞时,就可以自导自演,同时扮演“商家”、“购买者”双重角色,疯狂套取这25%的活动补贴。
事实上,类似的案例并不少见,本质上还是产品同学对商业化需求设计缺乏经验,尤其是对于涉及运营费用类设计不敏感,从而输出逆商业化的设计,还让公司蒙受损失。
其实,说了这么多,产品同学在设计之路上可能会犯各种各样的错误,甚至自己也会因此要承受被扣绩效等处罚,但往往越是低级的产品错误越是显微镜、越是放大镜,越能描绘产品人的能力画像。
当然,除了本文提到的这三点,其实还有很多设计错误需要改正和提升,比如在用户体验上相关的设计深度,可谓是永无止境。
但是,我们对此要有认知,并且要勇于、乐于下沉和修正,正如前面所讲的,在整个大环境都在消费降级的时候,没有谁是不可被替代的!
所以,目光和行动都得下探。