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

推荐订阅源

The GitHub Blog
The GitHub Blog
Engineering at Meta
Engineering at Meta
博客园 - 聂微东
博客园 - Franky
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
雷峰网
雷峰网
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
L
LangChain Blog
WordPress大学
WordPress大学
H
Help Net Security
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Y
Y Combinator Blog
Blog — PlanetScale
Blog — PlanetScale
MyScale Blog
MyScale Blog
IT之家
IT之家
酷 壳 – CoolShell
酷 壳 – CoolShell
罗磊的独立博客
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
有赞技术团队
有赞技术团队
Apple Machine Learning Research
Apple Machine Learning Research
云风的 BLOG
云风的 BLOG
博客园 - 【当耐特】
P
Proofpoint News Feed
D
DataBreaches.Net

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
关于产品思维,你需要知道的3个用处
TCC翻译情报局 · 2022-08-02 · via 人人都是产品经理

编辑导语:如何在眼花缭乱的功能点中确定哪些值得做呢?你或许需要产品思维来帮助你做出判断。作者在本文中介绍了产品思维以及它在三个方面的作用:定义问题并确定开发功能列表,根据产品目标确定功能优先级,帮助设计团队成员达成一致。作者通过提出一系列问题帮助设计师思考问题和解决方案,同时介绍了多种模板和设计工具帮助设计团队更好开展工作。

想象一下这个场景。团队中一个成员找到你激动地说:“我刚刚参加了一个绝佳的销售会议,想到了一个我们必须开发的新功能!你点击这里和这里,再这样做,然后它就会像这样!”或许他甚至边说边给你绘制了草图,画完后问你:“所以我们什么时候可以实现它?!”你全程一直保持微笑,但是内心想的却是“辣鸡”。

先来做个深呼吸吧,然后产品思维会帮助你。

在我们讨论具体应对方法之前,先同步一下什么是产品思维。产品思维的核心是解决问题。当你应用产品思维时,你其实是在从问题到解决方案的过程中将用户需求摆在了首要和中心的位置。我们进一步看看如何让整个团队都像产品人一样思考。

一、产品思维帮助你判断构建什么功能(Product thinking will help you know what to build)

首先从定义问题开始。像用户画像和 JTBD这样的工具可以帮你定义问题空间。

问自己:

  • 你的用户是谁?
  • 你的用户需要做什么?
  • 痛点和阻碍是什么?

接下来,探索机会点。思考一下:

  • 我们可以如何帮助用户解决问题?
  • 解决这个问题对于用户和我们的业务来说有什么潜在的影响?
  • 无法解决这个问题的风险在于什么?

最后,探索可能的解决方案。研究一下:

  • 哪个解决方案对我们的业务来说是最合适的?
  • 我们的局限是什么?
  • 科技能帮助我们什么?

现在让我们回到刚刚的队友这里。在面对他人呈交的一个看似思虑成熟的解决方案时,最好的应对方式是什么?停顿一下,称赞对方的兴趣和热情,并有礼貌地将对话引导回问题本身。这里是一些你可以采用的方法。

我用我的团队的案例作为模板。首先,你可以简单地提出一些关键的问题。针对每个新的创意或解决方案问你的合作伙伴以下问题:

  1. 我们想要为 x 用户或 x 用户画像解决的问题是什么?
  2. 可能的解决方案是什么?
  3. 对于用户和我们的业务来说怎样算成功?

通过思考这些要点可以帮助从解决方案模式转换成产品思维模式并有助于与成员达成一致并通力合作回答上述模板中的问题。一旦他们熟悉了这个模板,你就可以让他们自主思考并稍后一起回顾检查。记得要鼓励你的团队提供数据分析、用户反馈、竞品以及市场调研方面的材料来支撑他们的思考过程。从 JTBD 框架中推导出的工作地图也可以很好替代上述最基础的模板。

如果你想与利益相关方进行更详细的讨论,你可以用 5W1H 方法来对问题、机会、解决空间进行深入分析。这个模板在工作坊中使用能获得最佳效果,过程中可以以小组的形式针对图中每个问题进行头脑风暴。

改编自 http://narenkatakam.com/

不要忘记一点 —— 如果提出点子的人无法清晰准确地描述问题就需要进行研究分析了。你可以进行一天的定性研究:发放问卷调研,做市场分析或竞品分析,或对产品进行数据分析。任何能够佐证问题是否亟待解决的数据都是有用的。

二、产品思维帮助你进行优先级排序(Product thinking will help you prioritize)

一旦你明确了需要构建哪些功能,产品思维还可以帮你排列需求的优先级。我认为产品经理们在优先级排序问题上受到很多不公平指责。

通常情况下,当确定优先级很困难且面临巨大压力时,产品经理会用框架模板帮助将功能排序。但是,当产品经理对确定需求优先级感到困难时,不是因为他们不擅长或没有正确的工具,而通常是因为对公司战略缺乏了解。产品经理需要明确公司目标才能成功确定优先级

