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

推荐订阅源

罗磊的独立博客
The GitHub Blog
The GitHub Blog
Hugging Face - Blog
Hugging Face - Blog
博客园 - 聂微东
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
IT之家
IT之家
小众软件
小众软件
博客园_首页
G
Google Developers Blog
Apple Machine Learning Research
Apple Machine Learning Research
MyScale Blog
MyScale Blog
Engineering at Meta
Engineering at Meta
Jina AI
Jina AI
酷 壳 – CoolShell
酷 壳 – CoolShell
人人都是产品经理
人人都是产品经理
B
Blog RSS Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
D
Docker
B
Blog
雷峰网
雷峰网
WordPress大学
WordPress大学
Stack Overflow Blog
Stack Overflow Blog
宝玉的分享
宝玉的分享

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
当你把下一个环节当作客户的时候,一切就顺畅了
产品海豚湾 · 2023-07-31 · via 人人都是产品经理

当在团队协作时你遇到了问题会主动去向相关部门人员进行询问吗?或者领导交给你办的事情你发现有潜在的问题时你会主动去沟通吗?当我们在工作中遇到类似的问题时该如何解决呢?一起来看看作者是如何分析的。

前几天有一个产品经理在微信上向我吐槽,说明明在原型上有相应的说明,评审会也说过,但是最后还是会问他很多产品的问题,搞得他有点无语。

我相信这种情况是普遍现象,大部分人遇到问题第一时间想到的是最快解决问题的办法。对于产品需求不清楚地方,技术开发同学最快的解决方式就是找产品经理去问。

其实不仅仅是技术开发同学,在上下游配合中,当我们遇到上游有不明白的地方的时候,往往也会优先直接去直接问上游的人。

作为技术开发的上游,他们问的问题多了,经常打断我们的工作,难免会让我们觉得烦。然而,如果我们换一种思考方式,可能就不一样了。

一、把下一个环节当作客户

我们产品经理有时候也会参与到售后服务中,去解答客户的问题(个人推荐产品经理要抽出时间去做售后客服,直接面对客户获取一手信息)。我自己曾经加入到我们多个客户售后服务微信群,然后遇到了各种各样的问题。

有些问题非常简单,比如刚接触系统不久,找不到某个功能了;比如去哪里看xx数据等等。

这些问题其实看起来非常初级,但是我们却会耐心地解答,哪怕是觉得很繁琐也不会向他们表露出我们的情绪。

然而,到了和我们合作紧密的技术开发同学了,为什么反而会有情绪了呢?

说实话,一开始我这边同样会有情绪,觉得原型明明标注说明了,为什么不看?文档里写了,怎么不认真看文档?但是,后面我改变了这些想法。

印象中是看了《华为人才管理之道》这本书,里面有讲到了华为团队协作的要求,每个人、每个团队需要把下一个环节当作客户去服务。

从我们团队协作上来说,技术开发是产品设计的下一个环节,如果下一个环节工作做不好,实际上会影响到我们产品设计的工作价值。只有下一个环节的工作顺畅了,产生价值了才能体现你的价值,这其实和我们的产品与客户的关系是相同的。

客户如果用不好我们的产品,我们产品的价值就体现不出来,结果就是被客户弃用,造成客户流失。与客户不同的是,客户弃用产品后和我们可能不会再有交集,而我们和技术开发同学的工作配合是长时间持续的。

这就意味着,如果配合不好,我们的产品研发质量根本难以保证。

另外换个角度来说,开发同学愿意在开发前和我们确认问题,至少有两个好处,一个是说明他们比较认真负责,另一个是不会等到开发上线后才暴露我们的产品设计问题。

我也有遇到一种开发,全程不问任何问题,闷头开发,然后等到发版复核前才发现很多业务理解都是他自己想的,根本不符合产品需求,结果不得不返工修改,推迟上线。

所以,相比吭哧吭哧闷声开发的同学,我更愿意和提出问题的技术开发合作,大家在讨论的过程中能够提前查漏补缺,可以有效降低延期风险和减少上线后的bug数量。

对于产品设计来说,我们要把看原型、看文档的人当作我们的客户(或者用户),秉着他们能够轻松看懂的原则去画原型、写文档、做标注。这样,他们能够抓住关键信息,快速理解业务,反过来其实也能减少问题的数量。

二、做好下游

我们是技术开发同学的上游,也会是其他同事或者外部需求方的下游。换位思考一下,当我们有问题需要咨询上游的时候,以下两点可以帮我们做好我们“下游”的角色:

1. 有问题要提出来

这一点经常在和领导开会的时候出现,领导布置任务后,会问“有没有问题”。

不少人为了不给领导“添麻烦”,往往会说没问题。然而,可能到了要交付的时候却暴露出大堆问题,反而“添了大麻烦”。

我的习惯是,有问题我会提出来,哪怕是解决不了,至少让领导知道潜在的风险。如果是必须要解决的问题,那么更是要坚持让领导解决,而不是藏着捂着,最后等着问题爆发。

2. 不要零碎地提问题

国内企业内部沟通大多数都是通过IM软件进行的,好处是随时随地可以给同事发消息,坏处是随时随地可以“打扰”同事。

实际上,每个人每天专注工作的时间非常有限,如果经常被零零碎碎的临时事件打断,那么工作效率会非常低。

我自己曾经有一段时间不得不下班后工作,就是琐碎的事情太多,只有下班后有清闲的时间去专注工作。因此,我们有问题的时候,除非是那种需要马上确认的问题,否则建议是先列出问题清单,然后和“上游”同事约个时间一起讨论。这样双方的专注时间都会增加,效率自然能够提升。

比如,国外的邮件沟通其实就非常好,通常他们会把沟通的内容用清单列好,然后通过邮件和对方约时间。这种相比IM的方式,虽然时效性不强,但是其实效率会更高。

三、总结

在产研团队,个人认为团队氛围很重要,往往因为少数人情绪控制不好,结果影响整个团队的氛围。久而久之,整个团队互相看不顺眼,沟通不畅,配合效率大打折扣。

如果我们能够像对待客户一样对待下一个环节,以“用户思维”站在对方的角度换位思考,那么很多负面情绪都可以消退,甚至转变为推动认真负责的工作力量,让团队每个人的产出质量更高。

当每个人、每个团队需要把下一个环节当作客户去服务的时候,我们的产品研发、交付质量都会得到大幅提升。

专栏作家

产品海豚湾,公众号:产品海豚湾(ID:pm-dophin-bay),人人都是产品经理专栏作家。技术出身的产品经理,从事过 C 端产品和 B 端产品设计,擅长 SaaS 产品设计、产品架构设计和需求分析。负责的B 端产品完成了完整的从0到1,从1到 N 的过程,成功签约行业百强客户。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

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

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