从0到1,浅谈需求的模型转化

作者:张一弛,华中师大硕士毕业。曾就职于阿里巴巴移动事业群,负责UC浏览器海外版产品工作。2014年加入腾讯,先后在QQ群、QQ HD、PC QQ等产品线从事产品策划工作。现负责新产品TIM核心应用的产品相关工作。

需求从思维到概念的转化

产品设计流程中,在完成需求与市场分析之后,产品经理需要拆解需求场景抽离核心路径,梳理出大大小小的各类功能点,划分功能优先级最终得到版本需求列表,随着项目的行进,在设计师和工程师的协助下,以超出用户预期为目标实现产品满足用户需求。将产品由抽象的思维模型转换为逐步具象化的概念模型,最终推导出可行的功能和版本规划,是产品由0到1的关键转换节点。产品经理应该如何判断需求的主场景,如何定义和连接触点实现场景最佳路径,如何评价构建路径的功能价值呢?

明确产品目标

判断核心场景首先需要明确产品的目标。明确产品目标即明确产品的用户价值和产品价值到底是什么,清晰的战略层认知决定产品的根基。产品经理要能以最简洁的语句回答出以下两个问题:

用户价值判断标准

实现用户价值的核心不在于满足需求的方式,而在于对需求自身的判断是否准确。用户价值的判断标准一般包含如下维度:

需求是否真实存在

所谓需求,是在某个场景下,用户想要满足某个期望的诉求。需求伴随着场景而存在,即便用户可能从来不用某一款或某类产品,也并不代表他一定不存在类似的需求,而可能只是因为他没有遇到类似的场景。

不同用户群体在同一场景下的需求存在着差异性,产品经理需要描绘核心用户的群体特征,调校产品方向,尽量满足核心用户的体验。清晰的用户画像不仅包括人口统计学特征(年龄、性别… )还要了解用户的产品使用环境特征、消费心态特征以及领域经验与专业程度。

在需求分析过程中,还要注意甄别表象需求和伪需求,前者存在的原因是,用户表达的需求往往是在自身认知和经验上做出的理解和描述,是主观的第一反应,其背后的本质需求需要产品经理汇集足够多的表象描述后,通过自己的观察和分析挖掘得到;后者则缺乏真实的使用场景,属于拍脑袋的行为,可以通过场景分析和判断加以识别。

需求是否足够刚

依照马斯诺需求层次模型,越贴近底层的需求越需要优先被满足。因为越接近底层,需求痛点越清晰、需求覆盖场景越广泛,需求覆盖人数越密集。从个人PC时代、互联网时代直至移动互联网时代,每一次科技浪潮的来临,都为人们基本需求的满足带来了新的解决思路和方案,用户对产品的期望也在不断的提高。历数在移动互联网时代最终站稳脚跟的产品,无一不是快速、准确地抓住和满足了用户的基础需求。

所谓刚需,所谓基础需求不能孤立的看待规模、频次这些指标,同样需要依托需求所在场景进行分析。例如针对“出行”场景,打车属于最常见的基础需求,而在“打车”场景下,“最快的打到车”则是该场景下的首要需求。对刚需的定义,需要产品经理结合用户价值综合考虑。

需求是否足够痛

需求足够痛,意味着在这个场景下用户的心智尚未被侵占,需求作为切入点的价值潜力越大,需求被满足后,更容易让用户对产品的定位留下记忆,对品牌的塑造更有价值。需求是否接近痛点,也从侧面反应出该场景下的竞品(或者是产品自身)当需求的满足是否达到用户预期,产品的市场机会是否足够大。

需求是否有效满足

有效满足,背后的含义是产品经理所设想的需求满足方案是否能在现有技术条件和可控成本范围内实现,并带给用户超出预期的体验。技术条件的成熟带来具有颠覆感和创新的解决方案,可控的成本保证方案不会天马行空无法落地,超出预期的体验意味着产品是否具有引领浪潮的潜力。

产品价值判断标准

产品价值的判断,一般来源于前期的市场分析和产品决策者对产品本身的定位。普适性的产品价值评估要点主要包括:

产品要解决什么问题?为谁解决?如何解决?

