产品
用户需求
用户需求一定要立足于用户,一定要验证这个痛点到底是不是真的存在
如何获得用户需求:
stateDiagram-v2 确认目标用户 --> 数据分析与用户调查 数据分析与用户调查 --> 作出用户痛点的假设 作出用户痛点的假设 --> 挖掘数据与用户反馈 挖掘数据与用户反馈 --> 验证痛点存在 验证痛点存在 --> 深入面对客户 深入面对客户 --> 将痛点转为具体的需求
用户群体
- 针对性很强的客户
描绘用户画像:把这类用户抽象成一个人,然后用介绍这个人的方式来描绘这一类人
描绘用户问题:一句话,这句话能精炼、简单地描述你到底要为什么用户解决什么问题
最小化可行产品
- MVP
没有任何一个功能是“加上去也挺好的”,但是少了任何一个功能都无法解决用户最基本的需求。最小化的目的是降低试错成本,快速验证产品能否满足用户需求
产品指标
指标是定义了产品要完成的目标,需要表达清楚在什么期限之内、要达到什么具体的、可衡量的结果
- 明确最高目标
- 衡量最高目标所需要的指标
- 思考新功能与指标的关系
- 思考负面指标
产品评测
竞品评测
评测的目的:改善我们的产品
评测的范围:战略 定位 用户 功能 交互
评测的结论:我们要做的
基础描述:
- 行业描述
- 行业背景
- 领域定位
- 市占分析
- 产品描述
- 用户定位
- 商业模式
- 发展现状
- 评测描述
- 评测环境 版本 方式
产品分析:
- 产品定位
- 产品框架
- 功能框架 模块分类
- 产品对比
- 战略分析
- 商业模式 成长打法
- 特色功能
- 盈利对比
- 盈利模式 盈利能力
- 核心用户
- 产品壁垒
- 能力 技术
- 扩散对比
SWOT分析:
badcase 挖掘
- 不符合用户心理预期的产品输出结果
- 难以发现
挖掘方法:
stateDiagram-v2 数据标注 --> 挖掘模型 挖掘模型 --> 算法分析 挖掘模型 --> 日志挖掘 日志挖掘 --> 用户行为挖掘 日志挖掘 --> 预期结果挖掘 用户行为挖掘 --> 行为延续,有别于大部分用户的异常行为 用户行为挖掘 --> 行为时间,有别于大部分用户的异常行为时间 用户行为挖掘 --> 行为漏洞,连续的功能之间使用时间发生断层 预期结果挖掘 --> 结果对比,将用户的行为跟预期对比 预期结果挖掘 --> 异常监控
stateDiagram-v2 BadCase --> 定级 定级 --> 严重|中等|轻微 定级 --> 问题定位 问题定位 --> 原因分析 原因分析 --> 修复排期 修复排期 --> 产品上线 产品上线 --> BadCase
舆情分析
发生期 -> 发展期 -> 巅峰期 -> 余震期
技术支持
关键词:产品相关、公司相关、品牌相关、关键人物
舆情抓取:新闻资讯、社交媒体、传统媒体、公司留言、工商投诉
舆情报告:舆情数据、发展预测、事件分析
用户研究
用户属性决定了用户需求
从用户的需求可以细化出用户的场景
以场景需求为基础,建立核心功能
用核心功能服务核心用户
用户细分
核心用户:
- 较高留存粘性
- 付费用户
- 病毒源头用户
用户结构、用户画像
针对用户行为分析、分层精细化运营
用户行为
- 探索性行为:谨慎
- 习惯性行为:让用户用得更舒服
行为分析:热点分析、漏斗分析、多维度分析
路径分析:留存分析、路径优化
PRD
不做高保真、不重复、不写废话
- 以文档的形式准确传达需求
- 用来约束产品经理以及研发
- 验收产品质量
- 记录产品迭代
stateDiagram-v2 BRD(商业需求文档) --> MRD(市场需求文档): 客户需求=机会 MRD(市场需求文档)--> PRD(产品需求文档): 可行性 PRD(产品需求文档)--> BRD(商业需求文档): 执行
包含的内容:
- 解决的问题
- 验证痛点是否存在
- 需求成功的指标与负面指标
- 要解决的用场景
- 解释清楚需求
工具
- 文档软件
- 原型软件
要素
命名、编号
XX产品V1PRD_V2
版本历史、目录
版本号 | 修订人 | 修改日期 | 修订描述 |
---|---|---|---|
引言
- 产品背景(研发、市场趋势、发展前景)
- 预期读者
- 产品规划
需求概述
- 业务流程(功能模块图、流程图)
- 用户角色及用户描述
- 功能清单(功能模块、主要功能点、优先级)
- 运行环境
- 产品规划(关键里程碑、可能的风险)
功能性需求说明
- 简要说明
- 场景描述
- 业务规则
- 原型图
- 前置条件:需求依赖的前提
- 后置条件:操作后的后续处理
非功能描述
- 性能需求
- 运营需求
会议
有效的会议:
- 对选择决定限定最后期限
- 会议要与每一位参会人员有关
沟通
与工程师
- 了解工程师在乎什么
- 异步沟通比同步沟通更有效率
- 领导总体,细节让工程师们自己决定
- 帮助工程师们解决开发中的困难
催进度:
- 让工程师估工期,有掌控权
改需求:杜绝根据假设以及个人的意见改需求,用户反馈才是修改产品需求的依据
- 尽早发现变化,尽量不改
- 实在需要改了就积极承担责任
与设计师
- 新手设计师与老手不一样 新手们需要详细说明到面面俱到 老手们可以交由其一定自由发挥空间
- 设计师大都为艺术家型人格,追求面面俱到的完美
执行
- 结果导向、责任分明
- 把控做决定的速度
- 把控任务的优先级