需求性质：什么是伴生性需求

Posted 2020-09-19

作为 产品经理，我们工作的重点之一就是收集整理需求，那在这些需求中，哪些是刚需，哪些优势伴生性需求呢？本文和大家分享的就是伴生性需求相关内容， 伴生性需求在整个产品生命过程中占据极大的比重，如果说创造性需求是可以燎原的星星之火，伴生性需求便是为火焰燃烧提供的若干枯草。

 什么是伴生性需求

 在我们做产品时，存在许多没有太大价值，但又必须具备的功能，这部分需求我统一定义为“伴生性需求”，属于某些主干需求的衍生枝干。

·  当我们决定开发账号系统后，除了注册和登录是必须的功能，与之相对应的还会包含修改密码，找回密码这些非常规功能，此时，修改密码，找回密码就属于典型的伴生需求，

·  我们向用户提供了上传照片的功能，对应的就需要提供删除照片，尽管用的人非常少，使用频率也非常低。

 伴生性需求必须存在，但却不是非常的紧急 ，实际上，许多团队，往往会将伴生性需求挑选出来，必要时将这部分需求舍弃，置入下个版本的迭代计划。

正如他的定义一样， 伴生性需求必须存在，但缺少这部分需求，并不会造成多数用户的不满 ，损失非常有限。

产品经理加班的情况仅次于研发人员，实际上我们是一群和时间赛跑的人，与团队中的其他成员一样，我们也希望这个版本能够尽快的上线，投入到市场使用，然后获得非凡的成就。

而即使再多的资源，再多的人力，也没有办法同时开启所有需求，这是伴生性需求的一个特点，他总是承担着我们减负的第一个重担。

 伴生性需求的舍得特色

成熟的产品经理懂得砍需求，懂得对需求做减法，这个能力看上去很飘渺也很个性，可能大家听了许多次也只能幻想，手握数千需求，谈笑间，便砍去· 五百，对于这中间如何少的，为什么有些需求能砍，为什么有些需求不能砍，想来会非常困惑。

需求有主次，我们做产品的过程中，在每个版本里都会体现出需求的主次，需求的顺序，MVP  理念，需求优先级乃至于  kano  模型的都可以体现出这个观点。

我们会围绕核心需求投入许多资源，这些核心需求也就是我们的主要需求，同样的，我们会舍弃次要的需求，必要时，我们会舍弃一些看上去非常核心，但实际上他是仅次于主要需求的一个最大的次要需求。

现在告诉大家一个方法，能够极大的增加大家砍需求的能力。

现在我们有5 个需求，但我们的资源以及我们的时间只允许做 3 个需求，你会舍弃那些需求呢？

1.  为用户上传的照片增加贴纸功能

2.  做一个开放式的群聊，全平台用户可参与群聊进行互动

3.  开放上传原图，用户可选择上传原始尺寸的照片

4.  允许单次上传多张照片，即批量上传

5.  开发断点续传的功能，用户上传照片失败，可点击继续上传，已上传的照片不需要重新上传

这个题目其实很难回答，  也缺少正确答案，在不同的环境下，我们会有不一样的选择，需求的取舍与很多因素有关，并不是单一因素造成的，但是，将问题稍加修改以后，我想你现在会进行取舍了。

现在我们有5 个需求，但我们的资源以及我们的时间只允许做 3 个需求，你会舍弃那些需求呢？

