我们知道在财务系统里有三张表：「 资产负债表 」、「 利润表 」和 「 现金流量表 」。

1. 资产负债表反映公司的财务状况
2. 利润表反映经营成果
3. 现金流量表详细描述了公司的经营、投资与筹资活动所产生的现金流。

通过这样的抽象能让我们对一家公司的发展状况有一个可量化的认知。

那么，映射到产品管理的工作上，如果也用三张表来抽象的话，我个人认为是「 需求过滤表 」、「 项目排期表 」和 「 核心数据表 」。

• 「 需求过滤表 」代表着产品未来的发展方向
• 「 项目排期表 」代表着产品正在迭代的进度
• 「 核心数据报表 」代表产品在过去的表现

一、未来：需求过滤表

需求的来源有很多，如果我们不对需求进行有效过滤，一定会陷入需求爆仓的窘境。但是，我们必须保证对关键需求源的持续关注，也不能因为需求太多就不接收。

一般来说，客服、运营、核心用户群和跟踪竞品四个渠道能够比较靠谱地从内外部输出各种需求，因此我们要保证相关通道足够通畅，比如定期座谈、邮件report、调研等形式。

拿到各种需求之后，最重要的就是对需求真伪、优先级进行判断。

需求真伪听起来很诡异，用户想要一个功能还可以是伪需求？

是的，需求是否为真，最为关键是在产品树立了明确服务边界下，这个需求是否应该在我们的产品里得到满足。

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

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

这个需求属于比较典型的伪需求。

一个课程的服务边界是由我们来定义，如果让用户自定义的话：

• 对于用户学习效果无法得到有效保障，难保用户单买的那节课没有和前后节有关，导致听单节并不能取得很好的学习效果，因此这种过于灵活的购买方式反而是对用户体验的更大伤害。
• 从教育机构运营角度来看，我们是要追求有效收益的。本来可以买399一套的课程，现在让用户花39买一节，这里的营收空间整整被砍90%，对于机构运营来说是非常大的损失，自然也是不能支持的。

这就好比水果店卖草莓或者樱桃，很多店主不允许用户自己挑，因为里面有些有损伤——如果让用户自己挑，必然会折算较大利润。所以，追求企业营利的目标会让我们更加理性去看待用户需求。

老板经常举一个极端例子，你拿经济舱的价格让用户坐头等舱，用户当然爽，但那是做慈善，不是做企业。

2. 是需求还是解决方案

第二种典型案例是用户反馈希望提供XX功能，比如“希望提供一个历史课程删除功能”。当用户提到希望提供某个很具体的功能时，此时一定要高度警惕。

功能对应的是一个需求的具体解决方案，这个时候最好再和用户沟通一下，为啥你需要这个删除功能，他可能会说我的免费课程太多了，影响我第一时间找到那些更为重要的付费课程。

哈，这才是需求！

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

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

当然， 有时候需求和解决方案很显而易见。比如用户反馈“希望提供回放的倍数播放功能”，目的也很简单，就是想快一点看回放，从而节省时间——这种情况需求和解决方案的映射比较容易，但是依然要时刻保持对需求和解决方案两个概念之间差别的敏感度，不然很容易被用户带到沟里去。

然后再多说一句：有时候去比较一个需求的多种可能解决方案的核心因素还是在于成本和体验，能否以最小化成本去实现或超越行业同等对手的体验是考验一个产品经理的关键能力。

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

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

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

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

功能的覆盖面越大、使用频次越高、对用户的重要程度越大，优先级越高。一些产品相关的书还会教大家通过打分制来帮助大家去比较——我个人觉得数值化还是略有些机械，不如拉上Team Core一起去充分讨论，从不同角度去审视并达成共识。

共识比单纯的数值化打分结果更重要。但是这几个因素一定要牢记心中，在讨论时是一个很好的共识基础，避免过于离散的讨论。

需求过滤表核心字段：需求名称、需求详细描述、需求来源、需求提出时间、需求优先级、处理人、处理方案、处理进度、需求解决时间（记得在需求解决时，向需求来源及时反馈，让来源方感到被重视，未来能更加热情地合作）

二、现在：项目排期表

如果说需求过滤表是规划一个产品未来的发展方向，那么项目排期表自然是活在当下的一张表，项目排期表里一定要有的元素：项目名称、项目相关人、项目优先级、项目进度及状态、项目上线时间。

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

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

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

项目进度及状态属于过程中变更的信息，用于过程管理，项目上线时间则是结果，一方面用于后续数据分析时去初步判断某些数据变化和某些功能是否有关，另外一方面就是季度和年度review时好了解各个时间阶段的工作产出。

我理解在整个项目管理过程中，最重要的两件事就是review进度和异常情况的处理。

定期review进度能够帮助我们更好地知晓当前项目所处的进度是否正常，及时发现异常情况，尽量把问题在萌芽阶段就消灭掉。

至于异常情况的处理，这里的异常情况花样太多了：高优先级项目插入、团队成员生病了、产品经理在评审后要改需求（嘻嘻）、项目复杂度超出预期等等，各种花式问题会让项目delay。所以，这里就不提供具体每件事该如何处理了，也无法一一列举。但大致思路就是确保高优先级项目能够按时上线，中、低优先级项目可适当delay。

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

术有很多，核心还是想尽一切办法让项目如期上线。

呐，换个说法就是执行力和推动力。

最后，在项目优先级的整体把握上，要和公司战略保持一致，举个例子很多公司至今都没有走出当年PC转移动时代，因为慢半拍带来的被动。

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

三、过去：核心数据表

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

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

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

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

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

其次看数据的方式上，最重要的就是比较，只有比较才能看出变化和问题。比如我们常见的天级报表，对于核心数据的天级监控，同时拿天级数据和前日、周平均、月平均、季度平均进行对比并标出涨跌，这对于我们做到“心中有数”很重要。特别是天级报表中的异常值，涨跌超过一般幅度，比如收入一下翻倍，或者日上课人数掉了一半等等，是我们关注天级报表的重点工作。

那么，遇到这一类异常情况，我们马上要启动的工作是要“下钻”到细节上，比如日上课人数掉了一半，可以拉出两天具体课程级别的上课人数情况进行对比，看看原因是头部课程的下降，还是整体下降，或者是某个品类的课程下降，找到原因后再去和相关小伙伴去聊，判断这个下降是否在预期之内，如果不是那么接下来我们该采取什么动作去补救。

除了天级报表以外，趋势图是在一段时间内去看整体走势，比如一个月或一个季度，此时能看到一个整体的变化趋势，持平、上升还是下降。以及刚刚提到的在核心数据下的二级细化报表，比如日上课人数是核心数据，那么按照课程粒度的TOP50课程日上课人数排行榜、不同端日上课人数分布（PC网页、PC客户端、M站、APP）就能在更多细节上去支撑核心数据。

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

四、小结

综上，管好以上三张表将会极大地帮助产品经理找到产品迭代的方向和节奏。

如果在某张表上的管理老是遇到问题，那么就需要好好看看，在哪个环节还存在问题，比如需求过滤表的需求来源是否通畅、项目排期表的相关负责人是否知晓并按照这张表达成的共识推进、核心数据表的统计源是否准确无误等等。

通过这三张表的有效监控，将会让产品经理更加清晰、有效地推进产品相关的各项工作。

希望能帮到那些还不知道怎么做产品有效管理的小伙伴们。完成年前最后一更，祝大家新年快乐！

作者：刘雨（订阅号  小雨哥Rain），跟谁学产品负责人，目前主要负责跟谁学产品线的整体规划，在社交和教育领域有些研究。

本文由 @刘雨 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议