《解构产品经理》读书笔记

1,401 阅读31分钟

本文是刘涵宇先生所著的《解构产品经理》的读书笔记

I 解构产品经理

1 解构基本概念

1.1 什么是产品

产品是指可以满足某种用户需求,由人类加工生产,可供给市场用于交换的任何东西。

1.2 什么是好产品

可以恰到好处地满足用户需求,拥有完善的技术实现方式,同时可健康持续地创造商业价值的产品,就是“好产品”。

  1. 需求:恰到好处地满足用户需求

    • 满足需求(有用):能解决用户问题,满足用户需求,提供给用户价值。
      • 案例1:交流工具的演变,其核心价值都是为了满足人们“交流”的需求。
      • 案例2:不同时期流行的移动数据存储及同步产品,都在当时满足了用户的需求。
      • 案例3:12306 的体验一度很糟糕,但因为其有用,还是有很多人使用它。
    • 用户:讨论一个产品的好坏,必须是针对它的目标用户来进行。
      • 案例1:专业相机的手动档,让操作变得复杂,但对于摄影师是个好产品。
      • 案例2:广场舞可以满足“大爷大妈”的需求,但让附近居民遭殃。
      • 案例3:倒车影像对于一部分用户有用,但对于另一部分用户基本没用。
    • 恰到好处:并不是给用户的东西越多越好,在合适的时候为用户提供合适的功能,实现需求,但不添乱最好。
      • 案例1:某房地产客户端在用户选中城市为“深圳”后,其展示的楼盘信息无一在深圳,为推广推送额外的信息无可厚非,但原则是不能影响用户核心需求。
      • 案例2:某电商网站基于商品的相似性,为用户推荐短期内不会重复购买的已购买商品,显得有些多余。
      • 案例3:某资讯类应用在用户阅读过程中,不定期弹出反馈提示对话框,粗暴地打断用户的沉浸式体验,却仅仅是为了提示用户可以摇动手机反馈问题。
  2. 技术:拥有完善的技术实现方式

    • 实现:如果一个方案很优秀,但现有技术无法实现,或者无法保证其可靠性和质量,那么这个方案是办法成为好的产品的。
      • 案例1:龙珠里的“胶囊”,虽然很神奇,但以目前的技术无法实现。
      • 案例2:Windows在20世纪80年代末的UI,现在看来显得简陋,这是因为当时的计算机硬件无法处理更精细的图形,相关技术跟上之后,图形界面才真正发挥出应用的价值。
    • 完善:在一个充分竞争的市场环境下,只“实现”出来是远远不够的,还必须要做到“完善地实现”。
      • 案例1:搜狐对技术的不够重视,错过了搜索这班车。
      • 案例2:Siri的不完善,或许是其仍未获得广泛应用的原因之一。
      • 案例3:Note7手机的爆炸:技术的不够完善,让创新变成了严重的事故。
  3. 商业:可健康持续地创造商业价值

    • 商业价值,并不完全等同于赚钱:有的产品本身不盈利,但可辅助其他产品盈利,这也创造了价值。
      • 案例1:微信的基础部分虽然不盈利,但它在游戏分发等方面,依然间接地创造了巨大的价值。
      • 案例2:当年的打车大战,腾讯和阿里真正争夺的是“近场支付”这个重要场景 。
      • 案例3:做公益不能直接创造商业价值,却能反作用于商业。
    • 持续:靠一些手段也可以获得价值,但不可持续。
      • 案例1:诱导短信。
      • 案例2:游戏盈利模式从单纯售卖软件,到售卖点卡、道具等模式,变得更加可持续。
    • 健康: “健康”与“持续”相辅相成,前者往往可以使后者走得更远。
      • 案例1:养老保险。

产品经理在策划产品过程中所需要关注的核心:当想到一个“点子”的时候,可以尝试从需求、技术、商业三个方面来分析它是否“靠谱”。事实上,优秀的产品经理总是能够在这三者之间找到最佳的平衡点。

1.3 什么是用户体验

