编辑导语：产品的实现需要做好产品规划，而产品的规划决定了产品的方向。本文从战略规划的重要性、产品定位、设计产品架构图三个方向，详细地为大家梳理了产品实现的前期准备。一起来看看吧。

我们知晓了如何去发掘问题，并找到解决方案。

可对于问题的处理，我们可以临时应付，也可以相对稳固，甚至于可以扩展挖掘以解决长期的问题和隐患。

基于互联网可快递迭代的情况，以上三种处理方式都有其可取之处。

但是对于产品的整体性和发展来讲，需要的是战略规划，需要的是前瞻设计。

随着社会的快速发展，开荒式的创业模式已经基本不存在，加上大量资本存在快速入场和绞杀的情况，这种可能性更加微乎其微。

随着房地产的严控，过去一段时间的电梯式经济模式也已经不适用了。

坐上这趟电梯，后续就不用怎么管，收益、得到蹭蹭上涨的时代已经一去不复回了。

是的，这是一个攀岩时代，有多高的能力就上多高的台阶，上了台阶还不一定稳，还得小心意外风险。

让每一个人都在奋斗中去实现自己的价值。

产品的实现，就更需要做好战略规划，定好自己的北极星需求，搭建好自己稳固的框架，来实现稳扎稳打的推进。

先控制，后碎部，步步检核。

一、战略规划的重要性

在现实中，遇见问题，解决问题才会触发思考，才能提升更进一步。

随着入行的深入，见识了很明显的行业问题：

没有最小闭环概念；没有实现子系统的良好分割；没有串联清楚全部的业务；没有定好产品的优先级顺序。

1. 没有最小闭环

没有最小闭环，常表现为只做功能，未做直接的统计，报表未做数据导出功能。

例如，做了考勤的工作，却未做出勤天数、异常打卡、迟到、请假、加班的统计数据。

功能应用是其中很重要的部分，但是结果的反馈却能够提供很好的用户体验，降低切换使用平台的抵触心理。

没有最小闭环也体现在整体业务流程没有完全梳理完整，在哪些部分可以打断，在哪些部分可以扩展。

例如，在电商环境下，购物的整个流程就是最小闭环，从选择商品到下单，到订单支付，到收货确认，这就是一个最小闭环。

模拟订单最小闭环

但是基于最小闭环，可以继续扩展，如下图所示：

基于最小闭环扩展

2. 没有做好子系统分割

没有子系统做好分割，主要是系统间的解耦问题。

为什么系统间的解耦很重要？

按照现在B端的系统来讲，少则6、7个子系统，多则10几个，几十个。

当前一个系统需要修改，没有做好解耦的情况下，就需要在新的代码里，整体测试一遍，会导致测试的工作量急剧增加，也就是动一发而牵全身。

另一个就是，修改了一小部分，每个部分的人员都需要在，出现问题就需要各种追查。这在实际上是不需要的。

如下图所示，将一个系统抽象出来，主要由三部分组成，系统本身内部的功能、数据，输入依赖，输出能力。

解耦系统的抽象模拟

订单系统，需要依赖商品管理系统，实现基于哪些商品下单，输入依赖就是商品的查询。

对于订单系统来说，输出能力就必须有订单查询能力。

而同时，对于商品管理的系统来讲，商品的查询就是他的输出能力。

做好系统间的独立，就需要明确子系统本身功能集合，明确系统的输出能力。

基于这个良好的解耦，在其中某一个部分修改时，就能明确是这个系统本身的问题。

如果存在接口调用的情况，那就是需要做接口兼容。这样解决了之前需要联动才能完成的难题。

还能实现各个系统本身的自成长，只要持久保持之前的输出能力，后续的无限扩展就是内部系统的成长空间。

3. 没有串联清楚全部的业务

公司的发展一般模式都是，先做一条主要的受益路线，然后基于受益路线，扩展上下游，扩展路线的宽度。

上下游的事情比较难一点，是绝对的跨行业情况。而横向扩展业务是绝大多数的选择。

比如，正在经营的是一条销售线，是去发展销售物品的上游生产线，还是扩展更多的售卖渠道，甚至于扩展更多产品的销售，更多的倾向后面的部分。

基于公司业务的情况，所实现的系统需要去支撑整体业务的运转。

就需要业务本身相对独立，而在某些环节又是相同并行的，就需要在系统实现上一一拆解。

