【直播】PML 产品管理大讲堂第四期:《产品经理的四大关键文档串联(下)》文字稿

本文很长,共有12000多字,粗略阅读需要7分钟,详细阅读需要15分钟。


先和大家道个歉,本来这篇文章应该在上周三直播完后就发布的,但是世事难料,就在当天直播完后,我到外面抽了根烟,结果就被风拍了一下,第二天就严重感冒,嗓子都被封住了,脑袋的左半部分就像半身不遂一样又晕又涨,直到昨天才有所缓解,因此,这篇文章就耽误了一个多星期才发布,还请大家多多谅解。


在上一期直播中,我们交流了产品经理的四大文档-BC和BRD-该如何撰写,在本期直播中,我们就来交流一下MRD和PRD该如何撰写。

我们已经知道了BC是战略活动中的总成文档,BRD是规划活动中的总成文档,那么,MRD和PRD就是战术活动中的总成文档。

我们先来看一下MRD的内容结构都包括哪些,大家看PPT1:

我们先整体上看一下MRD的撰写思路是什么。

既然叫市场需求文档,其实也就说明了两个关键思路,第一个,要对市场进行说明,第二个,要对市场中现实的需求进行说明。

先来看第一点,既然我们都接受以市场为驱动的产品发展模式,并且我也很多次说过,一个市场中,无非就是存在三类角色,消费者、竞争对手和我们,而其中的竞争对手和我们已经在战略活动中通过竞争格局分析和企业自我评估完成了,因此,在MRD中,我们重点要说明的就是市场的情况,这个情况中就包括客观的市场本身和市场中存在的相关角色的信息。

好,接下来我们一一说一下MRD的各个部分该如何撰写。

为了更好的让大家理解,我在接下来的描述中就用一个我曾经做过的产品来进行说明。

我先简单说一下这个产品的情况啊,这个产品是一个视频转换的软件,也是我在《YES!产品经理》这个系列中阿泡负责的那个产品线上Iconvert这个产品的原型,接下来我就以IVC指代这个案例产品了。

之所以用这个产品作为案例,是因为当时这个产品面临着从桌面端到SAAS端的转型,尽管这个产品最终没有转型成功,可能也有些朋友认为这个案例比较老了,但是,我还是那个观点,产品经理学习案例,目的不在于案例本身,而在于案例所带来的在产品管理思想上的启发,并且,大家可能平时关注比较多的是成功的案例,而我个人呢,其实更喜欢聊失败的案例。

好,案例产品的情况介绍完了,咱们看看我当时是如何写这个产品的MRD的。

1、问题/机会

在问题/机会中,我们要说明三个方面的情况,分别是市场的、产品的和技术的。

我们都知道一个道理,就是问题和机会并存,因此,我们在撰写这个部分的时候,一定是先描述问题,然后再描述由问题引出的机会。

先来看市场的问题和机会,当时市场存在的问题以及带来的机会有哪些呢?

就是随着DV市场的快速发展,很多家庭购买了DV,但是我们都知道,要把DV中的视频导成可以供VCD、DVD播放或者网络进行传播的格式,必须要通过必要的软件进行转换才可以(简单说一下,当时的DV录制的视频格式还是以AVI格式为主),因此,从整个产业链的角度看,上游的硬件设备市场已经呈现大发展的趋势,但是配套的软件市场,尤其是国内市场,依然处于一个萌芽的状态,这从一定程度上影响了整个产业的发展。

其实这种情况我们很多朋友现在也在遇到,如果只从你所在的产业链的那个环节去看,你的产品可能很不错,但是如果整个产业链无法形成有效的闭环,那么,你的产品的发展就会受到很大的影响,比方说前些年在彩电市场热炒的3D电视,电视本身没啥问题,但是节目源的内容受限直接影响了3D电视的发展,还有现在VR/AR/XR这类虚拟现实增强技术的应用,技术成熟性是一方面,另一方面是整个市场依然处于一个小众的状态,为什么呢,因为无论从消费者认知,或是配套资源上看,都处于一种不成熟的状态。

IVC是属于典型的上游带动下游的产品,上游市场发展了,因此,中下游必然要跟着发展,因此,在MRD中,我就会这样写,大家看PPT2:

我们再来看产品的问题和机会都是什么。

