SAAS产品经理：用户要你加一个字段就加吗？

编辑导语：作为一名SAAS产品经理，如何通过用户提的“一个加字段”需求能全面做需求分析，给出不同抽象高度的产品方案？本文详细拆解了ERP SAAS常见的“加一个字段的需求”，以此来启发产品经理做到“以点带面，用标准化的产品方案来解决一类问题”。一起来看看吧。

在多年的ERP SAAS系统产品设计工作中，供应链产品老兵发现“加字段类”需求是非常多的，面对这类需求其实可以有不同抽象高度的产品方案。每种方案都无对错只有优劣，产品经理只需要结合实际业务、产品架构和开发资源来抉择哪种方案。

但是对于已经是从事供应链方面的产品经理三年以上的同学至少要能通过用户提的“一个加字段”需求能全面做需求分析，给出不同抽象高度的产品方案。

那么接下来我将详细拆解ERP SAAS常见的“加一个字段的需求”，以此来启发产品经理做到“以点带面，用标准化的产品方案来解决一类问题”。

一、业务场景

ERP系统中一个采购订单的新增页面，为了突出商品明细的字段，基础信息和供应商信息的字段原型我就省略了而是用了一个占位图代替。

假设目前商品明细中库存类字段只有“仓库合格库存”，销量类字段只有“30天销量”，有一天采购员小A给产品经理阿杰同学提了一个需求“在新增采购订单时商品信息那里，需要加一个字段【在途数量】”，那么面对这个需求的阿杰同学会怎样处理呢？

二、产品方案

1. 最爱是画原型

阿杰同学是一个非常实诚的人，能急用户之所急，于是马上写了一个需求并画出原型安排给开发宣讲需求，只见他在需求文档中写着：在采购订单的新增、编辑、详情页的商品信息中加一个字段“在途数量”，具体位置见原型 。

（1）优势分析

作为业务与开发之间的传话筒，把用户的需求直接转化为产品需求，高效率解决了这个问题。

（2）劣势分析

对用户提出的需求不怎么分析而是直接执行，导致用户后续对这个采购订单源源不断的提加字段需求，比如加“合格可用库存”、加“过去60天”销量等而没完没了。

有时候用户提出的需求不是真正的产品需求，产品经理是要深入分析的。如果在企业中产品经理不怎么分析需求，其实是可以不需要产品经理的，开发就可以直接面对用户。

（3）供应链产品老兵点评

这让我想起多年前我还在深圳做运营时候遇到的一个产品经理小姑娘，记得那时我作为运营提了一个需求就是要做官网，然后产品经理要我提供文案、UI稿、每个菜单的页面内容。我花了差不多2周时间提供这些给到她，然后看到她大概花了2个小时把这些用axure画了出来并提需求给开发排期。

那时我就在想既然做一个产品经理就是画原型这么简单，那我也去做，因为产品经理那时工资比运营高出差不多40%。

在互联网企业中目前还有相当一部分产品经理的段位处于这个阶段，即“需求方让我做什么就做什么，产品经理就是画原型的，剩下的时间就是和开发扯皮 ”。

这类产品经理在工作中最直接的表现就是“拿到一个需求不假加思索就去画原型，在原型中推敲逻辑，一旦逻辑改了就又修改原型，造成反复折腾原型”。

到此我不是批评这个段位的产品经理，而且我曾经也是这样过来的，就像射雕英雄传里头的郭靖一样是在成长中才练就绝世武功的。不过正是因为这个段位的产品经理太多了而且产品经理培训机构特别喜欢培训画原型，导致外界普通对产品经理的认知就是画原型的。

2. 能多想几点

此时阿杰同学在分析用户为什么需要加一个字段【在途数量】，其实是为了输入采购数量的值能合理，这就除了在途数量，还需要仓库合格可用数量、账面库存（仓库+门店的总库存）。于是在产品需求文档中写着要加这三个字段。

能通过用户提的一个需求，诊断出需求背后的业务场景，想到用户没想到的，这已经是一种进步了，已然入门到需求分析的段位了，如果不是做SAAS类产品这样已经能让需求方比较满意了。

（1）优势分析

能通过用户提的一个要求，诊断出需求背后的业务场景，想到用户没想到的，这已经是一种进步，已然入门到需求分析的段位了。如果不是做SAAS类产品这样已经能让需求方比较满意了。

（2）劣势分析

分析的不够全面，其实用户为了做到采购合理的数量，核心是要参考仓库有多少库存、各门店总的/分开有多少库存、过去销量情况、库存上下限情况、历史采购记录，这样一分析就是需要加二三十个字段的。

因此这个方案还是没有彻底解决这个问题，做为SAAS产品同一类问题不同用户或相同用户后续还会反复提加相关字段的需求。

（3）供应链产品老兵点评

做供应链产品经理与2C的产品经理，最大的内核区别就是要“实事求是从业务中来到业务中去”，从这个产品方案可以看出阿杰同学已经知道了从一个需求点上开花多想几个点成一条线，但还未做到以点带面做全面的业务需求分析。

或许是对需求的本质（采购数量根据什么来判断）还没看透，又或是思维中的全面思考的角度还不够。

3. 能想到一个面