在实际的案例中，两种不同的业务模式，代理、佣金，基础的业务执行是一样的，只是在费用结算时是不一样的。

代理依据订单来，直接结算订单中的金额。

而对于佣金模式来讲，则是以最后卖出去产品的数量来结算。

就是在这看似环节一样，只在某一个环节不一样的情况下，需要去拆解深挖。

业务发展的选择

以上的案例，没有按照业务模式去完全拆解各个业务模式的支撑，统一按照订单、第三方数据记账、销售结果上报的模式来处理，就存在较多的问题需要去处理，导致业务缠杂在一起。

同样是订单模块，代理的订单需要垫付保证金，需要追踪货物，货物报损做到代理公司身上，费用结算时包含保证金的处理。

而佣金模式，则是需要公司给公司交保证金，而不是订单内货物保证金，整个跟踪过程并不需要实时跟进和反馈，只需要确定最后的销售结果上报。

缠杂在一起时，用户学习、使用困难，学习成本高。如若直接拆分成为代理模式，以及佣金模式，就会爽利很多。

在业务拆解上不要偷懒。尽量的拆解出来最原始的材料，再重新组合。

如果经多方、多次验证，可以合并再统一。

子系统的一部分可左可右时，一定再检核一下，用最小闭环去检核一下。

去长远的角度看，从更高层次去看，从更多角度去看，可左可右是肯定存在区别的，只是当前是否能够识别。

要是万一难决断，就选择其中一个，并把当时考虑到的点记录下来。

互联网快速迭代的发展是可以兼容下部分偏差的。记录下来，也是后续自我优化、对照的信息来源。

4. 没有定好产品的优先级顺序

B端系统简洁一些的，子系统会拆解为6、7个，复杂一些的或拆解10多个，甚至更多。

在系统落地上，一定做好子系统优先级顺序，让前置系统先上线，接受用户的真实使用，从用户手上获取最直接的反馈。

系统研发常常出现，经过调研确认、详细设计、业务评审、需求评审、测试检查、运营模拟等一系列情况后，仍旧不符合实际的使用场景。

其实，这本身长链条的传递就容易信息丢失，更何况还存在调研对象不知道互联网模式的信息偏差，存在不完全一致是现实存在的。

（这个或许有点觉得不可思议，但这就是我们的专业认知偏差，我们以为我们知道，实际上，我们可能真的不知道。举个例子，微信下面的四个菜单分别是？）。

基于这种情况，产品研发的最好验证，是先运行起来，哪怕不是很好。

基于产品设计的关键流程，整体设计是没有问题的，出现的偏差主要是业务的熟悉度问题，信息表达的问题。

先把一部分功能运行起来，就能发现业务的盲区，以及相关干系人的沟通范式。

第一版本哪怕是很小很基础的部分，上线后运转起来，再发现问题，调整沟通，就能迅速让这一环节整体运转起来。

这里同时也说明了最小闭环、系统分割的重要性。

最小闭环，让这一块的功能完全转起来，不会存在做一部分事情，然后另外的事情又需要其他工具帮忙才能完成（小细节，最小闭环出的统计报表要有导出功能哟）。

系统分割好，当前系统可继续做升级优化，上下游的系统可以独立研发，基于新的变化做相应的调整就可以。

正是因为系统分割做得好，解耦好，新系统可以独立测试，然后串联已上线的部分延长整体的生产流程（类似火车车厢的拼接）。

车厢自身运转，车厢相互链接

随着各个车厢的完成，链接上线运行，整个火车就越来越有生产力和价值。

在互联网产品的研发中，一个系统的实现周期相对较长，子系统之间存在相互依赖，若是前置依赖没有完成，后面的环节即使完成也不能纳入整体使用，这对于研发团队是有很大打击的。

经历过一个团队，系统复杂很高，拆解子系统近20个，需求的沟通确认也存在很大的问题，在需求评审沟通上打一些折扣，在执行上研发技术因为技术难点再截取一部分，数据兼容、历史版本的处理再牵连一下，整体就是一个滕网状态。整体在最前期有些冒进，做了很多的系统工作，整体的工作量巨大，但是能交出去并真正使用的部分很少。

其中还因为产品需求调研的问题和思考逻辑的问题，四大主要功能模块都经历了3次以上的改版。

