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