一引言
相信各位PM小伙伴都遇到过这种情况，一个已实现需求的小调整，开发却向你反馈需要“重新做”的情况。排除开发同学抬杠的可能，我们可以从产品设计的概念上谈谈如何让产品变得更易拓展。本文不涉及具体业务，只是分享下思维方式，欢迎各位小伙伴评论区交流。
二逻辑与特性
大家都知道随着时间的推移，用户的需求是不可能被完全满足的，也就是大家常说的“需求是做不完”的。举个例子，某Saas产品原来是只支持本企业运营人员在PC端手动根据填写的资质和申请为新用户开账号的，后来由于业务发展需要，开放了在公司官网的手机号自主注册。上线不久后，公司Saas产品的代理商又要求为他们的客户也开放一套手机号自主注册的机制，又或者公司要求再开放邮箱自主注册。这种情况下，需求明显是做不完的，而且似乎会有一些联系，我们应该如何更从容地应对这些需求呢？
我们可以看看这个例子的业务抽象后到底是什么？
What:新用户/凭借某些方式/得到账号。
这是不是太抽象了呢？那我们再对“what”细分一下
How:
我们可以从得到账号的过程新用户是主动或者被动分为“自主注册”，“运营手动开通”或者其他；
我们也可以从得到账号的位置分为“代理商渠道”，“官网渠道”或者其他；
我们还可以从用户提交的资质分为“手机号”、“邮箱”或者其他。
这里What就是我们说的“逻辑”，而How就是我们写文档要写的“特性”。事实上，可以看到“逻辑”是长期固定的，而“特性”与具体业务息息相关，也正是需求做不完的关键。
而找到了“逻辑”和“特性”后，我们要做的是固定“逻辑”，而将“特性”剥离。好的设计会让你的迭代围绕在“特性”部分，而由于“特性”往往只对应较小的模块，甚至会有现成的实现方案，所以更容易掌控。
三如何区分逻辑和特性
都说逻辑能力是产品同学的基础能力，而对事物本质的洞见力以及抽象能力显然就是逻辑能力的体现之一了。我们常说艺术上的抽象是让事物变得特别（unique），而作为PM，我们的抽象是通过识别本质而让事物变得简单。
逻辑和特性的区分也是一种抽象，下面我们看看区分逻辑和特性的工作流程。
3.1尽可能多地梳理业务中的需求
见多方能识广，这个一个采样的过程，你的样本集能否代表业务全貌决定了你的抽象是否可靠。举个例子，如果如果只接触了“公司运营为新用户手动开账号”这一种业务，那可能我的抽象会变成”公司运营手动操作某些事情”。这不能说不对，只是明显对我们的思路会产生误导。所以尽可能多地了解你的业务场景，是一个好的抽象的基础。
3.2业务抽象
我们可以借鉴两种常用的思维方式：过程抽象和角色抽象。
过程的抽象，重点在于梳理出通用流程中包含的几个模块或者步骤。比如在“新用户/凭借某些方式/得到账号”这一过程中，新用户的注册信息、新用户的创建、用户前端的展示等模块都是必不可少的。看到这里的朋友其实也想到了，这一抽象方式在多个业务上的复用其实也就是对应着中台的理论基础；
角色的抽象，则需要我们先去考虑我们的整个系统到底有哪些角色参与，每个角色的信息和可能做的事情是什么。之后再对各个角色之间的关系进行拓展。这种抽象方式往往要求系统中参与的角色是立体的。比如如果我们从来没有考虑过“代理商”这一角色，那我们所有基于“代理商”的需求自然而然会是空中楼阁。
通过业务抽象，其实我们的逻辑和特性已经呼之欲出了。
3.3定义逻辑和特性
相信经过上面的步骤，你已经能“想清楚”了。后面要做的就是描述出整个业务的工作轨迹。你会发现，如同鱼骨图一般，特性（鱼刺）会很多，我们也会继续增加，但是逻辑（鱼脊柱）大多数都是固定的。
在这种思路的产品构建之下，比如我们如果要加一种注册方式，其实只是在“新用户的注册信息”中增加了一个特性而已。这并不会影响到我们的基本逻辑，而且有的特性复用的概率高的时候我们也可以通过“组件化”来消除不必要的重复工作量。
在构建特性的过程，在规定边界的同时，我们也可以加入自己对特性的理解和未来的可能迭代方向。
这篇文章没有涉及具体的业务，只是笔者结合实际工作中的一些思考，和大家做一个分享，如果对读者朋友有所启发，深感荣幸。也欢迎大家指正批评。