前三个设问产品经理需要站在产品决策者的角度,辨析产品对企业的价值,以获得组织的认同。回答产品要解决什么问题,是要求产品经理明确产品是否具有足够强的用户价值;知道产品为谁服务,即需要产品经理了解目标市场及其规模,市场空间决定着产品发展空间和成功的机会;产品解决问题的方式,则是帮助评判方案的实现成本和资源依赖当前是否足够满足。

存在哪些竞品?现在进入是否合适?为什么是我们?

市场的竞争格局一方面反应了市场的发展程度,另一方面从竞品没有覆盖或者体验不佳的场景中我们能找到新的机会。产品经理需要寻找可以结合产品自身优势和对手薄弱环节,打造具有明确差异化的产品切入市场。

判断当前是否是合适的切入时机同样重要。不同时机切入市场,产品的打法也大不相同。切入过早,可能因为技术的不成熟导致方案选择受到制约,也可能因为市场尚在培育阶段导致用户增长不如预期;切入较晚,则可能因为竞争对手领先太多错过窗口期,甚至因为错失流量红利或被新模式颠覆死在襁褓之中。产品经理需要根据市场发展状况和切入时间点来把控产品实施的节奏。

产品将如何推向市场?

产品主打市场不同,推广渠道和策略侧重点也有所不同。面向C端用户的信息服务类产品主要依赖线上渠道,在移动互联网时代,流量更多的聚焦在头部产品,背靠这些平台级产品可以获得更多的流量加持,生活服务类产品和面向B端用户服务的产品则倾向线上与线下相结合的推广方式,产品所在市场领域和所选取的推广方案,又决定了产品规模增长的速度。因此产品经理要尽可能利用所拥有的内外部资源,找到合适的推广策略,合理预判产品在不同阶段的发展规模。

成功的必要条件是什么?

明确产品成功的必要条件,就是要求产品经理知道产品成功所要满足的客观条件和资源依赖。产品的实施所需要的资源在合理的基础上要尽可能的量化,以便决策者准确评估;若需要组织外部资源的支持,要向合作者传递利益共赢的理念以获取信任。支持可能不是纯粹的资源,也可能是产品决策者的信任(信任意味着空间),这需要产品经理在向上沟通的过程中管理好产品决策者的预期。

如何判断产品是否成功?

最终我们需要通过符合SMART原则的度量指标来评判产品的成功。这些指标可能是纯粹的商业指标,也可能是衡量产品是否如期贯彻整体战略的标准。产品是否达到预期的规模?产品是否针对目标人群塑造了良好口碑?产品是否在特定领域起到了狙击竞争对手的作用?产品经理需要和决策者积极沟通,指定符合产品定位的评判标准。产品必须且唯一以达到评判标准为目标。

建立产品原则

产品原则是一系列明确的、体现团队特色的产品价值准则。它不但体现了产品的目标和愿景(战略层面),也是指导产品经理在后续场景、路径和功能价值评判与优先级划分的重要依据(范围层面)。有了产品原则,场景、路径和功能的对比和筛选才有意义。

建立产品原则的即定义产品三观:

价值观:回答“哪些能做、哪些不能做?“的问题。产品价值观是一套价值判断的框架,是企业价值观在产品上的贯彻体现。产品在衡量某些可以通向成功的”捷径“时,要坚持自己的价值观,除了依靠道德操守外,还需要产品经理始终怀有对用户的尊重之心和对需求的敬畏之意。

世界观:回答“要满足用户的哪一个核心需求“的问题。每一个产品都有一个核心场景,每一个核心场景都有一个核心需求,每一个核心需求都有一个函待解决的核心目标。在拿捏场景和功能时,任何与核心场景和功能不相关甚至影响需求满足的部分都应该放低优先级,集中资源投入到核心需求中。

人生观:即发展观,回答“未来发展方向是怎样的“的问题。产品所处环境决定着产品的生存和发展态势。就如人会因为生长环境不同形成千差万别的人格一样,产品未来发展路径决定了场景拓展的广度和深度,需要产品经理不断思考、并且能根据产品所处的环境变化灵活应对。

产品原则帮助产品经理和其他团队成员形成共同的价值观,在认识上保持一致性。在实际决策时,产品经理还需要对原则的重要性予以优先级排序,以免在实际操作时,团队因为视角和认知的差异性,在把握原则具体细节上产生分歧。

