产品总计：关于业务端产品的几点看法

作者：和光同尘

全文共 5487 字 4 图，阅读需要 12 分钟

———— / BEGIN / ————

很久没写东西了，最近也在读一些书，作为入行六七年的产品人，经历过创业公司，也经历过大公司，看了不少大牛们写的文章，再加上最近正在往增长方向转变，也在梳理最近这些年自己的一些成长与经验，借此机会正好将所得的一些感想与大家分享。

一、何为业务端产品？

实际上我们经常听到的产品莫过于两类，C端产品和B端产品，对于C端产品，大家很容易理解，就是to Consumer，面向广大的消费者/个人用户，比如微信、淘宝、美团，而对于B端产品，to business，字面上理解，是面向企业或商家，比如钉钉、阿里云、美团外卖商家端。

一般来说，公司内部的系统产品我们也会称之为B端产品，比如内部ERP、CRM、财务系统等。

但实际上对于很多以业务为导向的公司来说，像京东、人人车、顺丰等等此类公司，由于其业务链条过长，占比较重，一般也会把支持全业务流程及各业务线的产品叫做业务端产品。

二、业务端产品特点

对于业务产品来讲，其目的是为内部人员提供便捷良好的工具，提升业务运行效率，提高业务转化，最终达到提升人效、降低公司成本。

流程

对于任何一款业务产品来讲，契合业务运行的产品流程是根基，而流程的线上化是业务得以快速高效开展的保障。

在搭建产品流程时，一方面需要审视当前的业务流，另一方面需要考虑未来的业务走向，提前考虑到流程可能的延伸点。

另外，可采取主流程先行，次流程后进的方式，保障业务能提前及时落地。

效率

效率是业务产品的核心指标之一，比如销售的接单率、客服的电话量、编辑的审核时长等。

一方面，业务流程的线上化在整体上能提升业务运行效率，另一方面，在逐步精细化提效上往往会需要一些工具的支持，比如报表。

转化

对于涉及到销售环节的业务产品，比如crm，不断提升转化率是产品的终极目标，如何帮助销售更好的跟进线索、管理客户、推荐服务，是产品经理需要关注的关键。

转化环节往往会涉及到一系列策略，如线索分级、客户分配、跟进策略、推荐策略等，对数据的关注须更强烈。

体验

业务端产品同学经常听到开发同学的一句话就是：这个是给自己人用的，体验差点没关系，习惯了就好。

对于不那么严格的产品经理，往往也就妥协了。

产品体验分为两类：UI体验和操作体验。

一般来说，UI体验对业务效率的影响不大，反正是自己人用，丑点就丑点；但操作体验的影响却不可小觑——少一个筛选，少一条快链，对业务人员来说可能就增加了很大的操作成本。

成本

降低成本是业务产品的终极目标，不论是搭建线上化的流程，提高业务的运行效率，还是提升销售转化，其最终目的都是在降低业务成本。

业务产品经理经常会觉得自己做的是业务产品，不太会带来收入。但公司的收入其实来源两端：外部开源、内部节流，而节流就是业务产品的核心所在。

产品经理对效率、转化等过程指标的关注可以转化成人力、线索的成本数据，从而与公司业绩挂钩。

三、业务产品架构设计

我们都知道，产品设计三件事：搭架子、定流程、抠细节。

其中，搭架子是整个产品工作过程中最先做也是最重要的工作，尤其是对于创业期从0-1起步的产品，产品设计者需要深入如理解业务的现状及未来发展方向，去理解用户不断变化的需求，去理解公司的整个战略布局，从而搭建一个基于现有业务体系并兼容未来业务不断扩张的产品生态体系。

思考

产品的出现是为了解决业务问题，其本质是为公司业务服务，因此，在搭建产品架构时，需要详细了解公司商业模式，当前及未来可预见时期内的运营模式，不同的商业模式对产品的需求也不同。

比如同样是电商，C2C与B2C相比，产品就需要增加考虑买卖角色、功能、数据等。

而基于公司的发展阶段，运营模式也会逐渐发生变化，比如初期业务流程可能简单，但随着人员、角色的增加，整个流程管控体系也会增强，产品流程也会日趋复杂化，这些都会涉及到后续产品流程的深化。

沟通

在确定公司商业模式后，需要与业务方沟通清楚业务的运行方式：

产品有哪些人在用，不同角色的层级关系、不同层级对应的权限关系；

我们的客户是哪些人，用什么方式注册，客户会有那些信息，会在我们产品上留下哪些数据，我们想获取用户哪些数据；

我们的使用场景在哪、业务流程是怎样的、是否会有多业务线···

设计

在真正搭建产品框架时，你需要将所获取的信息体系化，从角色、用户、流程、功能等各方面去描绘，前期更重要的是对主流程的考虑，细节方面可以先放下。

另一个重要的点是确立架构后需要与技术人员沟通，防止技术上出现可行性问题（至少保障初期可行）。