最惨的是，不是基础数据提供的2个系统，每个经历3次改版，还没有到用户手上验证过1次。（好吧，就是我当前的团队情况，我认为我知道怎么办，也提供了方案，却没能被采用，就在这里进行自我的深度剖析。自我较劲也好，自我证明也罢，就是希望通过复盘的方式让自己想的更完善一些。当然，团队也有了新的改变，就跟随团队，一起前行吧）。

产品的需求在团队里，反复来了3次，这个时候，研发已经很不信任产品了。

为了稳住这个信任，要花费很多精力啊！

在这个情况下，我还看到了互联网产品可能不成功的另一个原因，产品团队的反复，消耗掉了团队的信任，团队内部战斗力降低。

整体战斗力的降低和士气低落，导致向上获取资源变难，最后，产品的落地成盒。就在这里，初窥管理的艺术和能量。

战略规划，就是为了规避这些问题，消除团队内部的内耗，指明前行的方向，在搏击互联网浪潮中，极大的提高成功率。

二、做好产品定位

需要做一个好的战略规划，就需要制定一个标准，用于各个环节的决策，产品定位就是这个标准。

所有的需求、团队资源是一个产品的小兵，如何用有限的人力资源，训练好自己的士兵，在市场上打出来一片江山，就需要建立自己的大本营。

为建立好自己的大本营，需要回答核心的问题：

这款产品以什么方式重点满足用户的哪种需求？

“用户的哪种需求”，是确定核心用户群的核心需求，“重点”是把关键的需求做深做透彻，“以什么方式”是在现有团队的条件下给出最优竞争力的解决方案。

这个需求要不要做，这个需求怎么做，这需求这样做能不能行…这一系列的问题，都需要依据产品定位来确定。

在做产品定位时，一定要找准自己的真实用户群。

即时通讯软件的用户是普通用户群，而细分的相亲即时通讯软件的用户则是适龄单身青年。

客户管理软件的用户群则是销售代表，而销售管理软件的用户群则是公司管理层，甚至销售管理软件会内嵌客户管理软件。

这时，客户管理软件就需要支撑管理层的功能，例如客户的分析、评价；客户的反馈；客户的分配…

销售管理软件目标用户是公司级老板及销售总监级，在功能的实现上，辅助销售更好的做销售是延伸，而记录销售的过程数据，并基于过程数据分析销售情况及对销售代表进行评价，才是支柱。

基于真实的用户，基于真实用户的核心需求，才能更恰当的搭建产品的最小闭环，也才能最佳的做好产品定位。

微信，是一种生活方式。

在每一次的微信升级中，提示语句更多的为：修复了一些已知问题。

在最开始的时候，还浅意识认为，基于微信这么大体量，新一版的更新必然引起众多媒体的宣传和粉丝的挖掘测试，因兴趣而引发推广，是一种营销方式的延展。

实际上也正是因为这个体量，那就没必要用这种方式来营销产品。

可是，换做以产品定位来进行解读这个，那就理所应当一些了。

微信，是一种生活方式，既然是生活，就不需要太多的打扰与过多的干扰，就是在我需要办什么的情况下，就会出现需要的帮助及工具。

基于这个情况，那每一次的版本升级是为了完善之前生活方式下可能走不通或有问题的，那更新之后，之前用那个生活方式的人就自己去经历，而不用这个生活方式的人根本不需要感知到。

深度挖掘和匹配，这就是产品定位的意义和作用。

同时，产品定位也不是固定不变的，随着市场的变化和发展，在整体公司战略调整中，是需要及时调整产品定位的。

互联网时代，信息传播速度变快，各个产品的竞争也日益严重。

更主要的，产品之间的竞争并不一定来自直接竞品或者潜在竞品。存在跨行业竞争，甚至于降维打击。

洛基亚47%的市场占有率也抵不住，苹果智能手机全方位的碾压，一个通讯工具是完全不可能抵抗一台能够通讯的电脑的。

柯达相机和胶卷即使到最后时刻也依旧是市场上最优秀的产品，只是因为数码相机的发明，未来已经没有胶卷的位置了。

银行或许怎么也没想到，支付宝的出现，让ATM机、线下网点、运钞体系、点钞能力员工、百万级的柜员，原本引以为傲的整个体系，在未来不被需要，“无现金社会”达成典型的降维打击。

时代在飞速的前进，产品既需要在时代的洪流中瞄准自己的锚，钉住自己的价值，也需要在适时的时间放开锚，激浪潮头。

三、设计产品架构图

