启示录
2016-08-13 21:44:57 0 举报AI智能生成
登录查看完整内容
启示录
作者其他创作
大纲/内容
启示录-打造用户喜爱的产品
人员
关键角色及其职责
产品经理
评估机会+定义产品
用户体验设计师
项目经理
开发团队
运维团队
保证产品服务正常运行
产品营销人员
产品管理和产品营销
误区一：由市场营销人员定义产品
误区二：两人分担定义产品工作
误区三：一人兼任两项工作
产品管理和产品设计
设计角色
用户研究
评估产品是否符合用户的使用习惯
交互设计
视觉设计
原型制作
产品管理和软件开发
开发人员帮助产品经理
直面用户，了解问题
了解最新的技术发展
在产品初期参与评估产品设计
产品经理配合开发人员
只定义满足基本要求的产品
进入开发阶段后避免修改产品需求和设计
出现问题尽快采取行动
预留一定的技术能力——20%左右
NPS-用户净推荐值
NPS=推荐率（9、10分）-贬损率（0-6分）
产品经理应有的特质
个人素质
正直、自信、自律、智力、职业操守
对产品的热情
做产品的CEO
用户的立场
职业技能
运用技术的能力
时间管理
沟通技能
商业技能
在大企业中产品经理如何施展拳脚
了解公司制定决策方式，向上司/决策者借力
建立人脉网络，分享信息，传播产品理念
臭鼬工程
工作之余尝试新想法
会前沟通，有选择地据理力争
合理分配时间
管理“上司”
为项目波动做好准备
注意沟通频率和方式
千人千面，按特性沟通
多提建议，少谈问题
缩短邮件篇幅
多用事实和数据说话
会前沟通，提高效率
向上司借力
内部宣传
产品经理自问
产品能吸引目标用户关注嘛？
产品设计是否人性化、易于操作？（可用性）
产品的核心竞争力在哪里？如何在现在和未来的竞争中取胜
产品能正常运行吗？运营状况如何？盈利状况如何？
团队其他成员对产品的看法如何？
产品未来的方向应该是什么？
用户的真正需求是什么？产品满足用户真正需求了吗？用户的需求有在变化么？
……
流程
评估产品机会
目的
淘汰需求，避免浪费资源；挑选合适的需求机会
产品机会十问
产品价值——产品要解决什么问题
目标市场——为谁解决问题
市场规模——成功机会多大
收益指标——怎么判断产品成功与否
竞争格局——有多少同类产品
竞争优势——为什么我们适合做这个产品
市场时机——时机合适吗
营销组合策略——如何把产品推向市场
解决方案要满足的条件——成功的必要条件是什么
评估结论——继续or放弃
市场调研
内容
用户调查
注意问卷设计的技巧
产品使用分析
收集用户行为分析
数据挖据
深度数据应用
拜访用户
人物角色
合理地描述用户特征的人格化虚拟原型
作用
筛选产品功能
避免产品团队把自己的需求当做用户需求
对用户优先级进行排序
方便描述，帮助团队达成共识
可用性测试
竞品分析
用户研讨会
对主讲人要求较高，灵活机变，熟悉产品，擅长引导
人群聚集时用户会被他人影响，善于表达者的想法容易取代别人
用户自身并不清楚自己的需求，除非见到产品
局限性
市场调研结果可以作为研发产品的依据和参考，但不能决定研发的方向
产品原则
对团队信仰和价值观的总结，是产品线的战略指南
对原则进行重要性排序
两类易犯错误
原则过于空泛
把设计原则误当产品原则
例
某电影网站的产品原则——相信社区用户的影评比专业人士的影评更有价值
团队内部要统一产品目标和目标优先级
特约用户
目标
深入洞察目标用户需求
赢得用户对产品的推荐
挑选标准
看好产品，认为产品可以解决他们的问题
是产品的潜在目标用户
在产品的目标用户具有一定影响力
仔细筛选，保持人数在可控范围内
特约用户的好处
参与构思产品创意，解决自己的问题
提前使用产品尽早解决问题
降低使用成本
产品经理的收获
在产品定义和开发上得到建议和帮助
调研便利，需求获取更准确
产品表现良好的话会得到推荐
产品评审团
在给定商业战略的条件下决定产品战略方向，监督研发流程，合理配置资源
成员组成
各部门管理者
高保真原型——重新定义产品说明文档
范围
PRD、BRD、业务需求文档、功能规格书等
要求
完整描述用户体验——需求、交互设计和视觉设计
准确描述产品行为
表现直观，易于理解
允许修改
高保真原型
功能需求、信息架构、用户体验、交互设计、视觉设计
用例作为补充
创业型公司的产品管理
创建体现用户体验的高保真原型
邀请真实的目标用户验证产品原型
确定产品原型之后进行开发
基本产品
只满足基本要求（价值、可用性、可行性）的产品
实现方式
产品经理和设计师合作设计产品高保真原型，只包含基本要求的实现
邀请一位开发参与原型设计
请用户验证原型
基本产品确定后不可能在削减任何功能
产品验证
正式开发之前，定义产品之后
测试的注意事项
不必等到完整原型完成后再测试，可以先测试主要项目
实现拟定测试内容
了解测试者未接触产品之前如何解决产品要解决的问题
观察测试者能否从原型首页看出产品要解决的问题
测试后通过聊天进一步收集信息
测试前不与测试者交谈过多
让测试者保持平和的情绪，不要让他们陷入吹毛求疵的状态
多观察用户操作，少听他们的抱怨
不给测试者提示，避免引导
从测试者的肢体语言和语气发现信息
目标——理解目标用户如何看待产品要解决的问题，发现原型与用户期望不一致或不相容的地方
可行性测试
价值测试
敏捷开发（Scrum）
先定义用户体验再动手开发，产品经历和设计师工作进度应比开发团队领先一两个迭代周期
前期架构制约着开发工作，架构的修改对开发来说无异于重来
开发中的产品应以固定的原型为基础
开发可以分成多次迭代，用户体验设计不能拆分
产品经理即是产品负责人
让开发人员自主划分迭代周期
瀑布式开发
基本原则
阶段式开发
阶段式评审
优势
流程具有可预测性
每阶段都有详实的文档
问题
产品验证严重滞后
确保产品设计通过用户验证，可行性验证
变更计划的成本过高
越早改越好
无法适应市场快速变化
平滑部署
毫无征兆的更新不必要的版本会令用户产生反感
做好测试工作，避免新版本存在的影响正常使用的问题
逐步发布新版本
快速相应阶段
产品发布后一周，留出时间快速响应、处理产品发布后的用户反馈意见
使用明确的、可量化的指标评估产品
产品
苹果公司的启示
硬件为软件服务？？？
封闭不开源——PC失败的原因之一
软件为用户体验服务
用户体验为情感服务
产品为真正的需求服务
提防特例产品
产品经理应和用户一起梳理需求，发现问题本质，提供更合理的解决方案
以产品原则为基准决策
新技术解决老问题
美观实用缺一不可
大众网络服务产品十大要点
可用性
扩展性
持续可用性
客户服务
保护用户隐私
口碑营销
全球化
用户社区管理
企业级产品
对象
中大型企业
类型
企业基础软件
安全、企业管理、通信软件
企业应用软件
营销自动化、客户关系管理、企业资源企划软件
要点
购买者并非使用者
正常使用
特例产品
坚持原则，发现本质需求
产品安装
简单的安装操作
销售渠道的需求
产品的配置、自定义、集成
和其他产品相互兼容、协同工作
产品升级
简化升级技术和流程
销售策略
销售人员的个人能力、互联网内的营销
平台产品
应用开发者能在其基础上开发应用程序
操作系统
运行环境（FLASH、JAVE）
web服务
游戏开发平台
应用平台（Facebook、Salesforce）
用户
应用软件提供商
关心平台的生存能力
开发人员
关心在平台上开发是否方便省力
终端用户——根本
关心最终结果
产品应该满足用户的情感需求
情感接纳曲线
技术爱好者
容易对产品经理产生误导
非理性消费者
情感需求与大众相同，但被放大
普通大众
理性消费者
更务实，看重性价比
超理性消费者
情感需求极弱
观望者
购买公认的好产品
对不满情绪的过度反应
帮助产品经理发现产品的内在价值
关注失望、不满、愤怒等一切负面情绪
0 条评论
回复 删除
下一页