我记得当时进上家公司之前，业务刚起步，在简陋的会议室，CTO跟我详细的介绍公司的模式，愿景、业务现状，我们俩在白板上一遍又一遍的讨论产品流程、功能框架、时间周期等，实际上产品架构正是在这种基于现有及未来业务的预期上讨论规划出来的。

四、需求管理

1. 需求来源

业务需求

作为业务端产品经理，你会发现：自己一天的工作，不是在写邮件、写文档，就是在与业务方开会，或者去体验一线业务流程。

发现业务问题，来自于业务环节的需求占了业务端产品需求的很大一块来源，这也是业务端产品的主要日常工作——因为业务产品的价值就是为业务服务进而推进业务增长。

数据反馈

数据的重要性无需多说：产品经理一天的工作往往是从看报表开始，产品的价值只有通过数据才能反馈出来；而数据也能更好的支持产品经理去分析产品/业务的的各项表现，发现并解决问题；因而，基于数据分析发现问题给出解决方案从而推动产品的优化也是需求的另一大来源。

问题导向

当产品的流程框架打磨完成之后，后续推动产品不断完善的着力点主要有两个：一是数据，二是用户反馈，用户产品在做用户反馈调研时，一般会采用两个方式：

1. 收集在线用户反馈，如在线客服、问卷等；

2. 产品可用性测试。

而对于业务产品，一方面要倾听一线业务人员的反馈，另一方面要主动去发现客户的抱怨，防止业务人员传达失真。

而基于业务人员及客户反馈产出的优化点，也是需求的一大来源。

2. 如何判断需求的真伪

考虑到业务产品经理经常会接到来自业务部门多方面的需求，因此对需求真伪的判断尤为重要，对于如何判断需求的真伪，很多人也总结了很多不同的方法，不过最常用的还是雷达法。

我们将对判断需求的不同价值维度列出，并对维度赋予不同的权重，再用这些维度对需求进行打分，再将不同维度的权重分加总，就可以得出需求的总价值分。

如下，需求价值总分=5*25%+3*20%+3*10%+2*15%+4*30%=3.65，而我们需要设置基础分，如高于3分意味着需求达到了需要考虑的程度，则该需求明显需要加入需求计划。

3. 如何判断优先级高低

对于优先级的判断，方法更是纷繁复杂，诸如KANO模型、矩阵分析法、经济收益法、核心用户优先···

我一般采取的方法就是矩阵分析法，对于经常面对一堆项目需求的业务产品经理来说，矩阵分析法清晰明了易用可靠：

五、与业务方的协作

我们是一个团队

面试过很多产品经理，整体来讲，业务端产品不如用户端产品积极、主动，甚至聪明程度上也稍差一些（不知道会不会有人想喷我）。

这其中主要有两个原因：

1. 业务端产品经理缺少对数据的关注度

2. 业务端产品经理总把自己当成一个需求的被动接收方
   

对于业务产品经理，大家会发现：一般是业务人员发现业务问题，向产品提需求，然后产品经理翻译成原型+需求文档，转给技术开发。

在这其中，业务产品经理实际上只起到了一个可有可无的传达者角色，并没有真正发挥自己的作用。

实际上，作为产品经理，我们与业务方本质上属于同一个团队，都是为整个业务的增长服务，只不过工作的侧重点不一样。

因此，我们应该积极主动的去接触一线业务，去发现业务运行过程中存在的问题，去思考产生这些问题的原因，去想办法如何帮助业务人员解决这些问题；而不应躲在业务人员背后，等待着业务同学来反馈问题。

我记得在上家公司时，我们跟着业务同学跑一下，和CC一起打电话，和评估师一同验车，和销售一起带看，晚上销售开会，我们陪到深夜，一起讨论业务中遇到的各种问题，一起沟通不同场景的用户反馈···

因为我们是一个团队，只有真正深入业务才能更好的给出产品解决方案。

一切为业绩服务

很多业务产品经理，对业务人员往往比较轻视，认为我们是在帮你干活，却不知一线业务人员才是公司价值的创造者。

对于以业务为导向的公司，一切产品、技术、财务、行政、法务···都是为了业务增长服务；对于产品经理来说，如何更好的发挥产品角色，为业务提供更好的产品，更完善的流程，更高效的操作工具，才是最应该考虑的问题。

所以，对于业务人员，产品经理应该主动学习，积极合作，共同为提升业务服务。

六、新业务的尝试

对于很多创业公司来讲，尤其是O2O行业，由于业务规模扩张的需要，经常会设立一些新项目，为未来的业务方向试水，而很多时候，这种尝试都会涉及到线上产品的支持。

那么，在面对新业务尝试时，产品经理应该怎么去协调产品在新项目中的定位呢？

要清楚认识项目的性质

