【产品笔记】2.互联网产品修炼

*晴儿*

于 2020-03-20 18:42:14 发布

阅读量1.2k

点赞数

分类专栏：产品

本文链接：https://blog.csdn.net/qq_34919415/article/details/104648810

版权

产品专栏收录该内容

5 篇文章 0 订阅

订阅专栏

如何做正确的产品（战略），比正确的作产品（执行）更重要

正确的产品，在正确的时间，正确的做出来。

选择比努力更重要。

产品的本质、规律

用户域市场是检验产品价值的唯一标准：任何产品价值的唯一衡量标准就是他的目标用户及市场

产品守恒定律：

1、你的产品多给力，用户就给你多少力

2、产品价值量守恒

3、产品复杂度守恒

产品使人的交互更简单了，那么隐藏在产品背后的复杂性就增加了。

如果使用起来很简单，意味着增加产品经理和开发工程师的工作难度。

靠谱的商业模式：

1、吃软饭，赚硬钱（增加服务量的时候，人力增加较少）

2、低者为王：赚“三低”人群（偏娱乐，偏低领，偏低收入）的钱；免费；用户体验也遵循着“低门槛为王”

3、“印钞机”：像印钞机那样自动赚钱（用户数量增加，人力增加较少，赚的越多）

互联网定律

1、诺威格定律：当公司的市场率占有>50%，市场占有率就无法再翻番了

大厂扩展业务的原因，因为占有率较高，很难再翻番。

2、基因使然：越成功的公司越难拐弯。某个领域特别成功的大公司已经被优化的极度适应这个市场。但它成功的基因未必适应新的市场，很难获得下一波巨大的成功。

3、顺势而为：对的时间做对的事情

选择做什么样的互联网产品时，一定要全面考虑到所在行业发展及周边环境的“势”

战略层：做正确的产品

1、感性和理性结合：需求采集与市场分析

2、行业和市场结合：洞察需求与满足需求

3、理想和显示结合：战略愿景与产品定位

需求分析靠谱，很难。调研的不够前面，市场分析不够透彻，会造成巡视。

将二者动态结合

洞察用户需求更多的是从行业端入手分析。

满足用户需求更多的是从市场、用户去入手分析。（入门）

行业端的位势必市场端高。

宏观越好，容错率越大。大的方面好，小的方法错，也会有用户使用，会接收批评。如果宏观错了，用户体验再好也没用。

准确把握用户需求——拎得清。我想要一匹更快的马。马（赛马者）？汽车？需要结合场景

产品也讲辩证法——舍得。免费策略，产品功能复杂性守恒说的就是一舍一得。

做人的思路做产品——换位思考

人们是否喜欢我们，往往取决于我们让对方获得的感受。

让用户喜欢产品，一定要将产品设计成一个举止得体，魅力十足的人。

种下产品成功的基因

一个产品最后是否成功，很大程度上取决于开始的出发点、产品战略、产品定位等。如果这些做好了，就可以认为种下成功的基因，后面的产品发展之路就会相对顺利。

要做先驱，不要做先烈。早起的鸟儿要选对时机。

产品成功与否，某种程度上取决于推出产品的时机。1、市场和用户需求。2、基于自身资源和投入产出比的问题。

人生就是一系列偶然的有意义的联结，产品也是。

产品的行业分析

互联网产品的行业特点

互联网行业发展

互联网产品的交互性：根据第一手的运营反馈来优化调整产品方向和设计思路

高固定成本，低边际成本：一亿个用户到十亿个用户边际成本几乎为0

互联网产品的网络效应：人人为我，我为人人；借助网络效应产生的价值量取决于用户数量和激发网络效应产品业务规则

网络效应的竞争启示：：1、尽快增加互联网产品的用户数量，越快越好。2、优化产品，使网络效应的“临界点 ”越小越好。3、尽快让产品比竞争对手先达到网络效应的“临界点”

互联网的本质

去中心化，每个用户都是一个中心

产品经理要把自己当做用户，从用户中来，到用户中去，才能真正做出好的产品。

8848（网购）目标很好，但是推出的时间过早。

QQ沟通方便，降低成本。

自我实现的需要、尊重的需要、社交的需要、安全的需要、生理的需要。

2000年前后，流量对于互联网公司最重要。

“借鉴”可以，但是要根据你的用户需求进行“适配”。做竞品分析的重要性。依据竞品的功能，分析用户的背景和需求。

哪里有痛点，哪里就有新的机遇。

团购：价格敏感性用户

小结:互联网用户需求的“进化史”

