产品管理最基本的工作之一，就是让需求保质保量地上线，并且测试完备，不出现严重的影响生产的bug。
如果质量控制出了问题，再好的策略，再贴心的用户体验设计，都会变得一文不值。你的产品都严重不可用了，用户就算想支持也无能为力。
这类bug的产生，至少有两类情况。
一种情况，是产品需求本身没考虑周到。
产品提了一个某环节的改动需求，开发照着产品的意思做完了，也全部通过早先的测试用例了。大家都以为没什么问题，就让功能上线了。结果没过几天，各种数据指标就变得异常，用户的负面反馈也纷纷爆了出来。最后详细一排查，发现按之前的产品设计，就是会出现问题。
比如，之前有不少用户反馈说，我们文档解析产品界面上东西太多太挤了，没用的可以先隐掉。于是我们调整了一下用户界面，在用户上传完文件识别完之后，自动收起上传区域。结果上线之后，另一些用户开始反馈说第一次上传完之后，不知道怎么操作第二遍。
一整个就是大写的尴尬。无奈之下只好重新设计，继续优化。
另一种情况，是产品需求没毛病，但开发实现的时候莫名其妙出错了。
这其实也相当容易发生，常见于复杂业务流程的改动上，比如订单交易相关的操作。复杂工程里，代码解耦程度不够高时，很容易牵一发而动全身，改了A，结果影响了B。
近期一个乌龙事件，就是在修改TextIn的后台付费套餐统计时，影响了前台自动领取免费试用套餐的逻辑，导致一部分用户即使点了领取，自己账户上的可用额度仍然是0。我要是用户，也一定觉得被骗了。
但对于产研团队而言，因为需求主流程是后台的统计优化，大家无论如何都想不到前台的免费套餐领取会出问题，自然也很难在上线前完整测出来。
当然了，难不是借口，总是有办法的。
上面两种情况的解法其实都差不多，可以是：
1）丰富回归测试用例：每次上线前，至少都应该保证主要的用户路径完全正常不受影响；
2）增加指标监控体系：做到半天或者小时级的核心指标同比/环比监控，让异常更早被发现；
3）灰度发布机制：新的改动不要一下子全量上线，而是在一部分用户里充分测试后再全线推广。
不过这些做法也跟产品的用户规模有关系，不同量级的产品，适合的方式也不同。但产品的质量控制，总归是同样重要的工作。
产品质量出了问题，用户体量小的时候，产品就很难长大；而用户体量大的时候，就可能出现公关危机，出现大量负面反馈，造成用户严重流失。
如果说产品工作里什么是根本，质量控制肯定是其中之一。做好了，用户没有感知，不会有表扬；但做不好，立马就会有负反馈。但正因如此，作为产品经理，反而不能松懈，而是要花大精力去应对才行。
善战者无赫赫战功，神医治病在于早期预防，说的都是这个道理。
如果质量控制出了问题，再好的策略，再贴心的用户体验设计，都会变得一文不值。你的产品都严重不可用了，用户就算想支持也无能为力。
这类bug的产生，至少有两类情况。
一种情况，是产品需求本身没考虑周到。
产品提了一个某环节的改动需求，开发照着产品的意思做完了，也全部通过早先的测试用例了。大家都以为没什么问题，就让功能上线了。结果没过几天，各种数据指标就变得异常，用户的负面反馈也纷纷爆了出来。最后详细一排查，发现按之前的产品设计，就是会出现问题。
比如，之前有不少用户反馈说，我们文档解析产品界面上东西太多太挤了，没用的可以先隐掉。于是我们调整了一下用户界面，在用户上传完文件识别完之后，自动收起上传区域。结果上线之后，另一些用户开始反馈说第一次上传完之后，不知道怎么操作第二遍。
一整个就是大写的尴尬。无奈之下只好重新设计，继续优化。
另一种情况，是产品需求没毛病，但开发实现的时候莫名其妙出错了。
这其实也相当容易发生，常见于复杂业务流程的改动上，比如订单交易相关的操作。复杂工程里，代码解耦程度不够高时，很容易牵一发而动全身，改了A，结果影响了B。
近期一个乌龙事件，就是在修改TextIn的后台付费套餐统计时，影响了前台自动领取免费试用套餐的逻辑，导致一部分用户即使点了领取，自己账户上的可用额度仍然是0。我要是用户，也一定觉得被骗了。
但对于产研团队而言，因为需求主流程是后台的统计优化，大家无论如何都想不到前台的免费套餐领取会出问题，自然也很难在上线前完整测出来。
当然了，难不是借口，总是有办法的。
上面两种情况的解法其实都差不多，可以是：
1）丰富回归测试用例：每次上线前，至少都应该保证主要的用户路径完全正常不受影响；
2）增加指标监控体系：做到半天或者小时级的核心指标同比/环比监控，让异常更早被发现；
3）灰度发布机制：新的改动不要一下子全量上线，而是在一部分用户里充分测试后再全线推广。
不过这些做法也跟产品的用户规模有关系，不同量级的产品，适合的方式也不同。但产品的质量控制，总归是同样重要的工作。
产品质量出了问题，用户体量小的时候，产品就很难长大；而用户体量大的时候，就可能出现公关危机，出现大量负面反馈，造成用户严重流失。
如果说产品工作里什么是根本，质量控制肯定是其中之一。做好了，用户没有感知，不会有表扬；但做不好，立马就会有负反馈。但正因如此，作为产品经理，反而不能松懈，而是要花大精力去应对才行。
善战者无赫赫战功，神医治病在于早期预防，说的都是这个道理。
开源一个 MCP Servers 导航站，在去年开源的 gpts-works 项目基础上做了升级：
1. 页面配置化。把导航站的页面内容抽离到了一个单独的 pagejson 文件，方便用 AI 生成页面内容（Pagen 的原理）
2. 风格模板化。把导航站的页面组件放在 templates 模板下，后面可以扩充不同风格的模板，做到导航站千人千面。
3. 数据与视图分离。结合上一次聊到的做导航站 SaaS 的 idea，后面的版本可以实现让用户导入一份自己的数据，选择一个模板，一键上线自己的导航站。
代码已开源到 GitHub👇
https://github.com/chatmcp/mcp-directory
欢迎体验，感谢 star
发现有个山寨产品买了我的关键词广告😓
我都想提醒这哥们，咱没必要，他这产品介绍页和预设光线选择，我就觉得他没搞对重点，产品有点差。
以及，以这个工具的ltv，买广告ROI真回不了正😓我怀疑他是不是新闻看多了，以为我靠小猫补光灯赚了不少钱。
现在对“创业”和“产品”多少有点点祛魅了。
谈到“创业”，脑子里第一反应是“生意”，就是这个事抛开一切理想情怀能不能第一天就在商业上成为一个立得住的生意，这样才有之后的各种设想和理想。
谈到“产品”，也会觉得“叫好”棒极了，但是更看重“叫座”，因为“叫座”才能活下去。“叫座”的“产品”才是成功的“商品”，“商品”是自身价值和市场价值的交集，某种程度上更难。
其实就是接受过毒打，知道热爱理想还是得建立在“活下去”是基础上的。
谈到“创业”，脑子里第一反应是“生意”，就是这个事抛开一切理想情怀能不能第一天就在商业上成为一个立得住的生意，这样才有之后的各种设想和理想。
谈到“产品”，也会觉得“叫好”棒极了，但是更看重“叫座”，因为“叫座”才能活下去。“叫座”的“产品”才是成功的“商品”，“商品”是自身价值和市场价值的交集，某种程度上更难。
其实就是接受过毒打，知道热爱理想还是得建立在“活下去”是基础上的。
你打开一个浏览器插件，看到页面上显示这个插件有600万用户数。
那么这里的用户数量是什么意思呢？
到底是600万的什么呢？
估计很多人都不知道，我调研了一番，搞清楚了含义，并且让 Claude 画了一张图给大家解释说明。
#自媒体运营频道 #@yunying23
有时候，难免因为一些事件，产生情绪，继而产生进一步情绪放纵、摆烂的想法。
倒也没必要全然克制，有一个原则是：设定约束边界，以不产生长期负面后果的行为为限。
比如，时间边界，选择沉迷情绪到影响其他关键事情节奏把控，或者破坏了既有习惯的，砍。
比如，物质边界，选择冲动购物到影响后续支出局面的，砍。
比如，对重要人物冲动言语暴力，可能致后续关系破裂，长时间难以修复的砍。
所以啊，选一些短期的、危害小的事，该放纵放纵。
有时候，难免因为一些事件，产生情绪，继而产生进一步情绪放纵、摆烂的想法。
倒也没必要全然克制，有一个原则是：设定约束边界，以不产生长期负面后果的行为为限。
比如，时间边界，选择沉迷情绪到影响其他关键事情节奏把控，或者破坏了既有习惯的，砍。
比如，物质边界，选择冲动购物到影响后续支出局面的，砍。
比如，对重要人物冲动言语暴力，可能致后续关系破裂，长时间难以修复的砍。
所以啊，选一些短期的、危害小的事，该放纵放纵。
