人人都是产品经理笔记

合集下载

产品小白的学习笔记| 许愿池产品从0到1诞生流程

产品小白的学习笔记| 许愿池产品从0到1诞生流程

创意来源过程:学习小组内成员在生活中的发现的痛点:关于过生日收礼物这个事件,主体:送礼人—-礼物—收礼人收礼人:特别是女生在收礼过程中经常有不喜欢的礼物,还不好意思表达意见,并指出你到底喜欢什么样的礼物。

送礼人:特别是男生,想送对方合心意的礼物但是不知道你喜欢哪个,选购礼物的过程花费大量时间,结果可能对方也未必喜欢。

所以初步讨论我们发现在收礼物这个普遍的场景下:将产品方向定义为:解决收礼和送礼的矛盾,让人们能够收到和送出对方真正想要礼物的产品。

二. 用户研究1. 定性研究:焦点小组:粗略定义下我们的客户群,有针对性的讨论特定用户群的共性和差异需求并作为产品设计的验证或依据。

客户群初步分类:由于收礼确实在年轻人中普遍行为,初步定义客户群为收礼方年轻女性居多,送礼方年轻男性和女性都适用。

初步需求:选礼物,发布礼物许愿让好友看到,好友帮忙买单,记录特殊日期并提醒等。

2. 定量研究:需要说明的是由于是在课堂做的实践,所以由于条件限制我们就只能做一定量的用户访谈作为定量依据了(一般来说用户访谈做定性研究比较多)。

目的:验证对产品的一些想法以及更深一步的了解用户的使用习惯和真实的心理诉求。

用户访谈的一般原则是先开放再聚焦,探索跟踪获得更多信息,避免诱导性问题。

本次访谈样本总数10人:实践小组共5人,每人访谈两人。

提前准备的具体问题如下:访谈总结如下:根据客户的访谈总结的人物信息统计,一般收礼高频(每月大于1次)使用者为20-30岁女性,而送礼(每月大于1次)一般为20-40岁男性和女性。

用户类型可描述为低价潮流型女学生,品质消费型职场女性,低调给予型职场男性等用户。

可以画用户肖像了。

根据用户的访谈结果,可以初步的对需求进行排序:痛点或期望并标记了需求的级别:高、中、低(注意需求优先级高低依据“用户诉求出现的频次”、“用户诉求对成功完成收礼这件事情的影响程度”进行综合判定的结果),顺序如下:1. 低调告知朋友我的心愿,或是获知别人的心愿2. 特定日期的记录和提醒功能(如生日和纪念日)3. 找别人代付4. 推荐精选比较好的礼物5. 看一看除了身边人之外的社会上需要帮助人有什么样的心愿三. 市场分析市场分析包括:1.宏观环境分析 2.竞品分析 3.团队自身能力分析1. 市场分析分析目的:了解政策,行业的现状,环境是否能为行业发展提供有力条件,现有的增量和存量是否能提供足够的商业机会存量增量市场(以下数据来源于网络):网络购物的发展截至2015年6月,我国网络购物用户规模达到3.74亿,较2014年底增加1249万人,半年度增长率为3.5%。

在我的研发团队里,人人都是产品经理

在我的研发团队里,人人都是产品经理

在我的研发团队里,人人都是产品经理产品经理在一个产品团队中处于领导地位,但如果团队成员所有需求都要产品经理做决定,那么团队效率就会比较低。

因此团队成员如果能想产品经理所想,问产品经理所问,甚至做决定也能自己拍板,这样的团队工作效率就会比较高。

刚来Facebook那年,快年终的时候,我拿出了准备许久的下一年roadmap给大家看,我的产品设计师平日里工作出色,人很nice,但是那天一直对我的计划提一堆意见,嚷嚷着要我改roadmap。

会后,他告诉我:他升到下一级的要求就是能够像产品经理一样思考,能够证明他自己的意见,能够修改PM制定的roadmap,所以他看到了我的roadmap一直绞尽脑汁思考改进意见。

后来我发现,不仅是产品设计师,工程经理要到高级,也需要体现自己拥有产品经理一样的战略眼光,能够在产品策略中扮演一个核心角色;大家提起牛逼的数据科学家,都说他能够用数据改变产品方向;厉害的产品运营人员,也是因为能够说服产品经理改变或者改进本来roadmap而蜚声公司。

