【必读】产品经理必须要熟练掌握的五类产品管理框架---辅助框架一：时间管理框架

产品管理并不是一种线性的工作。

一个产品经理每天的时间会被计划内的，计划外的，业务性的，事务性的各种工作所覆盖，这就要求产品经理必须有良好的时间管理能力才能处理好每天接踵而至的不同工作。

时间管理，说白了，就是如何分配时间的一种意识和手段，本质上类似于“优先级”管理技术，不同之处在于，它是以相应的维度来判断“时间”和“事情”的关系。

因此，产品经理要想做好五类产品管理框架中所涉及到的事情，那么，如果时间管理能力欠缺，一定会对核心框架中的工作产出产生不利的影响。

这就是为什么我把时间管理放在第一个辅助框架中的主要原因。

1）U/I时间管理矩阵

这是我为了减少敲字量，自己起的一个名字，其实就是很多朋友都熟悉的“紧急（不紧急）+重要（不重要）”的四象限时间管理矩阵，大家看下图：

虽然可能很多朋友都熟悉这个矩阵，但是为了凑够字数，我还是要简单一下这四个象限。

（1）紧急+重要的事情

这些事情大致包括：危机性的事情；紧急的事情；紧迫要解决的问题；受截止日时间驱使的事情；准备倒计时的事情。

比方说两周前要让你写一份商业方案，但是在交付的前一天你还没有完成，这就是一个“受截止日时间驱使的事情”，你现在必须去做，虽然压力很大，但这个工作已经变得非常紧迫，且重要性不言而喻，赶快去做吧，避免第二天被批。

（2）重要+不紧急的事情

这些事情大致包括：准备、规划的事；需要预防的事；需要澄清的事；提升能力的事；

建立关系的事；真正需要重建/平衡的事。

比方说制定产品路线图，很重要，但是因为一般会给产品经理较长的时间去完成，通常不紧急，但是问题在于如果在截止日期之前还欠缺很多，那么，这个事情就会向左移动，进入到左上象限中，成为“重要+紧急”的事情。

（3）紧急+不重要的事情

这些事情大致包括：能被中断的事；一些电话，一些邮件；一些会议；大部分所谓紧迫的事情；一些普遍性的活动。

这可能是产品经理面对最多的一种事情类型，其它业务部门认为紧急的，但是对于你来说，其实并不重要，比方说销售部门要做Q1的销售分析，对于他们来说是紧急且重要的，但是对于来说，虽然知道销售情况是重要的，但却并不紧急，因此，类似这样的会议，我的建议是如果没人拿枪逼你，能不参加就不参加，因为你还有商业方案没写完呢。

（4）不紧急+不重要的事情

这些事情大致包括：繁重但实际效果有限的工作；易于开展的活动；一些电话/电子邮件；即使不做也不会影响结果的事情；浪费时间的事情。

相对于第三种情况，这些事情往往是产品经理不太容易区分的，一般来说都是浪费时间的，比方说你向开发交付了PRD，但是还有部分开发人员三番五次的发微信，打电话，发邮件，或者当面问你，这就属于典型的“繁重但实际效果有限的工作”，让他们好好阅读PRD，而不是为了降低他们的开发风险而让你的解释性工作繁重起来。

2）4D时间管理框架

U/I时间管理矩阵，很多朋友肯定很熟悉，毕竟打有狗的那年就有了，接下来呢，我再介绍一个可能很多朋友就不知道的时间管理框架：4D时间管理框架。

这个矩阵源于哪里，咱们就不说了，不重要，主要是因为现在也没有可靠的证据证明其源于何处。

直接说4D是指什么吧。它其实是四个英文单词的首字母：

（1）Do：做；（2）Delay（Defer）：推迟（延期）；（3）Delegate：委托；（4）Delete（Drop）：删除（剔除）。

这四个D分别代表了我们在面对众多事务的时候，通过对每件事务的分析应该采取的四种操作，它是一种有助于简化我们繁忙日程的策略。

关于对这四个D的解释，大家看下图：

我还是对此一一做一介绍。

（1）Do：做

它是指“做一些只需要几分钟就能完成的任务，快速完成一系列小任务可以为完成大项目建立动力”。

这类工作是最简单的，但是它却有一个基本要求，就是：

它必须是重要的，关键的任务。

基于这类任务，你需要把这个任务分解为必须要去做的小任务，这样就可以通过在小任务上分配最多的时间来确保推动整体任务的时间是合理的，动力是不断的。

这样做的目的在于你可以在不忽视整体任务的情况下，把焦点放到每个不会带给你太大压力的小任务上，并通过完成每个小任务而增加整体任务成功的可能性。

比方说，作为产品经理，你要写一份商业方案，如果从整体上看，很多朋友就算手拿模板，可能无从下手，这个时候就可以把商业方案的内容结构好好分析一下，看看如何分解为多个小任务去完成，比方说，你为了了解当前产品的现实销售情况，肯定需要和销售团队沟通，一旦这个小任务确定，那么，别拖，拿起电话，或者发个邮件给销售部门，去获取完成这个小任务的必要数据。

也就是说，你要做的小任务之间，小任务和整体任务之间一定是相互依赖和自设时间限制的，这是非常重要的，某个小任务的拖延最终也会拖延其它所有的小任务和整体任务。

