一个本质，十点总结 -- 产品经理 2016 年的工作回顾

1、产品是什么

“产品是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合”；“an item that ideally satisfies a market's want or need”以上分别是产品在百度百科和维基百科的定义。

从定义看，首先产品的使用者是人或者市场，既然人或者市场需求是不断变化的，那么就注定了产品并没有固定的、最终的形态。同时，该种需求的变化是无具体规则、无明确方向的，那么对产品的设计都是对需求集合的假设。这样说好像可以给产品人员开脱责任，其实不然，所有的产品假设都需要以经验或数据为前提，以敏锐的嗅觉作为指导方向，以最小的成本验证假设，即埃里克·莱斯所说的MVP（最小化可行性产品）。不验证假设就大操大办无异于大炼钢铁，费时费力费资源。

综上，所有产品都是在验证假设，因此不会存在一个确定版本，这样说会被研发套麻袋吗？

人类演变史

2、适时清空固有经验

费孝通在《乡土中国》中说，“在变化很少的社会里，文化是稳定的，很少新的问题，生活是一套传统的办法.......愈是经过前代生活中证明有效的,也愈值得保守”。这套方法论在中国2000多年的农业文明中被不断固化，但如果遇到“三千年未有之大变局”，这套方法论会立即失效。

当信息传播的速度打破了时间、空间的限制，经验的有效期、生命周期会变的越来越短。传统的依靠时间积累经验，垄断资源的方法会变得越来越不适用。

产品设计上，固有的认知，固有的逻辑要适时清空，经验和保守看似遥不可及，其实也只有一步之遥。

一语点破历史的人--向费孝通先生致敬

3、决定不做什么比决定做什么更重要

德鲁克说“思考是一件痛苦的事，所以人们会用追逐潮流来代替它”。今年流行了区块链、AR、人工智能、供给侧、IP、新零售、小程序等新名词，再去谈O2O、P2P、大数据等概念就过时了一样。回想起来，自己也没能避免，追逐了很多热点，也和别人指点江山了一番，似乎去看看、去聊聊就跟这件事扯上什么关系。

面对新事物，出于怕被淘汰所带来的焦虑感，自身本能的会去追求确定性，体现在产品设计层面就是过渡关注、模仿竞争对手的动向，今年自己参与的购物车，搜索等功能中，或多或少都存在这方面的问题。反思起来，针对每一个需求，应该充分考虑场景所处的背景条件、边界条件以及适用条件，以此作为产品设计的基础，而不是简单忽略这个过程。

好的需求分析一定是对用户需求的精确把握，理解了用户需求才能决定什么该做，什么不该做，要做到什么程度。决定不做什么不仅减轻了研发的工作量，避免对用户的打扰，也要求自己将关注点放在用户核心需求上。

4、低耦合、高内聚

“低耦合、高内聚”原指在软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

软件系统是基于产品规划来设计的，这要求在产品规划以及设计阶段就考虑低耦合高内聚；例如电商之类复杂的系统，基础的商品信息、促销信息、仓储信息应尽可能独立设计，综合考虑；对不同业务信息进行整理、综合，舍去所有无关内容，采用模块化结构，通过冷静的构建让信息清晰易懂。

无印良品

5、增长黑客

15年，开始接触增长黑客的概念，增长黑客首先需要明确产品核心指标，然后通过病毒因子、AB测试、MVP等四两拨千斤的方式实现产品快速增长。产品的快速增长就如火箭需要达到第一宇宙速度才能摆脱地球引力一样，否则终会落地。

但增长黑客的前提是需要一个方向基本正确的产品，否则再好的增长黑客也无法拯救一款走错方向的产品。

6、关注核心数据，远离虚荣指标

初期在设计功能时，往往是完成了原型，流程图相关的工作，最后保证正常上线就行。常常忽略了埋点、数据搜集的重要性，数据分析可作为产品迭代的依据。当然，对于用户体量较大的产品，研发条件允许时，可以采用灰度发布，A/B测试等方法，在确认能带来较好的效果后再逐步全线发布。

数据分析除了需要关注所优化需求对应的数据外，还需要关注产品整体的核心指标，产品迭代需要依据核心指标，保证核心指标的增长。

7、和RD探讨User Story

年末参与了搜索相关的需求，PRD中写的“优先搜索搜索店铺名”（好吧，“优先”这个词本身定义不明确，请打脸），交付到研发人员的时候，他们不理解为什么本地搜索是优先搜索店铺名而不是商品名，反复确认了很多次，最终还是按照产品的需求把这个功能不情不愿的做上去了。

回想起来，那就是产品自身有必要和研发人员讲清User Story，相对于PRD，User Story是一个模糊的内容，其中的User用于说明需求的使用者的大致情况，例如用户是否对智能手机了解？是否熟悉操作过程？是否能明白我们的意图？消费能力怎么样？平时都在做什么？等一系列问题；Story则是说清楚用户基于哪些场景需要用到这个需求；讲清楚User Story有助于自身和RD共同面对困难，统一战线，谋划更好的解决方案；PRD写清楚了，可以防止RD人员出错；但如果缺少User Story，也就减少了RD人员提出其他解决方案的可能性。

8、怎么写PRD

年初用Axure做了一份PRD模板，在公司推广，省去了采用Word写PRD的工作，提高了RD人员的阅读率。PRD不管采用什么形式，能让RD快速理解就是好的PRD。

首先明确，PRD的使用者是研发人员，因此需要尽可能从研发人员的角度写PRD。对于涉及到前后台的需求，结合前后台对应页面，能使PRD更为直观。

PRD忌采用大段文字描述，一条一条写明场景、前置条件、输入输出、补充说明更为清晰、易读。当然，PRD是产品的基本功，花时间写一份较为详细的PRD，除了可以帮助自己理清思绪外，还能防止给研发人员挖坑。

附上用Axure做的PRD原型截图

PRD原型

9、避免马太效应

互联网产品的推荐系统、搜索系统、feed流等模块，都会涉及到信息的排序问题。微信的朋友圈目前依旧是基于timeline形式进行排序，这和微信本身基于强关系的双向社交属性有关；而微博是基于弱关系单向社交媒体，如若简单的采用timeline形式，不可避免的会出现马太效应，这也是初期的微博大V们有过大的话语权和影响力的原因（此举必然会承受有关部门的压力）；

回到电商系统，电商中首页、搜索、评价、推荐都会涉及到信息如何排序的问题。在保证准确率的前提下，如果单从销量、热度等方面考虑，会导致很明显的马太效应，影响中小商家的积极性，不利于平台型产品的长期成长。

10、信息安全

互联网产品，都会面对产品安全问题。例如验证码短信防刷，优惠券防刷，密码保护，通信加密，支付校验。很多安全问题除了需要研发人员考虑外，产品人员自身也需要实时关注，防止因为流程设计的漏洞，留下安全隐患。

好的促销手段、营销方案，除了会吸引正常用户外，也会引来众多的网络刷子，同时流量的爆发增长，也会对服务器带来压力，出现很多隐藏BUG，这个需要产品人员保持跟进，随时提供解决方案，以免造成过大的损失。

写于16年年末，希望在来年年末的时候，可以对这10点有新的认识

作者 sonaxu

关键字：产品经理, prd

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！