时间不够？分清主次，瞄准核心需求是关键

枯叶 2023-07-25 10:29:10

在产品经理的工作当中，存在一个极大的矛盾：时间。

挖掘高价值的双向需求，需要花费很多的时间，对这些需求进行验证也需要花费很多时间，往往一个好的需求，得投入2个月以上的时间进行探索和持续思考，但，在工作当中，时间永远是奢侈品，我们没有时间。

产品经理处于研发生产线的最上游，所有的设计人员，研发人员，测试人员等研发相关人员都是根据上游的输出而开展工作，我们确定了需求，并设计出产品方案，是这些产品方案激活了整条生产线，如果上游的输出停止了，没有产品方案交付给研发团队，整个研发生产线就会处于瘫痪状态。

所以，环境要求我们尽快的输出需求，不论是研发生产线，还是背后实际支付成本的老板，都在迫使我们尽快输出需求，尽快提供产品设计方案，只有持续的需求，连续的产品设计方案，才能让研发生产线能够运转起来，避免瘫痪。

因为这种特殊性质，产品经理的时间，与生产线的有效生产时间密切关联，不要说2个月的沉浸式思考，即便是一周的，完全用于思考的时间，也是欠缺的。

一方面，好需求需要时间挖掘和思考，另一方面，工作的特殊性质，不允许我们有太多的思考时间。

时间，成了产品经理极大的矛盾。

并且，随着岗位的晋升，公司对产品经理的期望越来越高，产品经理所带领的团队规模越来越大，对需求数量和速度的要求也会越来越高，时间的矛盾也会越来越严重。

甚至，会让产品经理形成一种极为矛盾的感知：做了是错，不做也是错。

解决矛盾的办法，在于我们对产品工作更深一层的理解。

01 释放时间

工作中，产品经理的时间主要分配在需求挖掘，产品设计，团队沟通三件事情当中，理论上，三者的时间分配比例应该是7:2:1。需求挖掘占比时间最大，沟通占比时间最小。

但，实际上，很多产品经理的时间分配是3:3:4 或者3:4:3，甚至还有2:4:4的分配，给到需求挖掘的时间，完全不够。

所以，时间矛盾的本质，是时间分配出现了问题，如果能有一些方法，能够调整时间分配的比例，我们就能够有更多的时间对需求进行辨识和挖掘。

比如，团队沟通的时间占比是可以压缩至“1”，甚至无限接近“0”。

团队沟通的主要目的在于帮助团队正确的理解产品设计，确保最终实现的功能效果，与产品设计相符合，这个目的是可以借助完整的需求文档及相关交付文档实现的。

或者说，交付文档原本就是作为沟通的替代方案而被设计出来的，好的交付文档，应该追求开发过程中“0”提问，意味着，开发团队借助文档的阅读，对产品设计没有任何疑问，文档能清晰，完整，准确的表达出产品设计的理念以及具体的做法。

现在，甲乙两人设计了两个相同的“刷新”功能，用户可以通过该功能，获取最新的信息，两者的差异仅体现在文档当中。

甲的文档：

用户可以在页面顶部向下滑动触发刷新功能，每次刷新获取最新内容，刷新失败时，用toast提示用户：网络信号差，请检查网络。

乙的文档-刷新功能：

触发方式：内容列表顶部，通过手势触发，具体手势为从上至下滑动。
获取内容数量：每次刷新，均可获取10条内容。
获取内容规则：按照内容的创建时间排序，获取最新发布的内容。
网络异常处理：网络异常状况，执行刷新功能后跳转至网络异常的页面，提醒用户检查网络状态。
网络异常：无网络，弱网络，均视为网络异常。
请求超时：若服务器5秒内未返回数据，提示用户“服务器忙，请稍后再试。”
内容数量不足：刷新时，若最新内容超过0条，但小于10条，则返回所有最新的内容。
没有更新：刷新时，若最新内容数量为0，则提示用户“暂时没有新内容，请稍后再试。”
防刷：若是非正常刷新，则该次刷新操作无效，并提示用户“刷新的太快了。”
非正常刷新定义：监控用户刷新频率，两次刷新的间隔时间低于1秒，即视为非正常刷新。

乙的文档里的每一个需求点，对于甲而言，都是需要通过多次沟通解决的问题。但是，对于乙而言，这些需求点都记录到了文档当中，也就不会产生沟通的负担。

仅仅是完善的需求文档，就可以让乙拥有更多的可支配时间，可用于需求的辨识和挖掘。

产品经理需要具备优秀的沟通能力，我们要重视团队沟通，但，并不是所有的沟通都值得提倡，尤其是需求遗漏，产品设计缺陷等交付形式的问题，是因为产品设计时考虑欠缺，导致的交付错误，沟通是对这种错误的处理方式，但不能视为正常现象，不能视为理所应当的，用沟通替代交付文档，这样的时间耗损是极低效的，并且，也是不值得提倡的。

所以，尽量完善交付使用的需求文档，减少沟通所使用的时间，这样可以释放一部分时间，让我们能够自由支配。

02 小需求策略

借助交付文档可以释放出一部分的沟通时间，只是，这些时间对于需求的持续挖掘而言，远远不够，产品经验越丰富，对产品经理的要求越高，相应的，产品经理对需求的商业价值要求也越来越高，需要花费的时间也越来越长。

如果成功，这个需求将会为产品带来非常高的商业价值，日活用户翻倍，新增速度翻倍，各项数据均会以指数级的速度增长。这是每一位产品负责人都希望做的事情，是真正能够让产品成功的需求，但是，很多时候，即使是0沟通，留给我们的思考时间间也远远不够。

这需要使用另一个能够争取到更多时间的技巧：小需求策略。

需求的数量非常多，有我们非常渴望的高价值双向性需求，也有让我们避之不及的单向需求，但最多的，仍然是小需求，他们既不会给产品带来十分杰出的价值，也不会为用户带来十分大的价值，当然，成本也是极低，不会给团队带来多少负担。

如同在头像功能的基础上，增加查看大图，或者下载保存图片，或者，在昵称的基础上，增加昵称的字段长度，又或者是在上传图片的基础之上，支持上传原图，均属于小需求范围。

这些小需求可以一点一点的完善产品的能力，尽管每一个小需求产生的价值有限，但累积起来却可以改善用户的使用体验，让用户更好的使用产品所提供的服务。

另一方面，小需求在需求挖掘阶段花费的时间极少，可以快速推动至研发团队，带动研发生产线的运作，能够为产品经理制造一个较大的时间差。

在产品的版本迭代过程中，存在很多以完善体验为主要目的的版本，这些版本里，产品经理花的时间较少，研发花的时间较多，通常情况，产品经理一周的输出时间，可以带动三周的研发生产时间。

多出来的两周时间，就属于产品经理的连续思考时间，对于一些重要的需求，我们甚至可以连续推出2个，3个用小需求构成的以完善，优化为目的的版本，从而获得更长的连续思考时间，用于需求挖掘。

一个由小需求构成的完善性版本，就可以争取到两周的连续思考时间，连续两次完善性版本，就可以争取到四周的连续思考时间。

100个平庸的需求，也比不上1个高价值的需求，而我们产品从业者，想要找寻的，就是那1个，能够为产品和用户带来高价值的需求。

但，想要获得高价值的需求，就必须先具备较多的时间筹码，需求价值越高，花费时间越长。

所以，现阶段而言，小需求策略是时间矛盾的主要解决办法。

同时，也是产品负责人必须掌握的一种时间技巧。