WEB1. 0时代
在互联网初期，用户处于因新鲜、好奇而开始接触、了解、学习互联网阶段，于是满足中国网民的互联网内容需求的门户网站迅速崛起(新浪、网易、搜狐3大门户)
WEB2.0时代
在用户被动接触互联网内容需求的不断发展的过程中，激发了“被动阅读”外的主动性需求，通俗的说就是“口味变重了”，于是激发了更进一步的“主动性”需求和一些专业化垂直化需求
于是互联网进入了以满足用户社交、尊重、自我实现等更高级需求为目的的，这时满足互联网的几大基本需求一即时通讯、搜索、网络游戏、电子商务等一的互联网巨头诞生腾讯、百度、阿里巴巴，由此确立了直到今天的互联网巨头格局
与此同时，些满足基本需求外的专业化、重直化需求的互联网细分产品(携程、安居客、大众点评等)也纷纷涌现出来

互联网的现状——移动互联网时代

娱乐应用占主导地位，商务应用出于萌芽期。

娱乐和社交应用成为主导移动互联网市场的主要力量之一（游戏、视频、即时通讯）

用户逐渐转向与生活紧密相关的实用性移动互联网产品（大众点评、58同城）

移动端产品典型特征

用户绑定、时间碎片化、有限的展示空间、基于LBS的定位功能、便捷收费、流量入口和APP

用户特性：限时限量、及时性、碎片性（步骤设计要短）

手机特性：地理位置、摄像头、麦克风、运动

移动端产品发展趋势：social（社交）+local（本地化）+mobile（移动特性）

互——单向互动→双向互动

联——PC→移动→物联网

网——web1.0→web2.0

大数据：预测、智能、大智慧

	资讯人与信息	交流人与人	娱乐人与服务	商务人与商品
web1.0 search	百度	QQ	盛大	阿里巴巴
web2.0 social	微博	人人	开心网	？
web3.0 mobile （我瞎填的）	今日头条	微信	农药吃鸡抖音	淘宝京东拼多多
web4.0 物联网（彻底瞎填）	天猫精灵、小爱同学？	5G发展中...？	5G发展中...？实时游戏，VR？共享单车？智能家居？	物联网机器人送货？

需求的分析与管理

需求是什么：

用户的角度：我要喝水/扇子/开窗户/冷水澡

背景：用户呆在屋子里，汗流浃背，非常热

从产品经理的角度：给用户解决“这里太热了”

需求是用户的最终目的

它不是某个功能、不是某个解决方案、只和用户的最终目的有关

用户的最终目的，也就是需求几乎不会变

用户的需求不变，但解决方案及用户的期许一直会变

用户对产品（解决方案）投了反对票，不代表他对他的需求投了反对票

围绕“需求”想解决方案

优化产品功能的时候，依据场景和需求

分析需求的利器——马斯洛层次需要

越底层、越原生态、需求越“强壮”（先满足客观需求再满足主观需求）

所有互联网产品需求都可以延伸至对应的马斯洛需要

要抢占“制高点”

产品需求、用户需求、马斯洛需求、包装产品需求

准确的找到需求

用户的需求像冰山：明确的需求、隐含的需求（不好意思说、懒得说）、未知的需求

准确找到需求：问其话，查其言、观其行。在他身边，为他设计，找到用户的痛点。先解决大多数用户的痛点。

定位到强需求（刚需）、频发性需求（经常发生的场景）。

真需求：产品经理提供了某个功能，大多数用户都会使用。假需求：场景没有真实且普遍的发生

将需求去伪存真：1、是不是目标用户的需求及普遍需求。2、分析需求表项。3、挖掘需求根源。4、关注需求背景。

管理需求

卡诺模型

需求管理列表（需求池）

规划需求：

1、贯通（利用公司其他产品，账号打通，流量入口打通）。

2、打桩（基本内容夯实，端的优化，增加需求）。

3、连片（自身的某一个模块，把场景连成一片，连公司其他产品）。

4、筑墙（构筑核心竞争力）。

5、延伸（非用户也能享受部分服务，赢利模式的延伸）。

遵循需求的价值量守恒（对C、对B的好处）、产品设计中的复杂度守恒

产品的执行

1、产品需求评审

2、产品研发

3、产品管理

互联网产品研发流程（☆为必须）

需求☆——需求分析☆——概要设计（生态模型）——产品需求文档☆——所有功能点罗列（原型&PRD）——UED☆（UI、视觉、重构）——研发☆——内侧☆——预发布环境——线上环境☆——跟进线上测试——反馈信息——给出优化方案——下次需求

