当前位置:首页 > 开发 > 研发管理 > 正文

人人都是产品经理

发表于: 2013-06-10   作者:aoyouzi   来源:转载   浏览次数:
摘要: 产品经理是一类人,他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚,转化为一个需求,进而转化为一个任务,争取到支持,发动起一批人,将这个任务完成,并持续不断以主人翁的心态去跟踪、维护这个产物,那么,你就是产品经理。至少,你已经是自己的产品经理,这才是“人人都是产品经理”的真谛。 互联网产品设计的五个层次——战略、范围、结构、框架、表现。 好产品能改变世界”一个
产品经理是一类人,他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚,转化为一个需求,进而转化为一个任务,争取到支持,发动起一批人,将这个任务完成,并持续不断以主人翁的心态去跟踪、维护这个产物,那么,你就是产品经理。至少,你已经是自己的产品经理,这才是“人人都是产品经理”的真谛。

互联网产品设计的五个层次——战略、范围、结构、框架、表现。

好产品能改变世界”一个产品经理的信仰。

互联网和软件业的产品经理放在一起讲,这是因为两者同属IT 行业,而且现在的互联网产品越来越复杂,越来越像软件,而软件产品也越来越多地基于网页浏览器。两个分支领域日益融合,越来越趋同。

产品就是用来解决某个问题的东西。

UC设计:用例设计  PMT产品管理团队  SNS社会性网络服务。

BRD:商业需求文档  PRD:产品需求文档。

种子用户:忠诚度高的用户使用新产品。

UGC:用户产生内容:用户参与到产品设计中。

可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性。

问题,通常只能做少数几个用户的测试,看他们怎么做,属于典型的定性研究。

用户跟福特要一匹更快的马,福特却给了用户一辆。对同一个问题,这两套解决方案的区别就是,一个是用户需求,一个是产品需求。而这中间的转化过程,就是这节的主题——需求分析。

用户需求VS.产品需求:用户需求:用户自以为的需求,并且经常表达为用户的解决方案。产品需求:经过我们的分析,找到的真实需求,并且表达为产品的解决方案。

需求分析:从用户提出的需求出发,找到用户内心真正的渴望,再转化为产品需求的过程。

需求分析与常见的技术分析最大不同是思路的本质差异,技术分析是“树干——树枝——树叶”的任务分解过程,技术人员很适应并乐于用这种方式思考,可以把大问题分解成小问题,发现难点逐一攻克,需求分析是“首先:树叶——树枝——树干,其次:树干——树枝——树叶”的分析过程,所以说完整的需求分析是一个“分-总-分”的过程。

伟大的需求分析师,可以无视用户想要的东西,去探究他内心真正的渴望,再给出更好的解决方案,或者说是用户真正需要的东西,这就是本节标题的意思——我们存在的价值。

用户是为自己提出的解决方案买单,而不是我们的解决方案。

产品设计的最高境界创造需求!

先把用户需求转化为产品需求,然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。

信息架构(Information Architecture),简称IA。它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁,是信息直观表达的载体。通俗点讲,信息架构就是研究信息的表达和传递。

公司是按照产品线划分部门的,对于某个产品来说,有自己的产品设计师、
开发与测试等,下一段时间要做哪些需求,完全可以在产品经理的层面上决定。

公司组织结构调整,变成了按职能线划分团队,有了统一的产品中心,包括所有的产品经理和设计师;研发中心,包括所有的开发工程师、架构师等;质控
中心,包括所有的测试工程师……这样的话,每个产品还是由原来的产品人员做,但是开发与测试资源在一定程度上就有了流动的可能。每个产品想做的需求都很多,所以都想尽可能多地抢到开发与测试的资源,然而人力资源总是严重不足的,所以最终把资源投给哪个产品,就必须上升到几个中心的大老板层面来决定了,而大老板的决策依据就是各个产品团队制作的商业需求文档。

其实,后来我们又经历过几次反复,部门总是一会按产品线划分的团队对产品本身是有利的,产品经理权力更大,可以按照自己的想法做,资源有保证,产品规划不容易被动改变。此外,各种职能的员工之间沟通顺畅,单线领导,开发的头、测试的头等都向产品经理负责。

