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

推荐订阅源

S
Secure Thoughts
Recent Commits to openclaw:main
Recent Commits to openclaw:main
H
Heimdal Security Blog
SecWiki News
SecWiki News
H
Hacker News: Front Page
N
News | PayPal Newsroom
L
LINUX DO - 最新话题
N
News and Events Feed by Topic
TaoSecurity Blog
TaoSecurity Blog
AI
AI
C
Cybersecurity and Infrastructure Security Agency CISA
Scott Helme
Scott Helme
PCI Perspectives
PCI Perspectives
S
Securelist
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
Cyberwarzone
Cyberwarzone
A
Arctic Wolf
Forbes - Security
Forbes - Security
T
Tor Project blog
Spread Privacy
Spread Privacy
WordPress大学
WordPress大学
I
Intezer
Martin Fowler
Martin Fowler
Help Net Security
Help Net Security
P
Proofpoint News Feed
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Cisco Talos Blog
Cisco Talos Blog
Latest news
Latest news
博客园 - 司徒正美
W
WeLiveSecurity
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
V
V2EX
P
Palo Alto Networks Blog
Google DeepMind News
Google DeepMind News
IT之家
IT之家
阮一峰的网络日志
阮一峰的网络日志
V
Vulnerabilities – Threatpost
Jina AI
Jina AI
S
Security Affairs
Hacker News - Newest:
Hacker News - Newest: "LLM"
Simon Willison's Weblog
Simon Willison's Weblog
Project Zero
Project Zero
T
Threatpost
P
Privacy International News Feed
人人都是产品经理
人人都是产品经理
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Application and Cybersecurity Blog
Application and Cybersecurity Blog
博客园 - Franky
Hugging Face - Blog
Hugging Face - Blog
Apple Machine Learning Research
Apple Machine Learning Research

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
设计问题中的不确定性
我是芝士 · 2022-09-23 · via 人人都是产品经理

想必对任何做设计/规划/策略为工作的人来说,意见不统一、结果无法保证、因果关系模糊不清的情况经常会出现。那么理想的设计过程是什么,如何开始一场理想的设计便尤为重要。作者也提出了自己的见解,希望对你有帮助。

题中的“设计”是一个比较宽泛的概念,不仅仅指交互设计、UI设计、产品设计,而是泛指“有目的的规划行为”。但是会主要以互联网行业的案例来说明。

一、设计师的日常烦恼

对任何以设计/规划/策略为工作的人来说,以下这些情况想必是家常便饭。

(1)意见无法统一、争论不下

我觉得这个方案好,你觉得那个方案好,谁也说服不了谁;这些都不太好,你还有没有更好的方案;定稿后有人提出新的意见,再改一版!

(2)结果无法保证

明明调研得很充分,分析思路很清晰,上线后却不如旧方案。

(3)因果关系模糊不清

这个banner变小了,为什么反而点击数据上升了?

那这篇文章能帮你避免这些情况吗?很遗憾,不能。但或许你能了解为什么会出现这些问题,以及如何与这些问题相处,并改善它们。

二、理想的设计过程

当我们将以上的情况视为烦恼时,其实有一个假设——我们觉得一个理想的设计过程能够一步到位解决所有问题,得到大家的普遍认可。我们追求的是确定性。比如以下这种设计的线性方法。

1. 设计的线性方法

设计的线性方法通常包含两个不同的阶段:问题定义、问题解决。

1.问题定义

在这个过程中,设计师确定所有要素,以及设计成功的解决方案所需要具备的所有条件。

2.问题解决

在这个过程中,设计师综合、平衡所有要求,产出设计。

——Buchanan R. Wicked problems in design thinking[J]. Design issues, 1992, 8(2): 5-21.

网上的项目复盘、设计作品集中经常能看到这种线性的设计流程,通常也会配以相当漂亮的数据反馈,比如以下这个例子(纯假设,非真实项目):

一个外卖平台的核心指标是GMV,设计师通过对GMV的拆解,得到这样一个公式:

GMV=日活用户数*每日每人平均打开次数*商品选择转化率*下单转化率*完单率*客单价。

经过调研发现,影响商品选择转化率的重要因素包括:商品推荐的准确度、商品图片的吸引力、价格、预计配送时间、配送费。

看起来只要解决了上面这些重要影响因素,就已经找到了商品选择流程的最优解,并能提升GMV,增加公司收入。

真的有这么简单吗?不如看看真实世界中的设计过程。

2. 真实世界中的非线性设计

订单配送时长的降低确实带来了收入的增加

– 2019年,中国全行业外卖订单单均配送时长比3年前减少了10分钟。
– 2019年第三季度,每单收入比2018年同时期增加了0.04元,每单成本则同比节省了0.12元——这也帮助美团在2019年Q3,多赚了整整4亿元。
——人物作者,公众号:人物《外卖骑手,困在系统里》

但同时,也给骑手和交通系统带来了风险

– 2017年,上海市公安局交警总队数据显示,在上海,平均每2.5天就有1名外卖骑手伤亡。
– 2018年,成都交警7个月间查处骑手违法近万次,事故196件,伤亡155人次,平均每天就有1个骑手因违法伤亡。
——人物作者,公众号:人物《外卖骑手,困在系统里》

后来,美团修改了外卖配送的计时机制,从原来的时间点修改为时间段。饿了么推出了“连续送单超过4小时,系统发出疲劳提示,20分钟不再派单”的规定。

可以发现,平台方的设计目标、考虑因素发生了改变,由最初的效率、利润,到后来加入对骑手交通安全的考虑。设计的线性方法在这里失效了,在问题解决之后重新返回到问题定义阶段。

3. 持续的治理过程可行吗?

既然设计无法一蹴而就,实施一个持续的治理过程可行吗,包括不断寻找目标、发现问题、预测环境变化、调整解决方案、实施方案、收集反馈、调整方案。

然而我们面临的问题不仅仅是信息的缺乏,发现更多的目标或问题不能确保完美的结果。

三、为什么线性方法或持续治理不可行?

真实的问题是不确定的:目标不确定,问题影响因素不确定,人的认知也不确定。

1. 多元目标带来的不确定性

(1) 在设计问题中,不同利益相关者有不同的目标,可能互相冲突

比如外卖问题中,有平台、商家、骑手、顾客、政府等角色参与其中,每一方都有自己的诉求。

  • 平台方希望获得更多的收益。那就要尽可能地提高送单效率,比如通过算法优化派单路线,减少每单配送费支出,压缩每单规定送达时间。
  • 骑手希望用更慢的节奏、更少的单量,赚更多的钱。
  • 而顾客希望用更少的钱,获得更快的外卖服务,还不要洒汤。
  • 政府希望能减少交通事故,同时也希望外卖平台能有更多产值,贡献GDP增长。

(2)即使是同一群体甚至每个个体,也会拥有不同的目标,这些目标有时会互相制约

  • 当我们自己点了外卖时,我们希望送得越快越好,会因为骑手送慢了给差评。
  • 当我们看到外卖骑手因为赶时间发生车祸,我们责备平台不人道,压榨底层劳动人民,表示愿意接受外卖送慢一点。

即使凭借持续的治理过程发现了这些目标,如何能找到这些相互冲突的目标的最佳平衡点?

2. 问题影响因素的不确定性

(1)在社会这个网络中各个系统相互连接,导致无法确定所有影响因素,以及解决方案可能带来的后果

在共享单车出现之前,城市规划设计师怎么会考虑到人行道会被共享单车如此占用?

(2)影响因素随着时间变化发生变化

出行更方便的需求是一直存在的,那为什么直到2010年才出现了uber?因为线上打车的几个必要条件在不久前才得以实现:便宜的智能手机、精准的定位、流畅的网速。

3. 面对相同的信息,可以产生不同的想法