阿杰同学经过全面的需求诊断后，发现用户本质需求是“采购数量要根据哪些字段来参考”，这样得出的结论是需要加二三十个字段，如果都加到采购订单的商品明细中是不行的，因为会导致商品明细字段太多用户查看起来非常麻烦。

于是阿杰运用抽象思维在想，能不能抽象出一个组件，这个组件里头都有这些字段。于是阿杰在需求文档中写下了这个需求“封装三个弹窗，分别是采购入库记录、库存汇总、库存批次明细，在商品明细行末尾操作栏用户通过按钮点击可分别打开这三个弹窗查询相关数据”。

做了这个需求后阿杰发现对于采购订单的明细信息这块，用户基本提不出加字段的需求了，因为其需要参考的字段都给加了。

（1）优势分析

此需求从用户提的一个需求中深挖出了一类问题，用标准化的方案解决了这一类问题，产品经理阿杰已经初步具备了全面分析业务的能力，也能抽象出标准化的解决方案，做SAAS产品能做到这个份上相当于就是既解决了这一个问题、也解决了其它用户未提出的需求。

这样就不需要客户就一类问题反复提需求了，非常容易获得客户的信任。

（2）劣势分析

思维受限于采购订单这一个面，没有想到其它库存查询页面、配送单、门店请货单等单据也是需要这三个按钮弹窗的，也就是说缺少整体架构思维，还不能做到结合整体产品架构来做需求，用大白话讲就是还缺少全局观。

（3）供应链产品老兵点评

一个产品是有架构的，就好比一个正方体有六个面一样，如果做产品设计除了能立足于一个面外还能全面考虑，那么就非常不错。

以这个例子为例，如果只考虑采购订单这一个面，那么其它库存查询页面和相关单据的用户也会提出这一类问题，到时后又是要相关产品经理做需求分析，甚至会造成重复造轮子资源不互用，因为做SAAS产品是要考虑方案互用的、这样开发成本才能减少。

4. 能全面考虑

阿杰同学比较熟悉业务，除了知道在采购订单商品明细中用户需要查库存汇总、库存批次明细、采购入库记录，还知道在以下场景中也需要，即“缺货记录、库存相关报表、配送单、门店请货单”等，于是他协调负责这些业务的产品经理把这个标准化的产品方案完美落地。

如果在企业中做产品经理做到这个份上那是非常不错的，因为不仅能全面分析业务还能全面设计产品，做需求时能考虑到产品架构，而不是那种“别人负责的模块和我没关系，我管好我自己就行了”。

假设不这样做就会导致同一类问题，不同的产品经理重复造轮子，而且每人造的轮子质量或风格还不一样，这样就会导致系统反复被打补丁。这就是所谓的用标准化的产品方案解决同一类问题，而让用户或需求方此后提不出问题，如果是做SAAS产品这样的方案是非常有价值的。

5. 能驱动业务

到了这一段位阿杰已经按照上述全面考虑的方案做了，但还觉得不够，他在想用户手动做采购订单主要是根据经验和客观数据来判断哪些商品要采购、采购多少数量、采购价是多少、找哪个供应商采购合适。

如果系统只是满足这基本的做单需求那么系统本质还是一个工具属性，而做SAAS的产品本质是提供行业解决方案，哪怕一个小需求也是一个行业解决方案。

想到这里他立即兴奋了起来，心想如果能做一个智能采购的算法模型出来辅助采购员做采购，那岂不是锦上添花。于是花心思与业务专家研究了行业内的诸多算法模型，然后予以算法模型产品化。

这样其实就相当于是到了产品经理的高段位了，到了这个段位的产品经理能做到驱动业务，也就是不仅仅能诊断出业务问题，还能驱动业务上的人和事怎样高效率地做。

这个段位是与行业沉淀有关系的，即使你是从某超级大厂出来的产品经理而非同行业也是很难短时间内达到这个段位。

也就是说做产品经理不是每一行都相通的，你在这一行是产品专家可能到了另外一个行业你就是学生，如果你不承认这一点那就很容易在企业中把产品搞砸，特别是做供应链相关的SAAS产品。

三、总结

在供应链相关的产品实际工作中，加字段类需求非常常见，上面五种方案每一种都会有客观存在，每一种方案背后的产品经理其实是处于不同的产品段位的，并不是能力不行。每一种产品方案都没有绝对的正确或错误，只有优劣之分，只是在实际工作中需要结合业务场景、产品架构、开发资源、商业价值来判断具体选择哪种方案。

还有每个产品经理也可以客观面对自己的段位，没有谁一参加工作就是武林高手，都是一路实践出来的，特别是供应链一定是实践出来的不是培训出来的。

但如果是做供应链相关的产品特别是SAAS产品，一定不要把自己混成“产品经理就是画原型的”，而是要全面分析业务，深挖业务场景，然后予以行业解决方案般的产品方案。

当然这一切都是基于熟悉业务，如果不熟悉业务就算你掌握了大厂出来的各种大佬专家的产品经理培训课程的方法论，估计也是只能做到“能多想几个点”这个阶段。所以如果你是即将转行供应链产品经理或者已经入门，希望能沉静下来实事求是多研究业务积累业务场景。

 

作者：产品老兵；微信公众号：供应链产品老兵

本文由 @供应链产品老兵 原创发布于人人都是产品经理。未经许可，禁止转载。

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