为什么要开这个专题
产品经理这个角色,最近几年才开始流行起来.人人都是产品经理这个词也逐渐流行起来,产品经理这个职位也是相当的时髦.但是在大家看来,要找一个真正的产品经理太难了.
这几年听到很多的声音,都是关于程序员对产品经理的抱怨,因此程序员和产品经理的矛盾也是很多.作者在这里只能想尽绵薄之力,让看到此文的产品经理和程序员,或者老板对产品以及产品经理这个角色有正确的认知.
当然有很多产品经理的体系,这里只说作者的经验总结.作者是一个务实的人,不希望让一件事走向条条框框.
本想写得生动一点,但是作者的业务时间不多,尽可能的把自己总结的东西先记下来.
产品经理角色应该是什么样的
产品经理是将组织的需求转化成产品需求的人,也就是产品的设计者.
产品经理该如何做产品
同样的需求,不同的产品经理可能会做出不同的产品.但是不变的是,产品应该是价值导向的.
因此,产品经理首先要做的是整理需求,整理需求其实就跟整理房间一样,会让你的家更舒适.
如何整理需求
首先需要明白需求的几个维度.
- 第一个维度:战略需求
- 第二个维度:业务需求
- 第三个维度:创新性需求
这个三个维度的潜移默化地影响着最终需求,首先是战略需求,战略性决定了组织需要创造什么价值.脱离了战略的价值,是与组织目标相背离的.因此一个产品经理不知道战略的发展,是很危险的一件事.
业务需求是在战略需求基础上预想的需要建立的业务.对,业务是预想的.业务需求不一定能满足战略需求,所以在很多组织,会进行试错.但是作为产品经理,应尽可能的减少试错.正确的认识业务需求才能发挥最大的价值.
最后是创新性需求,等价于发明创造.创新性需求取决于产品经理本身的造诣,当然也可以是产品经理驱动一批又造诣的人进行创造性活动.创新往往能给企业带来巨大的价值,所以对产品经理来说,是个很大的加分项.同时创新性需求可能会影响到业务需求,改变其原有的设定.
通常我说的产品经理有没有天赋,通常是产品经理创新能力.前面两个维度,只要认识并且训练,都是可以满足的.创新能力这个很微妙.
最后,总结下就是,战略是基本,业务需求是通过战略的实现,创新性需求影响业务,使其更贴近战略.
整理需求的工具
整理需求的工具,当然首选是脑图.脑图的本质其实就是一颗树,这点非常符合战略->业务->创新的演进顺序.
但是切记,不要拿脑图做为沟通工具,效果很糟糕.
如何做产品设计
至此,你已经对所要做的事非常清晰了,这时候就需要一个更具象的东西,你需要做产品设计,这将是作为产品经理最让人兴奋的一个步骤.因为,这时候你更像一个造物主.
做产品设计,需要更多的是逻辑思维能力,和创新能力.
-
第一步,首先要做的是,构建业务场景.业务需求往往是碎片的,抽象的.构建业务场景,就像是你在脑子里构想整个业务运转的全图.当构建完全图后,开始规划业务.
-
第二步,是做业务架构,什么是业务架构,所谓的架构,其实是高层次的结构和机制.为什么要做件事,因为软件工程通常是分治的,只有做好架构,才能做好业务上的分治.做完业务架构,业务场景也被归类了.
-
第三步,是为业务场景挑选合适的解决方案.创新也许会在这发挥的更好,如果你有足够的能力创新,就尽情发挥吧.如果创新能力有限,那至少你应该挑选成熟的方案,快速先解决这个场景,以免影响另一个场景的开展时间.
-
第四步,才是做原型,很多产品经理认为这就是他们工作的全部.做原型的目的是,你的业务场景,以及解决方案不够具象,很难把你的真实想法传达.但是要注意的是,千万别用高保真原型,那只会让你的设计陷入泥潭.GUI不应该是一个产品经理的职责,除非你对GUI设计的能力也很强.其实,GUI领域要远比产品领域成熟的多,专业人士很容易就能设计出一个优秀的GUI,所谓的用户体验,只是GUI设计的一小部分.所以产品经理不要轻易去挑战这个领域.
至此,产品设计做完了.有人问,评审呢?
是否需要做评审
其实所谓的评审,就是对某一项工作的不信任.不信任的原因,在于,做这项工作的人,无法搞定这个工作的方方前面,或者他本身要做的工作就不能做好,或者需要第三方视角来发现一些风险.
在产品设计工作中,
- 如果你不了解软件开发,你就无法知道某些技术的可行性.所以你需要技术专家做技术可行性评审.
- 如果你不了解软件工程,以及不了解研发团队,你就无法了解某个解决方案的成本,成本将最终影响到战略.所以需要工程负责人做工程评审.
- 如果你不了解战略,你就需要了解战略的人来做战略评审.
- 如果你产品设计没做好,你就需要产品专家做产品设计评审.
所以,最终,还是因为你的能力的问题,需要评审.其实,这些能力产品经理都是可以掌握的.这也是为什么有人说,一个创业公司的CEO最好也是产品经理,很多事,会变得简单一点.
实际操作
最后拿一个假想的实例来说明下,应该怎么做产品.以下内容纯属构想,如有雷霆,纯属巧合.
简书是如何做产品的?
首先是战略构想:
- 简书要为业务写作者构建一个互联网写作平台
- 通过互联网写作平台,积累更多的内容沉淀
- 通过更多的内容沉淀,搞到更多的流量
- 搞到流量后,就可以做广告的定向推送,创造现金流
- 有了更多的内容沉淀后,开始做内容出版,创造现金流
- 建立作者生态圈,形成核心竞争力
- 建立读者生态圈,使之成为潜在的作者
好了,战略做完了,很完美.
下面,该预设下业务需求.
业务需求
- 有支持写作的平台
- 有用户关系体系
- 有广告管理
业务场景
- 用户,下班后,利用业余时间,打开电脑,听说写作是个好习惯,该写点什么.打开简书,开始写,写完,发布.
- 太棒了,我写的文章收到了不少的赞和感谢,还有评论,我回一个吧.
- 看样子,我需要写点更有价值的东西.
- 哇塞,我的文章被收录了.
- 哇塞,我的文章被打赏了.
- 我的人生如此完整.
- 不好,有差评,我是不是该提高下写作水平了.
- 我是不是该往首页投个稿,让我的知名度更高一点.
- 这篇文章太棒了,可惜广告太硬.如果让我写,我会写得很软.
- 这篇文章太有用了,我该关注更多的作者.我该给我的朋友分享分享.
- 太累了,暂时换换脑子,关掉简书.
业务架构
- 写作支持
- 内容发布体系
- 用户关系体系
- 广告体系
- 作者生态圈体系
- 用户生态圈体系
- 内容传播体系
解决方案
这里忽略思考过程,尽管这是耐人寻味,有趣的一部分,因为作者没有时间,暂时到这.
- 写作
- 使用web
- 使用markdown
- 所见即所得
- 发布
- 先发后审
- 机器审核加人工审核
- 广告
- 做个软文审批报价后台
- 做个用户画像系统
- 做个推荐引擎,做跳转跟踪统计
- 作者生态圈
- 申请发布到首页
- 专题收录
- 签约作者标识
原型
时间关系,先写到这
网友评论