假设现有一个数据:在现有用户中,60%的用户每月定10次外卖,40%的用户每月定20次外卖。

  • 或许有人会认为,这将是未来一段时间的常态,在频次上我们已经无法再提升了。
  • 也可能会有人认为,现在远远未到稳定状态,只要我们加大运营力度,可以让那60%的用户也加大订外卖频次。
  • 当然也可能会有人认为,现在这个单一的数据无法支撑我们做决策,我们需要调研这60%的用户为什么每个月只订10次外卖。

假设经过调研,我们获得了新的数据:在这部分每月只订10次外卖的用户中,有80%是因为外卖太贵了而没有订更多。然而面对这个增加的信息,或许我们又会有更多不同的想法。

  • 或许会有人认为,我们投入更多资金,降低订餐价格,让这部分用户养成习惯,即使价格未来回到正常水平,他们也会保持这个习惯。
  • 亦或会有人认为,一旦没了优惠,这批人就不会再点外卖了。
  • ……

能找到一个正确的的方案吗?

四、设计问题是诡异问题

这种无法确定的设计问题,Rittel在《Dilemmas in a General Theory of Planning》将其称之为诡异问题(Wicked Problem),并详细描述了这种诡异问题的特性:

1.一个诡异问题没有明确的描述。

2.诡异问题可以从不同角度解释,解释的选择决定了问题解决的性质。

3.每一个诡异问题都可以被理解为另一个诡异问题的征兆。

4.每个诡异问题本质上都是独一无二的。

5.诡异问题没有可枚举的(或可详尽描述的)潜在方案集合,也没有详尽描述的可纳入计划的可允许操作集合。

6.诡异问题没有停止规则。

7.每个诡异问题的解决方案都是“一次性操作”,因为没有机会通过试错来学习,每一次尝试都很重要。

8.诡异问题的解决方案没有直接和最终的考验。

9诡异问题的解决方案没有对错,只有好坏。

10.规划者没有犯错的权利。

——Rittel H W J, Webber M M. Dilemmas in a general theory of planning[J]. Policy sciences, 1973, 4(2): 155-169.

五、如何应对诡异问题

1. 设计方法无法解决所有问题,应深入业务与用户,获得对影响因素的认知

设计问题的诡异性导致,没有一个通用的设计方法能完美应用到所有具体的设计问题中,因为每一个问题都是独一无二的。一些设计师将他们过往的工作经验抽象成方法论,这些方法论或许能帮助你成为一个讲道理、有逻辑的设计师,却无法确保你做出好的设计。

因为这种方法论注定无法覆盖设计问题中的具体细节,而这些细节却是我们设计决策时的关键因素。

设计问题中的不确定性

比如上图这个五导家设计方法,无法告诉我们外卖平台的”价值变现方式“应该是为了让用户尽快拿到外卖,压缩配送时间,还是考虑外卖员的安全、舆论导向、企业的社会责任,牺牲一些送餐速度。它甚至不会告诉我们在设计算法时,应该将这些因素加入考虑。

深入业务与用户场景才能获得对这些关键因素的认知。

2. 影响因素持续变化,保持对变化的跟踪

由于问题网络中各因素互相影响,任何一个看似不相关的因素的变化,都可能导致行业的巨变,比如通信技术的发展,导致了出租车行业的巨变。

期望通过定期的行业调研来捕捉这种因素是不现实的,一是因为这种因素不会定时出现,同时也因为这种因素可能不出现在本行业中。

对于社会、科技有广泛兴趣的人或许更能捕捉这些因素的变化。当然,很多时候即使我们目睹了这些因素的出现,也无法将其与自身的行业联系起来,这或许只能靠洞察力天赋以及偶尔闪现的灵感。

3. 不要在先入为主的类别中限制思维

范畴(category)具有固定的含义, 在理论或哲学的框架内被接受, 并作为分析现有事物的基础。立场(placeement)具有塑造和约束意义的边界,但不是严格固定和确定的。立场的边界为思考提供了一个上下文或方向,但应用于特定情况可以产生对该情况的新感知,从而产生一种新的可能性进行测试。
——Buchanan R. Wicked problems in design thinking[J]. Design issues, 1992, 8(2): 5-21.