概要设计(生态模型)

画流程图,并思考以下问题:

1.你理解到的:为什么要做这个产品设计?出发点和目的是什么?重点的体验目标是什么?

2.这个产品要满足用户的什么/哪些需求?用什么/哪些功能设计来满足?先满足什么需求?再满足什么需求?

3.这个产品在系统的众多功能中，设计重点有哪些?重要性的先后顺序是什么?

4.这个产品在系统中和其他产品的关联点有哪些?需要其他产品什么样的配合?

5.该产品需要做好哪些数据统计点?这些数据可以说明什么?

产品评审委员会

1每次新需求及需求变更都需要做产品需求评审，而且每个关键职位角色的相关同事都要参与。同时为了保证沟通效率，总人数最好控制在10人以内
2大版本建议控制在3次内定稿;而需求变更建议1次，最多2次定稿
3针对用户体验要求高的产品版本,建议可以分为2次评审:第一次把业务逻辑定义清楚(包括流程图、主要流程、主要的交互原型等) ;第二次产品经理把所有详细的细节给出来( PRD及所有交互稿)

4需求评审会前产品经理最好分别单独沟通、对一些细节最好提前完成多方确认，尤其是同部门]之间最好要会前就已经沟通确认完毕，这样在会上的评审效率会非常高
5产品经理尽量用数据和事实来阐述需求分析思路，比如有数据说明出的需求是确实有必要的，能缩短用户时间,能提高用户的在线时间等等
6不要有频繁的需求变更。原则上，通过需求评审后，需求变更次数制在3次以内，且产品经理、研发、项目经理最好做需求变更评审，评审通过后，相关文档要第一时间做及时更新

7关于“需求变更”的重要补充说明。就笔者所知，大部分公司的产品需求变更是这样处理的:产品经理更新PRD，发邮件给到研发，或者直接找开发人员沟通。不过，这种方式存在的问题是:研发有可能不看邮件就疏漏掉了，或者出现研发对于变更的影响没法评估、评估不够全面等情况。
所以建议需求变更一般都要评审,然后再决定要不要变更。而且参与的人员必须包括产品经理、项目经理、研发负责人、测试负责人。这样，就可以有效降低因需求变更而给产品带来的风险 !

PRD是产品项目进展过程中最为重要的文档(没有之一)
PRD是研发和测试的唯一书面依据，研发依此进行系统设计和编程，测试依此编写测试用例和测评,而项目经理依此进行项目管理工作,甚至产品经理也常常用它来回顾自己的产品设计思路。可以说，PRD贯穿于整个项目的全部研发过程，而且在很大程度上决定了最终上线的产品质量。

优秀的PRD应该是描述清晰准确、编写完整并尽可能简洁
一份产品需求文档至少对每个功能 (或称为“用例”) 在以下方面给出明确说明功能简要描述
角色
前置流程
流程图
用户界面
基本流程(主干流程)
分支流程
后置流程
商业规则

PRD实例——功能:手机注册

(一)描述

用户在易售登录页申请注册易售账号，根据既有策略,支持:手机注册、邮箱注册。本用例说明手机注册。

(二)角色
用户、易售
(三)前置流程
用户在注册页点击"使用手机注册“进入本流程

（四）基本流程（主流程）图

1用户在易售登录页点击“注册”，进入“手机号码注册”页面，按页面提示(见表1 )完成注册操作
在60秒内，同1个IP地址发起注册请求超过2次，前端需增加图片验证码防刷
2当用户填写完手机号(以移出为准)，需调用易售账号查询接口，判断该手机号是否能注册
如不可注册，手机号码填写框报错，见(分支流程1]
[注] :报错信息、及信息填写规妙:洋见表1。
3用户点击“免费获取手机验证码”按钮，判断是否满足发送验证码条件，如满足则用户可有效点击。条件包括:
( 1 )填写的手机号码可注册。
(2)满足防刷策略:
1 )前端服务，当触发1次后需等待60秒后方可再次点击

2）后短服务（注册服务后端控制）在60s内只能向同一个手机号发送一次短信

4调用短信网关向用户填写的手机号发送短信验证码，用户根据收到短信在页面中填写验证码;如发送不成功，可等待120秒再次点击。
( 1 )短信内容显示为:您申请用本机号码注册易售账号，注册验证码是${mobileNo}，120秒内有效。
( 2 )注册短信有效时长为120秒(即2分钟)。
5用户所有填写信息需符合表7-1所示规范，每个填写项以鼠标移出为准，作信息填写规则的合法性验证，如符合，可允许用户点击“注册”提交操作。
6用户点击“注册”按钮，先做图片验证码防刷验证,如符合防刷要求，则增加图片验证码要求用户填写;如无需防刷，则进入下一步。

