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

推荐订阅源

Martin Fowler
Martin Fowler
D
DataBreaches.Net
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
The GitHub Blog
The GitHub Blog
Blog — PlanetScale
Blog — PlanetScale
Microsoft Security Blog
Microsoft Security Blog
A
About on SuperTechFans
Vercel News
Vercel News
L
LangChain Blog
B
Blog RSS Feed
Y
Y Combinator Blog
IT之家
IT之家
H
Hackread – Cybersecurity News, Data Breaches, AI and More
GbyAI
GbyAI
V
V2EX
博客园 - 三生石上(FineUI控件)
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
阮一峰的网络日志
阮一峰的网络日志
有赞技术团队
有赞技术团队
D
Docker
V
Visual Studio Blog
aimingoo的专栏
aimingoo的专栏
Last Week in AI
Last Week in AI
月光博客
月光博客

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
产品实操系列 | “需求执行”可不是优先级象限图可以直接解决的...
觅云人 · 2024-10-05 · via 人人都是产品经理

在设计流程中,适当用一些方法,可以提高我们的工作效率。本文分享的象限图,希望可以帮到你一臂之力。

帮助创业团队做产品 第8篇 版本 v1.0

“Begin with the end in mind.

先有目标再行动。”

——史蒂芬·柯维

Stephen Covey

这句话还有更加信达雅的翻译:以终为始。

而这句话的作者,就是重要和紧急四象限图的发明人。

很多年前,我跟过一位美女老板,还是高知。

她有很多特点,但最大的特点就是需求执行的特别快。‍‍‍

经常会出现这样的情况:比如见到了某个客户,比如周末脑海中蹦出了某个想法,比如听了身边的朋友说了一嘴。

立即回来开全员会,然后拍板定出来,确定这是一个很重要的目标。

让全公司放下手头的产研任务,果断执行。

然后,一般过了2周左右,再重复一遍这个流程,因为新的更重要的目标又又又出现了。

就这样周而复始……

所有人都戴着痛苦面具,当然也包括她自己。

一、重要和紧急四象限图:超简单却超难以执行

↑ 我将以此图为大纲,帮助创业团队完善产品能力

今天这一篇,开始针对看板图的最左上角的:

需求分析能力 -> 需求执行

帮助创业团队做产品系列,关于创业团队的产品能力看板需求分析能力这个分类,之前讲过了需求涌现需求分析需求验证,最后再聊聊需求执行。

这张图简直太有名了,是美国著名管理学家史蒂芬·科维(Stephen Covey)提出的。对了,作为摩门教徒,他有9个孩子和49个孙辈。

这个图简简单单,一看便知。

许多做运营的,做产品的,乃至做管理的都十分熟知这张图。

那么,这叫我如何才能水上一篇?

……

但事实其实并不简单,能看到几乎所有团队都了解这张图,却几乎没有看到有团队可以很好地执行这个标准。

任何思维图都只是工具,团队内必须达成共识才能做下去。

共识的关键其实还是在操盘的一把手,也就是创业团队的Boss,或是中大型公司的部门管理者。

他们不光要认可这个象限图工具,更要提供统一的标准,才能把这个推动下去。

所以,一定要从管理者角度进行推动。

……有的时候我在想,管理这种东西可能真是学不来的,高雅了就是乐队的指挥,接地气了就是饭店大堂经理。

真正能指挥一群人把混乱、啰嗦、复杂的一堆事情可以处理的井井有条,这其实真的是一种天赋。

二、在产品需求中:应该怎么执行?

首先要做好定义

定义方式很多,我提供一个参考,供讨论:

什么叫“重要”

1.代表了和战略相关,和团队现在的、或者未来的生死存亡相关。

2.在战略契合性上,针对创业团队,我建议可以参考之前的内容:闭环,以及驱动闭环的增长飞轮

什么叫“紧急”

1.代表了必须要马上做的需求,我看到有文章的表述是有问题的,如果这个需求不需要马上就要去做的,则说明根本不紧急。

2.往往和应用层面相关,即和用户相关。

按照这个分法的话,其实可以解决很多疑惑。

举个例子来增加理解

还是拿之前曾举过的电商行业来举例吧,假设现在存在有如下若干个需求待解决:

  • 一个影响下单的严重bug
  • 在用户订单列表页,偶发的一个小bug
  • 某段重要描述有错别字
  • 营销活动提前了,今晚就要打开入口
  • 后台的营销统计功能需要实现
  • BD同事谈了网银支付功能,用户下单能有折扣
  • 商品详情页下,缺乏同类型的商品的推荐体系
  • 某重要流量来源的落地页转化率优化尝试
  • 缺乏折扣前的原价显示
  • 某处详情介绍页,UI实在不好看,需要重新设计。

让我们一个个来分析下:

一个影响下单的严重bug

重要吗?废话当然重要,不用分析;

紧急吗?今天不下班也要搞定,当晚就得上线。

所以是“重要且紧急”

在用户订单列表页,偶发的一个小bug

重要吗?一般来说,用户查看订单列表其实不是普遍行为,更何况bug是偶发的。

紧急吗?偶发bug,大多数情况下可能不影响使用。

所以是“不重要不紧急”

某段重要描述有错别字

重要吗?如果是关键位置肯定很重要。

紧急吗?当然不紧急。

所以是“重要不紧急”

营销活动提前了,今晚就要打开入口

重要吗?假设活动的产品配合已经完成了,且完成了上线部署。

紧急吗?突然要提前了,所以打乱了工作计划,需要给出资源做配合。

所以是“不重要但紧急”

……

按照这个方法,我们可以把这些需求进行一一匹配:

还是需要说明的是,这此处只是举例子,真正的需求执行应该根据真实状况来进行整理。

三、另外几点重要的技巧:能更好的利用此象限工具

重要且紧急

要占50%的资源

仔细分析手头要执行的需求,并非是所有的事情都是非常重要和紧急的,也不能把资源吃得满满的。

这里面最大的风险就是老板,老板经常会提出他认为“重要且紧急”的需求,因为老板也是人,而且他往往是整个公司最焦虑的那个人,需求的频繁提出和变更其实正是来源于他的焦虑。

当然,高水平的老板自会运筹帷幄,但在当下更是少之又少。

重要不紧急

占剩下50%的资源

如果重要的事情不去做,那么以后全都是紧急的事情。

不重要但紧急

尽量少发生

要让团队内所有人都达成共识,要把需求放入这个象限的行为是非常严肃的,一定要越少越好

偶尔可以发生一两回,但如果被占满了,这个团队将一事无成。

不重要不紧急

随手做、或不做

比如UI问题,比如小bug问题,可以在重要性高的需求上线的同时,随版本上线来完成。

也可以不做,毕竟创业团队哪有那么多资源。

……

其实需求四象限不仅仅是可以用在产品需求的执行上,更重要的应用是用在管理上。

那就留待我后面讲团队管理的时候,继续水吧。

本文由 @觅云人 原创发布于人人都是产品经理。未经作者许可,禁止转载。

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

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