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

推荐订阅源

Blog — PlanetScale
Blog — PlanetScale
博客园 - 司徒正美
Vercel News
Vercel News
F
Fortinet All Blogs
月光博客
月光博客
G
Google Developers Blog
博客园 - Franky
GbyAI
GbyAI
The Cloudflare Blog
I
InfoQ
雷峰网
雷峰网
WordPress大学
WordPress大学
罗磊的独立博客
大猫的无限游戏
大猫的无限游戏
T
The Blog of Author Tim Ferriss
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 聂微东
小众软件
小众软件
腾讯CDC
B
Blog
量子位
V
V2EX
S
SegmentFault 最新的问题
Google DeepMind News
Google DeepMind News

人人都是产品经理

为什么你的产品找不到差异化?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方法论+2案例+1清单)
产品方法论集散地 · 2022-07-24 · via 人人都是产品经理

编辑导语:每一件事情总有它的解决方案,在工作中亦是如此,而有效的解决方案,一定是具有系统性的。作者以一个工作案例为导入,分析有效解决问题,希望对你有所启发。

有效的解决方案,一定是系统性的解决方案。

什么是系统性解决方案?

从系统结构(或连接关系)入手,而不通过改变症状(即只解决当前问题)或原因(即通过改变人,包括自己与他人)解决问题的解决方案

什么意思?

北京疫情要求全民核酸,前期每次社区志愿者都是通过移动式喇叭,从早到晚,间歇性的进行宣传,目的只是想让所有居民均参与核酸,避免有遗漏,从而导致疫情扩散。

志愿者不可谓不尽心尽力,居民不可谓之素质低下,可每次依然有不少遗漏之人。

后期则采用进出公共场合、办公楼以及乘坐公共公交,必须72小时内核酸(前期甚至是48小时)的政策。

同时推出两大赋能性措施:一是构建大量方舱,且提供免费核酸检测,便于常态化核酸的便利性;二是检测结果与地铁公交系统打通,以及所有公共场合严查72小时核酸,如不满足条件者,直接无法出行。

现阶段的疫情常态化防疫,保证72小时核酸检测正常方可进出公共交通、场所的政策,取得了阶段性的有效进展,这就是系统性的解决方案所发挥的应有作用。

【复盘】前期与后期的防疫解决方案,关键变化就是从通过改变人去解决问题(即要求志愿者更努力的催,居民更自觉检测),完全转变成系统性的解决方案(即改变居民出行、工作与核酸检测的关联关系)。

一、案例:如何在数据与资源受限情况下,通过有效解决方案实现业务目标?

假如你作为一名产品经理(简称PM)入职一家新公司,负责构建其辅导老师工作台,基于【需求是1,方案是0】方法论指导,完成前期的调研,并完成了相关的用户体验地图以及产品架构图规划(如下图所示)。

当你准备落地时,发现有两个关键性的限制条件:

  1. 你所必需的数据均存储在中台产研侧,你方作为业务方无法直接读取与运用;
  2. 你可用的研发资源有限,不足以支撑有效解决大版本迭代更新。

比如当前学员列表显示的是全部学员(包括在读以及退课、转班等),而辅导服务只针对在读学员即可,至于退课、转班等失效学员,列表中需剔除。

即使如此小的一个需求,但受上述两个关键限制条件(即学员以及状态数据不在你方数据库,以及研发资源限制),技术判断为当前研发模式无法实现,或即使可以周期也非常长,且只能按照不完美方案执行。

此时,下面3种选择,你会怎么选?

  1. 选择一:告辞,我不干了,此处不留爷,自有留爷处;
  2. 选择二:将此问题上升,让你的上级与研发leader介入,协助解决此问题;
  3. 选择三:改变自己的需求方式,提前构建需求缓冲池,保证整体需求可提前规划与排期。

我建议你哪个都别选,为什么?

选择一是一种逃避问题的解法,对于新入职的你,还不至于;

选择二是一种症状解。即上级领导的支援次数是稀缺的,此方案只能解决当前一个需求的问题,无法持续;

选择三是一种原因解。即我改变不了别人,那我至少可以改变自己的工作方式,但效果有限;

我建议你可以从系统层面去寻求根本解,而不是通过症状解(即仅解决当前问题)或原因解(即通过改变人,包括自己在内)去解决。

二、什么是系统?什么是才是系统根本解?

系统=目标*要素*连接关系

上述案例中,你作为业务PM的目标是:用最低成本、最高效率完成辅导工作台的构建,以此实现服务品质的规模化复制。

关键要素是:规模化团队(即辅导老师)、业务产研与中台产研;

