前一篇说了在产品划定边界时，需要从用户的原始需求考虑。但即便满足了用户的原始需求，如果卖不出去，也并不是一个好的产品。所以无论是从产品边界还是解决方案组合，都需要从商业的角度重新考虑。
以我做过的高校平台产品为例，这个产品的本质和现有的操作系统类似，操作系统主要是为了软件提供运行环境，而平台产品也是一样，在上面跑的业务系统就类似于在操作系统上跑的App。但是如果windows只提供一套底层的运行平台，连“我的电脑”、“记事本”、“画图”都没有，更别说需要另外买的office，你还会觉得windows是个好产品么？那么为什么windows内置了记事本、画图、IE浏览器，却没有内置类似于微信、QQ这样的应用呢？为什么office需要另外购买呢？这一切都源于商业的考虑而不是用户的需求。
平台固然有其自己的管理价值，但是给客户的，是需要一个能够直接产生价值闭环的解决方案
要搞清楚平台产品本身除了支撑运行环境之外还需要什么内容，我们依然要把目光转向用户，无论平台建设的多么稳定可靠，用户依然要依赖业务应用才能完成日常工作，所以我们从用户的视角出发，看平台能够直接提供哪些使用价值。
1、前台那套页面是产品么？
这个部分我们误解过很多年，也会是很多平台产品甚至B端产品的问题
我们在过去的几年一直将前台产品的长相作为产品的一部分，希望全国各类的高校客户能够使用一套页面设计，通过一些产品标准化的配置项完成客户所需的个性需求，配置项无非是页面logo、背景图、颜色等等，整体前台的页面逻辑、内容和呈现方式都是产品标准的。
这是一套标准的互联网B端产品的做法，在之前的几年客户都是接受的。当时的客户在处在满足业务的基本需求上，只要能够呈现出一套外观还不错的前台展示方式，就能满足需求，并不会对前台页面设计要求很高。
而现在市场上的同类产品都能够满足业务需求时，客户更多的目光会投向前台的页面设计部分。而整体市场客户对于信息化的认知处在不同水平，加上审美和业务需求各异，所以再想用一套页面设计+标准化配置让所有客户满意是基本不可能的。
后来我们想过通过模板解决问题，使用不同的设计思路制作的、可供配置的产品标准模板解决问题。后来被验证依然是一条歪路。每个客户对于自己想要的设计风格根本无法穷举，即便是选择同一模板的客户，产品规划出的配置项也无法满足客户的想法，如果让定制团队介入，又会带来升级、后续维护等等一系列问题。
所以，有一点是可以肯定的，至少在平台产品中，前台那套页面并不是产品，或者不是产品的核心竞争力。
我们的解决方案是，如果没办法把前台页面标准化，那么就把制作前台页面的工具标准化，做一个客户和定制开发都能够轻松上手使用的模板引擎。只要模板引擎足够强大，配合产品标准模板+设计服务+定制开发团队几乎可以cover掉客户对于前台页面的设计需求。这才是可被标准化的产品形态。
2、平台有自己的业务么？
windows有自己的业务么？当然有，除了支撑系统正常运行的管理工具之外，windows提供了大量原生的业务应用，之前提到的画图、记事本、纸牌、便签、浏览器和office套件，到现在的微软小冰，都是windows自己的业务应用。正是因为有了这些，用户在购买windows之后能够马上使用起来直接处理自己的日常的工作和学习。
那么对于平台来说，业务是什么呢？这取决于其中的业务数据是否都由平台生产，或者平台能否进行业务闭环。想要定位这些业务点，需要结合现有的市场导向、用户实际的工作场景进行综合梳理。目前来说，在高校行业中，我认为平台可能涉足的业务范围如下：
(1) 通知发布与查看：类似于办公协同套件，在信息化建设水平高的客户中有类似需求
(2) 服务事项管理：聚合全校线上线下的服务指南并以办事大厅的方式对外展示
(3) 内容获取、集成工具：虽说数据需要第三方厂商配合，但是这类工具做的越多，适配的厂商越多，则越有业务价值。其中内容可以包含新闻、通知公告、课表以及其他业务系统中用户所关心的数据内容。
将上述的业务点作为产品组件划定在产品边界范围中，能够直接使用户在购买产品之后产生一定的使用价值，并且这些组件的业务逻辑相对简单，客户可能产生的定制化需求也相对较少。在系统架构设计时也比较好处理。
3. 只能靠第三方的业务系统才能办理业务么？
如前文所说，信息化产生的实际使用价值主要来自于运行在平台上的第三方的业务系统或者碎片化服务，平台需要对这些业务提供大量的底层能力支持，例如统一消息、统一任务、统一用户管理等等，但是除此以外，还有一部分业务内容是这些第三方厂商无法满足的。这类服务先称之为“流程小服务”。其特点是每个客户都会有这类的小型业务，例如会议室申请、临时通行证申请、VPN申请等等，这样的服务通常有一个完整的审核流程，包含一些常用的表单，由发起人填写表单后给审核人审批，即可完成。
第三方厂商很难将这些流程产品化，因为每个客户的流程都不一样，即便做出来价格也不会高，随着定制的需求增多，很难有利润空间。所以，这部分的工作最好的归宿是由平台完成。
和做模板引擎的思路一样，平台也无法对每一个流程标准化，所以退一步来说，打造一个能够低代码实现的配置服务的流程引擎，是平台能够解决此类问题的方法。客户可以通过流程引擎的方式简单快速的搭建出一个想要的流程小服务，而不需要依靠厂商漫长的建设周期和定制限制，对于客户来讲的价值就很大了。
自此，高校平台产品的产品边界已经梳理的差不多了，总结一下：
运行支撑层：
(1) 统一用户管理：包含了针对用户的全生命周期管理组件和统一身份认证能力
(2) 统一服务管理：包含了对校内和第三方的业务服务管理能力
(3) 统一数据管理：包含了对校内各项人员数据、业务数据等综合治理能力
(4) 统一门户：对终端用户的呈现内容，支持PC+移动的形式
(5) 统一运营中心：包含了整个平台各项能力组件的运行情况，方便管理员知晓当前系统状态以及对外展示
(6) 统一实施平台：包含了对整个平台的安装和升级工具
业务价值层：
(1) 模板引擎：能够根据不同业务搭建前台页面的工具
(2) 事项管理中心：能够对校内服务事项做全生命周期管理
(3) 内容集成工具：包含对新闻、通知公告、课表等数据的集中抓取和展示工具
(4) 流程引擎：包含能够简单快速搭建流程小服务的工具
那么这就完了么？对于产品本身的功能组件和商业化角度来说，确实已经结束了，可以上市售卖了，但是上述提到的依然是软件层面的边界和内容，除非是非常垂直的领域，软件之间的技术壁垒才会形成竞争力，而在大部分行业中，技术壁垒是一个可以被突破的东西，真正能够长期形成产品竞争力的，是技术以外的东西，在对产品做长期规划时，在搞清楚现有竞争力是什么的基础上思考如果保持竞争力才是最重要的。