用户体验(User Experience, UX)是一种在用户使用产品过程中建立起来的纯主观感受。

  1. 用户:对于不同的目标用户来说,即使他们的需求看起来一致或者差不多,但在具体使用产品的过程中,“用户体验好”的定义也可能是不同的。

    • 案例1:美图秀秀和Photoshop,都可以处理图像,它们分别更适合“爱美的妹子”和专业设计师。
    • 案例2:针对黑人用户优化了拍照功能的某手机品牌,风靡非洲。
    • 案例3:乐天商城的域名对于中国用户来说难以记忆,远不如淘宝、京东乃至亚马逊的域名。
  2. 过程中:在设计产品的时候,需要考虑具体使用过程中的环境和场景。

    • 案例1:阅读类产品的夜间模式
    • 案例2:Wi-Fi与数据网络的自动切换
    • 案例3:iPhone的单手操作
  3. 主观感受:用户体验只是主观感受,但是作为产品经理,必须去挖掘用户主观感受背后的真实的需求,不要被主观的、表象的东西所迷惑。任何时候,产品经理都要从实际出发,全面、客观地去思考。

    • 案例1:“如果我问客户想要什么,他们只会说更快的马。”——亨利·福特

1.4 定义互联网产品经理

  1. 互联网产品经理的一般职责

    • 产品规划:产品经理需要结合公司的发展方向、团队情况、技术难度、市场环境等因素,明确哪些需求是一定要做的,哪些不能做,哪些要优先实现,哪些可以慢慢来。
    • 产品设计:明确要做什么之后,产品经理需要具体设计相应的功能逻辑,主要有三件事:业务逻辑是什么、分支逻辑怎么办、逻辑的表达。
    • 推动研发:承担部分项目管理的职责,对各环节保持关注,确保需求的最终落地。
  2. 产品经理的能力模型

    • 底层能力
      • 逻辑思考能力:产品经理的工作需要极强的逻辑性,不能“想当然”。
      • 自我认知迭代:有能力意识到自己过去认知的不足,有勇气承认自己当下认知的缺陷,同时有动力去通过不断的学习和实践来构建新的更加完善的认知体系。
      • 理想:保持理想。
    • 应用层能力:见下表
序号 能力 入门级产品经理 有经验的产品经理
1 执行力 把上级交代的具体任务按时、保质、保量完成。 根据一个或许是非常模糊的方向来指定全套方案,并预知风险及做好防控预案。同时需要通过流程、方法论总结等方式提升整个团队的执行力,避免短板。
2 产品设计 完成相对单一的功能、模块的产品设计。根据不同的团队和产品形态,可能包括产品逻辑、操作流程、UI等设计。 更加深挖用户的需求和场景、深挖人性特征,更多地思考各模块之间的关系、整体的产品定位、用户体验与商业之间的权衡等
3 产品规划 对用户需求有一点深入思考,排列一些简单的优先级顺序 以产品规划的方式推动产品“成功”。需要明确地意识到,“成功”的因素是多元的。需要带领团队在对的时间做正确的事情,甚至需要忍受外界的批评和指责,但坚持把资源投入到当下真正最重要的事情上。
4 用户研究 使用常用的用户研究方法,如问卷、访谈等进行简单的调研工作。关注并收集整理用户反馈 深刻意识到,不同用户的需求是不同的。在进行任何分析、思考、策划时,都能从用户行为出发,客观、理性地推导用户场景,发现其需求,并深入挖掘这些现象、场景、需求背后的原因和逻辑,然后再以此为根据设计产品
5 市场研究 对市场容量、竞品情况等信息进行收集,以及做简单的横向对比 深入研究并思考主要竞品的特征、优势和劣势,以及其方向和打法。结合一切可获取的信息,对市场发展趋势做预判,并结合自身情况,发现机会点,帮助产品建构优势
6 学习能力 在工作需要时,能相对主动、快速地去学习新知识、新技能 能把脑中诸多知识形成体系,融会贯通。将知识形成观点和方法论,辅助工作
7 沟通能力 可以流畅、准确地与用户,以及日常工作中有合作的同事沟通。能把事情讲清楚,让对方理解,便于执行 根据不同角色、不同对象的特征和性质,采用不同的沟通方法,达到最优的沟通效果
8 行业理解 了解行业的基本历史、趋势、分工和模式(包括常见的产品模式和盈利模式) 深入理解行业,包括但不限于:行业事件、产品模式、盈利模式背后的逻辑,发展趋势及驱动力,不断尝试行业内的新产品和新玩法,并思考其内在逻辑及预判其趋势、发展方向、优缺点
9 运营及数据分析 了解常用运营手段,了解所负责的产品主要数据、核心指标;能做简单的数据对比、数据计算,并给出分析结论 总结提炼适合所负责的产品运营手段,深入分析数据,构建分析模型,并找到提升关键指标以及优化产品的方法
10 项目管理 跟踪项目进度 对工作量、复杂度有一定预估能力,可与开发、测试同事一起拆解工作量,做精细化管理。跟踪项目进度,及时发现并处理风险,预见潜在问题。协调内外部资源,找到共同目标和利益点,推动执行
11 其他相关知识和技能

