01
产品经理和研发之间，有两种关系：一种是“战友”，一种是“敌人”。
这是可以选择的，而且选择权在产品经理手中。
也就是说，我们可以选择与开发成为“敌人”，或者，选择与研发成为“战友”。
这取决于我们对一些特殊事件的看法。
比如，“这个功能实现不了”。
当研发告诉你，某个需求无法实现时，你会怎么看？
02
我的一位读者朋友曾经和我讨论过一个事件：

他们是做内容社区的，在内容上的运营非常出色，用户活跃度很高。
产品上线收费功能以后，为了增加用户的付费率，产品总监准备向某些潜在付费用户定向推送一些活动通知。
其中一类潜在用户，是“连续使用7天”的用户。
当他们第8天登录产品时，会自动触发活动弹窗，引导他们参与到付费业务当中。
我的朋友，是这项需求的执行人，落地执行时遇到了一些困难。
研发团队一致认为“这项需求无法实现”，并且，研发主管也有相同的看法。
如果是你，你会怎么办？
我的朋友将研发的判断告诉了产品总监，站在他的立场来看：
既然研发主管都说实现不了，那么这个需求就是无法实现的需求了。
而对于无法实现的需求，完成不了，也是没办法的事。
然而，这项需求，最后却实现了。
产品总监先是组织了开发团队进行需求评审，通过询问的方式，详细了解大家认为无法实现的原因。
最后，针对这些原因给出了一套解决方案。
这套解决方案的核心，就是对“连续使用7天的用户”进行“标记”。
系统会在每天凌晨01:00，进行离线计算。
以昨日有登录行为的用户为对象，统计他们的用户ID，在上一日是否有登录行为。
如果有，就继续向再上一日进行统计，如果没有，就停止统计。
循环7次，就能判断出一位用户在最近的7天里，是否连续使用了产品。
对这些连续使用7天的用户，赋予一个有效期为24小时的状态标记。
系统就有了一个简单的“是和否”的判断条件。
这样，就能够做到针对“连续使用了7天的用户”进行定向活动弹窗的需求。
开发团队认为该需求无法实现的原因，是因为系统本身并不知道用户的连续使用天数。
尽管我们可以在用户登录时，查询该用户过去7天的使用行为。
但这样会导致登录行为本身变得迟钝，也会产生服务器算能的浪费。
而产品总监所提出的解决方案：一方面赋予了用户临时标签，使得系统可以判断用户是否符合弹窗的条件；
另一方面，也通过离线计算的方式，将算能的使用至于凌晨1点。
此时，服务器大量的算能都处于空闲状态。
至此，一个原本“无法实现”的需求，最后，还是成功实现了。
这段经历，让我的朋友沉默了很久。
同样的需求，不同的态度，最后成就了两种不同的结果。
根本原因，还是我们的态度。
当开发团队告诉我们“需求无法实现”时，我们应该如何对待这样的回应。
03
条件满足时，所有的事情都可以做。当必要条件缺少时，原本可以做的事情，也变成了无法做的事情。
需求的实现，也是如此。
“无法实现”与“可以实现”是需求对于开发者呈现出来的两种特殊状态。
是否满足必要条件，则是需求处于何种状态的判断条件。
我们所说的“需求无法实现”，就是指某个需求的实现，缺少相对应的必要条件。
当缺少的条件，被补充上时，“无法实现”的需求，也会变成“可以实现”的需求。
如同，缺少墨水的打印机，无法打印文件，补充墨水以后，就可以正常打印一样。
根据缺少的条件类型，也可以将“无法实现”划分成多种类型。
比如，缺少时间，缺少资源，缺少逻辑，缺少业务等等。
朋友所经历的“无法实现”，就属于“缺少标记”的类型。
“标记”，是做逻辑判断时常用的字段，其核心意义是进行条件辨识。
通过“标记”，我们可以对用户是否符合条件进行辨识。
复杂一点，还可以辨识出用户符合哪种条件，并为不同的条件设计不同的响应策略。
缺少标记时，系统就无法对用户进行辨识了，对应的需求，也就无法实现了。
基本上，数据库里的所有字段都可以作为“标记”来使用。
而“标记”的缺失，往往也意味着数据库缺少了对应的字段。
比如，向男性用户推荐胡须刀，向女性用户推荐口红，就需要将用户的性别字段，作为标记来使用，以此来对用户进行辨识。
缺少标记所导致的“无法实现”，就需要在数据库里补充对应的新字段，或者采用其他的字段作为“标记”。
“针对连续登录7天的用户，触发活动弹窗”，这项需求无法实现的原因，就是因为缺少标记。
数据库里没有字段存储用户的连续登录天数。
因此系统无法对用户进行辨识，无法知道用户是否符合活动弹窗的触发条件。
产品总监的底层思想，简单来讲：就是对缺少的必要条件，进行了补充。
使得系统能够对用户进行辨识，能够判断出用户是否符合触发条件。
04
我们可以选择与开发做“战友”，也可以选择与开发做“敌人”。
如果，我们将开发所说的“无法实现”，理解成事情的“结论”。
将会采取的措施，无外乎是“争执”和“强压”。
从结果上来看，大概率也只有两种结果：
第一种，开发同事熬夜加班。
自己独立思考“缺失条件”的补充方案，对产品经理不抱有一丝期望。
第二种，即使熬夜加班，耗费了许多时间，也仍然没能找到“缺失条件”的补充方案。
既承担了压力，也付出了辛苦，还被老板和领导责罚，心里对产品经理充满了不信任和怨恨。
不论是哪一种结果，都意味着我们和开发成为了“敌人”。
如果，我们将开发所说的“无法实现”，理解成事情的一种状态，就会采取另一种措施了。
我们可以与开发一起探讨：
缺少了哪一个必要条件；
也可以和开发一起思考补充方案；
还可以对彼此提出的补充方案进行完善和修改。
最重要的是，我们站在产品的角度。
可以从需求和产品设计上，对缺失的条件进行补充，这是开发同事所不具备的优势。
无论我们最后是否找到了补充方案。
这样的选择，以及这样的过程，都会意味着我们和开发建立起了彼此的信任。
也意味着，我们和开发成为了“战友”。
那么，你想和开发之间，建立“战友”关系，还是建立“敌人”关系呢？
选择权，一直在你手中。
来源 | 枯叶咖啡馆（ID：gh_bbe17bbe6a9e）
作者 | 枯叶咖啡馆；编辑 | 杂芜
内容仅代表作者独立观点，不代表早读课立场。
继续阅读
阅读原文