其实当时并不是没有视频转换类的软件产品,而是当时该类的产品出现了两个情况,一个是商业级的,比方说电视台用的各种非线编辑类的软件,这个都是配套设备的,离家庭用户太远,一个是针对非常小众的视频爱好者的专业级的各类编辑软件,其中有个分支就是视频转换,尽管这类软件是面向个人群体的,但是有三个问题,第一个,就是以国外软件为主,第二个就是几乎都是收费软件,第三个就是太专业了,各种视频格式的参数对于普通用户来说,简直就是一道无法逾越的壁垒。

三个在国内明显的产品问题,就一定会给我们带来机会,那么,产品的问题/机会,我就会这样来写,大家看PPT3:

最后我们来看技术问题/机会。

实话实说,我对技术其实并不是太了解,当然,作为产品经理,其实也无需过于多的涉足技术,我们学习技术方面的知识,其根本目的是为了能够更好的思考如何解决用户的问题,比方说,当时我们分析过,这类产品普遍有个问题,就是转换的时间太长,当然,对于专业级用户来说,他们要的是结果的质量,时间长不怕,大不了我等几个小时,但是对于普通用户来说,如果转换一个视频花的时间过长的话,会让用户非常焦虑的,毕竟他们不是专业干这个的,因此,对于这些用户来说,转换的效率和质量就成为一个并行的技术指标,如何实现这个呢?

一方面要在转换的底层技术上不断优化程序效率,另一方面,还要压榨硬件的资源,还好的是,当时intel新推出了超线程技术,也就是HT,具体HT在技术上是怎么回事,我其实根本不懂,但是我知道通过HT技术,能够大大增强CPU的处理速度,因此,在技术上,我就建议技术的伙计们要充分考虑如何应用HT技术来增强IVC的效能。

因此,在技术问题/机会上,我会这样来写,大家看PPT4:

MRD中第一部分的内容这么写就可以了,不多我还是再强调两点,第一,一定要用列表来呈现你的观点,第二,每个列表要说明的内容要有必要的数据作为支撑,比方说,我说家用DV市场在快速发展,你就得用DV市场的发展数据作为论据。

好,我们来看第二部分。

2、市场概述

在这个部分里,我们需要说清楚四个方面的内容,分别是目标市场的特征、趋势、细分和约束条件。

当然,我这里假设大家已经完成了目标市场细分这个工作,那么,特征和具体的细分这两个内容都不难,填写进来就可以了,我重点说说我们容易忽视的两个地方,趋势和约束条件。

什么是目标市场的趋势呢?

简单一句话,就是你要描述对目标市场上有影响的发展趋势。通常包括工艺技术、经济环境、政策走向以及竞争格局。

正如我在前面提到的,影响我们产品市场表现的因素,不一定来自于我们这个环节,很多时候是超出我们范围的,在产品管理的工作中,我把这个称为是“构建产品业务流程”,那么,对于IVC这类产品来说,可能出现的影响趋势有哪些呢?

这个说起来,我就得说个失败的操作了,因为当时缺乏经验,因此视野比较狭窄,只能看到产品层面的趋势发展,而忽视了更大的经济环境的影响,比方说,当时我就认为互联网能够快速发展所依赖的固网基础建设不会那么快,而当时的互联网模式中,还是以文字和图片为主,尽管已经有人提出ASP模式,类似于现在的SAAS,但是我认为那是国外可以实现的模式,在当时的国内要实现这个,还有很长的路要走,但是谁也没想到,固网的基础建设一日千里,狠狠打了我们一个措手不及,当我们要开始转型的时候,已经有六间房、优酷、土豆这样的互联网视频服务商站在了我们的前面。

这就是目标市场的趋势,看视频,玩视频的还是那些人,也就是说,目标市场没有变,但是因为我们没有看到这种非产品层面的趋势的影响,市场就这样拱手让出了。

再来看约束条件,这又是什么意思呢?

还是简单一句话说明一下,就是你得需要说明任何约束市场解决方案推出的时间线。例如,约束条件包括:季节性产品的竞争、过时的技术和各种主要的因素。

我先不说IVC,就说一个冬天大家都需要的产品,羽绒服,这是一个典型的具有季节性特点的产品,那么,这类产品的约束条件都有那些呢?我来说一个,比方说,对于很多羽绒服厂商来说,他们是最喜欢冬天越冷越好的,如果是暖冬,销量就会受到影响,但是这玩意谁能预测的到,同时呢,羽绒服的生产又不可能实时根据气温来生产,毕竟服装业也是一个非常庞大的供应链,尤其是核心的资源,鸭绒,那是要看鸭子的心情的,是需要周期的,这就是约束条件。