按职能线划分的团队对多个产品间的资源共享有利,可以让资源流向更需要的地方,保证对核心产品的投入,但是效率不高,由于产品规划的决策需要在更高层面上敲定,单个产品的发展速度会有所降低。此外,资源战争可以把“鲶鱼效应18两种组织结构,给我“一攻一守”的感觉,产品在创业期的时候,需要全速发展,必然是产品线结构,产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后,就多用职能线来更充分地利用资源,因为在成熟的产品团队中,要做的事情通常比创业”从产品内部扩大到公司层面,使产品经理和设计师们更抓狂地为产品的发展而苦苦思索,这是一件好事。

准备出发:把需求打个包。

做项目,终极目标就是:多快好省。

项目TRQ:项目时间(Time)、项目资源(Resource)、项目质量(品质Quality 和数量Quantity)。

商业需求文档,Business Requirement Document,简称BRD;MRD:Market Requirement Document,市场需求文档;PRD:Product Requirements Document,产品需求文档。

“魔方计划”:将两个老产品整合为一个新产品,有点像魔方一样,通过打散、组合,得到一个全新的结果。

设计无大小,都须用心才能做得好。

做项目和做产品是分不开的。做产品的过程,正是通过做一个有一个的项目实现的,并不是项目的简单叠加。

产品还可以做到产品线,产品族。

产品经理:靠想。产品经理是做正确的事,其所领导的产品是否符合市场的需求,是否能给公司带来利润。

关注产品生命周期,能否赚钱。最重要的是判断力和创造力。

项目经理:靠做。项目经理把事情做正确,在时间和成本、资源约束的条件下完成目标。决定怎么做、谁来做、何时做。

一个事物必然有它的两面性,如果你只看到了一面,说明你只看到了系统的一部分,这时一定要跳出去,寻找另一面,之后在努力寻找“对立”背后的统一,正如黑格尔所说的“正反合”。

做项目:多块好省——范围大 时间短 品质高 资源省。

WBS:工作分解结构  TC 测试用例 UC用例  UAT:用户接受度测试

计划+控制:项目管理  奥卡姆剃刀:如无必要 勿增实体

文档版本管理的本质:多人合作 协同办公。  PPT:骗骗他。  DCP:商业评审点——>目的:项目继续、重新定向、项目终止

LCM:生命周期管理团队   有计划 更要拥抱变化

微笑曲线(Smiling Curve)是国内重要科技业者宏基集团创办人施振荣先生,在1992年为了“再造宏基”提出了有名的“微笑曲线”(SmilingCurve)理论
,人力资源配置呈“研发和市场两边高”的“微笑曲线”。

关键绩效指标法(Key Performance Indicator,KPI),它把对绩效的评估简化为对几个关键指标的考核,将关键指标当作评估标准,把员工的绩效与关键指标作出比较地评估方法,在一定程度上可以说是目标管理法与帕累托定律的有效结合。关键指标必须符合SMART原则:具体性(Specific)、衡量性(Measurable)、可达性(Attainable)、现实性(Realistic)、时限性(Time-based)。

人人都是产品经理

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
《人人都是产品经理》读后笔记20130305 最近在看《人人都是产品经理》这本书,这本书给我的感觉就是
《人人都是“产品经理”》 苏杰 《人人都是产品经理》是一本很有意思的书:它一开始给你“产品经理
今天过节,给大家透露一下全书的内容,其实就是在说下面这幅画。 产品经理的生态系统 第 1 章说了整
今天过节,给大家透露一下全书的内容,其实就是在说下面这幅画。 产品经理的生态系统 第 1 章说了整
《人人都是产品经理》读书笔记20130320 第三章:项目的坎坷一生 项目的坎坷一生的详图,如下图所示
Shared by 菲部理佐 说的实在是太贴切了 先不说这本书怎么样,光看这书的名字就够扯的,360行是什么
【讀書筆記】人人都是产品经理 SkySeraph Mar. 9th 2014 Email:skyseraph00@163.com ABOUT    
今天分享图书是《人人都是产品经理》,这本书的作者阿里巴巴的产品经理苏杰,是目前出国出版的二本
今天过节,给大家透露一下全书的内容,其实就是在说下面这幅画 产品经理的生态系统 第1章说了整体,
《人人都是产品经理》相信想要入行做产品的同学们都有所耳闻,作者苏杰基于他在阿里巴巴中担任产品
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号