产品经理具体是做什么的?不同的人都有不同的答案,本文主要分成三个部分,主要描述产品前期的需求分析、规划设计、文档输出这三个环节中产品经理该如何工作。 产品经理是做什么的?这个问题一千个产品经理有一千个不同的想法。 单从产品上来说,产品经理是负责管理产品生命周期的,从初期的需求挖掘分析、产品规划设计、文档撰写输出到中期的协调资源研发、验收产品质量、确保产品上线,再到后期的运营数据分析、不断迭代优化。一款产品从无到有、从有到优,产品经理的角色一直贯穿其中。 但在这些环节中产品经理该如何进行每项工作呢? 本文分三个部分,主要描述产品前期的需求分析、规划设计、文档输出这三个环节中产品经理该如何工作。 需求分析:场景化思考 每一个产品的诞生,都源于用户需求,但用户产生某个需求是因为用户在实际生活场景中遇到了某个问题。 首先我们说说什么是场景? 简单来说场景就是某个人在某个时间某个地方出于某个目的需要做某个事情。这里包含人物、时间、地点、目的、行动等元素,这些元素的组合到一起构成一个景象,这个景象就是场景。 产品经理的工作从本质上来讲就是——构建某种媒介帮助人解决遇到的问题。而场景化思考就是需要产品经理将自己代入到用户的角色中,置身于用户的场景中去思考用户的处境。并利用自身的能力去帮用户分析问题,最后构建出某种适合当前场景问题的媒介。 人是环境的产物,人不能脱离环境而独立存在,同样,需求是场景问题的衍生,在场景中分析需求才能抓到需求的本源。 拿共享单车来说:共享单车是解决用户就近出行问题的,从表面上看是用户下了地铁后到公司到家的距离走路太远、打车太近,很不方便。 但真是因为这样吗? 如果真的只是出行不便,为什么不买两辆自行车放到两个地铁口,可以很好的解决这个问题,并且也有很多用户已经这样做了。 但我们置身于这个场景中就会发现这样几个问题: 地铁口不方便停车; 自己的车容易丢; 有时不方便骑车; 摩的等工具成本太高而且不太安全。 所以用户本身是有能力解决这个出行问题的,但由于上述原因没有动力去实施解决。用户想要的是快速的、方便的、安全的到达想要到的地方,还不需要承担太大的成本。 所以,在思考用户就近出行这个需求时,表面上是解决从用户从一个地方到另一个地方的问题,但本质上是要解决用户的心理问题,让用户觉得方便,无责任。相信要是ofo的戴威,没有大学丢四辆自行车的经历,很难做出这么契合用户需求的小黄车来。 通过场景化思考可以对用户遇到的问题有更清晰的认知,只有深刻了解了用户处境,才能设计出更加契合用户需求的产品。 分析完了需求,产品经理就可以着手构建解决用户问题的媒介了。 规划设计:故事化设计 大家小时候都是或多或少都会听过睡前故事,在长大的过程中也或多或少的读过不少故事,故事对人有天然的吸引力,人在遇到故事时会不自觉地沉浸于其中。究其原因,人们普遍是以叙事性的方式进行思考,并通过故事来构建、表达想法。 换言之,故事具有两大功能: 首先,故事帮助人们感知; 其次,故事帮助人们体会、评价和处理情感。 唐纳德·诺曼在《情感化设计》中写道:"人们喜欢和人交谈,而不是机器。" 所以解决用户问题的媒介(产品)不应该是冷冰冰的机器或程序,而应该是一个有故事的‘人’,用户在使用产品时不是在和机器或程序交谈,而是在听产品述说他的故事或用户在创造、参与产品的故事。 产品故事化目前只有游戏做的比较好,人为什么喜欢玩游戏呢? 可以观察下小孩子或回想下自己小时候玩游戏的场景,在手动操作的同时,嘴里也会咿呀嘿哈的喊个不停。对小孩子来说游戏中的角色就是他们,不是游戏的角色在经历游戏中的事,而是小孩子自己在经历。 成年人同样也很喜欢玩游戏,只是没有小孩子代入感那么强烈,但同样会沉迷。 游戏好玩,表面上是玩游戏时特别爽、有各种反馈、有各种奖励。但更深层次的原因是:一个游戏就是一个完整的故事,玩一款游戏是在经历一个故事,而好的故事自然能使人沉溺。 产品故事化除了在游戏中,做的好的是智能机器人类产品,如:微软的小冰、百度的度秘、龙泉寺的贤二等,这些产品本身都有自己的故事。在和这些产品交流时,人是可以沉浸于与‘人’交流的故事场景中的。 但在其他类型的产品中目前没有看到完全故事化或高度故事化的(可能也无法完全故事化),但很多产品都在这方面做尝试。如:天猫、京东等电商平台,都在开始做产品故事化,目前更多的还停留在提示信息的故事化(情感化)的层面。 在天猫的很多提示页面都有天猫logo的各种形象,下面配有各种提示语,这时人面对的不是冷冰冰的提示语,而是会觉得是动物在和你讲话。相信天猫们的目的也是将产品故事化,你在使用产品的过程中不是单纯的在使用产品,而是在完成或参与一个故事。 产品的完全故事化目前虽说比较困难,但在设计产品时,可以带着故事化的思维去设计,将一个个功能设计成一个个故事,用户在使用功能时候,就是在完成一个个小故事。另外,故事化不单单在产品设计时可以用到,更多的可以用到向人传递产品价值上,可以通过讲述一个故事,让用户了解你的产品。 文档输出:结构化输出 首先说说什么是结构化? 人类很早以前就认识到,大脑会自动将发现的所有事物以某种逻辑模式组织起来,这种组织的过程就是结构化。所谓结构化输出:就是将零散的繁冗复杂的事件,以某种逻辑模式组织成一个整体的模型结构,并清晰的表达出来。 上文提到过故事化设计和故事化表达,首先故事本身就需要有一定的结构,一个完整的故事是由一个故事核心和一些故事情节组成。将故事结构化就是对故事核心和故事情节以某种秩序组织起来,可以是时间先后的线式结构、也可以是以描述景物场面为主的画面结构,也可以是其他的结构。 但无论哪种结构目的都是为了能够清晰的表达出自己想要表达的意思,假如一堆零散的故事情节以无序的形式表达出来,故事的的听众就会觉得茫然,并且会在各自的脑中也会对故事情节进行自行组织,最后可能的情况就是每个人组织成的故事是不一样的。 但就算将故事结构化了,以故事作为最终的产品输出物也是不够的,故事只能传递情感和感知,但对对画面感、模型化、场景感的传递上会有削弱,每个人的画面构建感是不一样的。 同样的故事,一个人听了构建出来的是这样一种画面、一种结构,另外一个人听了构建出来的是那样一种画面,一种结构。最终做出的产品在内部结构和外在表现上,可能不是自己想要的结果。 另外一点,以理科人的眼光看待这个世界,世界是结构性的,也是有逻辑性的,理科人很多时候是以结构化、模型化、逻辑化来理解世界的,而研发同学是理科人中的佼佼者。对研发同学来说,一个模型化的逻辑化的东西更容易理解,也更容易实施。 所以产品经理可以用故事去向用户表达产品,但在对研发输出时则需要将场景化的,故事性的需求转化成研发同学能够方便理解认知的模型结构。并且,研发产品本身是一项工程,而工程则是结构化的,各种信息以什么样的形式展示?各种业务模块之间有什么共性和依赖?以什么样的方式组合、用户以什么样的路径达到目的?都需要进行合理的规划和设计。 目前,在对程序员的输出上,产品经理们大多数以产品的信息结构图,业务(故事)的流程图,交互原型为输出物。关于这几种输出物就不在这里多做表述。 输出时最重要的是要保持信息的完整性,输出方式不重要,只要信息完整传递,并且信息的受众完整理解就达到了目的。而采用结构化输出,一来是结构化最能完整的传递信息,二来是结构化能够统一信息受众的画面感。 小结 产品经理是个简单的工作,也是个复杂的工作,表面上看是有序的,但实际上并没有一种统一的模式与方法,工作起来大多数是处于无序的状态,各个环节互相交叉,各种因素互相影响。而所谓的场景化、故事化、结构化只是一种思维方式和工作方式,并且某种方式也不一定真的适用于文中所述的某个环节。 产品经理工作的本质是解决问题,但最重要的能力是创造价值。只要能够解决问题,创造出价值,所谓方法、方式都只是小道。 这是去年写的一篇文章,算是对上阶段工作的一个思考,纯文字的,临时没找到合适的配图,有些无图无真相的感觉,姑且读之。本来打算写下半部分,项目推进和上线后的工作,但一直没进行总结,近期会把下半部分的思考总结一下。