惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hugging Face - Blog
Hugging Face - Blog
Recent Announcements
Recent Announcements
V
Visual Studio Blog
博客园 - 叶小钗
H
Help Net Security
aimingoo的专栏
aimingoo的专栏
宝玉的分享
宝玉的分享
U
Unit 42
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
F
Fortinet All Blogs
V
V2EX
Stack Overflow Blog
Stack Overflow Blog
WordPress大学
WordPress大学
D
DataBreaches.Net
J
Java Code Geeks
H
Hackread – Cybersecurity News, Data Breaches, AI and More
A
About on SuperTechFans
酷 壳 – CoolShell
酷 壳 – CoolShell
量子位
C
Check Point Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
小众软件
小众软件
Microsoft Azure Blog
Microsoft Azure Blog
M
MIT News - Artificial intelligence

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
因为这些设计被扣钱,到底冤不冤?
AI产品大峡谷 · 2024-08-06 · via 人人都是产品经理

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

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

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

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

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

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

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

前段时间去北京出差,顺便拜访了百度的产品同学,他向我讲解了百度对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 协议。