1.5 互联网的职能分工

  1. 互联网产品的逻辑结构

    • 《用户体验要素》五层级

    用户体验要素

    • 互联网产品四层级(本书作者主张)
      • 决策层:一切产品的基础,解决“做什么”、“为什么做”、“怎么做”三个核心问题。产品具体的方向、目标用户群、核心功能等都是在这一层产生并迭代的。
      • 逻辑层:产品功能具体的逻辑及实现,包括业务逻辑、商业逻辑、程序代码逻辑等。
      • 信息层:该层负责所有交互层面的问题,包括 UI 上的任务流程、信息的展现、提示等。
      • 表现层:即用户具体看到的产品是什么样子的,包括颜色、大小、形状、材质、明暗等。
  2. 互联网产品的技术结构

    • 在网页上登录(B/S结构)
    • 在手机客户端上登录(C/S结构)
  3. 研发流水线简述

研发流水线

2 解构基本观点

2.1 用户价值高于用户体验

在绝大多数时候,用户价值的重要性高于用户体验,前者是后者的基础。

  1. 两个需求层次理论

    • 马斯洛需求层次理论:较低层次的需求必须在较高层次的需求之前得到充分的满足。
    • ERG理论:人在同一时间可能不止一种需要起作用,如高层次的需求被抑制,那么人会对低层次的需求更加渴求。
  2. 用户价值与用户体验关系

    用户价值与用户体验关系

    • 有用:产品能满足用户的某种需要,即能提供用户价值。
    • 可用:产品的目标用户,以起现有条件可用顺利使用该产品,这一层混合了用户价值和用户体验。
    • 易用:对目标用户来说,产品易操作易上手,不需要付出过多的成本来掌握和学习,这是用户体验的范畴。
    • 用户会同时对上述三者产生需求,但在绝大多数情况下,可用和易用必须建立在有用的基础上。
    • 在一个非充分竞争的领域中,倾向于更关注用户价值。
    • 在一个充分竞争的领域中,倾向于在确保用户价值的前提下,更多地关注于用户体验。
  3. 关于用户价值和用户体验关系的案例

    • 案例1:脸萌提供了较高的用户体验,但由于其缺乏更核心的用户价值作为根基,走向了没落。
    • 案例2:街旁网虽红极一时,但在用户体验的新鲜感被耗尽之前,其未能确定真正的用户价值,因此迅速地被人遗忘。
    • 案例3:在网上办理政府事务,处于一个非充分竞争的环境中,用户价值被放大,而让人能忍受其较差的用户体验。
    • 案例4:海底捞能一炮打响,恰恰是在当时服务普遍不怎么样的餐饮行业,提升了用户体验的缘故。

2.2 用户体验是一条线,不是一个点