好嘛,原来你们一堆人个个都想当产品经理,那要我干什么?这些人个个想出风头,我做个决定多难啊,我估计这种工作方式效率一定很差。

而现在,已经在Facebook和微软带过6个不同的产品团队的我:真真正正相信一个好的团队需要。

如果一个工程师从来没做过产品经理做的事情,那这个工程师很可能在瞎忙活,出力没效果,而且自身的工作成就感也会低。

我工作的产品团队,负责的产品面对的用户(有年轻人、广告商、名人网红、公司用户等等)都不一样,团队成员的职能构成也不一样(比如有一个有特别多牛设计师的团队,一个有很多数据科学家的广告产品团队),但是共性就是:凡是团队成员需要产品经理做所有的决定的,团队的士气比较消极、效率低、并且执行力差。

而一个高效的产品团队,团队成员想产品经理所想,问产品经理所问,甚至做决定也能自己拍板,这样的团队工作效率高,团队成员积极性高涨,并且执行力给力。

人人都是产品经理 2.0 思维导图

人人都是产品经理 2.0 思维导图

人人都是产品经理• 00 开始:写在正文之前o0.1 为什么会有这本书▪第一,非产品岗位的同学,因为工作或者兴趣,需要了解产品的方法论▪第二,对初创公司来说,如何让非专职产品人员短时间内胜任产品工作▪第三,非互联网圈的从业者,需要更通俗的了解互联人是怎么做产品的、有哪些异同、如何选择性的借鉴他们的经验▪第四,学习资料太多,不利于圈外人找到真正适合自己的图书、网站、社群、公众号o0.2 本书的产品定位▪目标用户:-1~3岁的产品经理▪需求场景•对于“泛产品经理”,可以通过阅读此书,理解一套方法论体系•对于产品经理,这本书像一本知识图谱,可以粗读一边,后续有困惑再针对性的查阅▪产品概念•通过社群组织与用户保持沟通,加上相应的培训咨询服务、工具包,以及积累多年的社交媒体与此书构成有机整体▪竞争优势• 1.此书的底层逻辑方法论提取与作者相关的实体书籍,并非凭空搭建,这样的内容源头使得此书具备了第一无二的沉淀• 2.基于作者的个人经历,出身于阿里,不仅做过一线陈皮,也关注了很多关于“产品经理岗位”、“创新”的事情• 3.写书的过程中,通过读书会与国内产品经理圈内的作者沟通,把一些建议融入此书框架中,共同构建了更加经得起推敲的内容o0.3 本书内容与阅读方法▪把书对应章节的视觉引导图与内容互相对应,建立自己的知识地图o0.4 我与本书的局限性▪ 1.没有从无到有操盘过一款真正出色的产品▪ 2.广义的运营非读者的强项▪ 3.产品形态、公司类型太多,无法一一亲历▪ 4.创业的过程,最大的收获是体会到自己“做不了什么”•01 初始:大话产品经理o 1.1 从一个小故事谈起(通过小故事分析产品设计的流程)▪产品定位阶段▪需求采集阶段▪需求转化阶段▪产品概念验证▪新功能上线时o 1.2 产品经理的前世今生▪ 1.2.1 从人类社会出现分工说起▪ 1.2.2 岗位诞生,宝洁的故事▪ 1.2.3 从项目经理到产品经理•核心区别:一个靠想,一个靠做•项目经理是执行人,工作重点是把任务完成,并不充当任务的提出者,需要的是执行、计划和控制能力•产品经理是任务的提出者,更需要创造力•创造力、洞察力和对客户的感知力是产品经理需要掌握的核心技能▪ 1.2.4 与“传统”产品经理的区别•传统行业的产品已经相对稳定,能为公司创造更大价值的事是偏营销的。

人人都是产品经理读书心得

人人都是产品经理读书心得

人人都是产品经理读书心得(实用版4篇)篇1 目录1.产品经理的职责和重要性2.读书心得:了解产品经理的核心技能和方法3.产品经理的决策过程和市场分析4.用户体验和产品设计的重要性5.总结:成为优秀的产品经理篇1正文随着互联网技术的飞速发展,产品经理这个职位越来越受到重视。