一般在设立新项目时 ，项目负责人都会拉相关各方开会讨论项目的背景、定位、目标、时间点、涉及范围及具体流程等；这时，作为产品经理，你要能清楚的判断：该项目在公司/部门中的重要性，是否是核心业务，是否是未来业务方向，能给公司带来多大的价值，项目的紧迫程度等——因为只有了解了这些，你才能更好的判断在该项目上可以投入的成本有多大。

仔细评估新业务需要产品支持的成本及优先级

在详细了解项目具体范围及流程的基础上，产品经理需要能结合产品本身，做出判断，该项目可能会涉及的改动点，大概的改动成本及优先级。

优先级的判断是基于你对项目流程的了解，并结合当前产品流程综合判断的。

比如是否缺少某些功能项目就无法顺利往下走，或者会很大程度上影响项目的效果，则该功能的优先级就会更高点；而对于一些体验问题或者前期人工操作可以暂代的功能，则可以稍微延后一点。

兵马未动粮草先行

当产品支持因为工作量或者优先级短时间内无法保障时，可以先通过线下方式将业务跑起来，当产生一定效果后，再基于实际的流程经验予以线上化。

这样一方面不会打乱正常的产品排期，降低不必要的风险，更重要的是可以加快落地速度，并可以结合线下实操给出更有效的产品方案。

七、执行、执行、还是执行！

在面试产品时，我一般会从这几个维度来评价候选人：行业经验、个人特质（是否聪明、价值观是否契合）、执行力。

有一句话叫做，一流的创意加二流的执行 不如 二流的创意加一流的执行，执行力的强弱，在很大程度上能决定产品/项目的成败，对于产品经理尤其是业务端产品经理来说尤其如此。

业务产品本身的性质决定产品经理需要强执行力

业务产品由于面向的是公司内部各业务线，涉及到的角色与部门众多，这就要求产品经理能积极主动的去协调各方：既能游刃有余的沟通各方需求，梳理跨部门/角色的业务流程功能，又能在遇到问题时及时响应处理，灵活应对。

如果没有强大的执行力，产品经理是很难推进产品的正常进展。

用户产品的好坏看运营效果，业务产品的好坏看执行效果

对于用户产品来讲，其面向的是广大普通用户，产品的好坏可以直接基于用户运营数据分析出来。

对于业务产品来讲，由于其面对的是公司业务部门，产品只有在业务部门强力的配合执行中才能体现其真正的价值；而如何推动产品的落地使用，是摆在产品经理们面前的一道大难题。

一般来说，业务人员在初期对系统往往会产生一种排斥心理，挑出各种使用不顺手的毛病。因此，产品经理需要强力且有技巧的去推动产品在一线业务的落地执行，并且深度参与，跟进执行效果，这样才能更好的了解产品的使用反馈，推进后续的优化迭代。

而从个人能力来看，不管做的是什么产品，也不论是否产品经理，对于任何角色，执行力都是一项必不可少的标准，一个再聪明的人，如果没有执行力，也只能纸上谈兵，毫无作为。

八、数据的重要性

对于我们大部分产品经理来说，上班的第一件事就是打开邮件，看各类数据报表，数据是反映产品真实状态的最好方式，对数据的敏感性是产品经理最基础的要求。

产品经理日常关注的数据主要包括两类：

• 业务的整体运行数据，比如注册数、DAU、订单数、销售额···，具体数据指标跟公司的实际业务有关

• 产品的各项运行数据，比如各环节的转化、新功能的数据表现等等

对于业务运行数据，一般与公司的核心业绩指标相关。

这类数据有助于产品经理了解整体业务进展，尤其是对于实行OKR导向的公司，核心业务数据一般都会对产品经理的产品决策与排期产生影响。

比如当你看到业绩数据落后于OKR时，你需要想办法调动资源去迎头追上，否则有可能完不成目标。

而对于产品的各项运行数据，则是产品经理重点监控对象。

对于如何对产品进行数据监控，则需要做好以下几步：

• 确定监控目标。如需要监控一个新上的外部引流渠道的数据表现

• 确定监控数据。如该渠道带来的PV、UV、注册、下单、销售额、APPU值等

• 确定每个数据的意义及正常范围

• 考虑异常监控

通过以上步骤，建立起对产品的数据监控体系，而对于报表的提取，一般来说很多成熟的公司都会有自己的报表工具，比如BDP、Tableau等，很多产品经理自己也会去跑一些简单的SQL，一方面能快速获取数据，另外也可以减轻开发的工作量。

总结

文章写了两天，花了一个周末的时间，仅仅为作者个人这几年的感想，跟大家一起分享，后面也会陆续写一些关于如何防止采坑，敢于产品增长方面的文章，希望与大家一同学习。

———— / END / ————

作者：和光同尘，产品一枚，微信公众号：鸦口无言。

本文由 @ 和光同尘 原创发布于人人都是产品经理。未经许可，禁止转载

点击“阅读原文”下载APP