那么,IVC的约束条件有哪些呢?其实和大部分的IT产品一样,很多时候会受到一些未曾遇到的技术难题的影响,比方说,如何保证在当时主流PC配置的情况下实现效率和效能的平衡,这是很需要研发的伙计们的智慧的,当然,对于我们这些产品经理来说,在这种情况下,只能做两件事,一个就是多和研发的伙计们沟通,平衡好解决方案,另一个就是祈祷他们能够顺利解决各种技术问题。

接下来的第三、第四、第五部分,我考虑需要结合来讲,两个原因,一个是客户、购买者、用户早已在我们耳朵里磨出了茧子,但是,可能对于很多朋友来说,如何有效区分这三类市场中的角色,可能还不太清楚,第二个原因是这三类角色有时候是合为一体的,有时候是独立的,比方说在2B的产品中,这三类角色往往就是独立的,关键的是,在MRD中,我们基于不同的角色要思考的内容是不一样的。

好,我们先简单介绍一下如何来有效区分这三类角色,我还是通过一个场景来说明一下啊:

有个小学三年级的孩子想买一个AI学习机器人,和自己的爸爸妈妈说了,但是爸爸妈妈说要好好考虑一下,于是孩子就又找到了自己的爷爷奶奶,爷爷奶奶就没想那么多了,于是就对自己的儿子说,你们别管了,我们来掏钱买,儿子说,不是我们不给孩子买,而是我要评估一下这个AI学习机器人是不是如宣传的那样,真能解决学习问题,而孩子的妈妈想的更多的是要是有了这个AI机器人,会不会影响到正常的学习,别把这个机器人当成了玩具,新鲜几天就扔到一边了,因此啊,我们得认真评估一下,然后再决定是否购买。

好,在这个场景中,就出现了这三类角色,简单说一下:

爷爷奶奶是客户,父母是购买者,孩子是使用者,为什么这么说呢,咱们来看看这三类角色的定义:

  • 客户:为产品担负财务职责的实体。
  • 购买者:决定获得产品(解决方案)的实体。
  • 用户:和产品发生交互的实体。

我这里用的是一个针对C端的产品,其实一般来说,C端的很多产品这三类角色是合为一体的,但是在B端中,通常是分离的,做B端产品的朋友应该深有体会。

因此,在MRD中,如果涉及到角色分离的情况,那么就需要分开来说明,但是,针对不同类型的角色,撰写的内容侧重也是不一样的。

因为IVC是一款针对C端的产品,因此,这里我就另举一些例子来进行说明。

首先我们来看,在MRD中,针对客户我们要说明哪些内容呢?

一共有四项:目标客户细分;客户购买动机;购买影响因素;客户购买目标。

第一项简单,大致思路就和我们做目标用户细分是一样的,主要是确定出细分标准,第二项,客户购买动机,也就是你得说明目标客户购买产品的原因是什么,为什么会购买你的而不是竞争对手的,这一项不是太好写,尤其是对于B端产品来说,有很多客户的动机很清晰但是似乎不太好写出来,我说一个案例,比方说国内某些地区,一些企业购买产品不是看这个产品是否真正适合自己,而是看供应商和自己的关系如何,如果从动机的角度看,那就是谁和自己的关系铁,谁就能成交,兄弟们都有利可图,何乐而不为呢,第三项,购买影响因素,我理解这个影响因素不是指影响“买”还是“不买”的因素,因为,既然做了这个产品,那说明是有市场的,而应该把说明重点放到影响购买决策周期的因素上,那么,这些影响购买决策周期的因素包括什么呢,比方说对价格敏感,可选产品多,文化,无差异,样式、趋势或者收入水平等等,就以趋势这个因素为例,我说个乘用车行业的情况,18年国内乘用车整体表现欠佳,当然,原因有很多,有的说是消费降级,有的说是限牌限号,正好我前几天和一个4S店的聊,他们的看法是不是没人买车了,而是在持币待购,为什么呢,现在很多消费者不知道是该购买燃油车还是电动车,买燃油车吧,据说国家的路线图是5年后停产停售燃油车,要是现在买了,几年后怎么办,但是买电动车吧,想想各种技术的不成熟,配套的不完善,也下不了决心,因此,与其在迷茫状态下买车,还不如稍微等等,看看趋势再说,尤其是那些准备换车的消费者,想了想,反正车现在还能开,不如再等等,然后一步到位电动车吧,第四项,客户购买目标,这个也简单,就是说明客户购买产品是为了什么。