在企业中,产品经理担任着关键的角色,他们需要负责产品的整个生命周期,从市场调研、产品设计到推广运营等环节。

因此,了解产品经理的职责和重要性,对于我们提升工作效率和职业素养具有重要意义。

最近我阅读了一本关于产品经理的书籍,书中详细介绍了产品经理的核心技能和方法。

我深刻体会到,要成为一名优秀的产品经理,需要具备以下几个方面的能力:市场分析、用户研究、产品设计、团队协作和数据分析。

在实际工作中,产品经理需要运用这些技能,不断优化产品,提升用户体验,从而实现产品的商业价值。

在产品经理的决策过程中,市场分析是一个关键环节。

产品经理需要根据市场需求、竞争态势等因素,对产品进行定位和规划。

此外,产品经理还需要关注行业动态和用户需求,以便及时调整产品策略。

在市场分析的过程中,产品经理需要具备敏锐的洞察力和数据分析能力,以便从海量信息中提炼出有价值的数据。

用户体验和产品设计在产品经理的工作中也占据着重要地位。

优秀的用户体验可以帮助产品在竞争激烈的市场中脱颖而出。

产品经理需要深入了解用户需求,站在用户的角度进行产品设计。

在设计过程中,产品经理要注重细节,确保产品的易用性和稳定性。

同时,产品经理还要具备良好的审美能力,让产品在视觉上具有吸引力。

总之,要成为一名优秀的产品经理,需要具备丰富的知识和技能,以及敏锐的市场洞察力。

通过不断地学习和实践,我们可以提升自己的能力,为公司创造更多的价值。

篇2 目录1.读书背景2.书中主要观点3.读书心得及应用4.总结篇2正文【读书背景】随着互联网的飞速发展,产品经理这个职位逐渐受到越来越多的关注。

在这个背景下,我阅读了一本名为《人人都是产品经理》的书籍,希望能够从中获取一些关于产品经理的知识和技能。

Evernote

Evernote

才可能会有更好的服务、才是对内容原创者的平等对待。

体验后写在前面的话:Evernote有国内版本“印象笔记”。

不过小编严重建议使用国际版Evernote。

因为根据群友体验的结果,国内版“印象笔记”有如下不便。

写出来供大家参考:功能遭受严重阉割;国内版和国际版账号不相通;在某些平台上闪退(ios 6.1.3),有时候登陆不了;登录就成功,注销就提示网络不通。

Evernote 的体验版本和平台iPhone 5 ios 6.1.3 Evernote 5.2.3iPhone 4S ios 6.1.3 Evernote 5.2.3iPod touch 5 ios 6.1.3 Evernote 5.2.3iPhone 4 ios 6.1.2 Evernote 5.2.3iPad 3, Evernote 5.2.3小米1s, Android 4.0.4, Evernote 5.0.2Android, Evernote 5.0.2Mac OS X 10.7.5, Evernote 5.0.7Evernote 体验场景1. 新闻大事件收集,按类收集,比如微信、淘宝、微博,门户等等;2. 个人Idea随手记,偶尔的个人想法,打开就记录下来;3. 撰写文档,然后在文档软件譬如word里排版;4. 个人常态文件保存,比如账号密码记录;5. 其他等等~Evernote不同平台的亲密接触以下是在每一个平台的一些基本体验。

(写得有点多,看官如果没耐心看完,就胖揍下图的某只小象之一,希望然后能继续看下去~)I ios 6.1.3 Evernote 5.2.3(主功能:新建文本、相机、添加附件)1.进入应用注册很方便;2.登陆出现重大bug:a.与印象笔记服务器通讯时发生错误;b.用户名,密码无效;ps:网络状况优(之前登陆时账户名输错过一次,改正后出现以上问题,大退重新进入后就好了)3.自动大退:添加附件拍照后,回到主界面出现。

解构用户场景,真正满足用户需求人人都是产品经理

解构用户场景,真正满足用户需求人人都是产品经理

解构⽤户场景,真正满⾜⽤户需求⼈⼈都是产品经理⽤户场景不是⼀成不变的,解构⽤户场景,找到其中的“特定”。