在一般的互联网产品中,至少有四个主要因素会影响用户体验,分别是产品逻辑、UI、技术和运营。

  1. 产品逻辑:产品自身的逻辑会直接影响用户体验,并且有的时候产品层面和体验层面会有一些冲突,在一些情况下,要选择性地调和双方的冲突。 2.UI:绝大多数互联网产品都要通过 UI 与用户实现交互。
  2. 技术:技术的好坏,可能关联到一个互联网产品的运行速度、稳定性、安全性等重要因素。
  3. 运营:拉新、客服、推广营销、渠道销售、日常数据分析等都可以算作运营体系。

2.3 产品经理无法定义“用户价值”

真正的用户需求应该是用户“决定”的,大多数时候产品经理只能“发现”这些需求,然后设计相应的功能,通过满足用户需求的方式为用户创造价值。

  • 案例1:团购网站并没有创造出新的用户需求,而是“发现”了消费者和商家已存在的需求。
  • 案例2:共享山地车和共享充电宝,并没有真正的为用户提供价值,既不是刚需也难以盈利。

2.4 用户体验部无法统筹“用户体验”

现行的用户体验部无法统筹完整的“用户体验”,而产品经理作为除老板以外唯一一个有机会统筹全局的角色,必须关注到包括用户体验在内的所有必要环节。

2.5 人人都设计师

  1. 狭义的设计:所有基于表现层的,都是狭义的设计。
  2. 艺术与设计:“设计”意味着其作品要有明确的目标,而“艺术”则不一定具有明确的目标。
  3. 广义的设计:所有事情聚类起来只有两种,去“想”的叫设计,去“做”的叫工程。

3 解构基础工具

3.1 需求分析工具:用户场景

  1. 用户场景的定义:一种对过程逻辑的阐述方法,帮助产品经理理清用户使用产品的核心逻辑,涉及以下几个关键因素,并与用户体验定义的内容相对应。

    用户场景与用户体验定义的关系

    • 用户是
    • 在上面样的条件下
    • 有了怎样的需求
    • 会用什么方式实现
  2. 用户场景案例:以滴滴打车为例

    • 场景:出租车司机在没有载客的时候,需要寻找乘客以便于载客赚钱,所以他们一边在路上行驶,一边留意路边是否有乘客向其招手,如果有,就停车载客。
    • 表述:出租车司机(谁)涉及在没有载客的时候(条件下),需要寻找乘客以便于载客赚钱(需求),于是他们打开手机应用,应用会自动向其推送附近乘客发出的需求,他们可以选择合适的需求抢单,然后去接该乘客(方式),以便于达到载客赚钱的目的。
  3. 用户场景的功能

    • 将用户、条件、需求、方案四者分开,以便于产品经理逐一审视其合理性
    • 将上述四者组合在一起,以便于产品经理判断需求的轻重和方案的好坏
    • 方案确定后,也便于其他环节(如设计、开发)高效、准确地理解相关产品功能的目标、逻辑和价值,以支持相应的工作。
  4. 基于用户场景的思维方式

    • 用户场景除作为一种有用的工具使用之外,更重要的是,它是一种相比于“业务思维”和“功能思维”来说,更加适合产品经理的思维方式。
    • 案例1:银行转账功能只需用户填写几项重要信息即可完成汇款,而不是先列出所有可用的汇款方式,增加用户的认知负担和操作步骤。
    • 案例2:在用户进行相关操作时,才提示需要哪些权限并告知为什么,而不是首次进入便要求用户必须授权。

3.2 市场分析工具:SWOT分析法

  1. 价值

    • 全面了解市场情况和市场潜力
    • 明确所有竞品各自的优势和劣势,结合自身情况,找到最合适的“核心竞争力”
    • 为之后的产品策划提供大方向的依据
  2. 构成

    • 组织内部因素:SW(优势、劣势),包括企业品牌、独有资源、起步时间、内部生态
    • 组织外部因素:OT(机会、威胁),包括政策走向、需求轻重、行业壁垒、竞品情况、盈利模式

3.3 功能梳理工具:功能列表与思维导图

