产品经理最关切的三张表你知道是那些吗

一、未来：需求过滤表

1. 需求是要考虑成本和代价的

举个例子，某用户反馈“希望支持视频课购买单课节，让购课变得更加灵活”，这个需求听起来有点意思，我不想买所有的，只买一节或者先试着买一节听听，好再买整个课程。

这就像在水果店里卖香蕉或橘子，许多店主不允许用户自己挑选，因为里面有一些损害--如果让用户自己挑选，肯定会带来很大的利润。因此，对企业利润目标的追求，将使我们更加理性地看待用户的需求。

老板经常举一个极端例子：

你拿经济舱的价格让用户坐头等舱，用户当然爽，但那是做慈善，不是做企业。

2. 是需求还是解决方案

所以，提供一个删除功能是一种解决办法，那是不是这是最好且唯一的呢?如果提供一个课程分类或者快速筛选是否会是一个更好的解决方案呢?

所以，在做需求真伪判断时，一定要弄清楚用户反馈的是一个需求还是一个解决方案，如果是后者需要往深再挖挖。

特别是在团队规模或者公司规模较小时，有些功能点难度很大，是否有些土办法去尽量拟合效果，这里是能看出产品经理的智慧和实操能力的。

那么当真需求进来之后，就到了需求优先级判断了，这是一个很显产品经理在该领域洞察力的活儿。

首先有个经典的公式分享给大家：

需求优先级 = 用户覆盖面 * 用户使用频次 * 对用户的重要程度

需求过滤表核心字段：需求名称、需求详细描述、需求来源、需求提出时间、需求优先级、处理人、处理方案、处理进度、需求解决时间。

* 注：记得在需求解决时，向需求来源及时反馈，让来源方感到被重视，未来能更加热情地合作。

二、现在：项目排期表

如果说需求过滤表是规划一个产品未来的发展方向，那么项目排期表自然是活在当下的一张表。

项目排期表里一定要有的元素：项目名称、项目相关人、项目优先级、项目进度及状态、项目上线时间。

其中项目名称、项目相关人、项目优先级是在项目启动前就定好的：

项目相关人一般可以把PM、FE、RD、QA、UE五个角色的具体负责人都标上，便于项目执行过程中各自担起责任并相互协作。

项目优先级是从需求优先级带过来的，一般保持一致，当然有时候会出现一些时效性较高的项目，比如年度总结、双十一活动等等，这一类有明确时间要求的项目一方面要尽早规划，另外一方面确实需要在执行过程中做更精准的安排。

至于异常情况的处理，这里的异常情况花样太多了：高优先级项目插入、团队成员生病了、产品经理在评审后要改需求(嘻嘻)、项目复杂度超出预期等等，各种花式问题会让项目delay。

所以，这里就不提供具体每件事该如何处理了，也无法一一列举。但大致思路就是确保高优先级项目能够按时上线，中、低优先级项目可适当delay。

一般delay可以买零食哄哄技术小哥哥加班，人力缺失的要及时和技术负责人协调额外人力支持，时间紧任务重还有明确上线时间的需要封闭开发+天级站立会。

因此，如果一旦确定一个明确的战略时，产品团队需要第一时间去review手上项目和战略的一致性，如果有违背需要尽快收尾甚至冻结那些和战略不一致的项目，否则慢半拍会导致后面很多拍都跟不上。

三、过去：核心数据表

数据一定是对于过去动作的一种表现，它是有一定的滞后性，因此数据是帮助我们分析过去我们的产品行为是否产生了正收益的坐标。

看数据最重要的点是看什么，听起来蛮搞笑，但事实上确定核心数据项是一个非常重要的工作，这需要我们深刻了解我们做的事情以及影响这件事情的关键性过程指标和结果指标。

对，这里提到了两种指标：一个是过程指标，一个是结果指标。

比如一家教育机构，结果指标一定是现金收入和确认收入，但过程指标就会因为机构的规模和阶段有所侧重。比如刚开始阶段一定是新生获取量，但随着服务稳定之后就会开始关注这批新生的续费以及转介绍，再往后随着自身业务的横向扩张，就会开始关注扩科和多科联报等指标。

抓结果，重过程是我们看待数据的重要态度;过程对了，自然结果就对了。

除了天级报表以外，趋势图是在一段时间内去看整体走势，比如一个月或一个季度，此时能看到一个整体的变化趋势，持平、上升还是下降。

以及刚刚提到的在核心数据下的二级细化报表，比如日上课人数是核心数据，那么按照课程粒度的TOP50课程日上课人数排行榜、不同端日上课人数分布(PC网页、PC客户端、M站、APP)就能在更多细节上去支撑核心数据。

数据分析其实就是在不断地“上抽”和“下钻”中去看宏观表现和微观细节，既有大局观，也有细节认知。

综合上述，我们可知管好以上三张表将会极大地帮助产品经理找到产品迭代的方向和节奏。如果某个表的管理总是有问题的话，我们需要好好看看哪个环节还存在问题，比如需求过滤表的需求源是否畅通，项目调度表的相关负责人是否根据本表所表达的共识知晓并推进，核心数据表的统计来源是否准确等。通过对这三个表的有效监控，产品经理将能够更清晰、更有效地促进与产品相关的工作。