1.  为用户上传的照片增加贴纸功能  [伴生需求

2.  做一个开放式的群聊，全平台用户可参与群聊进行互动

3.  开放上传原图，用户可选择上传原始尺寸的照片

4.  允许单次上传多张照片，即批量上传  [伴生需求

5.  开发断点续传的功能，用户上传照片失败，可点击继续上传，已上传的照片不需要重新上传

是不是很容易识别出来，基本所有的伴生需求， 在优先级里都是可以被舍弃的，但并不是完全舍弃，只是在下一个阶段或者未来的某个时机，再来做，也许到那时，该需求就已经不再是伴生性需求，而是创造性需求了 。

只要我们能识别出需求性质，是被出伴生性需求，我们就能自己尝试去砍功能。

 伴生性需求的特征

作为减负的一个绝佳选择，是伴生需求的应用特征，  而我们能够如此应用还要归功于伴生性需求本身的特色，即 伴生需求无法单独存在，对其他功能具备极强的依赖和从属性质。

修改密码的功能对于我们来讲太常见了，这个功能便是典型的伴生性需求，若我们的账号系统，仅支持第三方账号登录以及短信验证码登录时，该功能便失去了存在的价值。

离开了自定义密码这样一个字段，修改密码的功能在逻辑上就已经不成立了，换言之， 修改密码便是设置密码的伴生性需求

同样是设置密码的伴生性需求还包括了” 找回密码 “ 这个功能。

如果设置的功能都不存在，那么围绕密码展开的修改密码以及找回密码就不再具备任何意义了。

 我们所认识的伴生性需求，最典型的特征便是依附于其他功能而存在，本身是无法单独存在于产品内的。

作为一款图片社交产品，允许用户删除照片以及对照片设置隐藏加密功能，也是一组鲜明的伴生性需求。

不论是对照片做任何形式的处理，或者业务，都需要建立在照片成功上传的基础之上，围绕照片展开的一系列功能均属于从属且依赖于被上传的照片而存在。

这些功能的操作主体便是被上传的照片。

可如果这个主体不存在，这些功能还会发生  效应吗？  若用户上传照片的功能被阻塞，那么这个照片的本体就不复存在，也就无法再围绕该主体展开功能型操作了。

现在，许多产品做的很重，而且这个问题的两处重灾区一个是从0 到 1 的过程中，堆积了大量需求，1.0 版本研发了一年多的时间上线，在这些问题的背后，便是我们将若干的伴生性需求当成了真正的用户需求。

现在，你是否学会如何舍弃某些需求，以及如何辨识出伴生性需求呢？

 伴生性需求”做功能“

伴生性需求本身是作为需求存在，可在做的时候，我们却不能将他当做需求来理解，这部分需求更多的是以功能补充的形式存在，极少用户反馈里会提及到这些。

因此，这也是最适合新人入门的一个领域，借助对伴生性需求的驾驭，会帮助我积累更多的功能库，逐步的掌握功能的使用方法以及开发过程。

我们关注伴生性需求，不需要考虑他是否符合人性，是否存在需求，是否存在影响力，只需要去思考如何做会更好一点，这会逐渐的增加我对功能的驾驭能力。

许多新人会容易犯的一个错误，不太重视文案，过多的将精力花费到了功能设计以及看各种资料上， 这其实是舍本逐末的做法。

《精益至上》  这本书里提到了这样一个案例：

某电商网站的用户新增很难提升，在一次优化尝试下，数据呈现了客观的增长，这个小小的优化，只是将注册按钮的位置做了一些调整，可以说没有进行任何功能的新增，只是调整了局部的布局。

与之同样的，我们也能从文案中看到差异，我们以一句简单的注释来举例：

1.  参与活动，有机会赢苹果 7

2.  赢苹果 7 ，参与活动，你也可以

两句文案很难说谁好谁坏，但我们能清晰的从这两句话感受到不同的信息，第一句，我们认为参与活动是主体，赢得东西是辅助的，第二句，则变成了赢苹果7 是主要的，而活动只是辅助的信息。

在做伴生性需求时，当尽善尽美，此时我不需要为整个产品的商业价值负责，不需要为用户需求负责，但我们需要对功能负责，让功能更容易被大家接受，不显得粗糙，难用。

 仅仅是将伴生性需求做出来，是无意义的，而且会极大的损害自己的成长，这个阶段的我们更多的与功能贴近，尝试更好的去表达功能，而布局和文案的使用反而是这个阶段对我们的两大挑战。

来源：人人都是产品经理