先发散,后聚焦。结合需求、场景和团队目标,把产品的功能列表梳理清楚,然后排优先级,再去细化具体的功能逻辑。

  1. 功能列表:将所有功能列出来,就成了功能列表。功能列表至少应包含以下 5 部分:编号,模块,功能名称,功能简述,优先级。
  2. 思维导图:使用思维导图,可以让功能、模块之间的逻辑和从属关系表达得更清晰。

3.4 逻辑梳理工具:流程图

绘制流程图可用帮助产品经理建立起对自己产品详细功能层面的宏观把控。

3.5 优先级及版本规划工具:四象限与 MVP 混搭

  1. 敏捷开发:使用小步快跑、快速迭代的方式推进产品研发。最初的版本只有简单的功能闭环,之后的每一个版本只完成一小部分优化和新功能,不断重复这个过程,最终迭代出相对全面、完善的产品。
  2. 四象限:将所有功能按照“重要”和“紧急”两个维度进行分类,从而排列优先级。
  3. MVP:指一个只有重要的核心功能,没有其它多余的功能,并可提供给用户的产品版本。
  4. 先使用四象限方法,排列优先级;再借鉴 MVP 思维,一个版本若上线某功能,则必须要保证与其相关联的主要功能也同步处于可用状态,以保证产品的“功能闭环”。

3.6 原型设计工具:线框图

  • 目的:从用户视角去审视功能、流程的完整性和合理性。
  • 原则:便于修改、便于标注、善用标准化组件。

3.7 需求表述工具:需求文档

  • 用途:记录和沉淀需求,跨团队、跨部门协作,辅助传承和交接。
  • 图文形式的需求文档:
    • 文档标题和变更记录
    • 背景介绍(可选)
    • 用户角色描述(可选)
    • 流程图、结构图(可选,建议提供)
    • 功能名称、优先级和详细描述
  • 带 UI 的流程图形式的需求文档

4 解构宏观产品设计原则

任何原则都不能机械地套用,而是要在理解其本质和适用范围的基础上,针对具体的用户、场景进行具体的运用。

4.1 基于用户心理模型来思考

心理模型是指人们遵循生活中某些习惯或经验而建立的对世界的认知。从用户的“心理模型”出发,而不是机械地执行业务逻辑,从而帮助用户更高效地完成任务,同时获得更好的用户体验。

4.2 用合适的方式交流

使用目标用户听得懂的“语言”、看得懂的“方式”与用户进行交流和人机交互。另一方面,“有效”的交互不仅仅是将信息传递出去,更重要的是唤起用户的有效认知。

4.3 形式追随功能

对于互联网产品来说,其所有外在的表现形式,都应当为场景和功能服务。且针对不同的用户群,由于他们的场景和需求不尽相同,往往需要提供相适应的不同表现形式。

4.4 Less is More

少即是多在互联网产品的角度上,有四层解释:

  1. 简化装饰:反对过度的装饰,因为过度的装饰不但无法起到正向的效果,相反还可能阻碍用户的使用。
  2. 简化功能:将核心功能做好,同时简化、去除相对边缘的功能元素。
  3. 简化认知:尽量减轻用户的认知成本,“Don't Make Me Think!”
  4. “减法”并不是唯一的选择:对于一些特定的用户和场景,做“减法”并不适合。

5 解构微观可用设计原则

产品首先是要给人用的,互联网产品的盈利往往建立在用户先“使用”的基础上,所以很多时候可用性显得尤为重要。

5.1 一致性

  • 定义:在一个(或一类)产品内部,在相同或相似的场景、功能上,应尽量使用表现、操作、感受等相一致的设计。
  • 目的:降低用户的学习成本,降低认知门槛,降低误操作的概率。
  • 通用标准:当在某一类产品、某行业中形成更大范围的一致,并得到普遍的承认时,一致性便成了通用的标准,这个标准被越多的人所遵守,整个社会的协作效率就越高。
  • 设计规范:在系统或产品内部,应有统一的设计规范,这会极大地降低用户的学习和使用门槛。

5.2 及时且有效的反馈和解释