场景梳理

有了明确的产品目标和原则,我们就可以开始梳理需求涉及的用户场景。所谓场景,是真实的以用户为中心的体验细节。场景依赖于人和人所处的环境,人的意识、行为和与环境的交互构成了场景。梳理需求场景时,除了产品经理通过日常观察、经验积累和逻辑推导等方式穷举外,还可以通过用户调研或CE的方式,确保场景不会遗漏。

以”到店就餐”场景为例,场景切分后的流程如下:

梳理场景时,需要带着思考:在这个场景下,用户会遇到什么问题?每一个场景用户都需要完成一件事儿,达成一个目标。有哪些因素是达成目标所必须的,哪些风险可能会导致无法达到目标或不能很好的达到目标。这些重点问题在进一步分析后,可以转化为细分场景,直至需求粒度达到在某一场景下的一个功能或某几个功能组合可以满足的范围。

需求评判

需求评判的目的是确定需求主场景,以及细分场景下的痛点需求。需求评判可以参照如下维度进行:

过分关注远离产品目标和原则的场景和需求,会迷失产品的方向,造成资源的浪费,最终导致产品核心用户的流失。由于用户的预期一直在提高,产品若受限于解决非痛点问题,长期缺乏有效的场景挖掘和优化,在激烈的市场竞争中就容易失去优势。

任何产品都不可能覆盖需求的所有场景,在资源有限的情况下,满足重点场景就可以大大减少痛点的存在。

场景的存在依托真实的使用环境,许多产品在用户在调研时往往表示愿意使用,但不代表在现实环境下他们真的会用。例如在办公场景下存在图片编辑需求的用户,编辑场景更多集中在桌面端,移动端虽然也有编辑需求,但受限于硬件设备发展的制约,用户习惯更偏向于图片的收发与传播。如果产品经理不能及早明确核心场景的分布,产品的方向和后续规划会面临较大的风险。

以办公场景下的文档协作需求为例,场景拆解如下:

假定经过分析和讨论,产品团队最终认定了如下产品目标和原则。需要再次强调,产品价值一定要落实为量化指标,以便更好地考量产品发展是否达到预期,及早发现问题一遍重新审视产品决策。

经过需求评判,我们认为文档的发现,编辑与分享是满足文档协作需求的主场景,并推导出如下痛点需求:

路径推导

解决场景需求需要定义各场景及场景间的用户行为路径,推导路径首先要判断场景的路径触点。触点是产品在影响用户行为过程中,场景的某个元素与用户能够直接产生接触的关键节点及构成节点的功能规格。触点的判断可以从两方面来看:如果该节点在产品经理设想的场景中必经,且需要用户长时间停留和聚焦注意力,则该节点可作为备选的触点。

寻找触点可以从竞品中获得灵感,因为从策划的角度来看,产品逻辑和流程的最优解,最终的思路往往殊途同归。凭借产品经理对用户习惯的理解、竞品分析,结合产品所属平台或自身亮点特性,通过逻辑归纳就能推导出场景的触点。

以上文的协作文档产品中的发现场景为例,场景触点应为一系列包含属性字段的文档集合视图页面组成。根据用户身份的不同,可以将视图划分为我创建的和与我共享两类,视图的基本字段应包含文档名称、文档创建者、文档最近编辑时间等元信息。围绕文档定位和管理,视图应包含一系列的针对文档增、删、改、查诉求的能力。其中视图的查找功能应该包括搜索、排序、字段过滤等基础功能… 产品经理在这一阶段要尽可能的穷举出触点构成元素以及可能包含的所有功能规格。思维导图是值得推荐的触点梳理工具,一份实际的文档发现场景的触点梳理全景图如下:

完成触点分析,我们接着要对穷举出的功能进行价值分析,分析结果将作为最终功能评估的基本依据。首先我们要划分功能分类,这里推荐一种温伯格在《探索需求》中提到的功能归类法,操作步骤如下:

找出最符合该场景下痛点需求满足的功能组合,该组合下属于明显分类的功能价值最高,属于隐藏分类的次之,装饰性功能则可以大胆砍掉。

