从点子到产品
2017-12-01 13:21:53 355 举报AI智能生成
登录查看完整内容
![003-从点子到产品[阅读笔记]--刘飞-产品经理](https://po-img.processon.com/chart_image/thumb/5f2e3b30e401fd13e7232758.png)
从点在到产品读书笔记总结
作者其他创作
大纲/内容
从点子到产品
产品价值和用户痛点
点子与方案
产品模型：设计合理性
何为产品逻辑？答：需求能够良好的运转起来
设计产品逻辑方法：那就是把所有想到的关系捋清楚，并且化成流程图或者结构图，在至少运行一遍，看是不是可以跑得通
合理的产品设计应该满足9个方面：
1.提高或不降低效率 2.降低或不提升成本 3.提升或不破坏体验 4.需求满足提供的可能 5.需求满足发生的场景 6.需求满足接受的意愿 。 7.是否存在市场 8.是否存在需求 9.是否存在用户
商业模型：盈利合理性
企业盈利的方式多种多样，如直接购买，会员体系，先得服务，企业服务，赞赏等等，但是哪一种盈利模式适合自己的产品模型，自己的产品又适合哪种盈利模式的组合，这就需要考虑产品发展现状，产品主营业务，产品核心功能以及产品所在客户党总所能接收的方式
环境：拓展合理性
产品的拓展性可以从产品本身的外延性考虑，市场上的技术，以及风投领域的热度，国家相关政策和盈利模式的变化来考虑产品可拓展性
团队：实施合理性
产品逻辑设计的很合理，商业模式也 ok，产品拓展性也很强，但是这样的产品凭什么要由你来做？能力配上野心，才有资格讲话
总结：你有一个好点子算不了什么，但是如何把一个点子做成产品才算牛逼
找到产品核心价值
解决问题是产品价值所在
产品的核心价值就是解决核心用户的问题
用完即走并不是不要粘性
用户来，是希望你的产品帮他解决问题，若你以各种手段诱惑客户而让其留恋忘返，你能留住什么样的用户，而真正的用户又该何去何从？
确保产品真正解决问题
产品如何‘真正’的解决用户的问题，而不是以为解决了问题，或者是假装解决了用户的问题，需要清除的辨别出产品设计的目的与结果
用超预期的方式解决
超预期的标准为：给用户到来的愉悦感和实际好处＞用户转移的心理成本+转移的实际成本
如何用超预期的方式解决现有用户的需求？做出超出用户预期想象的功能
总结：解决用户的问题才能体现产品的价值，不以真正解决用户问题而设计的产品可以说是耍流氓吗？
MVP 与痛点
设计 MVP
要求：达到可用和最小成本的平衡
MVP 方法
MVP 方法有广告，假 MVP，线下实现和众筹等
实现 MVP
实现 MVP 需要考虑选择什么平台，产品实现是否让位技术实现，外包所存在的风险
找到痛点
通过数据分析发现用户痛点
通过用户反馈发现痛点
MVP 不是不做产品模型的借口
总结：MVP 是用最小的成本（技术实现）是验证是否满足客户的真实需求，根据 MVP的数据及时作出调整
需求分析与功能设计
深挖需求
基于场景深挖需求
场景包含了人物，时间，地点，环境及情节。基于场景发现用户的问题以及用户是如何解决问题的
从人性本质深挖需求
需求可分为表现需求，深层需求，和人性需求。人性有哪些，如何满足人性的需求？
总结：‘我要什么’是需求，我要什么背后的原因则是更为重要的需求，驱使这个背后的原因则是人性的需求，也就是最为根本的需求
用户研究
问卷调查
确保问卷能够达到目的
问卷问题设计的合理性
样本的把控
用户访谈
确认访谈的目的
掌握好访谈的过程
控制好样本质量
可用性测试
可用性测试不但要观察用户的反馈，还要观察用户的情绪变化
数据分析
启动次数反应了用户的粘性
启动时间和时长反应了用户使用场景
事件完成率检验功能的优劣程度
使用出错情况反应了产品体验
用户活跃情况反应了对于产品的认可度
用户属性检验产品可拓展性
实地考察发现产品的真实问题
用户研究的结论
通过用户调研后的数据输出指导产品优化的方案
总结：用户调研的方法虽多，但需要根据自己产品的问题以及调研的目的，可不拘于形式，只要能够达成自己的调研目的的一切方法都是有效方法
用户体验
可见原则
可见原则不要让你的用户迷失在你的产品里
场景贴切原则
根据产品考虑功能
可控原则
控制权应该给到用户
一致性
整体产品风格以及使用逻辑需要保持一致性，与主流产品保持一致性
防错，防呆原则
切忌产品死循环，让客户知道下一步
协助用户记忆原则
帮助用户再次确认的功能体验
简约易读原则
界面足够简单，文案足够简洁
容错原则
避免客户无意犯下不可挽回的操作错误
帮助和提示
帮助和提示免去用户思考
灵活高效原则
帮助用户免去多余步骤的操作
恢复现场原则
保护现场，实现用户原路返回
关于文案
文案简洁无歧义
总结：设计产品时心中谨记我给谁设计的，设计产品是帮助用户提高效率，你所有的努力是让用的人用的舒服
产品管理
文档管理
产品经理要不要懂技术
技术所定义的概念是什么？产品经理需要理解所设计的产品除了交互层面都是数据交互，具体要懂多少技术知识则需要根据实际情况而定
好的文档到底是什么样的
没有逻辑硬伤
没有疏漏
逻辑清晰
可读性强
文档逻辑
功能框架的逻辑
拆分
组合
业务流程的逻辑
面向事件的
面向对象的
功能描述的逻辑
完整，设计所有流程分支
考虑到产品所有影响点（特别是在产品初创期，不以全局考虑而后期拓展业务的艰难）
条件判断清晰
叙述背景
总结：撰写文档的目的是减少与技术无必要的沟通成本，文档样式不重要，重要的是否解决了与技术无必要的沟通从而提高团队的效率
需求管理
获取需求阶段
判断需求本身的重要性
考虑需求来源
了解需求背景
讨论和设计阶段
确定需求的优先级
基于四象限法或者 kano 方法
方案的草稿
指定负责人
划定时间节点
待开发阶段
方案本身的可行性
有没有更好的方案
涉及的产品和技术环节有哪些
方案的成本如何
开发阶段
合理规划好需求的优先级以及项目开发排期
杜绝
产品方案不完整
需求方的主观改动
无法预测的客观原因
复盘阶段
复盘不但整个需求生命周期结束后需求，实时都需要
总结：掌握好需求管理，控制好开发节奏，让产品稳速前进
工作流中的管理
协作管理
与技术人员的常规协作
与技术人员协作的临时状况
与需求来源方的协作
双赢心态
开会
罗伯特议事规则
会议记录有助于大家记住会议内容
记录，防止死无对证
文档实时归档，后续可查
想法思路，交给笔记
流程管理
让协作标准化和流程化
减少手工劳动
Google docs
workflow
让一些工作可以复用
避免重复犯错
个人管理
任务管理
别把表现出来的焦虑当成任务的紧急程度
别把充实当成完成任务
眼观要足够长远，拒绝只做半衰期的事情
为事情限制截止日期
效果主要
知识管理
团队管理
专业技能服务
管理技能
总结：避免把生命浪费在无意义的事情上，高效的管理可以提高团队整体效率，节省大家的时间
技巧和方法
处理问题
发现问题
什么是问题
在工作中对任务要有预期
敏锐地察觉到与现型不符的状况
不应关心没有预期或与预期差别不大的状况
问题是合情合理的吗
问题是真实存在的吗
把问题描述清楚
考虑问题的背景
考虑问题涉及的人
考虑解决问题的期望
发现问题的主动性
发现问题出在哪里，然后根本性的解决问题
分析问题
抽象问题：发现问题背后的问题
逻辑分析的常见问题
混淆因果关系和相关性
概念歧义或者偷换概念
逻辑关系混乱，不熟悉归纳演绎方法
假设错误
轻易断言
太过主观臆断
片面归纳
比喻过度
被统计数据欺骗
解决问题
拆分问题
解决方案
问题和背景
方案内容
方案的负责人
方案的目标和验证方法
推动执行
确保对方获取到所有的信息
了解对方的态度
定期关注
解决后检验效果
备注：KPI 通常称为管理之刀，OKR 则称为刀法
总结：产品经理不但要能更好的发现问题，同时也能很好地解决问题
沟通
理解
找到重点
用复述来确认是否真正理解
区别事实和观点
关注诉求
表达
表达重点
确保对方理解
用更形象的方式
沟通的心态
把批评当成信息
不要过度解读
不纠结对错，不关心输赢
总结：倾听是最好的沟通方法，准确的表达自己的观点，才能更有效的传递信息
成长
好项目+好导师
好的项目让自己丰富实践经历，好的导致能够帮助你发现问题，更好的成长
博采众长
博采众长，融会贯通
素养
素养能让我们的产品变得更好
审美
不但产品需要审美能力，生活中各个方面都需要审美能力
善意
让别人念你的好
有趣
有趣，可以让你更受欢迎
招聘
综合评价产品经理能力，而非主观判断
【把自己也当成产品去迭代成长】-我已经按照这个方法实施有半年了
总结：跟对人，做对事，好好学习
兴趣和热情
产品的责任心
不缺席重要的场合
排除影响进度的问题
主动填充缺失环节
产生兴趣
需要你先产生兴趣
有兴趣未必一定擅长
兴趣和意志力
产品经理的自驱动
做一个自驱和驱动周边的人
总结：产品经理不但需要做好本职工作，还要时刻传递正能量，驱动团队共同成长
0 条评论
回复 删除
下一页
