切域名了，这是starfury.tech最后一次RSS更新
看到不少Inoreader来源的朋友，期待保持联系，欢迎订阅新站RSS

半年前实在受不了百度的广告，动手给自己写了个chrome插件，到今天无推广的情况下有2万周活，也算完成数字目标了。虽然这数字有点水分，比较容易达到，了解插件的具体形态就知道了。

其实很不想写总结的，标题名字唬人，但这玩意吧，远没到我预期中的样子，价值也不大。
但第一次走过段历程，自己该回顾下，可能对还在起点徘徊的朋友有些参考。更想抛砖引玉听听更成熟的意见。

还是再啰嗦下，降低对本文的预期：
如果成功打造独立产品是100分，那目前只到5分。如果到达5分有10种路径，那我只经历了其中一种。以下灵魂画师示意：

中间有些启示和疑惑，文章有点长，我相信对还在起点的同学，会有一些参照价值。
同时也抛砖引玉，如果有站在终点的同学，愿意分享更成熟的经验，那就更好了。

初心与行动：以自己需求出发

为什么做这个插件？我在插件的介绍里写了

百度在可达性和中文资源上有一些优势，有时避免不了用百度。但界面太脏太乱，“脏乱”的背后是大量注意力干扰。
所以某个下午不忍了，动手做了个插件 （后端技术管理，做前端开发有些挑战）…

• 需求还是很明确的，开始试用过一些插件，都不满意。
  • Stylus/油猴强大，但在百度适配上没有满意的，且Stylish曾大规模售卖用户数据让我担忧。
  • 一些针对百度专项优化的小插件，chrome/edge商店里但凡能搜索出来的，都试过都不满意。

无奈之下，打开vim、打开chrome开发者文档，翻着Javascript教程从零开搞，到了今天。

这里第一条的感悟：
作为大厂呆久了的技术管理和架构师，我听过无数宏大的PPT和“叙事”，甚至我有小半的工作就是思考规划。
脑子里也习惯性的把事情想得很大很多：它得让人激动、商业模式得清晰、产品要解决痛点痒点…
但辗转徘徊于各类想法之后，还是在原地没有动手。

一步不走，可能脑子里已经把所有流程都想完了，甚至能侃侃而谈了。
但几年后，可能还没走完一个最小流程：创意、原型、研发、推广、运维。还是纸上谈兵。

启动这事，可能没有那么多准备和仪式，可能就类似这次无奈之下的琐碎原因。

怎么启动？首先面对就是挑选需求，要解决什么问题。
这块是最难的，我在《给缀学者的信》有章节描述：发现问题的能力，才是当代最稀缺的能力之一。
虽然文章里侃侃而谈，但我过往并没有成功的经验。

以这次经历来说，我会建议如果没有洞察到好的需求。那就先以自己为目标客户，先解决自己的问题吧。如果我越普通，那理论上我所面临的问题受众越广，至少它不会是一个伪需求。

从宏大的故事中脱离出来，以自己为目标客户挖掘需求，走一个完整的流程。
这是第一段我想分享的。

信心与定力：一半海水一半火焰

上面讲了起点。这段讲讲，站在当下的一些感受和疑惑吧（过程也有意思，放后面章节）。

站在当下，我其实有两条看似有些矛盾的感慨，但其实并不冲突。

1. 但凡是真实的需求，再小再简单，只要用心做，一定会有人用
2. 一个产品的天花板有多高，有90%是在选定需求命题时就已经决定了

一、但凡是真实的需求，再小再简单，只要用心做，一定会有人用

在过程中，我对于会不会有用户，信心是非常反复的。
特别是进入繁琐的测试阶段时，无数次质问自己：“这玩意儿会有人用吗？”，在大厂都是THINK BIG呀。

但站在今天，确实有人用，不少用户通过邮件提需求。只要不是伪需求，做好，多多少少是会有人用的。

过程中为了适配足够多的卡片和端，确实有一点跟CSS有点卯上了，费了些劲。
这东西本来场景就小，如果适配问题还多的话，我自己都不会用。投入了些心血，也因此觉得会比之前试用过的插件，都好一些（吧）。

二、一个产品的天花板有多高，有90%是在选定需求命题时就已经决定了

这点是让我纠结的。确实有人用，但如果命题只在百度首页和搜索页优化，那这个产品的PMF是非常低的。
即便打磨到极致，似乎也难以有更大的价值作用。

这是目前真实的、没解决的疑惑，不隐藏。
现在是想试试放大命题，从页面优化这个命题，回到阅读注意力、信息源这个问题上，应该会有更大的PMF空间。

虽然我相对认可启动和经历的整个过程，但在当下你问我信心如何，确实是一半海水一半火焰。

从不懂前端开发，到2万人在用，给了点信心：如果找到真实需求，我是可能把它搞出来的，无关技术栈。只要是需求，搞出来肯定会有用户。

但选题这个事吧，太需要洞察力，难破题。否则很快就到天花板。

原则很重要：你要决策很多事情

既便这么小的插件，要决策事情还是很多，举简单的例子：搜索框要不要展示以图搜图按钮？

我喜欢简单，所以开始把首页的除文字搜索等无关的元素全部隐藏了。
但一天用户说希望把以图搜图的小按钮展示出来，犹豫了很久，做不了取舍。
最后回到要解决的问题原点：我想百度的搜索过程更加专注，但并不能以破坏主要功能为代价，否则那是花瓶。

然后我就定了条原则 在不破坏主线功能的情况下，提升搜索体验，排除干扰，最后才满足个人喜好
在这条原则的指导下，后续每遇到类似问题都能快速决策：

1. 搜索页工具栏是否展示：有按日期搜索等重要功能 – 展示
2. 登录后是否展示头像：一旦用户登录百度，代表其习惯使用登录服务，头像按钮可进入重要功能区域 – 展示
3. 搜索框无字模式：不影响功能，多数人潜意识里知道是搜索按钮;对专注度影响不大;满足个人简洁喜好 – 无字
4. 配置按钮要不要动效：不影响功能；但浮夸的动效可能引起不必要的注意力而产生打扰 – 去掉

再小的产品，要决策的点也很多，而原则是最高效的决策工具。
另外我们不是神，定的原则可能会错，甚至上述事例决策可能都错了。但比起随机决策，用错误反馈去持续修正原则，让原则越发准确，会让事情变得可迭代、可持续。

也通过另外几条原则，也帮我决策为什么不推广、为什么不加广告、每个版本到底框选哪些内容… 这些后面会讲到。

上架与迭代：有些事比你想的简单

当完成首个版本，极其简陋，朋友看到了想用。我想发到Chrome Store上，也好奇的想探探后续的流程。

从开始有想法去上架，到最终上架，间隔了45天，为什么呢？
我心理认为上架是个很麻烦的事情，要注册开发者、付美金认证、要填写一堆资料、做头图、审核…
是的这些流程很复杂，一想就头痛，事实上最终也确实是不步不落的走完了这个流程。但过程耗时只用了3小时。

用45天去犹豫，一件3个小时可搞定的事情，不是心思缜密、也不是惰性，就是犯了高估问题的毛病。

人对的关键目标，容易看得很重要，心里把它描红加粗，但并不代表它麻烦，可能击破就在一瞬间。
有些事心里障碍远大于实际困难。

如果只是一个例子的话，也不想拿出来说。但这个过程中遇到多次。
还有一次，我完成了window/linux/macos * chrome/edge * 黑白模式 * 登陆态非登态多个版本的适配研发，光听就知道测试得脱层皮吧，那这多组合还得找好多虚拟机。
我推迟3周，理由是“得找个好时候来搞”。后面实在觉得不能拖了，晚上用3个小时完成了全部的测试。又一次犯这样的错。

人在做未尝试过的事情时，多多少少会从心里放大困难吧，不知道大家是否有类似的体验，我后面应该还会犯，但知道了也就不那么怕了。

不推广：狭窄领域，让产品力自己发酵吧

第一个版本上后，我天天想着怎么让别人来用。
但在被zaker、appinn、少数派等网站浅浅的推荐后，现在天天想：大家先别用，再优化下才能见人。

