前几天看纯银说产品边界，领悟到协作产品最大的难点在于运营，而非产品功能。
这两天愁如何让用户协作起来，懊悔没早早预判到协作产品的要点。
然而，就在刚才和同事四目相对之际，脑海中突然划过节前HR发来的抱怨和期许，哈利路亚随之灵魂附体。
对协作工具有需求的用户，一定是：
- 团队100人起
- 需求的驱动者
如果一个人没有驱动需求，也不会没事找协作工具，毕竟：
- 基于国人对协作、对任务的理解，这类工具多意味着被管理
- 纯个人GTD需求的，直接找GTD工具就好，没必要用SaaS替代
因此「协作」需求本质上是「效率」+「提醒」，是个人效率工具+他人提醒工具。
需求方的驱动需求越强，越会关注影响效率的因素；但需求方的驱动需求越强，被驱动方也越感受不到「协作」的意义和乐趣——
我见到不少公司，用起协作工具来都是老板（驱动方）陶醉其中，而员工（被驱动方）不情不愿。
凑巧的是，虽然我只是一条幼年产品汪，但驱动方和被驱动方的角色我都当过，其中微妙的心态差异自然也能体会。
作为驱动方，如前所述，协作工具往往被其视为「任务清单」，毕竟除老板外，多数驱动方一定也是背指标的一方，即便任务拆解后部分归属于他人，驱动方也一定会将任务视为自己的。
这种场景下，即便所有任务都得自己check，基本也能接受，至少都在自己把控中。而企业语境下的协作，也常常可以理解为单纯的「Push」。
作为被驱动方，收到任务分配时的内心OS通常是「我知道了」。如果任务中产生需要沟通、说明的内容，被驱动方的选择往往是当面or微信QQ，因为还要打开网页打字沟通太麻烦，也无法保证对方能收到。这恐怕也是一些国内协作工具开始推沟通的原因之一吧。
总结一下：驱动方的诉求可以压缩到提醒（但必须触达），被驱动方的诉求则是让对方知道自己收到了。
这样的坏处是产品做小了，好处是不用替被驱动方背锅，路径清晰了。
也许是个方向吧。
