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

推荐订阅源

L
LangChain Blog
C
Check Point Blog
月光博客
月光博客
Y
Y Combinator Blog
I
InfoQ
B
Blog RSS Feed
P
Proofpoint News Feed
腾讯CDC
博客园 - Franky
MyScale Blog
MyScale Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
V
V2EX
Hugging Face - Blog
Hugging Face - Blog
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
云风的 BLOG
云风的 BLOG
罗磊的独立博客
B
Blog
人人都是产品经理
人人都是产品经理
Engineering at Meta
Engineering at Meta
MongoDB | Blog
MongoDB | Blog
Recent Announcements
Recent Announcements
美团技术团队
大猫的无限游戏
大猫的无限游戏

人人都是产品经理

为什么你的产品找不到差异化?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产品大峡谷 · 2022-09-15 · via 人人都是产品经理

我们都知道在工作与生活中,最难做的事情,往往也是最有价值的。对于产品经理而言,最难做的一件事情是什么?作者结合自己的实际情况,与大家分享他认为产品经理最难做的一件事以及一些应付的经验,希望对你有所启发。

最难做的事,往往也最有价值。

有人问了我一个很大问题:什么是产品经理最难做的一件事?我当时在开会,没来得及细想,晚上合上笔记本,坐在车里思索良久,我觉得对产品经理来说,最难做的事可能也是最有价值的事,四个字就可以讲清楚,那就是:保持平衡

结合上周的几个产品小案例,分享给大家一些经验。

一、业务思维还是产品思维重要?

上周在各事业部的每周工作例会上,镜同学被副总裁批评了,原因是产品思维稍强,业务思维太弱,导致项目进度进展过于缓慢。虽然批评很委婉,但的确一针见血,事情是这样的:我们在厦门有个项目,根据业务需求,我和业务总监A做了一个方案,我从产品角度出发,提出应该对某个系统做优化调整,以便更好地满足客户的真实需求。

业务总监A也同意了,项目也启动立项,我们产品开始着手进行产品的优化设计,根据需求,主要是增加“数据应用类”的功能设计,预计一个月左右上线,但业务总监A未及时汇报给副总裁。

结果,客户时间比较着急,对方boss直接与我们副总裁沟通,询问时间怎么这么久,解决方案不是现成的吗?

会上领导讲到:镜同学作为产品负责人用产品思维看待问题并没错,但业务总监A作为业务负责人应该从商业角度着手,用业务思维解决问题,应该在现有的产品功能体系下,先拿出解决方案,让用户先用上系统,再不断地去优化完善。

试想一下,你们要做的功能都是数据应用型的、统计分析类的,这样的功能你就是现在给客户他们也用不上,完全可以在方案中讲清楚,先让用户使用着现有的产品功能,等数据积累好了,统计分析类的就能发挥效能。而绝不是单纯地用产品思维去解决业务问题,要学会找平衡,该用业务思维时就要用业务思维,产品思维就要退一退,该用产品思维时就要用产品思维,业务思维就要退一退。

事后我复盘,领导的批评虽然委婉,道理却发人深省:最难的事在于找平衡点,什么时候该用业务思维(比如,新项目洽谈),什么时候该用产品思维(比如,功能沉淀优化)。找准了,事就成了

二、领域驱动设计的案例应用

《领域驱动这设计》这本书终于看完了,说实话,获益匪浅,对产品经理的设计思维有很大的启发,再一次推荐给大家,当然,书中的案例也更容易应用到实践中,上周我们的一个评审会我就引用了其中案例。

上周二,我们对“支付中台”的功能设计进行内部评审,其中也涉及“账户余额”这个字段,以往我对这个字段的理解只是数据表里有这个字段,每次需要使用时直接调用即可,但实际上,这个简单的字段设计有两种实现方式:“以状态为主”和“以事件为主”。

假设账户原本有100元,工资入账20000元,消费出账1000元,那么账户状态是多少?100+20000-1000=19100,下面看看“以事件为主”和“以状态为主”的两个视角的区别。

方式一:以状态为主

以状态为主的视角做法是:在每次出入账事件发生时,在数据库的进出明细表中添加记录,如入账记录20000元,然后同时将账户表中的余额字段改为20100。

也就是说,余额的计算是在写入明细表数据时同时进行的,明细表与账户表同时进行写操作,如果一张表写入错误,已经写入的另外一张表必须回滚,这是依靠数据库的ACID事务机制保证的。

ACID事务除了保证两张表修改的完整性,还会防止同时修改账户表的余额字段,因为账户表的余额字段是一个共享字段,如果有很多写操作同时发生,肯定会发生同时修改这个共享字段的情况,那就会发生竞争,ACID中的隔离性就是为了避免这种竞争而设置的属性,通常通过上锁实现,代价是牺牲性能和吞吐量。

方式二:以事件为主

但是,在事件溯源架构下,虽然同样还是要保存事件发生的明细,但是写入明细表以后,就不会去修改账户余额的状态,这样,整个写入过程就不会遭遇共享资源的争夺,也就没有必要使用事务机制,只是追加新记录,甚至可以使用普通磁盘文件,日志文件也是一种事件日志。