接下来再看MRD中的目标购买者部分如何来写?

在这个部分中,我们通常把购买者分为两个部分,一个是业务决策购买者(BDM:Business Decision Maker),一个是技术决策购买者(TDM:Technical Decision Maker),关于这两个购买者,我们只需要说明他们的动机和目标就可以了。

这两个购买者通常会对最终是否购买产品做出至关重要的决策,还以那个AI学习机器人为例,爸爸就是技术决策购买者,他要评估这个产品是否真的是基于AI来帮助孩子学习的,而妈妈则是业务决策购买者,她要评估如果购买了这个产品,别出现把教具当成了玩具的情况出现,不但没有帮助学习,反而影响了学习,这些意见会和爷爷奶奶沟通,告诉他们,根据他们的评估,建议暂时不要买,因为孩子还小,这种产品会影响孩子的自制力,甚至正常的学业,作为掏钱的爷爷奶奶,肯定会把孩子的学业放到第一位的,对吧。

如果从产品管理的角度看,两类购买者主要会从哪些方面评估呢,也就是各自的目的在哪里呢?大家看PPT5:

最后来看目标用户,不过在MRD里,我们就可以称他们为用户原型或用户画像了,这个部分应该是大家都非常熟悉的了,我也写过一些文章,大家如果有时间,可以到网站上挖挖坟。

在这个部分里,主要包括原型特征、现实需要和原型联系,前两个都不难,大家也做的很多,不过我估计很多朋友不太清楚原型联系是指什么。

这个我简单解释一下啊,原型联系是指你要说清楚原型和客户以及购买者是如何形成关系的。我们说清楚这种关系,有助于我们更好的定位原型和解决方案的联系。

是不是不太好理解,我还是以那个AI学习机器人为例来说明一下,如果你是这个产品的产品经理,现在已经明确了有一种场景就是爷爷奶奶掏钱,父母提供购买决策建议,孩子最终来使用,那么,你会考虑如何打动各个角色都对你的产品有积极的评价呢?

先来看客户,也就是爷爷奶奶,尽管大部分的爷爷奶奶对自己很省,但是对儿孙却是很舍得花钱的,但是这不代表着价格就可以无限高,因此,并且不同的目标细分市场中的爷爷奶奶的收入水平是不一样的,比方说你知道了对于三线以下城市的爷爷奶奶来说,他们最多能给孩子一次性支付的价格不超过2000块钱,这个确定了,你就知道如何设计一款能够在价格上打动这些爷爷奶奶的产品出来。

假设这个产品考虑好了,那接下来就是第二关,就是爸爸妈妈,如何打消爸爸妈妈的那些顾虑呢?功能上是不是更能直观的体现出AI的应用,不要让爸爸感觉这就是一个可以联网的,换了个壳的平板,对于妈妈来说呢,是不是可以明显的体现一些自动化,或者智能化的防沉迷的功能在里面,当然,最根本的还是你得用一些形式充分表现出通过你这个产品,确实提升了孩子的学习成绩,毕竟你的产品定位是AI学习机器人,学习才是核心价值点。

至于孩子来说,就简单多了,无非就是根据男孩女孩,最少设计两个风格的外形,如果能在成本不会增加太多的情况下,再在外形上做点花出来就更好了。

说这么多,那么和原型联系有什么关系呢?其实用一张图就表现出来了,大家看PPT6:

简单来说,三句话就说明了这种关系:

1、孩子对于父母来说,父母会想,你是我的孩子,你得听我的;

2、父母对于爷爷奶奶来说,爷爷奶奶会想,你是我的孩子,你得听我的;

3、孩子对于爷爷奶奶来说,爷爷奶奶会想,你是我的小孙子,我给小孙子买个东西难道不应该,并且还是学习用的,价格我也能承受。

然后我们再思考,在这三种关系中,话语权最小的其实并不是孩子,而是父母,因此,尽管在PPT6中表现的是一种通常的关系图,但是其实我们是可以对其进行优化的,把父母这个环节的权重减小,加强爷爷奶奶这个环节的权重,其实不但这个产品是这种情况,很多的产品都是这样的关系,各位不信,可以有时间的时候在超市观察一下,如果是父母带孩子来购物,父母通常会说,只能买三样你喜欢吃的东西啊,如果是爷爷奶奶带孩子来,则通常会说,想吃啥就拿。

这就是MRD中要说明的原型联系的意思。