每个⼈在使⽤产品的时候都会置⾝于⼀个环境中,或者处于某种状态,可以简单理解为⽤户使⽤产品的场景。

⽐如冬天总是对我们动⼿动脚,伸不开⼿操作的场景;旅途中没有⽹络信号的场景;着急快速完成的场景某件事的状态;⼀边看电视⼀边使⽤产品的场景等;阳光很强屏幕识别度低的场景等。

这些场景有些会对⽤户造成阻断性影响,体验很不好。

好的产品设计就是要在各种场景下为⽤户提供有效的解决⽅案。

可⽤户的这些使⽤场景都跟哪些因素有关系呢?解构⽤户的使⽤场景包括如下5个核⼼要素:1. ⽤户:⽤户场景围绕⽤户才能产⽣,所以⽤户就是场景中的主⾓;2. 地点:场景必须基于空间中,在这个空间下才能发⽣⼀系列的想象;3. 时间:⽤户是有⽣活规律的,这⾥基于时间刻度来定义活动性质;4. 动机:为什么会想要做某件事,需求产⽣了;5. 服务:⽤户有了需求,产品是否能为⽤户提供解决⽅案的服务。

Who:⽤户⽤户场景中的⽤户,是场景中的主⾓,所有的下⽂都是围绕这个主⾓转圈圈。

这是⽤户场景能成⽴的先决条件,没有⽤户就不能成⽴⽤户场景的概念。

好⽐我们⼀起为为喜欢的⼈过⽣⽇,最后发现主⾓没来,所有的Surprise全部落空。

再⽐如,我们曾为⽤户打造⼀款记录其财富积累过程的产品,供其在⾥⾯炫耀,上线后发现没有⽤户使⽤。

原因很简单,就是⼈们觉得财富是个⼈的隐私,谁也不愿意展现给别⼈看,⽵篮⼦打⽔⼀场空。

所以说,有⽤户是场景建⽴的基础条件。

Where:空间⽤户场景中的组成,空间部分占⽐范围⾮常⼴泛,因为⽤户真实存在,得基于某个空间。

⽐如,我们⽤家、地铁、建筑⼯地这三个空间场景来作⽐。

其中,家⾥的⽹络肯定都⽐较好,什么产品在这样的环境下可能都⽐较好;换到地铁上,⼈挤⼈不说,可能还要腾出⼿来扶着把⼿,⽹络信号也时有时⽆,可能还⼀直接收不到信号,脑⼦⾥时刻还要关注有没有坐过站,这样的场景下⾳乐类的产品还是⼀种不错的选择;建筑⼯地最突出的是听不见声⾳,可以想象打电话、听⾳乐的体验会是什么感觉,这样的场景下很难匹配到合适的产品。

唯品会产品体验报告 – 人人都是产品经理

唯品会产品体验报告–人人都是产品经理前言在我的上篇文章里,分析的是互联网界的以慢著称的大象——豆瓣,这次的App唯品会,我认为是以速度著称的猎食者——猎豹。

猎豹虽然在食物链中不处于顶端(顶端是阿里,腾讯这样的狮子),但是凭借其风驰电掣的速度和树上进食的习惯,在竞争残酷的非洲草原上也留下浓墨重彩的一笔。

唯品会也是一样,以极快的发展速度和独特的商业模式在竞争惨烈的电商世界坐稳地盘,并持续盈利。

与豆瓣相比,唯品会作为互联网界的猎豹,其惊人的发展速度,品牌理念中的快速,库存的快速周转等等,无不体现着其追求速度的调性。

豆瓣的慢还体现在他一直不断的在探索,而唯品会却目标明确,避开对手,逼近猎物,然后动用全身能量迅速出击,扑到敌人(这个从其版本更新记录可以看出,后面会展开讲)。

从产品风格来看,豆瓣是典型的理想主义App,会大刀阔斧的推进一个项目(比如阿尔法城)然后再推到重来,而唯品会则是保守主义,每一步都是在上一步基础上的细调,改头换面几乎没有。

这两种风格我都很喜欢,我喜欢豆瓣以用户为本的理想主义和不断探索的谦逊态度,敢于推倒重来的勇气,也欣赏唯品会头脑清醒,动作迅速且优雅的跨过电商世界一个个高低不平的梅花桩。