现在有些矛盾，一方面比百度专项优化插件的话，自信是远比目前商城里搜索”百度”靠前的插件好用的。 但另一方面，我是真不满意，应该要做得更好。

这是一个很狭窄的领域，没有什么竞争。
原则上应该专注提升产品力，让产品力会自己发酵，去够到足够多的用户。如果够不到，那肯定也是产品力本身的上限问题。
（如果做的是高竞争的领域，那不适用这个原则）。

上述是正向的原则，但这个过程中也有一点点负面情绪。
我很少去主动推广，主要是靠推荐，甚至边商城建议我优化关键字以保证能命中，这么基础的动作我都不愿意做。
越到后面反而越怕，我总觉得”这真不行，没啥用处”。即便好多用户发邮件来感谢，我还是这样觉得：向上够不到油猴，向下优于同类专项组件但并不是大步领先。

既怀疑这产品太鸡肋，也怀疑是心态有问题。

纠结，但确实就是目前的状态，分享出来。

不挂广告，不是体不体面的问题

设计配置界面时，留了个心思，一个是弹出配置页面，少量快速配置；一个面板配置页面，主题详细配置。

这个设计其实是希望给自己带来的流量：把第二个面板配置页做成了网页，想着有一天，可以动态挂一点广告。

后面打开第二层配置页面的人，不多不少吧，我尝试挂了几天广告，3.1美元。然后下掉了。

怎么说呢， 一开始觉得挂广告是个不体面的事情。是吧，开源精神、共享精神一堆一堆flag的。

可能有朋友会有类似纠结，不过目前我不纠结了：

故事是，期间我问过一朋友，他连续用了3个月，没有删除过甚至没有禁用过。我觉得挺好，那至少证明没有让他感觉到不适。
他表达了认可，使用过程无异物感，所以不会卸载。但当问他，如果在面板界面加一个广告，他表达有可能某一天会卸载了。背后的原因是他’觉得不值’。

怎么定认值不值？如果给用户来带来的增益，远大于广告的体验问题。那加广告用户也是愿意留下来的，否则就会失去用户。

所以回到”产品本身的增益作用有多大”的话题上了。
如果有足够的价值，加广告吧，不违心。甚至如果哪天我能写出一遍好博客，都会加广告（虽然目前还未写出..）

下掉广告，不是体不体面的问题，而是价值大小的问题，对价值有自信，那就自信的挂上广告。

（对我来说，如果只是做一个页面插件，于用户哪有什么大的价值呢？看后续吧）

警惕Fake Works

Fake Works，假工作，这个概念是从一个老外的newsletter里学来的。

他遇到一个朋友，离职了个人单干，做职业咨询师 。
首次做类似的事情，没有经验也没有信心。整天鼓捣他的个人网站样式、社交媒体内容，而不是迈出一步见一个客户，去完成一场真正的职业咨询服务。这种就是无意义的假工作。

过程中我也有类似的感觉，特别是当某个版本发布，下个版本不知道做什么的时候，天天在那鼓捣网站。
甚至因为看域名不顺眼，鼓捣着换域名。

从CDN、技术架构、analytics、adsense、内容… 全换了遍。前前后后折腾了近1个月，一共才6个月呀，这就折腾掉1个月！

大量的时间消耗，但对这个插件的功能没带来半点变化。

警惕在迷茫中，不敢迈步而捡起一堆的Fake Works来干，要聚焦产品本身。

小的感悟

• Your tech stack is not your product如果你是一个技术型甚至有代码洁癖的人，想开发独立产品的话。推荐看一下这篇文章。新潮的技术栈、整洁的代码，并不是你的产品。我这次完全是放飞了，没写过前端，一堆代码没有重构。
  但我挺释然的，现在并不纠结最开始是选择css叠加还是解析重组的技术方案，也不那么纠结那些让我抓狂的代码。
  可能大家也感受到了，全篇都在在纠结这东西到底能不能帮到人。既在这个语境下我在质疑和关注产品，而不是技术。
• 多端测试可能是最大的成本上面也讲到chrome/edge * window/linux/mac再叠加各种功能组合，测试成本极高，甚至还有不少国内厂商魔改内核版本（至今都无法重现360极速浏览器X上的某个BUG，真的是服了，套壳厂商为什么要去改API啊）
  站在今天，我建议个人开发者，初期要明确决绝的抛弃长尾兼容。把时间花在优化主流功能，这才对产品负责。
• 你可能没有足够的时间刚上线的时候，我收到了很多邮件，我兴致冲冲的应下了一堆需求，但后面我根本没有时间去完成。以至于觉得挺对不起用户的，不该答应的。
  你可能没有足够的时间，这点可能要代入各种实施类决策中。
• 做好应对预期之外的事比如网站没bei an，因为有段时间流量比较大… 不多说了，都是泪。
• 小步快跑还是憋个大招之前觉得这会是很难决策的点，后面发现真当你遇到这些事时，是很清晰可决策的。 我目前是 跨里程碑版本功能必须满足最小目标，不开发好不发布。里程碑内部内部小步快跑。 背后的原则是，在这个业余产品上：可以没有惊喜，但想减少让用户失望两次机率。
• 在国内，服务还是比较内容更有竞争力的写文章的话，一天500 IP可能很难了。做服务的话，就拿这个这么简单的来说吧，最高到可以到800 IP。
  做工具服务的空间还是比写博客高很多。也因为这个插件，建站没多久adsense居然就过了，意外之喜吧。
• 有条件的话，创作确实比工作有获得感真的很佩服那些创作力拉满的年轻人，也很羡慕他们有足够的时间去创作。比如：@timqian @diygod.me

说在最后

最后在扣一下开头的两个命题。

发现需求真是一个要命的本事，找到一个合适的需求太考脑子了。
我深信以自己为目标客户，挖掘需求，确实可能前期挖掘出来的需求受众或者场景非常小，但肯定不会挖掘出伪需求。多试几次、多演进几次，会不会就找到合适的需求了呢。
听一个产品老师讲过，好的用户型产品经理要能是：做个俗人，贪财好色。挺有道理的，入世，挖掘最广大人的需求。

一个小插件水的文字比写的代码都多，甚至都不确定会不会继续做下去，确实挺能水文章的。
还是想抛砖引玉，期待更成功的经验分享，想了解一下那些站在终点的朋友们，是怎么样的历程。

程序员应该要自己的数字资产，后续也期待在 优质中文信息服务 方向，能找到些同路人，讨论交流甚至搞事。优质信息服务方向，我觉得有点意思，我认为这是一个强需求且未被满足，但同时又觉得它有点反人性（惰性）。

可以在这里找到我。

半年历程两万周活 – Chrome插件阶段总结最先出现在Starfury.Tech。

一、从 玩票试水 到 深度应用

一开始买这台服务器，是只打算搭一个博客。

搭个博客 可能是不少同学买服务器的原因，实话讲一开始我认为我应该是临时性的技术自嗨，三分钟热度过去了估计就完了，什么写博客估计也就抛脑后了，所以一开始就买了一个最便宜的服务器 － 1核2G的轻量应用服务器。

一个1C2G的虚拟化服务器能干个啥? 但现在4个月过去了，不仅博客还勉强在写，RSSHub/FTP/远程桌面/Switch加速以及自己开发的一个插件和服务端，都跑在这台机器上（以及还有一个小猫咪）。

对个人视角来看，从买个服务器玩玩的心理，到现在确实挖掘了一些应用场景方便到我：不仅博客，还支持了我不少的生活工作场景。

从技术视角来看，看到这台服务器现在跑了这么多服务，能力上还有可以压榨的空间，心里感受正应了让子弹飞里的那句台词。

分享一下在这台机器上折腾过的一些服务。不会细写某一步应该点哪个按钮或者执行哪条命令（我会把这些操作相关的链接放在文章里），比起这些我认为实践用例可能会更有分享价值，包括我在也更关注工程师怎么折腾场景应用来寻找启发。

二、近期一些实践

1. 博客

