在当今快速发展的数字化时代，产品经理的角色愈发重要，但如何高效地设计出既满足用户需求又符合企业目标的产品，一直是行业内的难题。本文作者结合自身从营养师跨界转型为产品经理的丰富经验，以及在电商前后端产品设计中的实践，总结出了一套独特的“315产品法则”，希望能帮到大家。

承接前文总结我从「营养师到产品经理跨界转型」的经验，再结合这3年因工作分工调整，我从电商前转到后再到前后端串联的产品经历，细拆出一套「315产品法则」想分享给大家——分享给刚踏入产品经理行业的你、或是正负责前端的你、或是纠结是否要转后端的你。

前面总结了一个通用的解题公式「角色+目标+策略+情绪价值=解题思路」，对于工作实操来说是有点太高度总结了，貌似放之四海皆可用。没关系，今天我以一个真实后端产品案例，再为大家剖析一层。

01 弄清楚「我们」需要解决的问题

「315」产品法则的「3」，代表2个角色+1个目标，这是每个项目启动之前都要定位清楚的，也是整个产品方案设计的起点。2个角色分别是：「我」是谁、「我」要服务的用户是谁/都有谁，而1个目标则是「我们」需要解决的问题是什么。我转向后端产品后接手的第一个项目是商品上下架流程优化。为了让大家更好理解明确好「3」的重要性，我先补充一些项目背景信息及痛点问题。

如大家所见，电商平台最核心的就是商品，没有商品就没有所谓的电商平台。围绕商品最核心的链路是——前端商品上架售卖，用户在电商平台选购下单，最后到商品下架不卖了，用户也就无法再买到这款商品。而从后端角度，支撑前端这条核心链路就是商品上下架流程——该流程是否足够敏捷高效，反映了系统响应公司业务的速度快慢。

打个比方，市场部捕捉到用户需求变强，需要比原计划提前一两周上架新品。假若上下架流程非常复杂，涉及很多人工处理的话，系统只能说「臣妾办不到啊」，又或者硬是加班加点赶上去，搞得大家都筋疲力尽。而我当时调研商品上下架流程现状时就发现，我们的系统正正存在这样的问题：

1. 一个商品上架涉及4个系统，每个系统间相互不通，系统与系统间的同步完全依赖人工线下通知，一个不留神没通知到位，上架链路就断了；

2. 商品上架所必须的基础信息需要在多个系统，由不同部门重复录入，同样的工作重复做，大家都叫苦连天；

3. 商品下架流程中，电子审批单跟系统下架操作不完全同步，甚至发现早在几年前就不卖的产品，在系统里还是「在售」状态，而下架相关的市场披露信息都是靠人工逐个更新的；

你想，这样的上下架流程，能快得起来吗？

调研期间我还原了现状流程——每个节点都有谁，做了什么，下一步流转到谁。然后我做的第一步，是明确我是谁，以及我所服务的用户都有谁。我，当然是上下架流程的新设计者，而我所服务的用户是这个链条上涉及到的所有部门同事，一共10个部门，大半个公司部门都涉及到了。我发现后端产品与前端产品在角色定位和目标上差异非常大。前端产品的用户高度抽象出来其实「只有一个」——有购物需求的人，他们的目的就是买东西，非常纯粹。但后端产品流程主要服务于公司内部协作运营，这就意味着服务对象是公司各个部门，并且需要达到让各个部门在同一个流程中协作效率最大化的目的。

我作为新流程设计者，要同时满足10个部门同事的需求，共同解决「提升商品上下架效率」的问题，意味着我不能单一角度去思考，而需要分别站在这些部门的角度去设计合适的解决方案。顾此失彼一定无法让大家在方案上达成一致，亦会让项目卡在某个点上无法继续往下走。

那么，问题来了。大家所在的职场里应该多少都有感受，抛开个人小心思不谈，不同部门的立场都是不一样的。如何通过一个流程把大家串起来，为了相同目标，配合我们在产品方案上达成共识，就非常关键了。

02 核心流程只有1个

「315」产品法则的「1」，代表一个核心流程。商品上下架核心流程抽象出来，看似很简单：SKU信息录入—SKU审批—SKU创建—SKU测试—SKU上架—SKU下架。实际上也并不复杂，复杂的是我所在的环境，包括历史遗留的多系统以及系统边界问题、不同部门视角及其利益问题、部门内看待后端项目的价值问题、实施成本与预计收益问题。这要求我在设计新流程的时候，要很好地找到一个平衡点，让各方都满意。

我的解决思路就是紧紧抓住核心流程本身，找出系统间断裂的点、各部门同事重复工作的步骤、可以节省的人工操作、会带来商品数据不一致不准确的地方，这些也正是运营痛点本身。