体验环境体验产品:唯品会ipad版产品版本:5.2设备型号:ipad mini2操作系统:IOS 8.1.1体验时间:2015-06-08需求定位分析消费人群定位二三四线城市,年龄为20-40岁的中高等收入女性供应商定位二三线品牌需求分析二三四线城市有消费实力的人群因为地域原因,没有购买时尚品牌的渠道;传统大而全电商平台的商品质量问题(次品,假货);价格敏感度高的人群对于品牌质量的追求;二三线品牌因竞争激烈,库存压力大,需要快速去库存渠道。

产品定位一家专门做特卖的网站,每天100 个品牌授权特卖、确保正品、确保特价、限量抢购。

垂直型女性时尚电商。

核心竞争力:品牌价格产品特色专业买手团队和商业数据统计系统——确保挑选出符合潮流的品牌和大众审美的商品;独立的仓储物流——完成电商闭环生态,全面快速覆盖到各城市乡村,实现快速库存周转,节约物流成本;强大供应链和独家合作品牌——保证品牌多样性和和在此细分市场的垄断优势市场分析唯品会自上市以后一直保持着令业界惊叹的高增长速度,在网购交易的市场份额和移动购物交易规模市场占比中都位居天猫,京东之后,且重复购买率达到80%,粘性很高。

从想法到落地,原型演示的五个口诀

口诀三:讲多无谓,动手才真当产品的流程图制定完成后,拿起笔和纸开始绘制自己脑海中的界面。

这些绘制的界面需要契合上述的流程图,在界面中尽量突显页面局部信息、各功能等要素的分布和排版。

最重要的是,在绘制这些要素时需要把其物理尺寸大小标注出来,方便后面原型产品的控制和制作。

若需要以精准的网格尺寸手机模板,可以前往POP网 https://popapp.in/sketchpad/免费下载可供打印的手机尺寸网格图。

如果遇到特别的界面交互无法在纸上演示讲解时,可以通过用PS临摹演示用PNG并编制时间轴作出相应的动画,不过这需要花费一定的时间,投入回报比似乎失衡。

因此在这个步骤上,在保证效率的基础上可以考虑使用其他工具辅助做产品交互界面功能的效果演示临摹。

可用于辅助展示的工具推荐H5工具,可以通过一定的可视化按钮控件实现很多交互效果:页面跳转、滑动效果、元件点击旋转放大收缩、3D翻转等。

另外个人觉得H5工具的学习成本比PS等设计软件低,适用于设计基础不高的产品经理,学习到上手也是一天的事由于H5是基于云端制作,制作后可以直接分享。

一定程度上减少了其他软件的捆绑式下载、汉化破解等不必要操作,另外通过高效编辑完成的界面互动动画,可以生成二维码以及链接,方便产品经理及老板作产品原型的细节交互效果的把控。

口诀四:想法到落地,原型设计目前做产品的往往已形成一种固定的思维,做产品就必须用Axure。

没错,Axure的确是不可缺得的快速原型设计工具,把想法草稿做成逻辑关系清晰的产品原型。

但这也一定程度上埋没了很多有独特优势的原型设计软件,例如:Sketch。

Axure:梳理完成全部产品信息架构和功能。

所以Auxre之于我的重要性他不是画图软件、不是交互软件,而更多的是帮助我从无到有梳理整个产品大的脉络。

Sketch:基于线框图增强设计感,具象之前的产品;如果产品理顺了的话,设计UI在Sketch的帮助下产出简直是飞速的,这也是Sketch之于Photoshop之流在做UI设计时候的牛逼之处。

人人都是产品经理之产品与生活

上的停车站,知道该做哪一边的车,可两辆地铁也已经都开走了….将方向指示放在地铁站中间,或像大钟寺站一样上了两边台阶才能看到这个方向的行车路线,这实在让人着急。

我看到过很多次某个人哒哒哒从这边台阶上去了,看看行车路线然后哒哒哒跑到了对面。

北京这么大,地铁也较多,即使住在北京一段时间的人也不能完全掌握所有地铁不同方向的行车路线,况且流动人口还有很多,在地铁站给出不同方向的提示还是十分有必要的。