多数时候,用户是不耐烦的,如果用户发出指令后,产品在很长的时间内都没有给用户反馈,用户往往会离开。因此,反馈和解释必须及时且有效(注意,这两者缺一不可)。

5.3 信噪比

在可用性设计和UI设计中,应当尽量放大信号,减少噪声。尤其“大而全”,不如突出核心功能,因为少数核心功能应该可以满足多数用户的需求

5.4 渐次呈现

当用户需要在产品完成某种任务时,往往需要将任务分步骤,依次引导用户走完流程。确保用户在每一个步骤中只需要思考简单的逻辑,进行简单的操作,以便于更加高效、顺利地完成全流程

5.5 防错与容错

  • 优秀的产品应给予用户能纠正错误的提示和引导,甚至能猜到用户的一些小心思,帮助其避免错误,而不是生硬地告诉用户“出错了”。
  • 一些容易存在风险的操作应有相应的机制进行提示。
  • 部分操作提高容错性,可以降低用户的使用成本,提升用户体验。

6 横向扩展:用户研究与运营分析初步

6.1 以产品经理的视角看待用户研究

  • 用户研究定义:
    • 广义:只要能够帮助我们更多、更深入地了解用户的工作,都可以看作用户研究范畴。
    • 狭义:指在专门的“用户研究工程师”主导下,使用特定的科学方法所进行的一系列研究工作。
  • 从产品经理的视角:
    • 用户研究的结论往往不是终点,如何把它们运用到具体产品中,变成“方案”才是关键。
    • 用户研究的结论不应左右产品决策,只能供产品经理参考。

6.2 深度访谈

  • 定义:是用户访谈的一种,通常是由专业的访谈者对受访者进行一对一的自由式访谈,以便于深入挖掘用户的需求、产品使用场景、主观观点等内容。
  • 优势:
    • 可以深入、细致地讨论一个话题,对用户的态度、动机、需求、行为等进行深入挖掘。
    • 获得的信息量大,内容丰富。
    • 灵活性强。
  • 劣势:
    • 成本高(时间、金钱)。
    • 对访谈技巧和逻辑性有一定要求。
    • 难以量化分析。
  • 前期准备:
    1. 确定访谈目的
    2. 选择访谈对象
    3. 列提纲:尽量选择相对开放式的问题。
    4. 选择访谈场所
  • 问题设计:
    1. 避免专业术语
    2. 避免引导性问题
    3. 避免过于模糊、过大的问题
    4. 追问:表述不明确,或有挖掘空间,应进一步追问。
    5. 避免打断
    6. 给足时间,不要提醒
    7. 用问题回答受访者问题

6.3 问卷调查

  • 定义:将所希望了解的问题列成清单,供受访者一一作答,从而了解受访者对这些问题的看法和意见。
  • 优势:
    • 在短时间内,快速手机大量样本信息。
    • 丰富的传播渠道。
    • 可匿名,对于敏感性问题的收集优于其它形式。
    • 易量化,易统计分析。
  • 劣势:
    • 无法深入追问,无法了解受访者在答案背后的逻辑。
    • 不易精确选择样本。
  • 问卷设计:
    1. 问卷开头:目的、主要内容和保密措施,激励措施(如有,唤起受访者兴趣)。
    2. 问卷正文:
      • 以封闭式问题为主
      • 注意问题顺序
      • 注意措辞
      • 留有出口:设置“不知道/其它”选项,设置测谎题。
    3. 问卷结尾:对受访者表示感谢,及其它相关事项。
  • 问卷投放和回收:
    1. 选择投放平台
    2. 选择投放渠道
    3. 问卷回收

6.4 可用性测试

  • 定义:让一群具有代表性的用户对产品的典型任务进行操作,同时用户研究工程师和产品经理在一旁进行观察,聆听,以便于发现问题。
  • 优势:
    • 针对调查人员最关心的功能任务让测试者实践,目的性和可控性强。
    • 可以集中发现产品问题。
    • 配合访谈和相关研究,可以探求问题背后的原因。
  • 劣势:
    • 成本高(时间、金钱)。
    • 一般需要在方案确定甚至已经开发完成的时候进行,如遇重大问题,难以及时推翻原有方案并做大幅度修改。
  • 制定任务:梳理被测试的产品/版本中的关键任务。
  • 进行测试:在测试过程中,尽量不要交流,且不要打断被测试者的操作,以观察到的事实为主。