那么,知道了原型联系,还有什么价值吗?

至少有三个:

1、可以更好的促使我们思考业务流程如何优化和完善,我们通常习惯于在环节上进行业务流程的思考,但是我说实话,现在很多产品的业务流程环节都比较成熟了,后续需要做的其实是业务流程中不同角色权重和资源的配比,以上案例就是想希望说明一下这个问题,也希望能够给大家带来一些启发。

2、可以支持我们的营销团队更好的进行有针对性的工作,比方说,如果我们知道了,要增加这类产品的销量其中有个策略是主打爷爷奶奶,那么,推广策略就会根据你所描述的客户特征、动机和目的来进行设计,如果再结合第一点,就可以把原本配置到父母这个角色上的资源调配到爷爷奶奶这个角色上,这样可能效果会更好。

3、有助于我们更好的理解我们所面对的市场,这个就不用多介绍了,我们只需要牢记一点就成,一个市场,对于产品经理来说,不是只关注用户就可以了,在市场中有各种各样的角色和你的产品有着直接或间接的关系,而这些角色如何促进或阻碍我们产品的价值交换,这是必须要想清楚的。

大家再仔细看MRD的结构顺序,是有一定逻辑的,先说明市场的问题和机会,然后再说明我们能做哪个市场,接着再说明市场中都存在哪些角色和我们的产品有关,最后说明我们要做的产品的需求是什么,而产品需求是什么,这个,就是我们接下来要聊的PRD。

好,关于MRD就讲这么多,其实讲了不少,为什么呢,因为从现实工作的情况看,BC和BRD可能很多朋友没怎么做,而PRD呢,几乎人人都要做,而MRD呢,是处于规划活动和战术活动之间的一个文档,可以说是一个承上启下的文档,有些朋友似乎也在写,但是总是按照PRD的思路在写,因此,对于我来说,我觉得应该把这个思路和大家分享一下,MRD到底要体现哪些内容,如果能在这个方面对大家有点帮助,那这么多文字就算没白写。

好,接下来咱们就讲讲PRD,关于PRD呢,我就不打算按照通常的思路基于模板来讲了,网上一大堆PRD的模板,到底哪个好,其实谁也说不清楚,那我讲什么呢,就讲讲PRD这个文档的构建思路,我的目的是希望大家能够最终构建出适合自己的PRD出来。

我们都知道PRD是用来记录产品需求的文档,其实准确来说,PRD是用来记录产品介质层面的需求的,那么,对于一个产品介质来说,都包括哪些需求呢?

我觉得只有我们搞清楚了这个,那么,其实才能搞清楚PRD的结构如何来构建。

那么,一个产品介质的需求,都会基于哪些因素产生呢?也就是我们的需求关注原则是什么?

我先来回答一下这个问题。

其实,对于任何产品来说,无论是软件、网站,或是汽车、飞机,吃的,喝的,用的,其实都离不开三个因素的影响:

1、产品介质本身

2、产品运转的环境

3、使用产品的人

理解了这一点,我们就可以确定产品介质的需求关注原则,就是:

基于产品运转环境而出现的人和产品介质之间所形成的需求。

那么,基于这个原则,可能出现的需求都有哪些呢?

我还以IVC为例来解释一下,一个用户在使用IVC的时候会出现哪些可能的需求呢?

1)IVC是产品介质

2)用户是使用IVC的人

3)用户在使用IVC的时候是在一定的环境中的

那么,我当时是怎么考虑存在哪些需求呢?

首先,我一定会想到的是IVC这个产品介质本身的功能、性能、流程、界面这些需求,比方说,在功能上,我会考虑是否支持边转换边播放,是否可以支持续点转换等,在性能上,我会考虑多长的转换时间是用户可以接受的,如果太长,是否有一些策略能打消用户的焦虑,在流程上,我会考虑是让用户完全自选择转换的格式,还是把主流的格式转换明显的提出来,在界面上,我要考虑如何在一个界面上实现主要的操作,而不是多个界面跳来跳去。

我想,很多产品经理可能认为把这些考虑到就可以了,但是真的够吗?

别忘了,任何产品最终都是用户要去用的,那么,用户在使用产品的时候,会不会有非产品介质层面的需求存在呢?

肯定会有了,最直接的就是你必须得有一个帮助文件告诉用户如何使用IVC,这个大家应该能理解,但是,这还不够,如果用户在使用过程中出现了一些问题,那么,用户该如何和你的企业进行沟通呢?