而又为什么将提示都隐藏得那么深,一定要让用户走到站台中间、上了台阶才能发现呢?放在站内入口附近,让用户没有消耗成本就能获得提示,不是更好的体验么?又或者放在安检机附近,安检的时候人们都是无所事事的,完成的同时能看到提示,是否可行呢?降低用户获取信息的成本,给用户指定明确的路径,这在产品的设计过程中也都应该注意。

另一个吐槽的点就是十号线地铁的指示灯,居然用红绿色表示是否已经过了该站。

赤裸裸的鄙视我这样的色弱啊….男性约有7%、女性约有0.5%都是色盲色弱,这种设计就等于直接说明不为你们这个群体服务啊。

在设计中颜色可以作为不同状态的标识,但不应该成为唯一的标识,一定要考虑到色盲人群。

位置、大小、形状、亮暗等都可以跟颜色共同完成标识作用。

比如红绿灯,很多红绿灯除了颜色,还可以靠上下来辨认。

在设计产品时,要考虑到各种有生理缺陷的用户,这叫什么什么设计来我给忘了,大家明白这个意思就好~ 三、无聊的银行等待前两天去中行办个卡,随随便便就排了一个半小时~这一个半小时就坐在大厅里无所事事,椅子还是没有靠背的,不舒服啊~这一个半小时里,大厅平均应该有二十多个客户吧,基本玩手机的玩手机、发呆的发呆,总之都是一副很无聊的样子。

而其实我们是来银行办业务的,这一个半小时中除了椅子,银行没有为我们提供任何有价值的东西,反而是让我们自己去找资源消磨掉这段无聊的时间。

听说招行的微创新是客户等待时大厅摆糖让客户糖吃,对于银行业来说就已经算很大的进步了,但从体验来说,这还远远不够。

【产品】《人人都是产品经理》读书笔记

第一轮,产品规划阶段。

听用户定性地说,确定产品方向,做什么?随机抽样了40个用户做访谈,据此写出需求列表。

第二轮,某个项目的早期。

听用户定量地说,确定需求优先级,先做什么?投放了20万份调查问卷,确定了需求优先级的排序。

理解用户需求和产品需求之间的关系“Y”的越上面越是解决方案,越下面越是背后的目的。

“1-用户需求”,大多表现为用户的解决方案,往往是不好的,但好的“3-产品功能”一定是从用户需求转化而来,而不是凭空想出来的。

不要误解“创造需求”,你创造的只能是满足用户需求的解决方案——产品功能,而不是用户需求。

关于KANO模型最下面一条曲线叫“基础(功能)”,没有的时候,用户对产品无法接受,有了,也不会夸奖你,用户会觉得这是理所应当的。

所以,必5. 产品市场推广6. 产品生命周期管理产品经理的核心技能1. 沟通能力2. 无授权领导能力3. 学习能力4. 商业敏感度5. 热爱产品6. 注重细节,追求完美7. 日常产品管理能力适合产品经理读的书籍概括型:《产品经理实战手册》,王欣、夏济;《产品经理的第一本书》&《产品经理的第二本书》,哥乔斯市场营销:《水平营销》,科特勒;互联网思维:《启示录:打造用户喜爱的产品》,MARTY cagan;《结网》,王坚用户研究:《一目了然:WEB软件显性设计之路》,霍克曼;《点石成金:访客至上的网页设计秘笈》,克鲁格;《胜于言传:网站内容制胜宝典》,瑞蒂希设计:《设计心理学》&《情感化设计》,D.Norman交互设计:《软件观念革命:交互设计精髓》&《交互设计之路》,库帕企业管理:《公司进化论:伟大的企业如何持续创新》,摩尔;《跨越鸿沟》,摩尔;《创新者的窘境》,克莱顿·克里斯坦森;《罗伯特议事规则》,罗伯特。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
早一步是先驱,再早一步是先烈
成功发布,之后不断升级运营维护,项目上线后也有很多事情需要做
外包,延期半年发布
一路坎坷, 你我同行
一个只有七天的项目
项目:项目的坎坷一生
项目的坎坷一生总结图
分支主题
04
团队:我的产品,我的团队
团队:我的产品,我的团队
团队图
产品团队,游走于 商业与技术之间
大产品,大设计, 大团队
笔人


演 讲



