惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

雷峰网
雷峰网
B
Blog
博客园_首页
云风的 BLOG
云风的 BLOG
S
SegmentFault 最新的问题
罗磊的独立博客
Jina AI
Jina AI
C
Check Point Blog
Martin Fowler
Martin Fowler
J
Java Code Geeks
博客园 - 司徒正美
美团技术团队
MongoDB | Blog
MongoDB | Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
大猫的无限游戏
大猫的无限游戏
有赞技术团队
有赞技术团队
U
Unit 42
Hugging Face - Blog
Hugging Face - Blog
WordPress大学
WordPress大学
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园 - 叶小钗
博客园 - 三生石上(FineUI控件)
小众软件
小众软件

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
同一个方案,一个值5毛,另一个却值100万
陈天宇宙 · 2024-07-15 · via 人人都是产品经理

本文通过一个银行收单业务的案例,深入探讨了如何在面对需求时进行评估,并制定出既能满足业务需求又具有战略价值的方案。文章指出,即使是相同的方案,不同的出发点和定位会导致其价值大相径庭。

产品方案,就这么轻微地一调,蹭蹭蹭,价值就上去了,这是产品绝杀技。

当需求来了,如何评估需求,要不要接这个需求,为什么要接,接了打算怎么做,为什么这么做,都是门道。

我们就借一个小案例,聊聊这个门道。

即使是同一个需求,同一个方案,出发点不同或者说定位不同,它的价值也将截然不同。

北京线下班课间,一位朋友跟我聊了一个她当前面临的“刁钻需求”,之所以说“刁钻”,是因为她觉得不该做,但是又被需求方骚扰的实在受不了,不尽其烦,但是又没有足够的理论支撑和办法去说服和拒绝需求方。

这是工作中常见的困境,不想做,又没足够的论据去拒绝,做吧,又感觉会掉坑里。

她的场景是这样的,她们是一家银行,做收单业务,当前给商户的结算是根据成功的订单,但是经常出现长款,也就是清算机构清给他们的多,但是给商户结算的少。

这里有很多原因,比如因为自己系统不稳定造成的平台掉单。

出了长款怎么办呢?她们财务就给商户补款,补来补去,烦了,非得要求他们做一套对账体系,而且是“先对账,再结算,给商户结算准确的渠道清算结果”。

这个需求初看没什么问题,再一看好像还是没问题;不过在场的很多人都觉得有问题,大家觉得对账肯定要对,但与渠道的对账不应该影响给商户的结算。

单挖问题的本质,其实是银行系统不稳定造成的,并不是对不对账造成的,如果要治本的话,应该优化收单系统,但是,这也不是一朝一夕就能解决的,需要很长一个过程。

财务头疼医头也可以理解,但是即使对账上了也会带来新的问题和风险,比如对账做的不好,到了给商户结算的时间点时依然没有完成对账的全部处理,你说要不要结算?

结吧,账还没对完,不结吧,商户能答应么?商户会骂娘么?为什么你们银行总是不能按点结算呢?

不做也不是,做也不是,该如何是好。

究竟该不该先对再结呢?一般情况下并不建议这么做,对和结还是要独立分开,避免与上游渠道的纠缠影响与下游商户的良好关系。

但是,对于银行来说,你老是结错,每次都给我补账,是不是你们不行啊!其实丢钱是小事,商户对你失去信任是大事,特别是银行,信用比天大。

特事特办,既然现阶段咱系统不是很强,那就不能中规中矩,必须出奇制胜,剑走偏门,咱就先对再结算,这样,不就保住面子了么。

话说面子都是自己挣的,你先对再结,如果不能按点结算,不照样丢人吗?

这就是上面这位朋友的困境,做也不是,不做也不是。

不过在我看来,困境还有另外一层,做,好像是财务逼你做的,并不是你的初衷,等再换一波财务就可能觉得“你怎么能先对再结呢?”,你不就掉坑里了么。

需求可以做,但不能为“某个部门做”,不能因为她强势你就做,不然,回旋镖早晚会打到自己,所以,我们一定要将价值,转换到公司价值层面,这样,不会因为团队变化而峰回路转。

那么怎么把“先对再结”转换到公司价值上,得到一个无法被拒绝的理由,而值得去做呢?我们要从痛点出发。

  • 一痛:业务痛,收单登记总是不准,总是有长款,我们需要能够及时发现并调整长款,所以,我们需要对账,确保平台的收单记录准确。
  • 二痛:商户痛,对商户来说需要给我结算的准确,不能总是调账,不然我跟你合作心里不踏实,我们自家的账也得跟着你不断地调,不仅要准确,还得按时,不然就太难受了。
  • 三痛:银行痛,而银行自己呢?就是“面子”,面子上挂不住啊,信用受损,品牌力受到影响,无论是结算的不准确还是结算的不及时,都会伤面子。

以上三痛,就是“数据准确、商户体验、银行形象”,三个方面的痛,要想解决所有痛点,皆大欢喜就需要。

通过对账确保数据准确,但又不能影响商户按时结算,从而维护银行形象。

先对再结,虽然结算准确,但有可能不能按时结算,进而影响商户体验,损害银行形象;如果不对就结,虽然结算及时,那就会结算的不准确,也会损害银行形象。

这也不是,那也不是,难道就没有解法了么,肯定有,价值百万的方案来了:即能确保数据准确,又能确保按时结算,同时还能让银行保住面子。

为了数据准确,我们要先对再结;为了结算及时,我们要预留阈值,到点结算,也就是到点你对不完,不好意思,我先结为敬。

这个方案另一个妙处是,不一口吃成个胖子,也不躺平做咸鱼。

有多大能力,解决多大的问题,能解决多少解决多少,先对起来,确保结算准确;但是早期对账能力不强,我们还保留原有结算模式,确保按时结算,但是我们要不断的提升对账能力,逐渐降低超过结算时间而对不完的发生概率,直至100%的结算是“先对再结”。

等到有一天,我们的收单系统能力提升了,能做到100%准确,那么再“对·结分离”。

合为了更好,分也是为了更好,只不过,在不同的时间,有不同的选择。

为了财务而做,只值5毛,为了公司而做价值100万,产品价值观不同,结局截然不同;格局打开,蜂蝶自来。

本文由人人都是产品经理作者【陈天宇宙】,微信公众号:【陈天宇宙】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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