我发现首个关键问题是，「SKU信息录入」和「SKU创建」这两个节点，分别是由两个不同部门同事根据同一份SKU信息在不同系统录入，然后由第三个部门同事复核数据后，人工下放数据到电商平台。这样的设计带来工作量翻倍、人工录入出错导致商品数据不一致、反复找负责人核对商品数据等问题，而这两个步骤的目标实际上就是在电商平台创建一个SKU，以便能上架销售。因此，简化的方式就是多个步骤「整合为一」——由该SKU负责部门同事直接在电商后台录入SKU信息，形成审批单，当审批单通过后，电商后台自动根据所录入的信息创建该SKU。这样简化之后，既可以确保SKU数据完全由其负责人录入（毕竟他是最清楚SKU数据的人），而无需后续辗转多手来做同样的事情。其次，系统边界也更清晰，电商平台就负责SKU销售，SKU数据源就应以电商平台为准。新流程上线后，我统计了商品上架由原来至少提前2周开始准备，缩短至2天，大大节省了中间不必要的人力时间投入，运营效率得到极大提升。

其次影响核心流程效率的还有「SKU下架」，这个节点下还有分支流程——包括SKU下架申请（含下架原因说明）、下架申请审批、审批通过后平台需向用户展示下架原因，确保市场沟通充分。针对子流程的简化方案我也是如法炮制，先定位到流程中断裂以及需要较多人工操作的地方。我发现下架申请审批与平台操作下架及下架原因披露是完全割裂的。申请单是单独电子流程，审批通过后完全是靠人工通知系统配置下架信息，再在指定时间蹲点下架SKU。这样一来一回的流程，下架一个SKU得花一周时间。而简化方式亦是打通断裂点——根据下架申请单里所填入的SKU号 、下架时间及原因等关键信息，自动关联电商系统对应配置项。待申请单审批通过后系统自动按要求设置并执行，这样既不需要人工盯着审批单，也不需要大半夜蹲点下架SKU。时效上也从原本一周左右的准备时间，缩减到1～2天就能完成SKU下架，大大释放了其中不必要的人力。

但无论是是哪个节点的优化，或是子流程的优化，围绕的仍是一个核心流程。只要抓住了核心流程，知道每个节点设置的目的，自然就能判断出哪些地方可以整合，做出适当取舍。很多时候我们「既要又要还要」，流程延展得无比冗长，反而让一个简单的事情复杂化。

「简单的事情复杂化」这个现象，在很多传统公司数字化转型时都很常见，因为新流程打破了太多「固化的思维和习惯」。大家害怕变化，害怕变化带来的不确定性，害怕变化会动到某些人的「蛋糕」，因此新流程推行时一定是阻力重重。再加上公司如何看待数字化，又或是数字化部门如何看待自己的使命，很大程度影响着新流程能否成功落地，毕竟这个决定了你能获取多少资源和支持去做这件事。再者，传统企业的系统历史负债重重，一个新流程的改造没人知道会挖出多少雷，更让新流程的推行蒙上一层阴影。

但我总相信，做难而正确的事，正正是我们作为一名产品经理的本职所在。

03 5大检验点逐个查

「315」产品法则的「5」，代表后端产品的5大检验点。后端与前端产品最大的差异是，一个后端新流程上线并不能像前端功能一样，一刀切就可以上线了。前端功能上线了，反馈不好，我可以通过开关的方式把功能撤下来，但后端流程不能轻易回退，后端流程出现的任何问题，都有可能关乎到公司运营流程能否正常运作，尤其是新旧流程切换，一旦没有平滑过渡，可能会引发P0事故。因此如何检验后端产品设计是否考虑周全，是否有遗漏，我总结出5个适用于后端设计的检验点：

1. 流程效率是否最大化？

2. 核心数据流是否合理？

3. 存量和增量数据应怎样处理？

4. 上线切换新旧流程的方案是什么？

5. 上线后的运营方案是什么？

第一点顾名思义就是检验流程设计是否足够精简，有没有解决前面提及的重复工作或存在没有意义的分支流程。比较好用的检验方式就是按照流程节点，从起点到终点，包括节点对应的角色，利用泳道图完整画出来。这个方式能让你更全局过一遍，每个角色在节点中处理什么内容，一目了然，也能帮助你有效发现并去掉无效节点。

第二点主要是检验数据流向是否合理，尤其是涉及多个系统，每个系统边界不一定非常清晰的时候，更要谨慎弄清楚。以商品上下架为例，SKU的成本、定价等信息是非常敏感的，这些数据一定不适合同步到多个系统里，同步得越多，泄露的风险就越高。我们原本已有系统A来储存这些敏感数据，系统B负责审批单流转，系统C负责接收数据并对接物流平台，而电商后台负责审批单创建、SKU录入及上架，数据中台则是收拢SKU主数据。