2020-09-03


记理
目录
01. 写给-1到3岁的产品经理
02. 需求:一个需求的奋斗史
03. 项目:项目的坎坷一生
04. 团队:我的产品,我的团 队
05. 战略:别让灵魂跟不上脚 步
06. 产品经理的自我修养
01
写给-1到3岁的产品经理
写给-1到3岁的产品经理
为什么 要做产 品经理
需求DNA
分支主 题
分支主 题
需求的生命周期
分支主题
需求简报
分支主题
需求:一个需求的奋斗史
一个需求的奋斗史
分支主题
03
项目:项目的坎坷一生
项目:项目的坎坷一生
从产品到项目
一切从kick off开始
山寨级项目管 理
物竞天择适者 生存
又见需求
项目的坎坷一 生总结图
项目:项目的坎坷一生
A
项目的定义
文档
PRD产品需求文档
PRD是对产品功能的进一步细化,文档主要包含整体说明、用例文 档、产品Demo等,会对产品功能做具体描述
文档
FSD功能详细说明
Functional Specifications Document比较像用例文档,经常包含在 PRD中,从这步开始会出现很多技术的内容,产品界面、业务逻辑的细节 都要确定,比如网页上的某个表格中的数字,应该左中右对齐?保留几位 小数等,有点像“概要设计”。与此同时,硬件系统的设计、数据库设计、 表结构设计等工作,也开始由架构师、系统分析师们编写了。
设计之大
任正非“先 僵化,后优 化,再固化”
《用户 体验要 素》
《设计心理 学》《情感 化设计》
团队之大
接口人
组织结构
职能型
相同职责的人划分在一个部门
矩阵型
两种的结合
项目型
各种职责的人组成一个个的项目组
心思缜密的规 划师
激情四射的设 计师
团队:我的产品,我的团队
产品团队,游走于商业与技术之间
阴险狡诈的运 营师
狭义产品团队
01
产品 经理和产品规划师
02
产品设计师
功能级的设计
03
需求分析师RA
从概念设计到信息架 构
概念设计 需求采集之后,
需求筛选之前 产出:产品概念图 信息架构
《web信息架构》
激情四射的设计师
用户研究员 交互设计师 视觉设计师 前端工程师
字不如表, 表不如图
统一语言风 格
示项目生命周期就算完成了。
从具体要 做的事情 来看
产品 有更多的探索
项目 基本是在执行预设的任务
从产出物 的角度来 看
产品 通用的
项目 个性化的定制的
产品经理vs项目经理

产品经理 靠想,做 正确的事

项目经理 靠做,把 事做正确
项目:项目的坎坷一生
一切从kick off开始
01 项目计 划
产品 B 需求
需求 C 分析
满足需 D 求的方