如开头讲，一开始主要想搭一个博客。我选择的是传统的wordpress，既LAMP架构。虽然涉及软件是较多的，轻量应用服务器初始化时，也有开箱既用的Wordpress环境镜像可直接选择。即便手工安装（ 链接一 / 链接二 ）Apache/nginx，Mysql，Php网上的教程也非常多。

如果是非技术背景的同学，建议用wordpress，开箱既用插件多。对于技术同学我更推荐 Hugo / Jekyll / Hexo ，毕竟对于技术同学来说，Vim是最强的编辑器，Markdown是最好用的富文本语言，而HTML/CSS/以及VUE/React则是最顺手的主题功能插件。我后期也考虑切到hugo，资源层面还能再节省一大节。

因为我的主机在香港，刚开始国内部分区域通达性不佳，所以用Cloudflare做了内容加速（实际上Cloudflare在国内真提供不了加速，速度不快。但cloudflare提供的缓存服务可以减少机器流量消耗，也提供免费的https/ssl证书）。

优化上除了wordpresss自带的一些优化点之外，也用了 PWA 技术对一些资源进行本地化缓存（pwa必须要求是https）。总体来说目前访问还行，博客也不追求性能。这套方案后面稍微改了一下，也应用到一个Chrome插件服务端上，下面再讲）

关于博客，技术上其实比较扁平，不管用什么技术，最大的建议是一定要备份。

可能大多数同学和我一样，写博客是断断续续的。几年前有段时间文章产出比较多，当时不少公司和猎头通过博客来联系我，但后面就中断了。中断不可怕，甚至断断续续地写可能才是常态，但内容应该作为资产一样保留下来。我当时服务器过期未续费导致文章都丢失了，现在很心痛，目前也只能看到部份文章星零的在不同平台被转载。断断续续的写，只拉长到足够的时间，都是可观的积累。

博客在于内容积累而非技术，一定做备份机制，要能达到，即使这台服务器不在了，内容也能快速的恢复。如果是用wordpress的话，可用类似UpdraftPlus插件备份定期到信任的网盘上。如果用hugo，那在github上开一个仓库就好了，即使未来重新在其它地方部署，也能很快的恢复。

对于图片媒体资源，建议不要将图床做唯一存储，这会让你管理分散并还有丢失的风险（如果是蹭图床服务的话），以后恢复腾挪也更困难。我曾经有些文章因为图片丢失导致文章恢复困难，对写博客来说，制图的成本不比文字低。如果是担心流量消耗过多的话，可以使用CDN技术或者图床来帮忙做加速，而不是将唯一备份放在网盘或者图床上。视文章为资产，应该尽量减少打理管理资产的成本和花销。

2. FTP与远程桌面

FTP的搭建就更简单了，网上随意搜索就有很多文章，FTP很多时候是比较鸡肋的需求，但如果你是多设备用户，非常建议搭一个FTP以及一些多端协同，下面是我的日常设备示意图。

处于不同环境的多个端上面共享文件，是个非常常见诉求。我一开始也是搭建的网盘，还是被ftp/scp/rsyn/取代了，FTP是一个非常成熟的协议，在多个端都有不错的客户端。同时对于技术出身的同学来说，用shell真是的太方便了。

因为有多端的诉求，所以远程桌面就显得更重要的，我在服务器上有一个通用的服务，需要从不同端的上去查看结果或者管理。

VNC服务也是一个非常成熟的协议，可以在任何端上去访问，随时随地召唤一台电脑（如果早点有这个的话，那当年某阳师Gua机就可以随时随地检查调整了）VNC的安装也很简单（ 链接一 / 链接二 ），我的桌面环境用的最轻量级的xfce4。

不过默认的2G内存要跑ubuntu+xfce+vncserver够呛，一旦连接上去，只开一个chrome就会卡死，卡死后需要去阿里云控制台重启。这里一定要开启 SWAP 交换区虚拟内存，再加2G就会很从容了。

另外由于服务器在香港，我的switch也退掉了一个游戏加速器的服务的订阅费，现在玩怪物猎人组队，或是访问任天堂商城都很顺畅（不过下载速度一般，1－2M左右）

3. RSSHub与个人源聚合

这又是日常离不开的一个服务了，我用 RSSHub 搭了一个自己的信息聚合源。

信息爆炸的时代，网上自媒体有不少是低质量的，缺少观点、情绪化非理性、重复拷贝是这些信息的特点。而且往往利用的人性的弱点，比如抖音的成隐性，第一次刷抖音感觉只刷了一会，结果一看时间一个下午就过去了，整个过程中没有任何有益信息的输入，也因此当即卸载了也再也不碰了。这些低质量无信息内容在网上的传播很广，盖过了有真知灼见的信息与文章。如何从这些低质量的信息中（内容农场）脱离出来，最后还是选择启用的RSS。

现代博客都支持RSS源输出，这里有一份社区整理的 中文博客清单 （如果你有博客的话，也可以向这个清单提交）。

而像公众号/微博或者其它新闻媒体，如果有关注的人想定向获取内容的话，就需要用到RSSHub了，它可以将任何一种信息源（包括网页）转化为RSS源，送到自己的RSS客户端上，比如我定向关注抽取了几个微博博主发文，把我关注城市的土拍公告也转化成RSS源等。应用场景上比较广大，深度使用需要一些二次开发工作。

什么是注意力丧失。有一个场景，如果你某一时刻想去查一个博主的文章中的某个数据，你点开微博，进到这个博主的列表，找到了那篇文章，但这个过程中有一个广告，你无意识的看了一下，之后又有一个相关内容推荐，后面还有视频……
“查到那个数据”，本是是个很直接的路径，但现在服务让路径变得乱七八糟，不仅浪费时间，长久下去更大的问题是注意力的丧失，超过30分钟保持注意力已经是我们当代人面临的挑战了。非常建议重整自己的信息源。

因为国外IP访问国内的一些服务可能会被国内平台限制，最近把RSSHub搬到国内服务器了。

4. Chrome插件服务

给自己开发的一个Chrome插件，主要就优化搜索引擎体验的，插件要依赖一个HTTP服务，如下图所示的部分。

由于是个人向的插件，所以没有考虑过HTTP性能的问题，但后面朋友们想用，就上架到了Chrome/Edge应用商店。一开始看也没有什么人下载，没有在意，本意就给自己和朋友们用用。但后面发现经常打不开这个页面，才发现虽然Chrome商城里显示没什么人用（Chrome Store统计不到国内使用情况），但实际线下安装包已经不少用户了，下载JS/CSS经常会把流量打满，这对这台小服务器预期之外的。

结合讲博客时的结构图，首先我把这个服务也上到了Cloudflare，这下整体访问稳定性有一些了。但仍然非常慢，慢在dns解析与网络传输。于是在原有结构上做了变化:

一是在客户端引入dns-prefetch，解决dns解析慢的问题( 推荐一篇前端网络优化的好文 )，然后发现 Vercel 有100GB的流量且速度与通达性都不错，将把css/js等资源放在vercel上了，免费100G/月的流量，用来帮轻量应用服务器分担静态资源。

具体的方式，是在Vercel上搭了一个Hugo（注册好Vercel绑定好Github后，Vercel有自带的Hugo镜像可供直接选择安装），然后把插件服务依赖的资源放在了Hugo服务的 静态文件目录直接提供http服务 中。如果遇到Hugo版本问题,可以在项目Settings通过环境变量HUGO_VERSION指定版本。

另外开发这个插件的过程中，发现了这台服务器的另一个妙用：模拟低性能桌面系统。尤其在测试实际渲染效果时，比Chrome自带的模拟慢速功能真实很多。现在每次发版前，都会在这台机器上跑一下作为性能验收。

5. 一些试过又放弃的服务

• Gitlab 一开始搭了一个gitlab，后面发现github的通达性在慢慢变好（以及这台服务器上有小猫咪）。并且github在存储/代码服务上都很有优势，所以搭了gitlab后又也没有用起来。如果不是对个人的代码有绝对私密和安全要求，建议github就行了（github的私有仓储也不收费可以随意创建了）。