让我们进一步看看公司目标如何关联优先级。想象你的公司策略由愿景、目标、指标和行动组成,在一个非产品主导的公司里,行动就会以一系列待排序的功能的形式给到你。但在一个产品主导的公司里是怎样的呢?公司目标就是产品目标的出发点。除此之外,你还可以将用户反馈、内部反馈和行业流行趋势作为考虑因素。

一旦你心中有了产品目标后再选择那些可以帮你衡量项目进展的指标。下个步骤就是产出、收集、有主题地聚类各种创意。这是很有趣的环节!你可以开展头脑风暴工作坊、设计原型、进行用户访谈,并利用其它创新技术帮助你拓宽领域。

理想状态下,你的目标、指标和创意通过研究逐渐确定下来,研究过程会帮你收敛和聚焦创意,得到最终的创意列表。如果你的团队还没有走到这一步,也没关系,这通常需要一定的产品和流程成熟度的积累。

当你对创意聚类和排序好后,你就可以开始将它们拆分成产品功能或可开发增量。在所有这些都做好后,你终于可以来确定优先级了!

让自己放松一点,划分优先级并不简单,它不意味着产出一个功能列表并排好顺序,实际上在你开始前需要进行深思熟虑。如果给到你一份功能列表并要求你进行优先级划分,你需要像产品人那样将重点转回公司目标上来。问一问,这些功能如何帮我们实现公司或产品的目标?怎样算成功?

我相信,如果你从管理中得到了正确的指导,你可以不需要优先级框架图作为辅助。但是,框架图可以帮助你看清自己是如何以及为何做出这样决定的。通过可视化表格——比如矩阵图,也可以让整个团队同步到进程中来。

下面是我推荐的两个简单的框架:

“影响 vs 努力”是经典的优先级矩阵关系图。“影响 vs 未知因素”矩阵关系则更多应用在假设驱动的开发或验证迭代中,用这个矩阵关系图来确定哪些功能需要预先测试,哪些功能可以直接开发以及哪些应该直接摒弃。

故事地图功能栈排名和投注是其他几个让利益相关人参与到优先级排序过程中的好工具。如果在向矩阵中添加想法和功能时,让利益相关方和团队成员参进来的话,那整个团队将非常清楚需要将时间和精力投入在哪里了。

三、产品思维帮助你保持团队的一致(Product thinking will help you keep your team aligned)

最后,产品思维可以帮你保持团队一致。一旦你明确了待解决的问题以及解决顺序,你该如何与团队和公司沟通呢?你可能想到路线图是个很好的工具。在你的路线图中应用产品思维方法可以让你避免很多麻烦!

但首先,我要告诉你一个小秘密:甘特图适用于项目而不是产品。根据定义,甘特图是一种条形图,用于说明项目进度!甘特图需要花费大量精力来维护,并不能真正提供更高的透明度,而且可能也无法帮助你的团队获得成功。

如果你想让你的团队采取更加产品主导的工作方式,那就抛弃甘特图,使用“现在-下一步-未来”表格作为路线图吧。

这个表格适用于功能、主题、学习目标、想要开展的实验或想要验证的问题,无论你的团队想要如何组织你的工作它都很适用。此外,“现在-下一步-未来”路线图非常容易维护,且给任意次数的修改和调整提供了很高灵活度,并让团队和更广的公司范围都能看到可预期交付的内容。

“现在”一栏中的内容是定义明确的、细化的、完全聚焦的工作。这里体现的是高保真的设计、需求、和所有最高优先级的亟待开发的项目。“下一步”一栏中的内容是部分确定的、处在原型或线框图阶段的设计,和正在收集中的需求,这些内容优先级较低。“未来”一栏中则是高层次的、宏观的、优先级完全灵活的内容,这一部分可以作为你和团队收集想法和创意留待未来考虑的板块。

一个小警告 —— 当你提出这个图表时,习惯了使用甘特图的队友们可能立刻会提出关于时间和截止日期的问题。你可以礼貌地解释说,这个路线图显示了各种工作间的相对优先级,而不是一条明确的时间线。

如果你在一个大型组织内工作,用额外的一页补充信息可以帮助对路线图中的项目做出进一步解释说明。你可以用产品画布作为模板,或者试试下面这个简化的模板:

  1. 你在构建什么?用几句话描述你的功能
  2. 它服务于谁?明确最多两个用户画像或用户群
  3. 为何决定构建它?提供支持依据并描述你想要解决的问题
  4. 预期完成的时间?给出相对的时间计划,不是确切的日期
  5. 这个功能如何与公司目标保持一致?

如果你进行过能够提供依据的研究,你也可以将它链接到这一页。

此外,你也可以通过给功能定级(SABC)来进一步优化你的文档,这样做有助于管理那些关注截止日期的各相关方的预期。记住要用大概时间来限定你的交付日期——千万不要承诺确切的截止日期!因为你永远不知道开发过程中会发生什么。

原文作者:Merissa Silk(本文翻译已获得作者的正式授权)

原文地址:https://uxdesign.cc/bring-product-thinking-to-any-team-92995b474753

译者:李非凡;编辑:孙淑雅;微信公众号:TCC翻译情报局(ID:TCC-design);连接知识,了解全球精选设计干货

本文由@TCC翻译情报局 翻译发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议