这就需要你考虑通过什么样的形式来解决这个问题,是客服电话,还是网站论坛,或是公众号,还是小程序,还是邮件,等等,如果你是个新的产品,而现有的体系或形式并没有纳入你的新产品,那么,你是不是需要想好后告诉实现部门去做呢?

你可能会说了,这个有专门的人在做,这样是没问题的,但是,我要强调的是,如果你不把明确的非产品介质的需求告诉具体操作的人,你怎么确保对方是按照规范和标准在做呢?

我记得我最早做产品经理的时候,仅仅在做帮助文件的时候,就有一个多达50多页的帮助文件撰写规范,里面明确了印刷版和电子版(CHM)帮助文件所有的规范,已经具体到标题用什么字体,多大的字号,颜色,间距等。

我以前在写PRD的时候,一定会明确这个的,我把这些需求称之为“产品发布需求”和“产品文档说明需求“。

而这些和产品介质发布有关的介质,就构成了用户和产品介质之间的一种间接需求,但基于这些需求所形成的产出会让产品介质本身更加丰满和完善。

好,产品介质,用户可能出现的需求都有了,那接下来就是用户会在什么样的环境下使用产品,而对于某些产品来说,使用环境会影响到产品的使用效率和效果。

比方说,我就得想清楚,用户在使用IVC转换视频的时候,还会做什么,是不是把转换放到后台运行,而他还在使用办公软件,如果是这样的话,就得考虑会不会影响转换的效率,会不会出现兼容上的冲突等等。

尤其是对于我们这些软件、互联网必须依赖于某些环境的产品介质更是如此,因为它们都必须基于硬件和操作系统才可以,那么,你在考虑产品介质需求的时候,难道不需要考虑这些运转环境对你的产品介质可能产生的影响吗?

除了产品版本升级可能出现的兼容性外,还有一些硬件和第三方软件可能会对你的产品介质产生影响,这个我就不具体说了,大家应该都有一些体会的。

好,咱们先总结一下,基于产品介质、人、环境,已经产生了哪些需求呢?

1、功能需求

2、性能需求

3、外观(界面)需求

4、流程需求

5、产品文档需求

6、产品发布需求

7、兼容性需求

还有没有了呢?

当然可能有了,我的那个IVC当时还面向海外市场的,产品介质本身不会变,但是比方说在菜单上需要变成英文,那你就得准备一个”词典“来说明标准,我把它称为是”扩展需求“。

如果你做的是一个2B的产品,并且产品很复杂,需要培训客户企业的使用者,那就又涉及到了产品的使用培训,我把它称为是”支持和培训需求“。

除此之外,如果你的产品涉及到的是多个平台,那你就要对开发人员说明要基于哪些平台来做开发,在开发的时候,要优先保证哪些,我把它称为是”开发需求“。

我以前接触过的,需要产品经理来明确的产品介质的需求就是这么多,汇总一下,大家看PPT7:

当然,如果只写功能、外观和流程,可不可以?可以,不过那样形成的文档,通常就不叫PRD了,而是叫FRD(Function Requirement Document,功能需求文档),而PRD,要涉及的内容要远远多于FRD。

讲到这里,就又得涉及到一个情况了,就是我们能否用原型来替代PRD来表现产品介质上的需求呢?

答案很明显了,明显不行,因为原型只能表现出功能、流程和外观上的介质需求,其它的需求原型是无能为力的。

因此,目前来看,最合理的交付给技术实现部门的产品介质上的需求表现形式是PRD+原型,当然,这里面其实也涉及到一个平衡的关系,我们通常认为原型做的越丰富,越到位越好,但事实上并不一定如此,因为要做出高保真的原型,你必然要在这个工作上花费的时间越多,而在时间一定的情况下,你做其它工作的时间就少了。

那么,怎么办呢?

具体的我写过一篇文章,大家有时间继续去挖坟就行了啊,我个人的体会是:做原型,首先要确保快,然后才是精,必要的原型加合理的文字才是最适合实现团队阅读的,敲几个字,加一句话就可以说明的功能,何必非要花时间去做呢?

好,最后总结一下PRD和原型这个部分的主要内容:

1、产品经理一定会涉及到原型,但是,如果公司有原型师,那么,产品经理就需要明确原型的设计需求,以及做一个可供原型师参考的原型出来,如果没有,那就需要产品经理亲自去做了。

