PD · FW · 061
产品体验研讨小组
Study Group · study-group--jeff-weinstein
所属簇 产品设计、体验与 MVP 质量
解决什么问题
大公司中产品团队容易陷入内部视角,产品随时间推移产生"熵增"——各模块各自优化但端到端体验劣化。传统的 friction log 门槛高、频率低,难以让足够多的人持续以客户视角审视产品。
核心内容
Study Group 是一种结构化的客户同理心练习,让员工以角色扮演方式完整体验自家产品。
参与人员: 4-8 人,不限职能(工程师、销售、支持、活动团队均可),自愿报名。
流程:
- 临时编造一家虚构公司(如 "Dolphin Aquarium Industries")和一个业务目标(如"在农夫市集上卖门票")
- 从小组中选出一人担任"CEO",由 CEO 决定今天要做什么
- 全程以该虚构公司员工身份使用产品,目标是从头到尾完成该业务流程
- 时长约 1-1.5 小时,节奏要慢,不赶时间
两条铁律:
- 规则一:你不在这家公司工作。 不得使用任何内部知识(知道某个按钮在哪、知道某个文档链接有误但能绕过)。主持人一旦发现,立即暂停并要求重来。需要多次纠正,但参与者最终会真正"入戏"。
- 规则二:不解决问题。 不批评、不建议、不提方案、不报 bug。只记录,留待后续处理。唯一目的是练习客户同理心。
输出处理: 发现的问题汇入公司已有的 bug 分级流程,而非另建体系。设有 craft 相关的 bug 标签和 SLA(如 P0 craft bug 需 7 天内确认)。
规模化: 可设立 "captain" 机制让各团队自行组织。在 Stripe 几个月内已运行 25+ 场,250+ 人参与。
适用边界
- 适用于多产品线的大公司,尤其是产品模块化分工后端到端体验容易断裂的场景
- 不适用于单一简单产品或早期初创公司(创始人本身就是客户)
- 主持人需要有一定权威来执行"不使用内部知识"的规则
- Jeff 强调这是"非惩罚性、有趣"的方式——如果变成强制考核会失去效果
- 需要已有 bug 处理流程来承接输出,否则发现的问题无处安放
关键引述 · 原话
"Rule one is you do not work at Stripe and rule two is we're not here to solve any problems. This is just about practicing empathy for the customer." — Jeff Weinstein
关联卡片
与 Stripe 的 friction log 互补;与 "users having a bad day" 指标同属"用非自然方式对抗内部视角熵增"的方法体系。
出处:Jeff Weinstein · 03-podcasts/jeff-weinstein.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2