• NextClound 开始在多端协同是想搭网盘，后面也没有用起来，被ftp/rsync/scp+shell取代了。一是因为FTP是一个非常成熟的协议，在多个端都有不错的客户端。二是对于技术出身的同学来说，用能shell脚本，配合scp/rsync/ftp等服务用非常方便灵活。

三、接下来继续折腾

上面便是最近的一些使用实践了。从一开始只想搭个博客，买个服务器技术性自嗨，到现在真切的影响到工作生活体验。无论从服务器能力、场景应用上都还很超期。

脱离一线工程研发工具比较久了，但这段时间围绕这台小机器折腾的过程中，再次感受到工程技术的乐趣，也实际带来的方便。

如果说架构师工作是讲究规模与治理，讲究在概念空间与工程架构之间的zoom-in/zoom-out。那工程技术最大的能量就是直接的创造力/破坏力，技术融合场景创新。这句话有点空，但以服务自己生活为目标，不想那么大，总能长出不少点子来。

接下来准备再基于这套服务器做一个信息服务。一方面还是以服务自己日常生活为目标，同时也是看着服务器的内存和CPU空置让我觉得还有继续压榨的空间。计划是利用阿里云FaaS做Serving，用这台轻量级服务器承接存储服务（ES）。

事实上我建议很多小型初创公司，都可以考虑将自生的serving部分打散，可以更激进一些直接到FaaS模式，在业务中间期以较少的人力获得较高的创新效率与服务保障。

现在的基础设施真5年前7年前便捷了太多，但技术设施就静静躺在那里，能不能找到场景发挥作用，更多是看工程师自己。再往后的话，准备再买一台国内的ECS/轻量级服务器，除了数据相关的，服务类的全容器化掉。建一些服务，应该可以退掉一些云盘/会员订阅等云服务。

如果也有类似想法，可以考虑试试阿里云 轻量应用服务器 。

轻量应用服务器：1核2G能干什么最先出现在Starfury.Tech。

另一博客同步发布

从AI部门小书架上抄起来的书，刚好当时和大家在讨论产品相关的话题，带着一些问题看完了。

整体来说有点“平淡”，不是指作者本人不厉害，而是作为先行者，作者的产品理念在行业里已经是常识了，以至于看下来增量比较少。 如果有过产品经历，或带过产品团队，亦或经常参与到产品决策中，那这本书里的增量认知可能不多。

内容纲领

书的篇幅不长，整体分为四个章节。小节篇幅很短基本在平均2页左右，倒没有阅读压力但有些小节会有浅尝辄止的感觉。

前两个章节讲角色分工、流程与工作界面，集中介绍产品SOP（当然，也有作者的自己的理解）。 第一章节是介绍产品经理的角色定位，包括去比较项目经理、主程、销售经理在做产品里的优势与劣势，产品经理怎么周围角色协同，甚至如何招聘这些课题，如果已经在运转一个产品部门了或已经有相关思考了，这个章节的信息比较枯燥且平淡，可以跳过。

第二章节聚焦在介绍产品流程、每个流程环节的工作界面、如何与不同职能部分协同工作。比如去介绍了如何探索论证一个产品的空间，采用什么样的产品迭代方式最好，如何做原型测试等。这块整体也比较平淡或者偏常识（同上，可能是因为作者作为先行者，所定下的很多经验已经成为行业常识造成的“平常”），但开始有一定可参考的方法以及有特色的观点出来。整体阅读价值还是偏低。