2、如果是产品经理去做,那么,不要把原型当成是万能的,对于技术实现部门来说,他们对你提供给他们的产品的阅读需求是:越容易理解越好,越容易阅读越好,越容易协作越好。

3、作为一个产品经理,必须要明白的是,即使只是在PRD中,产品要涉及的需求类型也是很多的(产品介质、人、环境),原型能表现的需求就是那么几类,而其他的需求依然需要PRD去承载。

最后一个话题,咱们讨论一下兼有C端/B端的产品该如何管理。

咱们先来看两个PPT啊:

第一张PPT是2C产品的产品管理普遍性流程,第二张PPT是2B产品的产品管理普遍性流程,这两张PPT大家了解一下就可以了啊,咱们重点说说如果你的产品是兼有2C和2B该怎么来做。

我还是不讲什么大道理,只讲我个人的经历啊,只要大家能从我个人的经历中感到有一些信息是用的就足够了啊。

我回忆了一下,在我个人的经历中,我只是在一家公司负责过有这样特征的产品,那么,我们当时是怎么做的呢?

先说说当时的背景,我们是以C端产品起家的,后来因为有点名气了,于是一些企业客户也找到我们,要做OEM。

当时我们内部也讨论过这个问题,具体怎么做,老大的原则就两个:第一,收益要尽可能高,第二,成本要尽可能低。

老大们就是这样,总想着能占尽天下便宜,但是原则既然提出来了,那咱们就得分析怎么来尽量满足老大们的胃口。

首先看收益这块,如何把收益做到最大化呢?

因为我们做的是纯软件,因此,OEM的客户主要有两类,一类是PC厂商的软件预装,一类是作为某硬件厂商的产品的软件层面的承包商,通常来说,只要量起来了,那么,收益就会增加,因此,当时我们会对OEM的厂商进行选择,比方说当时联想就是我们最大的OEM客户,联想当中90%的PC都预装我们的软件,还有当时,我就负责了一个和浪潮合作的针对农村基层党建的远程视频学习系统的软件层面的产品。

收益的砝码明确了,接下来就要考虑成本的砝码了,谁都希望收益的砝码越重越好,成本的砝码越轻越好,那么,如何来评估成本呢。

主要分了两个方向,一个是可见成本的,比方说给联想OEM,那么,UI这块肯定是要按照联想的要求来做,这个成本是必须付出的,另一个就是不可见成本,也就是管理成本,流程成本这些。

具体到产品管理这块,当时也有人提出,是不是可以再成立一个企业级产品部,老大一句话就怼回去了,这买卖又不是天天有,升级更新又没有自有的产品那么有规律,让现在的产品部一起做了不就行了。

于是,这活就扔给了我们,但是,产品部就是这几个人,在人力有限的情况下,如何最低成本的把C端和B端的产品做好,就成为当时我们首要考虑的事情。

现有的产品管理流程是针对我们自有产品的,也就是C端的,肯定有些不适合B端,因此,我们后来也搞了一个针对B端产品的流程,就是前面给大家的那两张PPT,当然,这个流程是后来我自己逐步完善起来的。

但是,如果按照两套流程去做的话,那么,流程成本太高了,因此,我们就琢磨,能不能把流程进一步优化一下。

比方说,在需求管理这个工作上,我们认为核心的原则和过程是一样的,因此,这个环节就设定为统一的,区别只是在《需求反馈单》的需求来源上,我们会说明是来源于哪里,当时我们设定为两类来源:A、消费级用户;B、组织级用户。

在A类来源上,我们会继续细分来源项,比方说A-1:直接用户;A-2:经销商;A-3:通用产品市场部;在B类来源上,我们会分为:B-1:厂商;B-2:组织级合作伙伴;B-3:政府组织。

需求的不同来源确定后,又一个涉及到不同的环节就是产品需求文档,当时我们有两个类型的产品需求文档,第一个类型就是本次直播讲到的PRD,我们当时叫产品型PRD,第二个类型我们把这个文档叫做项目型PRD,因为在当时我们的B端产品中,项目的特征要多于产品的特征,但是呢,我们也不是完全就按照项目的模式去做,两个原因,一个是当时公司所有的产出物(包括通用级的产品和定制化程度比较高的产品)都统一归到了产品部下,但是在产品部下,又不能设立项目组,因此,产品经理就要干两种类型的工作,当时只是在营销体系中分为通用产品事业部和行业产品事业部,第二个原因是尽管有通用性和定制性产品的区分,但是在一些技术实现和平台上,我们还是要尽量实现标准化的,这就有点像汽车行业的技术平台,比方说大众的MQB平台,可以生产从A级到C级的所有级别和所有类型的车型。