当你决定设计一个电风扇来降温,可能就放弃了更高效的降温方式——空调,或者一个更有趣的降温方式——水上乐园。

当你视自己为设计移动应用的交互设计师,便放弃了其他视角能看到的可能性,遇到通过界面设计、流程设计无法解决的问题,只能摊摊手说这不是我的职责范围。

当你视自己为用户的代言人,可能就忘记了站在外卖员的立场看看他们的生活状态,或者忘记了站在企业的角度看看是否商业可行。

一个成熟的设计师应该能切换多个立场看待问题,以发现新的可能性。

4. 避免不假思索地接受上游的方案

由于设计问题的诡异性,不同的人对于同一个问题可以从不同的角度解释,得出不同的解决方案。为了消除这种诡异性,一些在上游在向下游传达他的需求时,通常会提出一个他认为合适的方案。

有时候,这种上游认为合适的方案确实能提高沟通的效率,让下游知道其对于解决方案的预期。但是对于下游来说,应该清楚上游提出的这个方案只是一种可能性,可以通过讨论改变。

5. 高效沟通与决策

方案可以通过讨论改变,那么如何通过讨论,达成一致意见呢?经历过无休止的讨论可以说是任何“设计师”的必经之路。

为了解决这种无休止的讨论,可以参考这三家公司的做法。

在Facebook的工作流程中有两个术语。一个叫escalation,意思是说“咱俩这事意见不同无法统一,谁也说服不了谁,无法推进,找上级(可能是同一个)解决吧”。另一个叫disagree and commit, 意思是说“咱俩这事意见不同无法统一,谁也说服不了谁,但因为你是我上级,我服从”。
——https://www.zhihu.com/pin/1347954590105645057

在苹果,每个项目有一个“直接责任人”DRI(directly responsible individual),DRI最重要的是授权而不是追责,DRI不需要向任何人解释选择,如果你强迫DRI解释过多,会刺激他们在监控下发布项目,对陷入解释的无休止循环的恐惧会使DRI偏离轨道,导致人们推迟行动而不是带着对行动的偏见工作。其他人可以提供意见,但没有权力感受被倾听或在最后的决策中被考虑。
——https://www.notion.so/pmthinking/Vol-20220109-7e58d0dd4ed24ddaacfd2554410527bb

在coinbase的决策模型中也强调了在决策之前需要确定“负责拍板做决定的人“(一个或少数几个人)。
——G,公众号:胖福馒头《Coinbase创始人:从0到1000亿美元的公司如何做决策》

这三家公司对于如何高效决策的思路都是相似的,参与者可以提供意见,但最终拍板决策的人必须是少数人。其潜在逻辑是:更多的人并不能提升决策的质量,反而可能会降低决策效率。其理由也比较容易理解,不同的人的意见可以帮助决策者补充他的盲点,但群体决策却有可能使决策陷入无休止的讨论或是随机式的投票。

(1)什么样的人适合做拍板的人?

  1. 对问题领域拥有最丰富的经验
  2. 细节导向,兼具战略视角
  3. 有很强的沟通能力,会倾听,且善于提问
  4. 有承担的勇气和决断的坚决

需要警惕的是,有时候上级在指定“拍板的人”后会因为其决策不符合自己的预期,否决其决策。

(2)依靠拍板的人,其他人就可以躺平了吗?

当然不是,“一人拍板”机制只是为了解决“无休止讨论带来的决策瘫痪”。其他参与者提供的建设性意见是决策的基础与原料,作为“非拍板人”的每个参与者,都能提供自己独特的视角与观点,因为设计问题是诡异问题,站在不同的立场能获得不同可能性。

作者:我瞎说你瞎看

原文链接:https://mp.weixin.qq.com/s/rjUetGTkAypoBxMMAeS6cw

本文由 @我瞎说你瞎看 授权发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

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