核心问题

PM 需要具备哪些技术广度，才能和工程师有效对话？

真实场景

工程师说：“这个问题可能在 CDN 缓存，也可能是后端接口超时，还可能是数据库慢查询。”如果 PM 完全没有基础概念，就很难参与判断。

你不需要都能实现，但要知道它们在系统里扮演什么角色。

常见误区

坏判断是：

我只要懂业务，不需要懂技术链路。

不懂技术链路，PM 就很难判断需求影响面和故障影响面。

工程视角

建议的一横包括：

网络：请求、延迟、DNS、CDN、HTTP
前端：页面、组件、状态、浏览器兼容
后端：接口、服务、任务、权限
数据库：表、索引、事务、迁移
缓存：命中、失效、一致性
消息队列：异步、削峰、重试
CI/CD：测试、构建、发布、回滚
监控：日志、指标、告警、追踪

PM 可以怎么做

学习每个领域时，只先回答四个问题：

  • 它解决什么问题？
  • 它常见故障是什么？
  • 它和需求排期有什么关系？
  • PM 评审时该问什么？

Atlas Action

画一张你产品的技术链路图：

用户 -> 浏览器/App -> CDN -> 前端 -> API -> 服务 -> 数据库/缓存/队列 -> 下游

标出你最不懂的三段，优先补。

小结

技术广度的目标不是样样精通，而是能听懂系统语言。

一横让 PM 不再只能站在工程讨论门外。