分析出所有主场景的触点及构成触点的功能价值后,依照用户使用习惯连接触点,就能得到场景间的最佳路径和路径功能列表,进行到这里,我们也就完成了产品范围的定义。

功能评估

到达功能评估这一步,已属于解决产品结构层面问题的范畴。产品经理要和设计师一道着手对较高价值的功能进行交互与信息架构设计,同时还要拉上工程师粗评功能技术方案与工作量,结合项目周期确认功能优先级,最终将路径功能列表拆分为实际可用的版本需求列表。这里推荐一种可行的操作方法:

完成版本需求列表初稿后,产品经理需要和产品决策者及时确认需求列表。在项目行进过程中,根据阶段性目标的变化,灵活调整后续版本的功能规划与排期。

风雨兼程,不忘目标

回顾一下需求从场景到功能的完整推导过程:

不难发现,产品目标不仅是最早明确的核心要素,也是需求分析过程中的“指明灯”,但产品目标并非一成不变。产品经理始终保持握市场风向和用户需求的敏感度,定期review产品目标,灵活调整阶段性目标和打法,让产品这辆高速列车始终朝着正确的方向一路前行。

参考文献

《启示录——打造用户喜爱的产品》 -- Marty Cagan

《用户体验要素》 -- Jesse James Grrett

《探索需求》-- Gerald M. Weinberg

《缔造企鹅——产品经理是这样炼成的》 -- 胡澈

《任务链及其在功能创新上的应用》 -- feixiong(熊飞)

《场景化的产品设计思考》 -- arsenli(李森)

原文发布于微信公众号 - 腾讯大讲堂(TX_DJT)

原文发表时间:2017-04-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏智能计算时代

探索机器学习中的数据科学

原文作者:原微软技术与研究部门合伙人数据科学架构师Mario Garzia 译者:杜红光 数据科学与“大数据”已经成为21世纪高科技产业的流行语。而“大数据”这...

3367
来自专栏大数据文摘

网络营销大数据实操七步走

3256
来自专栏腾讯大讲堂的专栏

产品经理探索之路:如何理清思路确定方向?

导语 在设计和运营产品的过程中,产品经理们或多或少会遇到这样的问题:产品方向不明确,对未来也毫无头绪,不知道要如何走。针对这个问题,我们简单谈谈如何破局,更快的...

20810
来自专栏云计算D1net

云计算离超级云计算还有多远?

单就一个行业而言,一直以来我们对于云计算所带来好处的认识可能显得过于狭窄了。如果云计算是一次真正的革命性变革,那么它就必须能够支持生产和用户体验的模式,而这些都...

4706
来自专栏AI研习社

解惑:Python是否值得学习?最强语言展露端倪

5 月 13 日,由 ThoughtWorks 主办的 2017 技术雷法峰会在北京召开。 正如官方宣传提到的:“ThoughtWorks 技术雷达” 并非一个...

4347
来自专栏SDNLAB

网络管理的六大关键趋势

我们生活在IT技术飞速发展的时代。无数新技术正在改变网络的构建方式,例如如何提供访问、如何传输和存储数据等等。云、物联网、边缘计算和机器学习都为组织提供了以数字...

1354
来自专栏云计算D1net

企业应谨慎对待托管数据中心和云计算

日前,调研机构451 Research公司高级分析师Dan Thompson表示,尽管进行了数字化转型,很多组织仍然需要数据中心开展业务,其原因包括从成本到专注...

900
来自专栏Java架构师学习

如何做系统重构

重构,是任何一个技术团队都无法绕过和回避的话题。记得10年前,我第一份正式工作,就经历了项目持续的重构历程,为了写好代码,当时还反复读了Martin Flowe...

3485
来自专栏ThoughtWorks

如何成为一个技术全面的架构师|洞见

本文首发于infoQ: http://www.infoq.com/cn/articles/the-well-rounded-architect 架构师是一个充满...

3454
来自专栏DevOps时代的专栏

驱散谬见 | 7个常见的 DevOps 误区解读

前言: 本文将介绍《DevOps Handbook》全书中的一部分:对 DevOps 常见误区进行解读。有些朋友对DevOps不熟悉或有一些不准确的理解,比如是...

23510

扫码关注云+社区

领取腾讯云代金券