一个审批单在电商后台创建时，就必须从前置系统A里抓取到部分定价相关的数据，创建成功后传送至系统B流转，审批结果回传至电商后台触发SKU自动创建并上架，再同步该SKU至系统C，以便后续能顺利通知物流平台发货。最终SKU主数据汇聚到数据中台以服务未来业务销售分析。

因此，这个数据流向是从哪个系统获取到哪些数据，哪些数据应该储存，哪些数据应该同步给其他下游系统，这些都要考虑周全，避免出现上游系统从下游系统抽取数据最后又回到下游系统这种毫无意义的「死循环」里。

第三点是要设计存量和增量数据的处理方案，包括存量数据如何清洗、查漏补缺，新流程带来增量数据的准确性都能被覆盖到。当时我们的项目是分阶段上线，因此还出现了一段过渡期间需要人工定期初始化数据的工作。初始化数据的范围、频率、处理时效都要与各方定义好，否则容易出现要用数据的时候这里缺、那里少的情况。增量数据则是回归流程本身去思考是否都覆盖了，包括增量数据是否具备完整性、准确性，而无需过多人工操作去修复或者补全数据。这里的经验是，不要过多依赖人工修数，非常容易遗漏！

第四点新旧流程切换的考量。新流程上线建议设计试运营阶段，即旧流程正常使用，选取影响范围较小的切片场景试用新流程，验证新流程是否在各个节点顺畅流转，有没有在处理上存在问题。试运营真的能有效确保你「进可攻，退可守」，不至于一下「把自己绑死在一棵树上」。试运营如验证基本无问题，且效率足够有保证时，可以通过逐步扩大应用场景至完全切换到新流程上。新流程运行至基本稳定后，才考虑在入口、指引上完全关闭旧入口。

第五点是新流程上线后，如何能有效确保大家都使用新流程。运营方案具备较大延展性，也跟公司情况强相关。一般必备的基本操作是对内宣讲培训新流程——通过公司门户相关的入口指引、新流程操作手册的分发、旧流程中的指引说明，逐步将用户习惯培养至使用新流程上。否则，一个新流程上线大家都不使用，等于一连串的努力都白费了，从另一个侧面亦反映了新流程的设计并未考虑周全，大家都不喜欢用。因此，做好上线前的引导和培训非常必要。

以上5个检验点我认为是后端产品设计时必须自查的，这也能帮助产品经理设计出更周全、更完善的方案，同时也能有效保证新流程平稳过渡，不出大问题，并让各方都能更好地适应。

04 前后端思维打通，产品思路就更广阔

最后，我想谈谈这段从前到后又回过头兼顾前端的经历的感受。最大的体会是，后端产品真的太不容易了！

首先，你需要具备抽象总结能力，能抽象出关键节点，串联成核心流程。

其次，你需要更熟悉系统流程，帮助判断方案的取舍。

再者，你需要具备更强大的沟通技巧，因为你需要与非常多个部门沟通。如何听明白对方说的话，如何让对方听明白自己说的话，尤为关键。不同部门所关注的点都不同，沟通方式也很不一样，例如法务非常严谨、财务非常细致、IT非常直接等等，并没有一种说话方式走天下的捷径。学会换位思考、求同存异、避免自说自话，是我认为能更快与各方达成一致的路径。

再回过头看前端方案设计，「315法则」同样适用，只是在颗粒度上略有不同，思考范式是一致的。前端更靠近终端用户，如何能让平台更有温度，是给前端增添色彩的一个重要方向，也是能留住用户的「必杀技」。就如前篇转型心得所说，共情用户，是一个好的产品经理所必备技能。

最后我想说说，为什么我总结这个「315法则」。大家都知道「315」是国际消费者权益日，俗称「打假日」。

我想，产品经理也需要打假。

在我所接触的范围内见过太多「假的」产品经理了。

有的人心思不单纯，打着「为用户好，站在用户角度想」的旗号，实际上产品只是他们往上爬的工具和武器，根本不关心用户需要什么。

有的人过分经验主义，做几次用户访谈就大谈心得经验，只着眼于个案特例，而忽略了思考究竟要解决用户的什么问题，他们更关心的仅仅是在不同场合内秀出自己的访谈经验，拿用户案例作为谈资，彰显自己「更懂用户」。

有的人认为数字化就做前端就够了，只做「一层皮」，毕竟「这层皮」大家都看得见，后端看不见的就不做了，出了问题再说。

这些我都不认为是在认真做产品，亦有负用户所托，全浮于表面功夫。

因此，总结出「315法则」亦是希望与大家共勉，我们要时刻提醒自己要做一名真的产品经理，实实在在通过我们的知识框架、思维方式、经验沉淀去懂用户所想、给用户所需、解用户所困。