用户需求vs产品需求
用户需求
用户自以为的需求,经常表达为用户提供的解决方案
用户需求vs产品需求Fra bibliotek产品需求经过分析,找到的真实需求,并且表达为产品的解决方案
用户需求vs产品需求
需求分析
从用户提出的需求出发,找到用户内心真正的渴望,并转化为产品需求的过程 是一个分总分的结构
02 沟通从 头开始
03 项目管 理方法
项目计划
工作量评估 brd初评->项目经理初评->细化到个人自己评估
工作量=(最乐观+最悲观+最可能*4)/6 1人天=5~6人时 风险点
沟通从头开始
干系人权责不明确,出 工不出力 1
遗漏了利益相关方(业
务方,各bu,或者以为 只需要前端修改漏了后
备注:强势的老板会把Q也定了, R还是不足的。
备注:与老板产生分歧,只要不 违背自己的价值观,就尽心尽力
完成任务
项目案例
封闭开发
集中到会议室开发
一路坎坷,你我同 行
三边六拍
A
三边:边计划、 边行动、边修改
六拍:脑门、肩膀、 胸脯、桌子、屁股、
大腿
B
01 02 03 04 05
几个项目的成败
过不了压力测试 需求阶段叫停,转移给别的团队 市场调研阶段认为不值得做
需求的价值
分支主题
需求分析方法论
需求的成本
分支主题 工期和工作量的区别,举例,生孩子要10人月
需求:一个需求的 奋斗史
活下来的永远是少数
需求pk 少做就是多做
组织架构
以产品线组织的组织架构 由产品经理直接对手上的产品负责,
有直接对接的技术、测试资源 优点:适合创业期
以职能线组织的组织架构 所有产品一个部门,所有技术一个
目 v
西目一 s
一次 直, 做流
流 程
,程
总就
结是
敏捷方法
拥抱变化
一开始的计划中间要留有一些弹性
迭代周期内尽量不加任务
集中工作,小步快跑
团队小,迭代周期短,每日站立晨会
持续细化需求,强调测试
测试驱动项目,用于补充和细化需求,比如业务逻辑的限制条件、异 常流程等
不断发布,尽早交付
大问题分而治之
项目:项目的坎坷 一生
用户需求vs产品需求
满足需求的方式
提高现实 降低期待 转移需求
需求分析方法论
分支 A 主题
需求的 D 种类
产品需
B
求列表 需求的 E 价值
需求的 C 基本属

需求的 F 成本
需求分析方法论
产品需求列表
分支主题
需求分析方法论
需求的基本属性
分支主题
需求分析方法论
需求的种类
分支主题
需求分析方法论
样本少,以偏概全
1.愿意做访谈的用户已经与普通用户有差异了 2.区域性 策略:增量方式,先根据5个用户的访谈得出结论,再 做5个观察结论是否有变化直至趋于稳定
“沉默的大多数”容易被初始发表观点的人引导
调查问卷
作答时间不超过5分钟,开篇放无需思考的问题,中间 放关键问题,个人信息放最后
调查问卷
封闭式问题
调查问卷的常见问题和对策
样本偏差:调查到的用户与想要调 查的用户群不一致
会做问卷的人,即是一种筛选,这 种隐性筛选实际上很多
对策:将目标人群的特征定义成一 系列问题,在回收问卷后进行筛选
样本过少
样本过少时不要用百分比
避免诱导性问题
可用性测试
主流程
01
02
测试过程中让用户去 完成测试任务,观察
其中的问题
用户体验部 门
交互设计与敏 捷开发的权衡
信息的呈现 方式
文案
阴险狡诈的运营师
01 负责把产品“卖出去”,让产品从“叫好”到“叫座”,获取更多用户 做裂变,病毒营销
需求采 集人人 有责
用户访谈
开放式问题,用于 找产品方向
用户访谈的常见问题和对策
说和做不一致
1.讨好访谈者心理,说访谈者希望听到的答案 2.没想过这个问题,现场编 对策:结合“说”和“做”。比如把“你喜欢哪个颜色 的游戏机”改成“挑一个颜色的游戏机送给你”
避免诱导性问题,例如“如果有这个功能你会使用吗”
文档
UML图
流程图
时序图
用例图
泳道图
axure
文档
交互图
文档
A
业务方面由产品定 (输入字数限制等)
技术方面由技术定 (在数据库如何存
储)
B
概要设计与详细设计
需求活在项目中
需求评审 PRD评审
设计评审 测试评审 分支主题
项目:项目的坎坷一生
山寨级项目管理
01 文档管 理
02 流程管 理
03 敏捷方 法
我们到底 是不是产 品经理
一个产品 经理的-1 到3岁
02
需求:一个需求的奋斗史
需求:一个需求的奋斗史
从用户中来到 用户中去
需求采集的大 生产运动
活下来的永远 是少数
心急吃不了热 豆腐
听用户的但不 要照着做
一个需求的奋 斗史
用户访 谈
调查问 卷
可用性 测试
数据分 析
需求:一个需求的奋斗史
需求采集的大生产运动
商业团队,冲锋陷 阵
技术团队,坚强后 盾
容易被遗忘的角落
团队:我的产品,我的团队
大家好才是真的好
团队:我的产品,我的团队
大产品,大设计,大团队
01 产品之 大
02 设计之 大
03 团队之 大
时间之大:产品生命周期
五种用户
分支主题 创新者 早期追随者 早期主流用户 晚期主流用户 落伍者
需求采集卡片
需求采集方法
现场调查
和客户一起工作一段时间
AB测试
日记研究
同行对产品的分析
卡片分类
粉丝级用户自己提需求
需求:一个需求的奋斗史
相关文档
最新文档