连接关系是:辅导老师的规模化服务品质与人效的提升,依赖业务产研的支持;而业务产研因数据受限制于中台产研(双方却各自有自己的目标),资源受限制于编制与研发模式,导致难以有效进行工作台的建构,从而导致服务品质难以规模化,形成一个负向增强回路。

如果要形成系统性的解决方案,则需从三个关键要素的目标与关联关系入手,方可探寻到根本解。

中台产研的目标是:尽可能通用化所有能力,用最小投入赋能更多业务线;

辅导团队的目标是:尽可能快的用上更高效的系统,以便尽快提升人效,实现服务品质规模化;

你作为业务PM的目标与辅导团队的目标一致,却与中台产研目标有所差异。

从系统论的解决思路中,核心就是从多方目标与连接关系入手。

首先,中台产研目标是最小成本的通用化,那你就可以将你的辅导工作台的建设目标,当做其通用化的子集,形成双方目标的一致性;

其次,从连接关系看,则可采用专项双方进行混合共建的研发模式,改变你们双方的研发模式,由双方各自为战的模式,变成双方协同作战的模式。

案例最终采用了专项形式共建通用化工作台的方案,虽工期与预期有差距,但最终也完成了上线,并实现了整体最优的策略。

此方案既达到中台产研通用化最小成本的目标;也实现了业务产研侧的辅导工作台的建设,双方一起实现了对辅导团队的规模化服务品质的系统层支撑,从而达到整个系统(即公司)的最优解。

三、扩展:如何有效解决需求方随意提需求,浪费产研资源问题?

作为一名业务型PM,你可能会遇到业务方随意提需求的问题。有时苦口婆心1小时,方才拒绝了一个不合理小需求;有时你迫于无奈,被迫接受了一些需求,上线后发现无人使用,导致你被研发吐槽,公信力下降等问题。

此时如果有下面3个选择,你会选择哪个?

  1. 选择1:每个需求都当面对接,不合理需求就“动之以情,晓之以理”的柔性拒绝;
  2. 选择2:你努力提升自己辨别真假需求与说服人的能力,并定期给需求方的KP(关键决策人)进行培训与宣贯,让他们具备识别需求、理解产研成本的意识;
  3. 选择3:你构建一个需求缓冲池,并建立一种周会制,与关键KP进行需求准入情况、优先级与进度共识与同步。

无论你选择哪个,均正常,它们可能是你所处不同阶段、不同业务环境所能采取的解决方案。

我想提供一个第4选择,供你参考。即让需求方与产研方共背双方的绩效目标与成本。

为什么呢?

选择1其实属于症状解,每次只能解决当前的问题;

选择2属于原因解,即通过改变你跟需求方的能力模型解决问题;

选择3属于弱化版的根本解,即通过改变需求方与产研方的连接关系,让需求方来匹配产研方的目标以及工作模式;

选择4是典型的根本解,即通过改变需求方与产研方的目标,让双方形成共同目标与连接关系,结构性的解决问题。

当然,受限于企业组织架构等问题,选择4的实操成本可能比较大,鉴于此我们至少可选择3作为可落地方案。

四、总结

方法论:从系统结构(或连接关系)入手解决问题,而不通过改变症状或原因

即根本解才是系统性解决方案,而不是症状解跟原因解。

  • 症状解就是只解决当前症状的解决方案。比如案例中只解决当前那个需求的方案;
  • 原因解则是通过改变人(包括自己与他人)解决问题的方案。比如案例中PM自己构建缓冲需求池(或软磨硬泡洗脑研发要给力);
  • 根本解则是通过改变系统的目标、要素与要素之间的连接关系的解决方案(即系统=目标*要素*连接关系)。比如案例中业务产研与中台产研采取共建模式进行专项构建的通用化工作台方案。

实操清单:

  1. 先识别系统(如一个企业或部门)中的关键要素(如企业角色);
  2. 梳理清楚关键要素的关键目标(如角色A目标是增收,角色B目标是降本增效等,或是角色对应OKR与北极星指标等);
  3. 梳理清楚关键要素之间的结构或连接关系(如因果链、增强回路、调节回路、滞后效应等);
  4. 确认关键要素之间目标的差异,并找到影响结果的关键要素之间的连接(重点关注负向增强回路与调节回路);
  5. 弱化关键要素之间目标的不同,基于相同目标重构双方共同目标,并基于此将负向增强回路或调节回路切断,形成新的增强回路;
  6. 将目标、关键要素以及连接关系所生成的解决方案(一定不是依赖改变人,而是改变结构),与相关角色之间形成共识,并落地成为制度、流程、规则、策略等(如有必要可辅以产品化的工具支撑);

落地执行,在执行中收集反馈进行优化迭代,最终形成一种可执行、可落地的方案。

#专栏作家#

邢小作,微信公众号:邢小作之家,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。

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

题图来自Unsplash,基于CC0协议