第三章节是本书的核心，开始介绍作者的产品理念，介绍了如何去收集定真实需求、以及作者的一些产品理念(体验与需求可用性与美感等），如果想快速获得作者关于产品内生的一些思考，看这个章节就可以了。

第四章节只有2小节，介绍产品经理在工作过程中的一些反思清单，工具性强一些。

实话看的过程中，有一些枯燥，尤其是前两章介绍产品工作SOP时，偏常识。

增量观点

看完已经有一周了，在没有刻意整理的情况下，脑子里还有的一些留存观点在。

1. 不写一行不知道用途的代码

这个是作者序言中的一个观点，“不写一行不知道用途的代码”是我转换成技术视角来口语化表达。这个观点是让我有共鸣的。作者介绍了因为缺乏客户调研，在HP开发了一个最终没有“价值”产品的经历后，感叹到如果在没弄清自己的产品能帮到哪些客户、提供了什么有价值的服务时，不盲目投入任何精力（这倒是和雷军讲自己97年那次产品失利的感悟很像）

我同时有二三线公司和一线大厂的经历，如果比较差别的话，其中一条便是小厂因为资源有限，对于任何一个产品决策都会反复的确认其商业价值、用户价值。即使是中后台的产品也如此。

大厂因为暴满的研发能力与研发资源，会习惯性的忽略产品的客户与价值这些基本的因素，在很难听到炮火声量的中后台部门，如果失去了大的趋势判断后，非常容易陷入拿着方案找问题，这种预设立场的方案往往是不需要的，也造成了大量中台产品存活周期非常短，甚至从没有有对业务或者管理产生任何增益。

我现在的部门也有这样的迹象，这并不是同学们“个人特质”有问题，还是因为在资源满足甚至溢出的情况下，环境会潜移默化的引导了风向变化。甚至在这种环境中，习惯追问产品价值的同学显得更为异类一些。这点上也一直在影响我老板的一些思维，去探寻产品的价值，否则写的任何一句代码都是多余的。

这里需要补充的是，不是说所有的产品都能成功，有些就是风险型探索性的项目，但这时仍然是需要去定义，需要探索的是什么，需要论证的是什么。而不是陷入“因为我能做所以我要做”，或者“因为这个有挑战所以我要做”的陷阱中。

2. 情绪化用户是最佳的需求挖掘对象

作者将客户分为情绪化用户、理性用户、无主见跟随用户，并将情绪化的用户列为最价值的需求采集对像，原因挺有意思。

客户“需求”，可以转换理解为是对当下现况的不满。比如现在的打车软件，解决的就是原有客户对传统交通的灵活性、可定制性的不满；导航软件，解决的就是原先大家对纸质地图的不满。

产品经理的工作，尤其是商业型产品经理，就是去捕获这些不满，对这些“不满”捕获的越准确，产品定义自然会更准确。而情绪化用户对于不满的表达，往往是最显性和激烈的。而对于理性用户来而，遇到一些“不满”往往会有一些忍耐空间，导致产品的需求在早期在他们身上传达的不强，更为隐性。

找到一个观察场景，让客户的不满情况得到释放；或者直接到一个群苛刻不容易满足的客户，从他们身上去捕获更强的需求信号。

关于需求挖掘，作者还有一个观点值得一说：提防技术爱好者与特殊需求用户。

技术爱好者对于产品的点评讨论会是更热烈的，声量更响的，但有可能是脱离实际的，因为他们用某种产品，很可能是因为产品内在更新了某些新技术，即便这些技术并没有带来新的体验提升与应用场景拓展，他们仍然非常热衷，因技术层面的满足感，反而会忽略对产品能力的问题。

而特殊需求用户，能提出的异类小众需求，有时可能是超前的引导，因为他们先行于市场，而更多时候可能将产品引向错误的方向。这里本质上是一种对产品定位是否清晰、产品方向是否有定力的考验。当然，如果定位上就是定制软件，那这点上顾虑会少一些，定制软件是交付导向，以交付驱动。

关于情感与需求，我认为是作者在本书中唯一有深入表达的部分，中间有一段访谈实录，值得一看。

3. 硬件为软件服务，软件为体验服务，体验为情感服务；产品为需求服务;

这个标题很泛化很方法论，举的例子也是浅浅的夸了一下苹果的产品设计，本来想直接跳过的。但想到一个反例，让我对这段话的共鸣更深刻了一些。

产品为真实需求服务，这点是最好共识的，但如何挖掘价值需求定义产品，有时候不仅需要方法论，更需要创意与情感，尤其是对C的产品。

而“硬件为软件服务，软件为体验服务，体验为情感服务”这点上，脑子里首先跳出来的产品反例既是小米11 Utrla。 作为阐述了一个观点，用自己的话说，既是所有硬件、软件、体验的提升，都是需要有服务目标的：我们为什么加这个副屏，这个副屏服务了什么，解决了什么需求。 没有服务目标的堆叠（不限于硬件范畴了）是技术性的自嗨。

小米11 Ultra的副屏，现在在社区讨论中多偏负面，也是犯了这个错。 再深入一层，11Ultra的Case可能还会再复杂一点，当推出副屏时，圈子对副屏未来的作用和场景还是有一些期待的，包括我也主观上认为副屏能带来一些体验提升和应用场景，但小米并没有继续在软件层面开发利用好这块副屏，使之成为摆设。

这便是硬件与软件了割裂，不管是硬件太超前还是软件太缓慢，结果上就是断层和割裂了，硬件与软件的脱节导致没有联合起来形成场景应用和体验提升。站在今天来反问，这块副屏到底是硬件部门自己加的，还是软件部门有体验提升想法，向硬件部门提出的？ 如果是后者，软件部门是没有执行原定想法的吗？从这个视角来看，一个拉横的产品经理很关键。

4. 大众产品、企业产品、平台产品

作者对大众产品、企业产品的定义，是指分别以服务大众与企业为某个场景目标的产品（如打车、如自动化营销），作者分别例举了10条个人经验，总体来说不算新颖，不再复述了。

因为当下部门正在做一个拉通多个职能部门的平台类产品，所以对平台产品这块有一些共鸣。 平台产品的第一个挑战点是服务的对象角色变多了，不仅要定义清楚对每个角色的服务目标，还需要定义不同角色的权力/责任/利益，其复杂度从设计一个效率/体验工具，变成了设计一个虚拟组织。 组织工作流程可以类比为工厂里的流水线，假设生产一个产品需要三条流水线协作，每个流水线有十个环节，那么第一条水线的第一个工人，对第三条流水线的最后一个工人的工序和目的，肯定是不了解的。 这带来了第一个挑战，需求收集变得困难。

如果说以服务个体或者企业为主的产品，产品经理可以将自己代入到客户视角，去实操感觉去提炼需求，那当服务一个组织时，“组织”这个实体是具备多面性的，像一个多面体，只从一个角色去描述它都是不准确的。这个多面体的每个面，可能还是局部冲突需要博弈和规则裁决的，有一个场景可以示例一下这种冲突：如果大公司里没有内控或者PI部门来制定审批流的，那个每个部门对于审批流的设置和理解可能是完全不同的，权力大、工作少、风险责任低是所有部门对审批流的最大诉求，但全局来看这明显不可能的。

我在内部开玩笑，做平台产品在收集需求，就好比要调查案件需要采访10个人收集线索，这10个人立既不同甚至有些微冲突，同时还不一定说真话（“不说真话”是指这个过程中某个参与角色因为对全局缺乏了解，他讲述的理解不一定是正确的，而不是指对抗性的说假话）

所以当设计一个平台产品时，需求定义需要基于全局的理解，对目标概念约定会有更多的讨论；“权责利”成了最大的设计要素；产品思维之上还需要叠加架构思维，这也是平台产品往往需要很强大的业务架构师甚至全局架构师介入。

作者在书中例举的是windows这样的平台产品，这中间的角色包括应用开发者、内核开发者、终端用户、供应商等，角色性质上和上面举例差异比较大，但平品设计本质上，还是需要围绕参与者之间的核心诉求以及“权责利”设计。

如果继续升维，我认为平台产品可以分化提炼出生态产品，这个方向上比较推崇微信，微信就像一个上帝视角的规则制定者，设定公众号、服务号、小程序、广告商、用户、ISV之间的交互关系与约束，甚至连”一个公众号在不同情况下，分别可以主动向客户发几条什么样的消息”这样的细则都有约束。微信完成这个生态规则制定后，这些角色之前围绕各自的需求与利益的，便自行运转起来了。

能证明这些规则指导下的生态是否足够好，我认为可以从这个生态的规模、效率以及洁净程度来衡量，前两者很好理解，最后一条看的是这个生态的自洁性，背后对应的是生态的质量及寿命，一个无法自我净化的生态系统是会很快毁灭的。 一个自洁性好的生态，往往在花费少量的治理（运营）成本，便可对生态的运转质量及寿命进行保证，而这个点也是业内对微信产品力认可的重要原因。微信在业内得到认可不是因为软件聊天软件体验好，相反，在对比skype，tg，discord，微信的聊天体验真的算差的。但这并不掩盖微信生态的强大。

读书笔记:启示录-打造用户喜爱的产品最先出现在Starfury.Tech。

另一博客同步发布

意外的决定

这段时间技术部门和HR的开始催促我带团队，最终的决定，未来半年不带团队。多少让他们有点意外，也打乱了一些计划。

找我来的一大目标就是带Lead团队，前几周也确实在计划团队相关事情了。但做出这个决定，也确实是深思后的结果，应该会是更好更互利的决定。。

带团队算是比较擅长的事：24岁开始带技术职能团队，26岁开始带综合部门。也正因为如此，对于“带人”在欲望层面比较早就淡化了。 之前团队有个同学，无论如何都想带团队，问他为什么他也答不出。其实我知道多少都有对权力的想法，也是跃迁一个层级最外化的标志。我当年也一样，不过较早的满足淡化了。 另外权力和责任是对等，尤其是刚刚开始当TL的同学，往往对于责任的担子认知是有一些缺失的。

对我来说，带团队带部门有两个比较重要的前提：

• 一是我有非常相信且非常要达成的目标，我需要更多人配合我一共拿到结果达成目标。
• 二是我对部门和团队的同学是有明显增益的：这个增益既可以是经验也可以是获得感甚至是氛围与心情。

目前我在第一条上是有缺失的。目前我还没有一件每天想去check进度，想要全力达成的事情。我需要先找到这么一颗种子，我的主要精力也会放在这上面。

任性地拒绝团队之后，我也需要回答，我未来的重点方向。

反向行进

从职能上讲，我期望未来先还是做域架构，在更大域范围内做架构师。

这对我来说是一个更意外的决定，算是反向行进：在很长一段时间，对于单纯的域架构角色，是不认可的。

架构思维打开来讲，是以逻辑空间中有层次性结构性的认知/推理/判断能力为基础，衍生出来对问题概念目标约束的识别定义，对解法的设计，最后是外化表达为一张张的架构图/方案图。不管应用架构还是业务架构师抑或是偏中台治理的全局架构，只是在工作平面不同，涉及的基础原子能力其实是类似的。

工作早期我被抓到公司架构部去工作，呆了不到3个月，就跑出来了，后面很多次架构部想抓我的时候，也都是躲得远远的。

我很认可架构师的原子能力所带的价值的，也确实有类似的原子能力。但长久以来不愿意做“单纯架构师”角色的原因：

一是单独的架构师不具备影响事情落地能力的。在一个个商业项目/技术项目的设计及落地结果，一直是我较大的获得感来源之一，而单纯的架构师是很难具备影响事情落地的能力的，以至于我最喜欢的角色其实是Lead和架构两个角色兼任，我不仅想设计，还要掌握落地资源交付价值的能力。

另一个原因是，我认为架构师的能力模型中，很重要的一项是权衡与取舍的能力。知道了解完美的方案/终态的方案其实是件低门槛的事情，无论是业界的方案还是同行的交流交锋，对于”理想方案”是能较快获得一些共识的。但知道“规模不同的公司在各个不同阶段”需要什么样的方案是更难的命题，也是我觉得很有意思的部分：去动态应对不确定过程中的每个阶段，比死板的向终极方案推进，更难更好玩。在一个设定场景下，匕首的作用可能比长剑更大。这中间对事情的判断力，往往是需要通过前线信息和反馈来强化训练的，站位靠后的架构师对于信息的掌握，有时有缺的。

既是妥协，更是尝试

长年以来管理和架构师兼任的经历，让我更适应这样的组合角色。而现阶段主动去做大域架构师，有三个原因。

一是“非职权影响力”，我上面在质疑单纯的架构师角色的落地能力，但在蚂蚁我遇到了一个例外，他的架构能力让我佩服，更重要的是，他在没有任何直属部门的情况下，让多个部门围绕着他转圈，为他的设计落地服务，他靠的是我没有体系化学习过的“非职权影响力”，他们存在改变一点我对架构师的理解。

二是我对团队的帮助，前3个月我申请做架构师来过渡，在这边团队落地。虽是过渡意图，但是是展现出了对部门的增益，对问题的梳理c对方向的思考以及向上的汇报，应该是帮部门打开了一些局面的。来这的第一个目标，确定方向并在在更大范围内都共识且支持这个方向，目前应该也算略超预期的。

不过第三点是最重要的，我希望有一段深度学习思考的时间，能在银行全域认知上有更大的突破： 如果往回看，23-27是在业务战线上的时间，也是最适应的时间段：当直面客户、直面市场、面对竞争时，肾上腺素起来是很快的。 而在蚂蚁的4年，我把银行中后台业务做了大半圈了，甚至让大家都误解是中后台方向特质的人，给晋升也在中后台上给我更多的挑战。从过程从结果来看，前4年一直没在自己最擅长的位置上，让我很后悔时间有些“浪费”，甚至未来半年一年还会在这个角色上继续服务，既然如此，那为什么我不好好利用这段时间，反向补全能力和认知呢。计划要这半年到一年的时间内，对银行全域业务/数字化转型方向，积累全域视角和认知。也算是为我下次回到业务前线指挥，提供更多的判断力和能力积蓄。

写在最后

在蚂蚁以来，从个人视角，一直没有最兴奋的位置上工作（直面客户与竞争时总能让我肾上腺素起来的更快，也相对更擅长VUCA式工作），过程中一直以“组织需要”为首要目标，建了几个团队，也跨地域来回倒腾，其实有些事是违背我个意愿的。

上次在面一家小公司（其实也不小，专精特新小巨人）的区域负责人时，最后只给到部门总监的Offer，当时很疑惑，我当时很疑惑，因为从技术面试过程来说，大家契合度是非常高的。但对方hr的理由是说服我的:

“从设计组织的视角出发，是希望个人的利益与公司发展的利益是绑定的，个人的目标甚至欲望愈发满足，而这家公司的业务能更好发展，这是最好的组织设计”

而在蚂蚁一直感觉自己是一个输出者，做了很多从个人视角来看是“服务组织服务团队的事”，没有自发主动的去尝试找到“共生”“共同获得”的模式，是我的缺失。那次沟通对我收益非常大，虽然最后拒了对方offer，但仍然与HR老师一直保持联系。

而这次的决定，其实就是夹杂了我的私心的，我想看有更多的时间去思考见识，去看完整个银行甚至更大范围的领域，为我以后的职业生涯积蓄。我觉得，这应该就是那个HR老师说的寻找“共生”。

另一博客同步发布

不领团队，再做半年架构最先出现在Starfury.Tech。

另一博客同步发布

这几个月过得挺慢的，在反复的自我发问中度过。

刚完成了与管理层的汇报，还算比较成功，包括运营线的老板，对这块的预期也变得高了一些，兄弟团队的事情也得到了支持。

但这并不能掩盖对信贷运营工作的一些方向性的疑惑，甚至我感觉为了大小团队的事情可以得到支持和加速，这次的汇报是起到了不那么“全域最优”的负向搅动。

本来是既想写认知，也想写判断的，但后面发现判断往往都是业务数据认知带来的，讲判断就算间接把业务情况也指明了。所以把判断部分都删除了，先干瘪瘪的写一些认知层面的事吧。另外后续文章会在另一个博客同步发布。

信贷转化的基础与效率

之前负责电商搜推时，虽然核心是搜推，但通过产品和技术影响力，掌握了全站70%以上的流量决策，所以实际运营的核心也在我这。对比两段工作经历，电商的转化运营和信贷的运营差距还是挺大的。

对电商运营而言，客户有需求而我们有供给，这是最朴素的交易转化–供需。但电商运营有大部分来源，是通过购物节/人传人/砍一刀等运营活动，通过刺激触成交易。供需需求或冲动消费需求都能促成交易转化。甚至在电商领域，由于CLV的考核机制难落地，导致做刺激性运营会远远比做供需运营（如复购）能更容易证明价值，也更能获得认可和资源。

而企业信贷领域完全不同，有消费者会冲动消费，但没有法人/企业主会冲动贷款，信贷规模的理论上限就是由供需决定的，我们能提供200万的资金需求，市场有100万的资金需求，两者求最小值，100万就是供需匹配的上限，主动的转化运营并不能提升规模上限（这点电商可以通刺激性消费在周期内突破供需规模上限，同时如果做消费信贷贷，因为消费者冲动消费因素存在，主动运营也是有提升上限的功效的，但这里我主要讨论企业信贷）。

信贷主动运营聚焦在提升转化的效率：如果说供需匹配上限是100万的规模，不施加任何影响干预手段，在足够长的时间内，比如3年5年，肯定是可以达到上限的。而主动转化运营的工作就是极大的缩短这个时间，比如3月5月，主动的转化运营不能影响业务转换规模的上限，而聚焦在业务转化的效率。

因为难以创造需求，供需变得关键，同业和风控决定了银行的供给（资金与额度分别由同业和风控部门产出，挺幸运同业/风控/运营，银行展业的三驾马车都做过了），而主动运营聚焦在转化的效率上，再细化一层就是匹配与撮合：

匹配是指完成授信供给与客户需求之间的识别和链接：某企业展业需要1万块，风控恰恰完成了对这个企业的评估给出了适应的额度和利率，运营发现了这对匹配关系，并通过工具完成触客通知，就是一个再朴素不过的流程，但也是可以做得非常深的领域，精确营销是个朴素的词，但在企业信贷领域是可以做得非常深且价值衰减很平缓。

撮合则是当供需之间有些许不匹配时，通过运营从心理上或者实质上消除缓解这些不匹配，但交易可以达成。继续展开上面的例子，如果上面那家企业预期利率是4%，但银行的风控只能出给5%的利率，那这笔交易是无法达成的。但通过主动运营，比如提供一张0.5%的免息券，那这笔交易有就成功的可能了，这是运营工作的另一个空间。 上个月有家同业银行来集团给我们办理员工贷款，利率3.7%，没犹豫就变了，但在签合约时发现上面对方风控给出的是4.5%的利率，而运营部门直接用营销预算补了0.8%的降息，撮合完成了这笔交易。虽然动态营销定价有很多的创新和突破，但对于当于情况来看，感觉当下撮合运营的空间整体是有限的。

简陋又深刻的”择人择时“

从”匹配撮合“视角再展开，运营工作可以再拆解”择人、择时、择渠道、择内容、择权益”。既主动转化运营的核心都是“找到需要用钱的企业在需要用钱的时点，用可以高效通知的渠道以恰当的内容通知到，并酌情是否需要搭配相关权益”。

事实上所有交易转化的核心就是这句“废话”，但信贷运营因为是以强依赖需求拉动，难以创建需求的，渠道/内容/权益我认为是可以弱化的，注意这里说的是弱化而不是说不做。这些是要做但不深卷的，如果真的能及时发现某个企业主需要用钱，那一条平淡恰当的短信和一段带场景视频短剧广告，对这个急需用钱的企业主来说效果是大差不大的。

但择人择时方向是完全深入下去的， 如果能先于其它银行知道某家资质不错的企业需要建一个新厂，那就在竞争中获得的前机。对个体个例的感知和判断需要极大的依赖数据以及对数据利用能力（算法认知）。 同时不止个体认知这个方向，”猪周期“、”苹果季“、农忙、服装周期、烟草进货特异周期、区域性节日….. 叠加各类细碎行业区域的认知，能再更大程度上获得竞争优势。

小微企业尤其是个体户，他们的个体数据在行业内或者互联网上出现的非常小，叠加这种行业化区域的数据认知能力，是银行在小微领域的决胜能力。

企业信贷运营的空间及考核

如果企业信贷主动转化运营的主要作用是转化效率，那评估某个时段转化运营的重要性就变得简单了。

当额度供给远大于信贷规模，或者额度供给增长速度远大于贷规模，那这个时候，就就当在运营上投放更多的资源。授信额度与贷款规模之间的差值越大，证明“转化效率”的作业空间就越大。

相反，如果贷款规模已经逼近授信规模了，那再卷运营是没有意义的，就像互联网产品讲究PMF，如果两者的差值非常小了，类比就是PMF已经到顶了，需要提升“产品”了。 由于ROI/ROE以及客户运营（CLV）等多目标叠加，信贷主动运营每个阶段的考核往往是很复杂的，有时还需要结合复杂的静默干预实验确定，但考核其余额规模与授信额度之间的差值与比值 ，是一个简单有效的指标。

同时针对于，是否要建立精细化的考核机制，也是需要权衡的，有时运转一个超细粒度的评估机制，让其转动起来的成本已经难以覆盖管理收益了。 尤其在是业务快速动销展业期间，锚定上面说的差值指标，我认为是一个不错的选择。

再谈品牌运营

现在我更加坚定的认为企业信贷运营皇冠上的名珠，就是品牌运营。

回想小时候看到一些银行的广告就很简单的一句，“做你身边最忠实的伙伴”，当时觉得这挺傻的，似乎啥也没讲，这怎么能转化带来交易?

上面我讲”信贷转化的基础是供需，转化的效率是运营“，这个定义里其实少了信任这一环的，因为金融的严肃性，所以客户对于不置信的金融机构是有非常强的排斥意识的（比如之前各类暴雷的、暴力催收的等等），这不像一件T恤背心，货不对版退货再买。信任是金融交易转化的另一个核心条件。

金融领域品牌运营品牌的传播，不仅能带来自然流量，吸引客户自己来。更重要的是能建立信任链接，消除信任壁垒。从这个角度来看，渣打银行在08年金融危机时，打出“陪你度过最黑暗的时刻”的广告语，对于陷入经营危机的各个企业主来说 ，应该是有相当大的心理震撼的。

虽然大家都说品牌运营不是产研的活，但还是没忍住找了好几本品牌运营的书来说。做工程出身，不相信有银弹，但品牌运营这东西，就像一颗银弹一样横躺在运营领域，让人忍不住想看看。

回到供需

转化的基础是供需、企业信贷不能创造需求、行业化区域化认知能力是小微信贷的决胜能力，结合当时疫情反复小微企业用钱需求增长，风险也增加。 如果在供给端（同业资金、风控授信），尤其是在风控授信端，做小微风控、行业化风控，才是当时最需要的，也是最具竞争力的。

我们这么一个人口大国，靠国企大企业养活十多亿人是不可能的，得靠小微企业/个体户。而传统银行只做国企大企业（风险低、规模大），他们的模型评估不了看不见小微企业，这是我非常相信的故事。 说“扶持小微”太傲慢的了，说“服务小微”太矫情了，同时对于小微来说我感觉是经营展业的困难远大于流动性困难，我们也解不了他们最难的问题，但能在流动性侧帮到一点忙，我觉得也是可以一辈子吹牛的资本。但我现在做的事，和相信的故事之间，还隔了几层呢？

写在最后

• 文字里隐掉了不便说的判断和疑惑，因为这些疑惑，已经连续推迟了好几次把团队划给我的事项了，我还想再推迟一段时间（但可能有点难再推了），让我再以比较轻松的方式思考论证下去，也希望当我面对我的团队时，对他们讲出来的话都是我坚定相信的东西。

• 同时，在这段时间的交流和思考中，我确定了我身上有比较突出的产品（PD）特质。技术是爱好，架构和管理是工作，但产品思维和能力，可能是我当下阶段解决问题最需要的工具。现在找到了一个可以偷师的产品高管，挺好。

• 最近和算法部门大TL最近一起聊了一下，虽然很客气但对于将运营引向这个方向，还是表达了一些苛责（还没有到不满）。我和他相信的方向认知是一致的，希望将这块规整好后，能再另一头碰头合力。

• 另外最近看了信通院发的企业数据化营销评估模型，我们再干一段时间，规整规整，感觉可以冲击一下。

企业信贷增长运营(二)最先出现在Starfury.Tech。

另一博客同步发布

最近从金融智能撤出来，把两个团队移交出去了，进入营销增长的事情中。免不了俗，为了建立沟通基础，快速阅读了《硅谷增长黑客实战笔记》。

之前在电商带搜推时，受益于产品引导，实际已做过一些增长相关的工作，概念和流程的接受度上还不错。不过读过该书后有不少深度和体系的增补，一些点状概念想法开始建立，有一些来自书中，有一些来自回忆，先分享记录一下。在后面的实践中去把这些想法转换更体系和更实践的经验，会再来更新。

关于之前金融部分信贷核心、同业资管、交易结算、产品中台、财务管理相关的积累，后面抽空写些脱敏的感悟，先挖个坑吧

产品价值与增长 – PMF天花板

之前电商做过一些增长的尝试，有短期效果，但站在公司视角并没有足够显著的作用。

产品可服务的用户数上限，是由产品服务的核心价值决定，而增长是挖掘迫近这一用户数天花板的方法。

产品价值越高，其用户上限越高，没有价值的产品做增长是本末倒置，沙地盖楼。

一个剃须刀产品即便拥有弄断地位，也无法服务60亿人，既无法覆盖女性、一个性价比产品难以吸引品质类客群、一个无价值的APP注定无法留住客户……

没有足够的产品力支持，产品市场需求匹配（PMF）不足的情况下，不要做增长。

之前在电商短暂进入一个误区，既是在供应链优势（效率、价格、品质）持续被追上，市场扁平化的过程中，忽略了构建差异化竞争力的内核，而寄希望与尝试提升端内转化与留存。

事实证明有短线效果、甚至中期留存效果也不错（激励），但并不是一种可持续的路子。 增长应该是在“产品可服务用户上限”的天花板这一层作业，当触及到这个天花板后，应该协助提升产品核心价值，提高天花板，而不是跳过天花板，去半空中作业。

增长团队复合职能 – 特种兵

增长团队的职能，会覆盖运营、市场、产研、数据分析等多个职能领域，我目前的概括认知是：

• 产研是产品核心价值的构建者
• 市场是价值的传播者
• 运营是产品生态的经营者
• 增长团队，则是要以数据驱动的方式，完成对上述职能的整合和迭代

我认为，增长团队基础技能是能利用数据，整合市场、运营、产研的工具和资源（渠道、预算等资源）促进增长，而高阶技能或者说高阶价值是完成对产品能力迭代升级：一轮一轮的让用户数逼近产品所匹配的天花板，并能承担用研，甚至直接承担产品经理角色，持续提升产品的天花板（PMF）

增长团队的负责人，很符合我推崇π型人才，也需要具备追求的VUCA的能力。很像体系内喜欢提到的一个”特种兵”的定义。

不想去讨论职位能级的高低，大家目标不同、切入点不同，同时很多概念是螺旋式上升的，一些职责也是渐变生成出来的：

以运营为例，除了注意短期效果的活动运营，也衍生出了会去侧重用户长线价值的用户运营。以营销市场为例，即使不提增长黑客，公司的广告投放的考核指标也在逐步下钻，从点击率、激活率等短时指标，渐渐的去关注留存等长期考核。

不过具备整合职能的岗位，能获取更多的视野和资源工具支持，可以更好的达成目标；同时视角更全，能亦会遇到更全局的问题，在一定程度上能从战术执行层面，升维到方向决策层面。

AARRR、用户生命周期与跃迁策略

海盗模型（AARRR）：增长是拉新→激活→留存→变现→推荐，覆盖了短期助推、中长期可持续、商务变现的视角。

我之前对增长的概念认知，还多停留在短期刺激和助推层面。实际上增长团队，既要提供催化剂（对产品的传播贡献），也要供给更多的反应物（对产品力的提升贡献）。

海盗模型的提出，也从关注“拉新”这个单环节，升维到了关注整个用户生命周期体系，而不只是引流注册激活。同时也把增长工作的工作复杂度提升了：

更多的工具库 x 更多的运营环节 = 更复杂策略

上图只是一个简化表述，其用户生命同期的状态节点定义，我觉得应该以专家经验假设出发、考量行业特性和数据验真、方便运营策略出发，进行适配定义。

比如，信贷领域应该定义成”高信贷余额用户”、“高周转用户”甚至更细节的“半年内借还三次的用户”，更复杂的状态机设制加更复杂的跃迁路径。权衡策略粒度及管理复杂度：状态机的细化可以下钻运营粒度，但也会带来策略定制实施复杂度。

策略与算法 – 白与黑

策略是什么？单从技术实质上，其就是一堆流程条件组合，一个决策树。下面是网上随意找的一张图

每一个策略，都是基于专家经验、行业规则、运营灵感也产生的。它定义如何通过对工具的编排利用，达成既定目标，具备可解释性、业务语义，是白盒化的。

不仅营销策略，信贷中的风管策略: 给某个人多少额度，给什么级别的信用卡。背后都是一个高度复杂、被科学管理迭代的决策树。例如：早些年，论坛里会有人教你如何办下某家银行的信用卡，如先在某个餐厅消费多少元，再去某个酒店下一个订单… 并让银行感知到这些行为，然后再去申请信用卡就成功了。本质上就是早些年有些银行的信用卡准入策略简单且被人逆向发现了，目前这种情况比较少了。

说完了白， 那黑盒是什么？黑盒我目前定义是一些不可解释的算法模型，它能解决最优化的问题。

比如策略定义，针对新用户，登录首页需要发红包拉新 ——— 这是白盒规则。而算法可以根据性别地域时间等其特征，算出来给多少金额红包成功率高且成本低，以及针对一个客户给出不同的红包等等最优决策（杀熟来啦 ！）。

策略定义流程，算法最优化流程。 这是目前可以摸到的，但其实我也在想，有没有可能让算法去辅助定义流程，借助算法的全局优化能力，帮忙策略定制，辅助决策 。这块的难度，我初步细化下来，不在于算法、不在于工程，更多在于数据，这需要的数据底盘的厚度和数据标准的规范性要求太高了，准备探探。

数据分析与数据技术的一些实践记忆

不管是之前的实践经验，还是书中提到的，数据洞察能力是增长策略的关键。这些洞察既有对特事专家假设的前置验真支持，也包括对策略测试的指标进行后置跟踪分析。这块好理解，没有感触的就不做旁白式的阐述了。 这块我的经验，技术上需要重视三个点，也是我之前实践过程中的一些经历：

流量埋点

不管是APP还是WEB，流量埋点机制的合理性科学性，将会极大影响迭代效能。我们做得最差的时候，基本是每新增一类埋点，都需要研发。

埋点技术方案是相对明确的，可以在很多地方增加切面，日志收集上报等机制也是业内非常成熟低门槛的技术。

但埋点模型上，一定要足够的低维，不要要过多业务语义的埋点，由后续的ETL等数据工作翻译为高维业务语义，保障埋点的稳定性。我们当时做到比较大才意识到这个问题，花了很很大力气做整改，其中工作量除技术设施技术标准研发SDK的以外，最重要的就是埋点剥离业务语义。

数据建模

数据建模层面，我们之前做了三块大域：行为域、交易域、元数据域。 其中行为域分成两层：

一层是流量埋点中的行为事件，这块可以参考神策数据，二层则是基于这些行为数据二次建模的更具业务语义模型。例如第一层行为事件是描述了”用户在什么时刻访问了某个界面并在某个时刻点击了某个按钮“，而第二层则是用户访问了购物车，用户访问了购物车并在3秒内加购了推荐商品： 带有主题型的分析。

交易域在电商就是各类订单、支付单；元数据域我感觉可能没做好命名，本质上是想表达商品、用户、画像等相对静态全局的数据。

分析工具

我面过一些同学，大家的焦点喜欢集中在分析工具上，其中这块是相对扁平的，这块的目标是高效、灵活的一个分析面板，从存储层的hologres、kudu、phonenix、es，还是应用层面的notebook、powerbi甚至自建，其实技术层面难度是不高的。

流量理点和数据建模，一定提前规划，这块是提前规划成本低，并不会在前期造成过大的成本投入，但后续效益高的。

增长SOP与迭代效能

增长的流程很明确：提出策略想法、前置验真、实验方案设计、产研协同、数据跟踪分析的循环迭代。

这块SOP可以去网上找到更准确的解释，这里想讨论的是，增长SOP是否需要全线上化管理？

以增长黑客一书为例，作者在各个公司的实践，其实还是以驱动研发为主要方式的：提出猜想、下发需求到各产研部门、产研改造、上线跟踪。之前我在电商时，也是协同相关产研域进行实验方案的同步改造。

而目前我们想把整个目标定义、策略构建、产品联动、数据跟踪管理全链路线上化：由增长团队定义一套分版交互协议，去定义用户入端后，进入到某个界面、应该展示什么文案、交互流程如果定义、弹窗设计及方案区分 。既通过一套标准化的协议，让各域对域，各域在接受到流量后，按AB分版分别控制自己的可调要素。 这块我要重点考量一下，既构建这套机制的成本（特别是对产研的干预和影响，虽然目前增长的指挥棒举得最高，但我还是不希望对产研有极大的干扰），是否能覆盖收益。

这套统一协同理想机制，前期成本过大，但能解决策略实验过程中因协同和管理阶段的信息过载而导致的效能问题或可实施性问题。

增长黑客一书中，以及之前电商的实践，都选择了有轻度的干预，而非统筹性、技术框架性的干预：我们会把配置化的诉求，下推到各个域内自己解决。比如我们天天向购物车提分版需求以及控制要素定义，他们自己也会做一些内部抽象来提升效能。既我们用需求的指挥棒软性的逼产研团队提效，而不是硬性技术方案焊接。

两套方案，各有优劣，我希望我能找到其决策维度以及其收益成本变迁的点。

电商 VS 金融 – 一些零星差异点分析

电商和金融的差异还是比较明显的， 这块后续实践过扣我也会再更新，目前看起来，有几个点是比较明显的。

电商会关注激发消费动力的激发，适时助推，客户在加购犹豫不决后，给紧迫性文案；而金融本质是上偏理性的，我认为要做好 “清晰表达、建立信任”

电商切换成本非常低，留存层面要花很大力气；而金融客户的稳定性整体上更强。 例，有些客户顾虑多用一家银行信贷，多上征信

电商客户和产品匹配度复杂，客户类型多，产品类型多，且都随时间变化；而金融产品集中在理财和信贷两个原子产品，靠量点也多是利率，诉求相对明确

电商领域的个性化空间较大，本质上有内容营销成份在里面；而金融产品的个性化，主要集中在定价

皇冠上的明珠 – 品牌

最后想提一下，我一直认为最厉害的营销是打造品牌 – 高认可度、高传播度、高溢价的品牌是营销皇冠上的明珠。 现在想迭代一下观点：最厉害的增长策略是打造品牌。

汽车领域中，BBA的例子讲得比较多，同样级别配置，就是能多买一个级别或者半个级别的价格，并且消费者从心理和身体两个层面都买单，既用脚投票、也帮忙宣传。在手机领域中，国内的华为了从超低端品牌完成了高端品牌的转型，而小米还在挣扎中：品牌管理真是一门有意思的工作。

同样是汽车领域，我本来想以BYD为负面例子来对比阐述的，但发现近几年BYD的品牌力也在逐步提升。我非汽车领域的爱好者、研究者，不专业，从收集到的信息来看，核心产品力的提升，是他逐步构筑品牌的关键（他们在营销侧做得似乎不行）。

这也暗合了第一点提到的，产品价值才决定是增长产品的天花板。同时也支持了这一次的观点迭代： 打造品牌不仅是营销的事，更是产品内核价值的事。增长工作的明珠，或许可以往品牌管理层面再探探？

看完后，我发现有一很有意思的点，既书中提到的一些正面案例，如clash for clan甚至还有一些已经暗淡的产品，目前还算成功吗？ 增长不应该以某个阶段论英雄，增长应该结合短期催化和长期可持续迭代。

用户增长的一些思考最先出现在Starfury.Tech。