之前的文章有提到过，对于所有的需求谋定而后动。作为一名产品经理，需要经常思考如何让产品更好，但是产品是一个抽象的概念，而指标是量化的、可衡量的，所以如果要评价一个产品的好坏就需要抽象出评价产品的指标体系，比如C端产品常说的用户数、PV、UV等。因为本人是支付产品出身，所以以支付产品为例，分析一下体现支付产品核心竞争力的三个关键指标：1.支付成功率；2.资金处理的准确率和及时性；3.支付安全性
关键指标一：成功率
我们回想一下线下或线上的付款的场景，用户在买东西时挑挑拣拣，终于对商品的各项都满意之后，到了付款的环节。这个时候应该是立刻付款拿着商品离开。如果这时一直支付不成功，用户会立刻放弃购买。商家所有前期的营销，游说都将功亏一篑，为了让用户愿意买可能付出了100分的努力，但是只需要一个小问题都将让所有的成绩归零。所以成功率很重要。在这个关键问题上不要把我们内部处理的流程与支付流程掺杂在一起，先让用户把钱付了，拿着商品离开，后面再解决内部销库存、记账等流程。
影响支付成功率的因素很多，比如：业务结构的合理性，业务流程的完备性，异常情况处理机制完备性，各业务模块之间状态的一致性等等。在支付流程中，信息流和资金流是分开的，支付成功率一般指信息流。
举一个在产品设计中很容易被忽略的影响成功率的例子：「系统异常」
因为产品经理大部分时间的关注点是在完善产品功能，而且按照产品的发展进程，业务初期产品比较简单时，业务结构的划分也会相对比较简单，系统出现的异常情况很少。但是随着产品复杂度增加，业务逻辑和系统交互变多之后，系统稳定性成为了影响成功率的关键因素，这个时候之前欠下来的债就都会找上门，很多情况下也是因为处理各种异常情况忙得焦头烂额。似乎直觉上稳定性更多是技术同学需要关注的，产品经理可以发挥的空间有哪些呢？
1、定义异常，错误类型要定义的尽量详细，而且需要定义不同场景下的异常情况对应的解决办法，如果考虑的不全面很多业务异常提示都会变为“系统异常”，不明确的异常提示首先让用户不知所措，消磨了用户的耐心，其次让问题排查和解决都变得成本很高；
2、分类异常，把异常情况分为可系统自动补偿的异常、需线下运营的异常、提示用户如何操作的异常、技术异常，除了技术异常，其他的异常流程都是我们在设计产品，阐述需求的时候要考虑全面的部分，可能异常情况出现的概率只有10%，但是需要花80%的力气去处理。在支付业务中主流程做的再完美，如果异常处理不完善直接导致的是客诉增加，成功率下降，根本上影响的就是品牌形象和用户的信任度下降；
3、监控异常，对于所有的异常情况都要进行监控，不要让你的产品处于失控状态。一个异常如果出现的次数很少，当前的处理办法或者运营工具处理的时效性能满足需求，那么暂时不需要产品优化。但是如果一个异常频繁出现，而且对整体的成功率或者客诉率影响很大时，这时就需要考虑新的解决方案，一切纲领是目标。
其实「系统异常」是一个比较通用的例子，在具体的业务中还有很多围绕支付成功率在不断完善的地方，比如支付路由、收银台的友好交互体验等等，这些产品设计的目标就是提高支付成功率。
关键指标二：资金处理的准确率和及时性
刚刚说成功率主要是信息流处理流程，那么资金处理的准确率和及时性就是资金流的处理流程了。
之前大家应该都听过1分钱偏差导致大额资金损失的事例，可见资金处理的准确性多么重要。因为支付公司承载的是千万家企业的交易，那么如果流程处理不当，就可能会出现资金损失，毕竟支付公司一笔一笔赚支付手续费不容易，一次资金损失可能就是损失了几个月的收益。
资金处理的及时性更是建设我们和企业客户之间信息的充分必要条件，企业每天都有大量的资金在途，而且环环相扣，一个环节稍有延迟可能是影响了整个业务链条。
所以对于资金处理一定时时刻刻秉承着敬畏之心，每一次事故都可能成为客户流失的导火索。
关键指标三：支付安全性
支付安全性是指两个方面，用户的安全感和支付业务的风险控制，用户的安全感是在使用我们的产品时，产品本身给用户传达的，比如规范整齐的页面样式和给人安全感的颜色，关键环节的安全验证，明确的风险提示，都是在告知用户，产品本身是专业的支付工具，而且所做一切都是为了确保你的银行卡信息安全。
用户体验和支付安全本身是两个相悖的命题，为了体验好我们希望用户操作的步骤越少越好，少用说明性的文字，设计用户体验路径引导用户。但是为了安全我们要增加很多验证流程难免把操作流程拉长，而且在一些关键性环节增加安全提示。
所以在产品设计时需要在这两者中间找到一个平衡点，同时要在你收集用户任何信息时明确告知目的和用途，其实用户自身也是非常关心自己信息的安全性和支付的安全性。
这三个指标不是支付产品经理遵循的指标体系的全部，但是我认为是最重要的三个。不同的业务的指标体系大不相同，但是方法可复用。在设计产品之前，先建立指标体系，从时刻关注指标开始，优化战略和战术，不断自问如何提升指标。
最后，作为2B业务的产品经理，尽量熟知所有业务逻辑的细节（至少关键逻辑），否则将丧失对产品的全局把控力，这种情况下的需求分析将带有一定的片面性，输出的产品设计很可能因为思考问题不够清晰而导致更多线上的问题，直接影响的是评价指标。
