一个完整的产品要包含的内容远比软件功能多的多。举一个不恰当的例子，在几年前的乐视，进军电视行业时，开机呈现的字幕会告诉用户你打开的不是电视，而是一个生态（大概是这个意思）。
抛开乐视现在的处境，当时的这句话表达了乐视对于产品的理解，电视是产品么？对于消费者可能是，但是对于乐视来说，电视仅仅是整个产品的一个端而已，真正的产品是软件+硬件+服务运行体系的生态圈，这个理解没有问题，只是做出的结果不美好罢了。
产品的边界怎么划分？我认为首先要看产品的定义。
产品是一个问题的解决方案
有需求的产生才会有产品的出现，而需求来源于用户在日常的生活和工作中产生的问题。所有此产品的内容都是为了解决用户的某个具体场景。基于这个前期，我才会花了很多期去分解产品的各类用户，基于每类用户的问题去圈定产品的边界范围。
下面还是以高校的平台产品为例，说明产品的边界是如何划分的。
最初视角是基于用户的原始需求场景，也就是基于用户在没有产品时产生的痛点提炼出的产品范围，但这部分范围并不是最终商业化产品的表达。
1、明确产品的核心价值
描述产品的核心价值，无非就是在什么情况下解决什么样的用户的什么问题。树立好这个前提，之后所有的产品动作都必须围绕这个前提执行，划定产品范围亦是如此。
对于高校行业来说，平台产品的核心价值是为了帮助客户把高校信息化建设好。这句话类似于“让天下没有难做的生意”（是不是很熟悉？）。看上去很虚的一句话背后，需要做的事情确实非常多的。
2、拆解用户和产品价值
有了这个看似笼统的核心价值之后，接下来就要开始拆解用户，也就是整个产品到底为了哪些人服务。核心价值中的高校明确了行业属性，帮助高校建设信息化明确了产品的职责：是作为一个建设的底层工具，而不是直接解决了具体业务需求。这样拆解下来，产品边界就清晰了一点。
接着重点考虑建设信息化。谁来建？怎么建？怎么样才算建设好？
谁来建决定了产品的重点客户是谁以及各自的核心需求；怎么建决定了产品的核心功能包含哪些；怎么样才算建设好则是决定了产品落地效果的验证方式，根据我目前做过的产品，拆解的结果如下：
(1) 谁来建：
在高校内部，信息化建设当然主力是信息中心，其次是各个业务部门。而高校外部，也是比较容易忽略的用户群体，包含了第三方业务应用厂商、实施团队、产品定制团队。
总结出的核心需求如下：
信息中心：省心、省力、看得见，另外要权责明确和易于维护
第三方厂商：集成方式足够简单、开放能够足够强大、平台升级之后没有额外工作量
实施团队：简单的安装&升级过程、方便的需求反馈机制
产品定制团队：清晰的定制范围、较低的定制难度、定制之后的平滑升级
除此以外，建设信息化的最终目的是给终端用户提供服务，具体的用户剖析已经在上几篇写清楚，这里就不多赘述直接上结果
普通师生：统一登录、方便查找业务、及时知晓业务进度
业务老师：统一查看任务、学习成本低、可靠稳定
(2) 怎么建：
这个问题是行业属性非常重的部分。需要对整个行业的发展历史有相当的了解才能准确拆解出核心需求。
高校信息化行业总体逻辑是通过校内业务内容向师生提供服务。其中校内的业务内容可能是学校自身的网站信息，也可能是第三方厂商的MIS系统，也可能是学校通过低代码工具创建的流程服务等等。用户需要通过某种方式找到这些业务内容并完成整个业务流程。平台的核心需求即是完成业务系统与用户之间的串联，基于上述分析以及多年的行业经验，平台产品所需系统的核心功能如下：
(1) 统一用户管理：包含了针对用户的全生命周期管理组件和统一身份认证能力；
(2) 统一服务管理：包含了对校内和第三方的业务服务管理能力；
(3) 统一数据管理：包含了对校内各项人员数据、业务数据等综合治理能力；
(4) 统一门户：对终端用户的呈现内容，支持PC+移动的形式；
(5) 统一运营中心：包含了整个平台各项能力组件的运行情况，方便管理员知晓当前系统状态以及对外展示；
(6) 统一实施平台：包含了对整个平台的安装和升级工具；
利用上述核心功能，能够完成一个高校信息化建设从安装-管理-使用-运维的基本业务逻辑闭环。
(3) 怎么样才算建设好？
和上个问题一样，建设好这件事情是一个行业属性的问题。如果公司的客户规模小，那么可以利用初期制定的几个标杆客户效果作为起始标准；如果公司的客户规模大，需要对整个客户群的使用效果进行多维度的总结和提炼，列出建设好的标准并在产品中通过数据看板、数据报告的方式体现。
根据上述思路做出来的东西，是整个产品软件的主要部分，而并非产品的全部内容。
根据以往的经验，平台类产品往往由于架构复杂、组件繁多，整个产品会显得很重，导致售价较高，但并不能让客户购买后直接产生价值和使用效果，以往的平台产品反而会因为这种情况丢失到一部分预算较低的客户，客户会直接选择一个更加便宜的、短时间容易出效果的产品解决方案。一个好的产品需要实现使用价值闭环，仅仅做好上述内容，虽然已经比较复杂，但最多只能称之为“运行支撑工具”，客户购买之后并不能直接生效，还需要采购其他的业务类服务才能产生使用价值，这是客户并不想看到的，那么就需要产品线从商业的角度重新考虑产品边界内容，除了用户的原始需求场景以外，还有哪些是平台产品需要做的东西？
下一篇会描述此部分内容。