6.5 运营分析初步:常用指标与漏斗模型

  1. 常见数据指标:

    • PV:即页面浏览量,一般只按次数,不区分用户、地域和频次等。
    • UV:即独立访问量,需要定义“什么是独立访问”。
    • DAU:即日活跃用户数,一般用户只要打开一次就算一次“活跃”。
    • MAU:即月活跃用户数。
    • 转化率:指在一个统计周期内,完成转化行为次数占推广信息总点击次数的比率。
    • 留存率、流失率:在一个任务中,某步骤的UV / 上一步的UV,就是主观步骤的留存率,相反则是流失率。
  2. 其它数据指标:

    • 渠道分布
    • 版本间数据对比
    • 业务核心指标
  3. 漏斗模型

    • 构建漏斗模型:每个产品都会有用户的核心任务和流程,将流程每一个步骤及其对应的数据拼接起来,就会形成漏斗。
    • 分析漏斗模型,进行优化。
    • 案例:应用商店的漏斗模型,使用>下载>安装>激活。

6.5 数据分析初步:Excel 常用函数简述(略)

7 纵向扩展:互联网产品盈利模式浅析

7.1 流量变现

  1. 普通广告:广告是流量变现的基本方式。

    • 案例1:门户网站上的广告
    • 案例2:feed流广告
    • 案例3:验证码广告
    • 案例4:网盟广告
  2. 匹配广告:根据用户需要的内容来匹配广告,投放更精准。

    • 案例1:Google 搜索关键词广告
    • 案例2:Facebook 精确匹配广告
  3. 导航站:将流量导给其它互联网产品。

    • 案例1:hao123
    • 案例2:浏览器
  4. 移动应用分发:在移动互联网时代,移动应用分发才是主流的流量分发产品形态。

    • 案例1:第三方 Android 应用商店
    • 案例2:应用商店
    • 案例3:分发平台
    • 案例4:换量
  5. 预装分发:与手机厂商合作,将应用预装在未出厂的手机中。

    • 案例1:手机出厂前预装。
    • 案例2:手机管理工具。

7.2 增值服务

  1. 基础功能免费,高级功能收费:使用免费功能来聚集用户黏性,然后将一部分用户转化为付费用户,产生商业价值。

    • 案例1:QQ 会员
    • 案例2:标准版和专业版
  2. 游戏道具:游戏道具已成为当今大多数手机的主要盈利方式,其本质就是一种增值服务。

    • 案例1:王者荣耀中的英雄
    • 案例2:直播平台中的虚拟礼品
  3. 高品质内容:向用户提供更高品质的内容。

    • 案例1:QQ音乐的无损品质
    • 案例2:腾讯视频的清晰度选
    • 案例3:视频片头广告
    • 案例4:艾瑞咨询的收费研究报告

7.3 佣金与分成

  1. B2C平台

    • 案例1:天猫的软件服务费
  2. 第三方支付

    • 案例1:支付宝的收款佣金
    • 案例2:iOS 的支付手续费
  3. 开放平台

    • 案例1:人人网开放平台
    • 案例2:游戏联运
  4. O2O

    • 案例1:易到用车

7.4 收费服务及售卖变现

  1. 技术服务

    • 案例1:阿里云提供的云服务
  2. 付费软件:所有功能都需要付费使用,没有“基础功能免费,高级功能收费”的增值服务模式。

    • 案例1:全面战争等单机游戏
  3. 付费内容:直接售卖内容。

    • 案例1:腾讯视频的付费内容
    • 案例2:得到 APP
  4. 网上渠道:仅仅将互联网作为售卖渠道的产品。

    • 案例1:小米商城
    • 案例2:卖花的公众号
    • 案例3:余额宝(基金销售)