7注册服务核对短信验证码是否正确，如正确，进入下一步;如不正确,则进入[分支流程2]。
( 1 )需检查手机号码与短信发送的号码是否匹配。
( 2 )检查短信验证码是否正确。
8如操作成功,前端流程可正常跳转至补填注册资料页，进入下一步;如创建账号失败，则报错，进入[分支流程3]。

9用户根据页面提示补填注册资料信息,需符合信息填写规范。
(1)如不符合，在当前页报错;
( 2 )用户也可直接跳过“补填注册资料”，进入[分支流程4].
10如操作成功，则进入注册成功页;如不成功,则报错进入[分支流程5]●11注册服务向用户发送通知短信。短信内容显示为:您已成功注册易售账号，账号名是您的手机号码。
12用例结束。

（五）分支流程（异常情况的解决）

（六）用户界面

（七）后置流程

补全注册资料，申请成为经销商

（八）商业规则

(八)商业规则
注册防刷策略汇总:
1.图片验证码显示规则:在60秒内，同1个IP地址发起注册请求超过2次，前端需增加图片验证码防刷。
2.手机短信验证码发送规则:
3.在60秒内，注册服务(后端控制)只能向同1手机号发送1次短信。
4.如在60秒内有应用请求发送短信，拒绝报错为:“已向该手机发送注册短信，1分钟内请勿重复请求”。
5.用户通过页面，请求发送注册短信;每触发1次，需冻结60秒方可允许继续触发6.注册短信的有效时长为120秒(即2分钟内)。同1个手机向注册服务提交注册
6.短信验证码发送请求，在2分钟内，发送的短信验证码是一样的，无需变更。

产品研发管理

项目启动
第一步要进行工作分解
也就是把大块的工作化整为零，庖丁解牛。
目的就是把大的项目通过细分，变成系列小的、可操作和易实现的活动。这些活动，会落实到项目中的每个成员每天应该完成的工作。
互联网产品的项目计划时间表通常都是细化到功能或子功能

责任落单（写在单人身上）

在预计想项目的活动及时间安排上，要尽可能的详细

每次正是开始前，发个KiCK OFF邮件

敏捷开发的技巧
产品负责人由产品经理担任
产品经理应该是产品的负责人,因为产品经理是所有业务的接口人，最熟悉业务，也最了解用户的需求,并且需要与产品研发团队保持频繁密切的沟通，协助监督开发进复,以及及时解决出现的问题。所以说，产品经理是产品负责人的最佳人选。

一定要做好产品的功能规划
在敏捷开发环境中，对人员能力的要求是非常高的，不仅需要产品经理明确产品的方向和目标，往往还需要产品开发处于第一期时，产品经理就要明确给出第2期，甚至第3期的需求，而在需求文档产生之前的功能规划往往要更加久一些。
不过，在敏捷开发环境里,规划周期应该适当缩短为好

产品经理的需求要领先1~ 2个开发周期
产品经理要确保产品需求分析工作要领先研发团队1~2个开发周期,以确保能够有足够时间进行正确的需求分析工作

每天review一次

采取“站会”形式，防止“偷懒”（风险可控）

产品经理进度管理、把控 项目进展表

产品经理一定要做到“无缝沟通”

“当面说”是最有效的交流沟通方式，“文档+当面沟通，双管齐下”更保险

产品管理

特约用户：最好的用户研究方法就是把产品做出来，给用户反馈

设定固定紧急需求接口人(“114" 合作流程)
1 :尽可能通过1个需求接口人来反馈BUG等紧急需求,由需求接口人向产品经理反馈紧急需求，由产品经理向设计师、视觉、重构、研发等安排任务，以便达到任务有序安排,有序跟进,有序汇报;
1:当需求跳过需求接口人时,需求接收人，请第1时间反馈给需求接口人和产品经理，再由产品经理记录并安排任务优先级，以便有序跟进，有序汇报;

4 :超过4小时未反馈，且与下一任务发生优先级重叠时，请需求接收人负责协调资源，解决问题(此点要求会提高需求接受人不按时反馈BUG等其他紧急需求的成本,以便保证做到对用户的需求快速响应;此外, 4小时的设定是让需求接收人能过意识到团队是多么关注客户的需求)。