（2）Delay（Defer）：推迟（延期）

它是指“暂时暂停不需要立即处理的任务，并在你有时间的时候再安排”。

这类事情其实对产品经理是个挑战，因为我们总会担心延迟会带来某种风险。

但其实大可不必担心，有三个技巧可以参考使用：

A、在面对一个任务的时候，先去评估完成这个任务的关键因素是否具备，比方说你要召开一次产品创意评审会，需要各个部门的老大参加，但是其中开发部门的老大出差了，两天后才能回来，而他又是关键人物，这就是缺乏一个关键因素，那么，这个时候一定不要在他缺席的时候开这个会，而是延迟到他回来后再开。

我相信，如果缺席召开，等他回来后，很大程度上还会再开一次，这不就是做重复工吗。

B、如果某个任务没有明确的时间限制，比方说需要持续性做的产品探索，那么，这个时候，你最好可以把产品探索放一放，毕竟你现在可能还有更关键的任务需要去做。

C、你可以按任务时间顺序组织一份你的待办事项清单，然后按照截止日期的顺序来处理每个任务，不过你需要避免的是，当清单上的某个任务很简单或者很有趣的时候，就需要你克制你的冲动，抵制诱惑，比方说你就这几天就想往外跑，放松一下，然后就找个调查市场的由头溜出去了。

当然，对于你来说，要延迟某些任务，对自己还好说，但是对被人可能就有点挑战，因此，延迟任务的理想时间是当你处于“心流状态（老汤注：心流状态，state of flow，是指一种在进行某项活动时，个体完全沉浸其中并感到极度愉悦的心理状态。）”的时候，当你被别人打断的时候，除非是紧急情况，否则把时间往后放一放再与他们交流，这样，你就可以保持的心流状态并保持专注。

（3）Delegate：委托

它是指“把重要的任务重新分配给别人”。

试图完成所有的任务是糟糕的时间管理技能的标志。

尤其对于产品经理来说，似乎只要和产品有关的事你都得涉足，当然，作为产品经理个人肯定需要学会完成一些任务，但更重要的是，我们还得学会把一些任务委托给其他人。

原因主要有两点：

A、作为一个团队，企业必须鼓励团队合作，以及预防某个人的超负荷工作，必要的给予产品经理授权可以让每个人都有科学的投入，避免忙的忙死，闲的闲死。

B、一个好的产品经理在分配任务时一定会衡量个人的优缺点，因此，某个特定的任务一定会被赋予到在完成这个任务上非常数量的人身上。

但是，委托任务的棘手之处在于你可能会因为担心失去控制而导致焦虑。

比方说，好多互联网企业的产品经理都涉及产品原型制作，有些甚至是高保真的，我不止一次说过，产品经理完全不需要做原型，我相信，任何一家互联网企业都有UI设计师，这本就应该是他们的任务，你做，还是人家做，结果不就是出一套图吗，人家的制作技能要比你强的多，干嘛不委托给他们呢？

但是，很多产品经理总是担心他们无法充分实现的自己的想法而亲自操刀，但是这样做真的不太聪明。

这里有一个“70%”法则可以参考一下，如果你能找到一个人，他完成任务的能力至少是你的70%时，你就应该把任务交给他去做。

这个法则其实是对抗完美主义的一个简单方法，而完美主义正是阻碍合理授权的因素之一。

说白了，就是“事事亲为，事事糟糕”。

其实社会中很多这样的实例，比方说，很多企业的外包就是这个思路，开发外包，只需付正式员工70%的工资，就能干正式员工120%的活，裁员的时候还可以避嫌，这买卖多合算。

（4）Delete（Drop）：删除（剔除）

它是指“从你的日程中删除不必要的任务，继续前进”。

一个好的时间管理者必须知道什么该做，什么不该做，因为这对优化一天内的工作时间大有帮助。

比方说作为产品经理，你可以干脆的拒绝参加对推进业务或产品目标不重要的会议，也就是上图中提到的“非生产性的会议”。

这似乎是不言自明的，但现实的情况是说起来容易做起来难，毕竟，如果真有一些事情是不必要的，那它怎么会出现在你的任务中呢？

这就涉及到一个技巧，就是你需要在你任务安排中寻找那些隐藏的无效的事情，比方说，一个45分钟就可以开完的会，为什么实际上花了1个小时，多出来的时间都花到哪儿了？

还有，当你早上查看微信的时候，你是花15分钟时间把全部未读消息都看一遍，还是只看和工作有关的？

花点时间想想你的日常工作，你把时间都花在哪里了，你可能会惊讶的发现，有许多任务其实是可以缩短时间或完全取消，而对你的工作影响其实并不大。

当然，和其它所有的框架一样，每个框架都有优劣，4D框架的挑战在于你必须清楚的知道这四个D在现实中确切对应的任务是什么才能用好。

但是一说到现实，都是泪啊，老大非要让你参加一个对你意义不大的会议，还是必须，马上，立刻滚进会议室，你说我把这个任务Delete掉，讲真，你敢吗？

唯一的解决思路就是当你面对这种情况的时候，你需要和他们好好谈谈这样乱的时间管理是如何影响到你的工作效率的。

不过我相信，很多朋友同样也不敢。