7.5 其它类

  1. 付费开发:靠售卖开发能力来为客户开发软件来盈利。
  2. 金融增值:靠“账期”来赚取金融增值部分的利润。
  3. 第三方付费:技术公司负责开发,客户与第三方进行一定的利益置换,由第三方付费。

II 推广产品思维

8 以产品思维应聘产品经理职位

8.1 找到用户:谁会负责简历的筛选(略)

8.2 明确需求:读懂职位描述(略)

8.3 设计UI:写简历(略)

8.4 厘清逻辑:与面试官相谈甚欢的套路(略)

8.5 快速迭代:“等通知”期间可以做什么(略)

8.6 毕业生与转岗:没经验怎么办(略)

9 以产品思维沟通

9.1 与设计师沟通:我们一起改变世界(略)

9.2 与工程师沟通:我很靠谱,跟我干没错(略)

9.3 与上级沟通:明确目标与给出方案(略)

10 “互联网+”产品思维初探

“互联网+” 就是 “互联网+各个传统行业”,但这并不是简单的两者相加,而是利用信息通信技术以及互联网平台让互联网与传统行业进行深度融合,创造新的发展生态。

10.1 “互联网+”的三个阶段

  1. 阶段一:渠道、媒体与工具(从前)

    • 最初,对于“传统行业”来说,互联网是一种通信和宣传渠道
    • 在这个时期,互联网与传统行业的连接往往是很简陋的。
    • 案例1:易趣网的卖家身份验证需要通过线下的邮件完成。
    • 案例2:当当网的支付渠道,当年还包含“邮局汇款”。
  2. 阶段二:业务融合,改造与重构(现在)

    • 现在的“互联网+”更多的是互联网与传统行业的“融合”
    • 在未来几年,互联网会越来越多地与传统行业深度融合,改造甚至重构一些行业及其内部的体验
    • 案例1:滴滴出行事实上是对城市客运这个行业的资源产生了“动态调节”的作用。
    • 案例2:“互联网+医疗”正在慢慢改造甚至重构这个古老的行业
    • “互联网+”还是“+互联网”,是一个伪命题,谁都不可能颠覆对方,想做事,必须深度合作
  3. 阶段三:思维方式融合(未来)

    所谓“互联网思维”,在未来将不仅仅是指“适应互联网行业的思维方式”,也不仅仅是指所谓的快速迭代、试错、用户体验等,而是会继续升华为“以互联网等行业为代表的,社会上最先进的人才、机构所相对的思维和行为方式。”

10.2 如何策划“互联网+”产品

互联网产品就像一座冰山,用户在前端可见的只是冰山浮在水面的部分。而“互联网+”产品则像一个更大的冰山,其隐藏在水下的、普通用户无法直接看到的逻辑更加庞大和复杂。

  1. “互联网+”研发链条中的角色:

    • 传统行业人士:不仅仅是B端用户,也许还会扮演多种完全不同的角色, 不能盲目地接收其建议,而是要用互联网的思维与其碰撞,进行融合和重构,才有可能更加蓬勃的创新出现
    • 合作方:在融合的过程中,往往需要引入一些合作方填补缝隙,应尽量“用好”合作方,将专业的事情交给专业的人去做,但要注意对方向和质量的把控
    • 社会机构:有可能涉及一些社会机构的辅助和监督,在此背景下,对大环境的趋势一定要有足够的把握和理解,使用合法、合理的方式推动产品发展。
  2. “互联网+”产品的策划方法

    互联网产品和“互联网+”产品研发流程对比

    • 行业解构:与一般的行业调研、用户调研不一样,“互联网+”的行业解构要求更深入,既需要知道需求,也需要知道原因,还需要研究“需求”以外的目标(如行业惯例、政策及法律限制)。
    • 结合行业现状思考产品方案:采取恰当的结合现状的产品方案,解决用户核心需求。
    • 构建并迭代商务逻辑:必须同步深入思考商务逻辑,而思考的过程往往需要从双方各自的资源、目标出发,思考对双方都有利的方案。