产品功能边界

在其他网站看到一个很棒的文章，留存一下：http://www.woshipm.com/pd/310454.html
原作者是：@蓝胖子_ Simon 原创，发布于人人都是产品经理。

概念

产品的功能边界。在产品中，每个功能不应该是无限扩展的，而是有它的边界和限制，而决定功能边界和限制的就是功能自身的属性决定的。

优点

根据产品的功能边界去设计产品，有什么好处呢？

从产品的角度来看，功能应该是独立和模块化的，产品只是根据业务和用户体验，在不同的页面，拼接不同的功能模块，从而达到产品体验的最大化，同时使产品富有灵活性和可扩展性的特性。

活动优惠券例子

开发一个活动，活动展示，点击优惠券后，会领取优惠券，领取成功后，会向用户进行发送短信，讨论的点也就是发短信这边。活动和优惠券是两个不同的产品功能，短信肯定是调用消息通知进行发送，那谁要去触发这个短信，也就是发短信应该是在活动端还是在优惠券端？

观点：

发送短信应该是活动端进行调用的，而不是优惠券端。

阐述：

其实但就这个问题来讲，一个很核心的点就是优惠券和活动的对应关系。在我看来，优惠券和活动应该是多对一的关系，也就是一个活动会发送多张优惠券。

就比如滴滴活动时，会发送一堆券给到用户，去涵盖比如打车、专车、拼车等多项业务，多种价格，就是很典型的多张优惠券对应一个活动的形式。

假设发短信放到优惠券端，在优惠券领取成功之后，就会发送短信，那如果出现一次性可以领取多张券的情况，就会出现用户收到多条短信的情况，在整个用户体验和短信成本两边考虑都是不合适的。

而将短信的发送放到活动端时，就会很好的避免这个问题，当券领取成功后，统一发一条短信给到用户，同时短信内容还可以根据活动进行自定义，不管是用户体验的角度还是短信成本的考虑，都是最合适的选择。

乐高积木例子

产品的功能就如同乐高一块块独立的积木，而产品就是通过不同积木组合，依据业务需求和产品经理的一点奇思妙想，拼出来的模型。而积木与积木之前拼合在一起的只是那简单的几个卡扣而已。一旦某一块积木出现问题或需要调整，只需要动到那一块积木和与之相连的即可。
通过借助产品的功能边界，去设计功能，从产品金字塔最低端的细小功能点一点点去设计，到后来功能块、功能、页面，乃至整个产品，看似是个完整的整体，其实里面又独立者大大小小的个体，通过个体与个体之间的独立又紧密配合，来达到整体的配合，无疑这是最完美的情况。

如果将功能按照功能边界的思维进行拆分和整合，你会发现，当你再做另个产品时，可能只需要对功能模块进行重新排列，就可实现了。如果一个需求到了这边，你也会能够准确的分析出，涉及到的功能点和影响范围，从而更轻松的应对需求，实现更好的产品迭代。