明确产品的定位，描绘出产品的核心，此后就需要将定位在现实中拆解开来，逐步去实现。产品架构图就是落地实施前最好的指导。

类似建房前，需要进行施工图设计，进行材料入驻，之后才是按部就班进行整体的建设。

产品架构图也需要达成这些指导，主要包含产品的子系统构成，系统之间的依赖关系，从而也确定系统的优先级顺序。

框架搭建的好，对于未来的扩展性就好很多。

尽管在软件研发中，系统重构几乎不可避免，但好的框架可以支撑更广泛的业务，也能够在更大程度兼容业务，保持更持久的生命力。

框架结构更稳定，墙面完整性、隔热隔风能力更好，房内配置更加稳固、可迁移性好，构建完整的一间房本身的安全性、舒适性、实用性则更好。

而本身坚固安全的小房间可以相互叠加，构建成为更大的建筑。

我们拆解的每一个子系统就是一个房间。

1. 电商MVP

以电商产品架构为案例，进行产品架构的落地设计完善。

初期的电商就是将线下的店面销售搬上线，利于客户下单，是直接的直营销售。

初步形成主要是展示自己有多少商品，让用户注册之后立即能够查看所购买内容，找到自己所想的商品则立即下单并完成支付，之后进行配送的跟踪则达成整个订单的完成。

则系统设计规划为：商品管理、用户管理、订单管理、支付管理、配送管理。

小店社区物品配送产品架构图

这实际也是电商模式的最小闭环，实现电商系列的MVP。

适用于店面直营销售，可用于社区周边商超提供该工具，利于周边住户下单购买。

2. 京东初始产品架构

随着客户的发展，需要扩展相关业务的支撑，在营销上进行发力。

需要支持获取客户、客户激活、客户变现以及客户列表，也就是支持营销活动。

则系统规划扩展：用户等级管理、营销活动管理。

用户等级管理实现VIP等管理，以区别客户的不同潜在价值，为运营活动提供支撑。

营销活动管理则实现活动通路，满足打折、满减、满赠等一系列营销活动。

京东最开始着力在3C电器的销售，初始也更多的坚持京东直营。

则需要以上产品架构的支撑。

之后京东决策在物流体系上发力，构建更为快速、便捷的物流体系，形成了京东的核心竞争力。

支持物流扩展出物流管理、仓储管理系统。

运营活动支持和物流体系支持

一个人的关注度有限，加上产品体系的增大，管理人员易存在较多盲点。

基于业务，基于实际情况，进行风险预警管理，可以实现在未发生前发现问题，在问题较小时尽早处理问题，在问题发生以后总结经验防止类似问题重复发生，扩展：风险预警。

3. 电商平台化

以上均是一个店家的情况，实际电商的模式存在很大部分的相似性，可以实现一套产品管理很多商家，产品则需要扩展完善。

既是实现平台化，就需要实现商家管理，扩展商家入驻的业务流程。

基于运营活动精细化的管理，在订单完成时，实现一定的经验积累及成果积累，获取用户更多的使用时长，增加客户黏性。

同时也通过积分的方式让利部分，让用户获取更多的“实惠”，逐渐将产品渗入到用户的生活中去，从而扩展出积分管理。

大数据挖掘和分析在当下已经逐步趋于日常。

每个用户的使用偏好，同样是洗发水，不同用户可能偏好不同的品牌。

各个用户可能处于他自己的不同阶段，有人可能处于画画研究的痴迷阶段，有人可能处于初当奶爸的阶段…

大数据分析构建用户画像，将最合适的产品主动推送到需要的用户身上，极大的增加了用户好感，也加快了产品变现周期，扩展出数据挖掘。

电商行业产品架构图

产品的设计及规划立足于解决现实业务问题，需要以业务为基准，解决业务的实际问题，凸显出产品的优势。

以上以电商行业为例，初步构建产品架构图，梳理产品规划。

以下为经验总结，输出通用产品架构图。

通用产品架构图

当前业务的急速发展，技术的快速迭代，都在加速这个时代的变迁。

现如今已不简单的只是产品架构的搭建，而其中各个环节的强化都在变得更具有扩展性和包容能力。

业务中台、数据中台将产品适应性、扩展性都急剧扩大。

在大平台的发展上，这些新的技术是需要产品、技术共同去落地的，站在巨人的肩上走得更远。

关于业务中台、数据中台，且先留余地。

本文由 @钢铁侠战幻视 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议。