全文共计7008字，预计阅读时间20分钟                本文记录我在小红书电商产品部营销组的主要工作与收获，三个月实习期间我承接了来自3个模块的6个需求，每个需求的耗费时间并不长，但我的收获和成长都比较多。  商家后台的体验性需求：商家后台服务于自营店铺和第三方商家，里面的板块众多，我只承接来自促销板块的需求，这里的两个体验性需求是我在刚入职时做的，难度不高，主要用于熟悉产品流程，但后来复盘时发现也有较多值得思考与改进的点。 促销场景的调研与拓展性需求：这个模块是在制定平台促销的底层规则、拓展新的促销场景和营销工具，由于平台已经有一套较为成熟的规则，并且一次变动带来的影响范围较广，所以这边的需求没有太多的迭代，我主要通过调研了解了电商促销的体系，并支持C端沉淀了一个新的券场景搭建工具。 价格中台的迭代性需求：价格中台主要为小红书C端各个业务场景提供价格计算能力，有长期业务价值、需求复杂度也较高，但我所承接的需求的实际方案并不复杂，在这个需求中比较困难的点在两个方面 1）沟通与协调各个C端业务场景，2）梳理现存的规则找出不合理性。              本文内容如有不妥，请联系我删改           商家后台的体验性需求          商家后台主要服务于自营店铺和第三方商家，后台包含了诸多商家日常管理的模块，比如店铺、商品、订单、物流等，我所在的业务仅承接其中的促销模块。我在这部分业务中主要做了两个需求，一个是惊喜盒子活动报名流程的优化，一个是预售管理的体验优化。          惊喜盒子活动报名流程优化          需求背景          惊喜盒子是小红书内给用户发优惠券的场景之一，用户在逛社区笔记的过程中，会掉落惊喜盒子券，促进用户从社区转化到商城购物。  这个需求来源于负责收集与审核惊喜盒子券的运营同学，商家每月会提报一定数量的券，整个流程为：                     整个流程出现了以下问题：               商家提报的券和主图不符合要求的比例较高，尤其是主图不合格数量占比80%             运营审核不通过后，重新报名比例较低               需求分析          分析后发现，出现这两个问题的原因在于：               商家在报名过程中无法感知到运营设定的券和主图的要求             商家无法收到报名审核不通过的通知             商家看到审核不通过的列表后找不到重新报名的入口，只能重新走一遍报名流程              需求复盘          需求的背景很清晰，方案也不复杂，在整个需求过程中，我遇到的问题主要集中在评审与开发阶段：               需求评审时被质疑有实现复杂度更低的方案             评审过程中开发提出当前方案会影响系统中的其他部分，影响商家的判断                  在通知商家不通过的方案中，我的提示话术是"您有一条活动报名不通过"，这会让商家误认为这里的提示是针对所有类型的活动报名，但我们本次的需求仅针对惊喜盒子类型。                        开发过程中研发需要相关的提报情况数据，作为开发成本的判断              通过这个需求遇到的问题给我带来的思考：               业务价值的判断：这是我前期在做需求时感悟最深的点，需求的实现最终是为了推动业务发展的，因而在接到一个需求前首先需要明确的就是这个业务的价值有多高；             提前思考方案的实现复杂度：当前是最优方案吗？有没有替代性方案？这个方案与替代性方案相比有什么优点和不足？这里的优点是否值得去做更高成本的投入？             方案设计时考虑对相关模块的影响：由于B端的需求之间联系密切，往往牵一发而动全身，因而去改动系统中一个逻辑时需要更全面的思考它的影响范围，这里的影响范围不仅是其他板块，也可能是其他业务方；             产品文案打磨：在设计产品的过程中避不开一些文案撰写，比如功能名称、提示语、页面引导语等。              预售管理体验优化          需求背景          预售是电商促销中非常常见的玩法，用户通过提前支付定金预定商品，并在尾款期支付尾款完成下单。而在此之前，商家需要在后台提前配置好预售商品，包括商品的预售时间（分为定金期和尾款期）、预售价格（分为定金价格、尾款价格、膨胀价格）等。          在使用过程中，商家遇到了一些体验问题，并提出了如下需求：               可以支持多选预售状态导出预售数据             已终止的预售ID，支持查看详情             商品价格落入"真空价格区间"（报关商品会出现的价格校验区间）报错提示更详细             可批量配置定金预售              需求分析          以上的四个需求，前三个主要在于新增入口或功能，并无太多方案产出的空间，需要产品推动研发实现，主要集中在最后一个需求，需要考虑批量配置的方式和流程：               配置方式：以Excel格式批量上传             表格字段：包含预售必须的商品ID、可售量、预售价、定金金额、膨胀金额             配置前：提供模版下载入口             配置后：需要提示是否配置成功，若有失败，应该告知失败名单和原因              需求复盘          处理这个项目遇到的主要问题有：               需求被砍：在评审过程中，多选预售状态的需求实现难度比我们想象的要大很多，加上研发认为当前分几次导出的工作量并没有这么大，因而这个需求被否掉了             需求价值被质疑：在开发过程中，批量配置的后端工作量超出预期，需要后端重新写一套逻辑，花费了3pd去做这件事，导致研发在此期间一直有问我日常预售商品的配置数量如何             上线后发现影响较大的错误：在三八大促预售配置当晚，自营运营同学发现定金校验的规则是不完全的，实际校验规则比我最初制定的要更复杂              为我带来的思考：               不对实现成本做过高预期、不在未评审情况下对任何需求打包票：在处理第一个需求的时候，作为产品我低估了它的实现难度，导致我们在和运营对方案时保证这个需求可以做，但实际研发评审时发现并非如此；             提前了解业务价值：由于惊喜盒子和预售的需求是同时推动的，所以在处理这个需求的时候我依然忽略了业务价值的问题，包括运营目前配置的商品数量有多少、目前有另一个替代工具为什么无法满足、以及开放给商家后商家的使用频率和上传数量有多少；             注重与业务了解需求中涉及的细节：平台针对定金金额的范围有更复杂和详细的限制，但我在做产品调研时，仅从系统提示的内容判断，丢失了其他限制，而这个内容是需要和运营了解的。                  在去做这个判断的时候我犯了两个错误 1）对需求中涉及的规则没有更详细了解，尤其是当调研时发现平台对定金金额做了限制，应该去思考是否有其他限制，2）没有和业务方了解更多信息，业务方会默认你知道。                              两个需求的复杂度都不高，是入职前期熟悉产品流程、了解沟通协调的练手项目，但处理需求的过程中，无论是在方案产出、需求评审还是后续上线，都踩了不少坑，也让我认识到产品经理是需要对需求的整个过程负责的：在接到需求时需要判断价值、在输出方案时需要思考需求的实现成本与更优方案、在需求评审时需要让研发清楚 背景与收益、在开发过程中遇到问题需要及时判断哪些可以放弃（实际研发时，研发也会发现其他成本高/不合理的地方，产品需要判断能不能做、怎么做以及如果不做是否有影响）、在实际上线后需要考虑收益是否达到预期，遇到bad case如何处理。              促销场景的调研与拓展性需求          这个模块是在制定平台促销的底层规则、拓展新的促销场景和营销工具，属于较为散、且无具像化产品的模块。  平台促销的类型众多，彼此间的生效逻辑也较为复杂，产品需要定义其生效逻辑以保证减少用户参与促销时的理解成本、提升用户享受的促销力度、同时保证商家不会让利过度，这里的底层定义我并未参与，平台目前的底层逻辑定义已经较为成熟，我所做的工作仅是 调研和梳理现存的规范并发现改进点。  虽然底层的规则目前较为固定，但平台营销的玩法却并不完善，因而即使作为B端，我们也要去发现新的营销玩法，并且为这些玩法提供工具支持，从配置和生效侧去定义活动玩法，同时考虑一些C端的承接场景。          促销规则调研          调研背景               平台目前的促销规则经过几轮迭代，加上pm的更新，因而缺少最新的调研文档参考             我们希望从当前的规则中查找不合理的地方，修正并提出新的规则              调研过程          整个调研过程经历三个阶段：1）翻阅历史文档，2）有基本认知后梳理一版初稿，3）调研竞品并做对比。在这个过程中，我了解了电商促销的整体体系，总结如下：                     整体来说，我们有两个角度的维度，从玩法来说，分为预售、单品、多品和券，从范围来说，分为平台、店铺、全店和指定商品。               平台维度是由平台运营配置、商家参与报名             店铺维度则是商家可以自主配置。              在这些维度下会有更细一层的玩法划分，例如超级单品促销下划分为限时购、闪购、会员福利购和新人价。          在更细一层的玩法中，玩法之间会存在生效规则，即互斥、优先级和不可叠加               互斥：在配置侧就限制住、不允许商家同时配置             优先级：在生效侧会在n个生效时间交叉的促销活动中优先展示一个             不可叠加：是在结算侧限制用户在n个活动中只能参与其中某几个。              调研复盘          最初接到促销规则调研时，我没有任何的头绪，整理出的初版内容没有任何个人的思考，在后续不断对接、修改和看竞品后，勉强算是梳理了框架，也有了一些感知，总结我个人的调研方法如下：               明确调研目标：目标抓准了才会有头绪，在确定大目标后需要拆解小目标，然后以此为目标针对性调研；             梳理历史文档：详细阅读公司内部的相关文档，提出疑问点、寻找文档之间的共同点，然后理出这块内容的框架，这个框架可以为自己的调研提供方向；             梳理现状，必要时调研竞品：按照框架梳理现状，并根据目标输出调研结论。                  注意文档的可读性：内部沉淀的文档往往会供其他同学查阅，因而要站在不了解这块业务的同学的角度                   竞品调研的思路：确定目标——根据目标通读相关资料或体验产品——梳理现状，提出启发点                         裂变券工具搭建          需求背景          在大促期间，C端产品策划了裂变券活动并取得了不错的转化率，并且目前淘宝和京东都支持商家自建裂变券，因此B端需要将裂变券工具沉淀为商家自运营的玩法。          需求分析          整个券工具的搭建分为几个模块：               底层券模版：券的结构分为券模版和单券，举个例子，满300-40的平台券是一个券模版，但用户领到一张满300-40的平台券是一张单券。券模版定义了券的字段，包括券类型、可领时间、可用时间、优惠门槛等等；             券推广渠道：即商家建好的裂变券需要在C端的哪些渠道露出和推广，我们需要提前设想好，并制定露出的规则；             活动限制：如何限制用户的行为（发起用户+助力用户），从而确保在为商家带来流量、用户愿意参与的前提下，商家不会让利过度、平台和商家不会被薅羊毛；             与C端的合作与界限：裂变活动在B端创建、在C端露出，因而这是一个BC端联动的需求，我们需要和C端产品了解他们的产品方案，以及哪些工作应该由我们推动、哪些由他们推动。              在接到需求后，我首先针对淘宝的裂变券玩法做了系统的调研，梳理完毕后根据我们的券模版梳理券的字段以及限制条件、推广渠道的露出规则。          需求复盘          整个需求处理过程中难度并没有很大，前期比较系统的竞品调研带来了很多的启发，比较难以确定的点主要在于裂变券父券（分享者可领的券）的力度限制、透出逻辑，这些问题在和mentor对接以及需求评审后都基本解决。          这个需求是我离职前的最后一个需求，在这个过程中我能感受到自己入职以来的成长：               在做竞品调研时比之前更有方向，更能梳理出框架；             需求评审中，在遇到其他产品与研发同学提出的质疑时，我在会前有过预判，并且能够给出我的方案设计的原因，以及竞品的做法。              在这里，我将产品设计的流程总结如下：               竞品调研：这里不仅包括实际的竞品，也包括项目启动前的其他相关需求，例如裂变券的需求我也需要查看C端产品的裂变方案；             梳理产品框架：做完调研后，能够做到对需求有基本的感知，此时需要梳理做这个需求会涉及哪些内容、哪些相关方，理出框架；             设计详细的产品方案：在这个过程中还需要详细思考方案的可行性，与前文我在商家后台体验需求中提到的类似，不再赘述。              价格中台的迭代性需求          价格中台主要为C端各个业务场景提供价格计算的能力，这个模块的业务价值有两方面：1）保证所有场景的到手价规范一致，2）降低其他业务重复造轮子的成本。在这个模块中我主要负责迭代两个需求：1）迭代当前到手价的规则，2）统一当前商品tag的露出规范。          到手价规则迭代          需求背景          到手价用于为用户展示商品实际到手的价格，我们会在商品原价的基础上为用户减掉能够享受的优惠，目前首页、店铺、场次（电商平台中的会场，例如大促会场）和搜索场景均已接入中台，但商品详情页没有，并且我们和商详的计算规则存在部分不一致，导致内外展示的价格不一致。          到手价规则在我接手期间经历两次迭代：               预售商品的价格计算规则迭代：在三八预售期间，我们发现诸多商品在会场中的价格和商详不一致，会影响用户转化甚至引起客诉，因而紧急修改了这一块的规则；             商品多件多折、商品有单品促销且有会员价的计算规则迭代：后续微商详（可以参考目前淘宝从首页到商详中间的商品卡片流）重构需要接入价格中台，商详与中台的不一致会阻碍微商详重构的进程。              需求复盘          在处理预售价格迭代的需求的过程中，我主要承担沟通协调的工作，一方面是因为本身规则不一致的点并不难找，研发侧在线上case出来后就发现了不一致的点，另一方面是预售的需求是紧急处理上线，因而拉齐大家的进度，确定是否有其他bad case更为重要。          沟通协调在产品经理的日常工作中尤其重要，我从自身的经验出发，总结一下日常工作中如何沟通协调：               前提是了解要沟通什么：即有哪些事情/问题与谁沟通，首先要对自己接手的需求有所了解，了解后发现其中的相关方及需要与相关方确定的疑问；             对接不熟悉相关方前做好功课：如果遇到不太熟悉的相关方，尽量了解一下对方的业务或者准备好问题，否则和对方对接可能一脸懵逼；             一次沟通仅拉最需要的人：在找相关方时，我们有时会在一次会议中拉上全部，但部分相关方在一次会议中参与度并不多，这会浪费对方的时间，不利于后续的合作；             尽可能一次性解决：大家的时间都很有限，所以问题尽量一次解决，反复沟通不仅拖累进度，而且会让相关方厌烦。              在处理多件多折和单品促销有会员价的需求时，我的主要难点在于不了解现状，尤其是商品享受单品促销且有会员价的需求，我对后端会输出几种价格、每种价格的含义并不清楚，仅仅通过简单的看实际case并不能让我了解后端应该如何去修改。最后去处理这个需求时，我们和研发详细了解了当前价格输出的类型和规则，在这里不展开具体的类型与规则。          在前几天的面试中，我被问到如何从产品侧而非更改计算规则避免因价格不一致带来的客诉？这为我带来了新的复盘角度，即客诉问题的产品解法，这个问题我还没有很好的思考点，在这里暂不展开，欢迎朋友们指教。          商品tag收拢中台          需求背景          商品tag是用以展示商品或促销等信息的标签，如下：                     当前商品tag存在如下问题：               目前所有的tag是由后端输出，前端自行维护，导致各个场景下的tag露出规则不一致，并且后续如果有新的tag加进来，维护成本也会很高；             当前tag零散、没有分类，所有tag一起排优先级，如果有新的tag加入则需要重新再排优先级，并会出现部分tag永远无法露出的情况。              这个需求是由首页产品提过来的，但做规范需要推动首页、店铺、场次和搜索一起，并为所有场景指定一致的露出规范。          需求分析               目标：我们需要确定现有的tag在C端有到手价的情况下如何露出，是需要展示还是不展示，展示需要展示哪些tag；             需要做什么：梳理现有的tag，了解后端输出tag的规则和优先级，了解各场景的露出现状，最后制定统一的规范。              需求复盘          接手到这个需求的最开始我是毫无头绪的，甚至对于我要做什么不明确，与需求方对了三次才明确需求目标，之后调研了后端这里管理的所有tag和优先级，然后与其他场景的产品讲述需求背景、了解他们的看法和需求，最后理出了头绪。          但这个需求做完并不是全部，在梳理的过程中我发现tag的种类太多、也很分散，如果C端想要新增一个tag需要单独走排期，成本高、后续也不利于维护，因而将tag这件事收到中台一起处理很有必要。中台应该如何去处理呢，这里给出我的想法：                     首先是分组，之前的tag是按着预售、平台促销（其中包含跨店满减tag、跨店多件多折tag等）、店铺促销这样来划分，但这已经是tag维度，如果新增一个tag就又会作为新的分类和原先的比较优先级，因而在这一层之上缺少一个系统的划分，我这里简单看了竞品后给出以下分组：                                   然后是确定分组后输出的规则，组之间是否有优先级，组内是否有优先级，如何输出去能满足各个场景的需求：我认为可以在单个标签组内对标签划分优先级，并让前端感知优先级，在前端不做动作的情况下，按照默认优先级展示，但若前端有特殊需求，则可将标签组重新排序。                   营销中台的定位是将电商营销相关的底层能力都归结在一起，方便后续业务迭代、减少重复开发的成本，这部分需求为我带来的更多是长期价值的思考、与各方沟通协调能力的提升，由于这里的需求本身就足够复杂，因而我并未经手太多，做出的方案也较简单，直至目前，我对中台的理解依然是浅显的、模糊的，这是我离职后需要去多加学习与补充的点。              后记          三个月的实习期，我能够处理的需求不管是复杂度还是周期都有限，但通过这段实习我对电商营销有了一些基本认知，本篇仅是我对实习期间做过的需求、需求过程中踩过的坑就行复盘，后续还有更多有关电商的内容等待我去学习与输出（拖更警告）。          这是我的第二段产品实习，是严格意义上的第一份完整的产品经历（上一段由于特殊原因两个月不到就结束），因而我的思考和认知都非常浅层，也并无太多业务思考，这也是我未来需要弥补的点，非常欢迎各位朋友和前辈私聊或留言，为我提出更多建议~          附录          这里放上几篇与我需求相关的文章，供大家参考:           1.B端产品文案参考： B端产品文案指南           2.tag需求相关1：移动端UI一致性解决方案           3.tag需求相关2：闲鱼UI快速变形利器--擎天柱           4.tag需求相关3：O2O生鲜电商商品标签的梳理与优化           5.裂变券相关：淘宝裂变券文档