好,接下来,我们看一下这两个产品设计文档的区别在哪里,通用性产品的文档基本就是前面讲到,我们看看定制化文档的内容都包括什么。

咱们看这个PPT啊,大家看总体设计里的第一项,就是功能需求列表,这个就是来源于需求反馈单的不同来源类型,也就是说,我们会根据输入端的来源,然后确定后续的环节,输入端确定了,才会启动不同的产品需求文档。

具体内容我就不讲了啊,我有这个文档的模板,如果大家有兴趣,可以找我要啊。

不过我这个产品是纯软件的,没有阿兵哥的那种软件和硬件结合,不过我估计思路都是一样的。

好,产品设计文档搞完后,开发流程也基本上是一样的,在验收通过后,就又有不一样的地方了,就是我们会对负责大客户的市场人员进行培训,告诉他们如何交付产品,如何让客户快速把产品整合到客户自己的产品中,我整理了一个流程,大家参考一下。

这个流程不一定是对的,只能说适合当时我们的公司情况,也就是说,我们看起来是在独立管理B端产品,但事实上采用了我们称之为“双轨制”的流程,不过这个双轨制不是完全独立的两套流程,而是用一个灵活的产品管理流程来最大限度的适配两种不同客户类型的产品。

当然,这是和当时我公司的产品整体目标有关系的,前面说了,就是收益最大化,成本最小化,那么,在资源有限的情况下,如何实现这个目标呢,其实很简单,假设老大的收益指标是确定的,那么,只有降低成本才可以,因此,我们当时做的最多的工作就是对涉及到成本的方方面面进行了重新的评估,省不了的成本就不省,能省的就一定要省。

流程成本是当时我们能想到的,是有很大的压缩空间的。

当然,其它的地方能否还有成本压缩的空间,这个就需要遇到这些问题的朋友们实事求是的评估了,我只是提供给大家一个思路。

最后呢,我说一下我对兼有C端和B端产品的朋友来说,如何更好的管理起来。

1、一定要明确企业对C端和B端产品的整体目标和各自的目标是什么,我前面说了,对于很多老大来说,是想占尽天下便宜,占领全部市场的,但是,这可能吗,不可能,因此,有些太耗费成本,但是收益不大的市场,完全可以考虑放弃,这本来就是咱们做产品的一个基本原则,是吧。

2、在整体目标和各自的目标确定后,比方说C端产品的目标是带来稳定现金流,而B端产品的目标是占领市场,那么,你就要考虑了,在现有企业资源的情况下,如何来分配资源完成这个目标,比方说,C端可能更多的应该是分配有助于稳定个人用户和企业之间关系的资源,而B端可能更多的应该是分配有助于市场扩展的资源。

3、资源分配策略有了后,也就意味着你的投入方向有了,接下来要考虑的就是成本压缩方向了,除了合理控制显性成本外,很多时候我们不要忽视了隐形成本,我们常说,不要重复造轮子,这个不仅仅是指产品本身,比方说尽量能复用现有的平台或技术来兼顾C端和B端产品,其实也可以涉及到流程,管理上,上面那个流程,主要就是借鉴了RPM战术活动中五个阶段的思路,然后再结合需求管理体系中的一些思路搞出来的。

但是,这里就存在一个情况了,就是我们和B端产品的客户其实已经不是一种简单买卖的关系了,是属于双方资源整合后的一个整体产品,那么,如果只控制我们自己的流程成本和质量,而无法涉及合作方和我们进行交互的流程成本和质量的话,那么,就一定会出现下面的问题。

比方说C端需求和B端需求是否具有通用性,如何验证,还有就是,因为我们的产品只是作为B端客户自己产品的一个组成部分,我们并不直接面对B端客户的的终端用户,那么,我们如何能够获得这些客户的问题反馈,因为很多时候这些终端用户并不知道他们使用的是我们的产品,而B端客户提过来的需求很多时候都是基于他们的产品的,而不是我们的产品,这都该怎么办呢?

不过我也得实话实说,对于纯软件来说,可能还好,但是像阿兵哥那样软件+硬件的情况,尤其是硬件,每个车型可能都是一种规格要求,确实不太好平衡,硬件这块我经验不足,就不乱说了啊,咱们还是多探讨啊。


扫码进入直播间进行回听

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址