既然账户余额并不是在写操作时修改,那就需要在读取数据时实时计算。当每次读取账户余额字段时,首先读取事件明细表,获得入账事件20000元和出账事件1000元这样的事件集合,然后计算100+20000-1000=19100。

有人觉得每次读取都进行计算性能会差一些,这个问题可以通过缓存得到优化。缓存其实是一种快照,第一次读取余额状态时会计算一次,然后将结果保存到缓存中,如果写入事件明细再次发生,就会删除缓存中的余额数据,等待新的“第一次读取请求”发现缓存中没有余额数据了,就会转而从数据库中获得余额的初始值,然后读取进出事件表,最后计算出当前余额,保存到缓存中,供其他读取请求快速获得。

在评审会时,一开始我们的产品经理也是以为是通过数据表直接查询该字段,我便将这两种实现方式都跟大家分享了一下,得益于书中的案例应用,我们对技术思维有了更深的理解。

实际上,我们还可以发现,在技术实现上也遵循着“平衡法则”:“状态为主”并发时容易发生竞争,上锁虽能实现,但会牺牲性能;“事件为主”不会发生资源竞争,但也会降低性能,不过,通过缓存就可以得到优化。

矛与盾,巧妙地演绎着动态平衡。

三、晋升中心副总监

群里的同学可能已经知道,镜同学月初被提拔为研发中心副总监了。

主要负责产品设计部,技术开发部,测试部,运维部四个部门日常工作,当然80%以上的精力还是产品设计,毕竟还兼任产品总监。

我在群里跟产品同学分享了一个感悟:人生最难的事有哪些?

我觉得找平衡一定是其中之一,组织架构调整的同时,也有很多事情随之而来,木秀于林风必摧之,逆境时需要保持乐观,同样的,向上时一定要有向下的心态,这就是所谓的“一阴一阳之谓道”,就是“易经思维”,本质就是找平衡。

镜同学这次升职其实心态十分平和,不骄不躁,为何呢,说心里话,还是读书的原因,读《资治通鉴》,读《史记》、读《易经》,以史为鉴:历史不会重复,但总会押韵

升职当天我还自占一卦,竟得“坤”卦:

1. 卦辞

元亨,利牝马之贞。君子有攸往,先迷,後得主。

略懂易经的应该知道意思:要有龙马精神,要遵循上位领导,凡事未思考先自己行动就会迷失,低调后发则可获得认可。

2. 其初六爻词:履霜坚冰至

意识是,鞋子上有霜,不清除就会结冰,小的毛病或坏的习惯,微妙的关系,不去处理就会滚雪球成灾害。

3. 六三:含章可贞,或从王事,无成有终

意思是,不要急于表现,有点小成就兴奋,就很难有大的发展,也很容易走下坡路,要有内涵修养。

易经这本书,读了几遍,六十四卦可熟练背诵,张其成老师,曾仕强老师视频也反复看了很多遍。

浅薄认知:易经作为群经之首,中华之典,真的可以让你趋吉避凶,但这并非玄学,底层在于改变你的认知,心态,让你学会找平衡:

  • 刚去一个新环境,你想要快速证明自己,易经却提示你,不要急于表现,先要学习周边情况,熟悉掌握信息,这就是“潜龙勿用”。
  • 你工作中犯了错了,很是自责懊悔,易经却告诉你:风雷益,君子以见善则迁,有过则改。(看到善言善行的人就虚心向他学习,而看到自己有过错了就马上改正)
  • 你职位晋升,事业顺风顺水,易经却立马警示你,要对下布施,学会利益分享,这就是“损上益下,民说无疆”(意思是减损上面增益下面,民众很喜悦,喜悦的范围没有边界)

在我看来,产品经理是一个综合思维的岗位,天花板很高,但同时需要掌握的技能和思维能力也很多,在纷繁多杂的当下,对产品经理来说,最难做的事就是多一份平和,不断去修正,动态去调整,始终处于平衡发展状态。一样米养百样人,每个人都有自己的思维习惯,找平衡需因人而异,但道理却很朴素,以至于可以充实在产品生活的每一处:

  • 你周末很愉快,玩的很开心,可明天还有评审会,这个时候你就要去找平衡:周日晚上提前看一个小时原型设计,第二天评审一定会更加顺利。
  • 你产品设计很优秀,汇报演讲很成功,以至于升职加薪,歌颂纷至沓来,你必须有平衡心态:遁者,见之先也。(要在关键上升期学会隐藏锋芒)
  • 你需求调研、产品设计就差临门一脚,中途受挫,你想放弃,此时平衡出现在你脑海:人但有恒,事无不成。(行百里者半九十)

镜同学以为,易经并没有用宏达的叙事,也没有用夸张的修辞,正所谓其大无边,里面的人生哲理可受用终生,甚至包含一切的产品思维。

从这个角度来说,他所彰显的朴素逻辑一定直抵人心,以我浅薄地认知看来,易经的低调魅力与巨大威力,正是通过帮你重塑平衡,让你可持续地向上前行。

也正如《易经》所言:凡益之道,与时偕行

专栏作家

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文由@公众号:产品大峡谷 原创发布于人人都是产品经理,未经许可,禁止转载。

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。