我们知道在财务系统里有3张表：「 资产负债表 」、「 利润表 」和 「 现金流量表 」。
- 资产负债表反应公司的财务状态
- 利润表反应经营成果
- 现金流量表详细描写了公司的经营、投资与筹资活动所产生的现金流。
通过这样的抽象能让我们对1家公司的发展状态有1个可量化的认知。
那末，映照到产品管理的工作上，如果也用3张表来抽象的话，我个人认为是「 需求过滤表 」、「 项目排期表 」和 「 核心数据表 」。
- 「 需求过滤表 」代表着产品未来的发展方向
- 「 项目排期表 」代表着产品正在迭代的进度
- 「 核心数据报表 」代表产品在过去的表现
1、未来：需求过滤表
需求的来源有很多，如果我们不对需求进行有效过滤，1定会堕入需求爆仓的窘境。但是，我们必须保证对关键需求源的延续关注，也不能由于需求太多就不接收。
1般来讲，客服、运营、核心用户群和跟踪竞品4个渠道能够比较靠谱地从内外部输出各种需求，因此我们要保证相干通道足够通畅，比如定期座谈、邮件report、调研等情势。
拿到各种需求以后，最重要的就是对需求真伪、优先级进行判断。
需求真伪听起来很诡异，用户想要1个功能还可以是伪需求？
是的，需求是不是为真，最为关键是在产品建立了明确服务边界下，这个需求是不是应当在我们的产品里得到满足。
1. 需求是要斟酌本钱和代价的
举个例子，某用户反馈“希望支持视频课购买单课节，让购课变得更加灵活”，这个需求听起来有点意思，我不想买所有的，只买1节或先试着买1节听听，好再买全部课程。
这个需求属于比较典型的伪需求。
1个课程的服务边界是由我们来定义，如果让用户自定义的话：
- 对用户学习效果没法得到有效保障，难保用户单买的那节课没有和前后节有关，致使听单节其实不能获得很好的学习效果，因此这类过于灵活的购买方式反而是对用户体验的更大伤害。
- 从教育机构运营角度来看，我们是要寻求有效收益的。本来可以买3991套的课程，现在让用户花39买1节，这里的营收空间整整被砍90%，对机构运营来讲是非常大的损失，自然也是不能支持的。
这就好比水果店卖草莓或樱桃，很多店主不允许用户自己挑，由于里面有些有损伤——如果让用户自己挑，必定会折算较大利润。所以，寻求企业营利的目标会让我们更加理性去看待用户需求。
老板常常举1个极端例子，你拿经济舱的价格让用户坐头等舱，用户固然爽，但那是做慈善，不是做企业。
2. 是需求还是解决方案
第2种典型案例是用户反馈希望提供XX功能，比如“希望提供1个历史课程删除功能”。当用户提到希望提供某个很具体的功能时，此时1定要高度警惕。
功能对应的是1个需求的具体解决方案，这个时候最好再和用户沟通1下，为啥你需要这个删除功能，他可能会说我的免费课程太多了，影响我第1时间找到那些更加重要的付费课程。
哈，这才是需求！
所以，提供1个删除功能是1种解决办法，那是否是这是最好且唯1的呢？如果提供1个课程分类或快速挑选是不是会是1个更好的解决方案呢？
所以，在做需求真伪判断时，1定要弄清楚用户反馈的是1个需求还是1个解决方案，如果是后者需要往深再挖挖。
固然， 有时候需求和解决方案很不言而喻。比如用户反馈“希望提供回放的倍数播放功能”，目的也很简单，就是想快1点看回放，从而节省时间——这类情况需求和解决方案的映照比较容易，但是仍然要时刻保持对需求和解决方案两个概念之间差别的敏感度，不然很容易被用户带到沟里去。
然后再多说1句：有时候去比较1个需求的多种可能解决方案的核心因素还是在于本钱和体验，能否以最小化本钱去实现或超出行业同等对手的体验是考验1个产品经理的关键能力。
特别是在团队范围或公司范围较小时，有些功能点难度很大，是不是有些土办法去尽可能拟合效果，这里是能看生产品经理的智慧和实操能力的。
那末认真需求进来以后，就到了需求优先级判断了，这是1个很显产品经理在该领域洞察力的活儿。
首先有个经典的公式分享给大家：
需求优先级 = 用户覆盖面 * 用户使用频次 * 对用户的重要程度
功能的覆盖面越大、使用频次越高、对用户的重要程度越大，优先级越高。1些产品相干的书还会教大家通过打分制来帮助大家去比较——我个人觉得数值化还是略有些机械，不如拉上Team Core1起去充分讨论，从不同角度去审视并达成共鸣。
共鸣比单纯的数值化打分结果更重要。但是这几个因素1定要牢记心中，在讨论时是1个很好的共鸣基础，避免过于离散的讨论。
需求过滤表核心字段：需求名称、需求详细描写、需求来源、需求提出时间、需求优先级、处理人、处理方案、处理进度、需求解决时间（记得在需求解决时，向需求来源及时反馈，让来源方感到被重视，未来能更加热忱地合作）
2、现在：项目排期表
如果说需求过滤表是计划1个产品未来的发展方向，那末项目排期表自然是活在当下的1张表，项目排期表里1定要有的元素：项目名称、项目相干人、项目优先级、项目进度及状态、项目上线时间。
其中项目名称、项目相干人、项目优先级是在项目启动前就定好的：
项目相干人1般可以把PM、FE、RD、QA、UE5个角色的具体负责人都标上，便于项目履行进程中各自担起责任并相互协作。
项目优先级是从需求优先级带过来的，1般保持1致，固然有时候会出现1些时效性较高的项目，比如年度总结、双101活动等等，这1类有明确时间要求的项目1方面要尽早计划，另外1方面确切需要在履行进程中做更精准的安排。
项目进度及状态属于进程中变更的信息，用于进程管理，项目上线时间则是结果，1方面用于后续数据分析时去初步判断某些数据变化和某些功能是不是有关，另外1方面就是季度和年度review时好了解各个时间阶段的工作产出。
我理解在全部项目管理进程中，最重要的两件事就是review进度和异常情况的处理。
定期review进度能够帮助我们更好地知晓当前项目所处的进度是不是正常，及时发现异常情况，尽可能把问题在萌芽阶段就消灭掉。
至于异常情况的处理，这里的异常情况花样太多了：高优先级项目插入、团队成员生病了、产品经理在评审后要改需求（嘻嘻）、项目复杂度超越预期等等，各种花式问题会让项目delay。所以，这里就不提供具体每件事该如何处理了，也没法逐一罗列。但大致思路就是确保高优先级项目能够按时上线，中、低优先级项目可适当delay。
1般delay可以买零食哄哄技术小哥哥加班，人力缺失的要及时和技术负责人调和额外人力支持，时间紧任务重还有明确上线时间的需要封闭开发+天级站立会。
术有很多，核心还是想尽1切办法让项目如期上线。
呐，换个说法就是履行力和推动力。
最后，在项目优先级的整体掌控上，要和公司战略保持1致，举个例子很多公司至今都没有走出当年PC转移动时期，由于慢半拍带来的被动。
因此，如果1旦肯定1个明确的战略时，产品团队需要第1时间去review手上项目和战略的1致性，如果有背背需要尽快扫尾乃至冻结那些和战略不1致的项目，否则慢半拍会致使后面很多拍都跟不上。
3、过去：核心数据表
数据1定是对过去动作的1种表现，它是有1定的滞后性，因此数据是帮助我们分析过去我们的产品行动是不是产生了正收益的坐标。
看数据最重要的点是看甚么，听起来蛮弄笑，但事实上肯定核心数据项是1个非常重要的工作，这需要我们深入了解我们做的事情和影响这件事情的关键性进程指标和结果指标。
对，这里提到了两种指标：1个是进程指标，1个是结果指标。
比如1家教育机构，结果指标1定是现金收入和确认收入，但进程指标就会由于机构的范围和阶段有所侧重，比如刚开始阶段1定是新生获得量，但随着服务稳定以后就会开始关注这批新生的续费和转介绍，再往后随着本身业务的横向扩大，就会开始关注扩科和多科联报等指标。
抓结果，重进程是我们看待数据的重要态度；进程对了，自然结果就对了。
其次看数据的方式上，最重要的就是比较，只有比较才能看出变化和问题。比如我们常见的天级报表，对核心数据的天级监控，同时拿天级数据和前日、周平均、月平均、季度平均进行对照并标出涨跌，这对我们做到“心中有数”很重要。特别是天级报表中的异常值，涨跌超过1般幅度，比如收入1下翻倍，或日上课人数掉了1半等等，是我们关注天级报表的重点工作。
那末，遇到这1类异常情况，我们马上要启动的工作是要“下钻”到细节上，比如日上课人数掉了1半，可以拉出两天具体课程级别的上课人数情况进行对照，看看缘由是头部课程的降落，还是整体降落，或是某个品类的课程降落，找到缘由后再去和相干小火伴去聊，判断这个降落是不是在预期以内，如果不是那末接下来我们该采取甚么动作去补救。
除天级报表之外，趋势图是在1段时间内去看整体走势，比如1个月或1个季度，此时能看到1个整体的变化趋势，持平、上升还是降落。和刚刚提到的在核心数据下的2级细化报表，比如日上课人数是核心数据，那末依照课程粒度的TOP50课程日上课人数排行榜、不同端日上课人数散布（PC网页、PC客户端、M站、APP）就可以在更多细节上去支持核心数据。
数据分析其实就是在不断地“上抽”和“下钻”中去看宏观表现和微观细节，既有大局观，也有细节认知。
4、小结
综上，管好以上3张表将会极大地帮助产品经理找到产品迭代的方向和节奏。
如果在某张表上的管理总是遇到问题，那末就需要好好看看，在哪一个环节还存在问题，比如需求过滤表的需求来源是不是通畅、项目排期表的相干负责人是不是知晓并依照这张表达成的共鸣推动、核心数据表的统计源是不是准确无误等等。
通过这3张表的有效监控，将会让产品经理更加清晰、有效地推动产品相干的各项工作。
希望能帮到那些还不知道怎样做产品有效管理的小火伴们。完成年前最后1更，祝大家新年快乐！
作者：刘雨
