构建成功产品：我们学到的 50 个 Lessons Learned
构建成功产品：我们学到的 50 个 Lessons Learned
我们在 PostHog 学到的经验
Ian Vanagas Feb 27, 2025 61
为了庆祝 Product for Engineers 达到 5 万订阅者，以下是我们构建成功产品过程中学到的 50 个最重要的经验：
-
小型团队（6 人或更少）可以构建出色的产品，但他们需要被赋予自主权来设定自己的目标、确定路线图的优先级、选择指标、与用户交流并快速发布代码。
-
产品的成功来自于参与其中的人。 设定高招聘标准至关重要，因为人才会产生复利效应。没有什么比一个表现不佳的糟糕的招聘更能拖慢你的速度。
-
构建伟大的产品需要信任。缺乏信任通常是团队最大的瓶颈之一。这很可能是由于招聘了水平不够高的人，或者未能向该人提供反馈以帮助他们改进。
-
信任也建立在透明度之上。公开工作，公开讨论，并记录你正在做的事情。这为每个人提供了他们需要的背景信息，并消除了困扰许多公司的政治争斗。
-
依靠信任和反馈，而不是流程。这是我们的核心价值观之一。构建和扩展人们想要的东西是一个复杂的问题，所以我们让人们运用自己的判断力。当他们犯错时，我们会直接给出反馈。
-
管理层应该分享公司目标；产品团队（工程师）应该弄清楚要构建什么来实现这些目标，并设定自己的目标。两者都应该使用指标和用户反馈来审查他们正在构建的东西是否具有实际影响。
-
你的产品是 你的理想客户画像 (ICP) 的下游。他们是你为之构建的人，是帮助你决定构建什么的最重要因素。准确的 ICP 不仅会定义你定位哪些客户，还会定义你的产品和市场进入战略的_每个方面_。
-
要找到你的 ICP，先猜测，然后测试。在注册时提出问题，比较保留率，识别你的超级用户，运行 NPS 调查。随着你获得更多情报（和信心），添加细节。
-
创建产品原则。我们的原则是“提供评估成功所需的每种工具，首先进入，并成为客户和产品数据的真相来源”。这些为你提供了讨论想法和做出决定的通用语言。
-
绘制用户可能想要的一切，因为你需要它来确定路线图的优先级。这确保你不会错过视野之外的绝妙想法。
-
你的产品不仅仅是其功能。 它是你的品牌以及其他人如何体验你的产品。 你在每个功能上投入多少，你雇用的人，你决定构建的内容，哪个功能领导你的公司，你的客户沟通以及你的定价，这些都在使你与众不同方面发挥作用。
-
你的网站是你的产品给人的第一印象。 一个无聊的、模板化的网站表明该网站背后的产品和团队不是很强大。 创建一个专属于你并为你理想的客户画像构建的网站是防止这种情况的一种方法，并鼓励用户进入你的产品。
-
有时，这是市场的问题，而不是你的产品。例如，当 Monzo 创始人兼 YC 合伙人 Tom Blomfield 正在为大学朋友构建一个账单分摊服务时，他得到的建议是停止构建并开始尝试获取新用户。当他在四周的电话推销后获得一位新用户时，他知道是时候进行转型了。
-
如果你要转型，要大刀阔斧地转型。 Stewart Butterfield 将两家视频游戏公司转型为 Flickr 和 Slack。 LinkedIn 联合创始人 Reid Hoffman 表示，创业公司创始人可以从失败走向成功，但前提是他们“砍掉”业务的其余部分。如果看起来相似，则更进一步。
-
正如 37Signal 的 Jason Fried 所说，“你无法验证一个想法。 它不存在，你必须构建它。 市场会验证它。”
-
计划是有用的，但严格遵守计划不是。 良好的执行不应意味着执行特定的计划，而应反复做最重要的事情。 根据人们的交付成果、交付频率以及工作的影响来判断他们，而不是根据他们是否“坚持了计划”。
-
等待“再一周”发布某些东西几乎总是一个坏主意。 这种态度推算到几个月 = 势头小得多。 你越早将某些东西交到用户手中，你就越早了解它是否是他们会重视的东西，以及如何使其更好。
-
减少你的在制品。 PR 应该可以在一天内完成，从回复其他人的审查请求开始你的一天，随时合并，在功能标志后面发布，并在生产环境中进行测试。 这些都减少了完成工作所需的上下文量。
-
快速发布是我们产品开发理念的核心部分，但我们意识到这会带来权衡。 技术采购、计划会议、敏捷仪式、指标审查退居其次。 异步进行 使我们更有能力做到这一点。
-
只有在出现诸如成本过高、扩展挑战或客户需求等紧急问题时，才应将新技术引入到你的产品中。 可以通过询问你的团队或其他团队以什么方式自行解决了该解决方案来找到潜在的解决方案技术。
-
人为的截止日期 不会让你的团队更快。 它们通常会导致恶性循环，从而导致大量技术债务和倦怠。 相反，清除减慢团队速度的流程，并让小型团队自主快速发布。
-
加快发布的另一种方法是默认情况下不进行设计。 运行设计系统，然后让工程师构建。 在需要时，进行设计审查并润色已发布的内容。
-
功能标志 使产品工程师能够快速发布更改，在生产环境中进行测试，并从真实用户那里获得反馈。 它们还可以通过充当未按预期工作的推出的终止开关来降低风险。
-
PostHog 上最好的沟通方式是 pull request。 与消息或问题相比，它们可以立即将反馈转化为影响。 这与我们对行动的偏见保持一致，并帮助我们创建更紧密的反馈循环。
-
明确所有权。 这使得决定构建什么更加清晰和快速。 当所有权规避团队可以只是发布时，他们会花费太多时间进行计划、集思广益、开会和项目管理。
-
工程师有能力决定构建什么。 他们了解技术限制，看到跨功能的模式，并且可以弄清楚如何解决问题。 当涉及到用户想要什么时，他们可能只是有一个信息瓶颈。
-
与其控制工程师，产品经理 应该通过分析产品分析、进行用户研究、进行竞争对手研究等方式为产品团队创建背景信息。
-
大多数人不是 Steve Jobs。 他们不仅仅是从一开始就“知道”要构建什么，或者有一个宏伟的愿景。 相反，他们发布东西，将它们交到用户手中，根据反馈进行迭代，然后重复。 你越快做到这一点，你的产品就会越好。
-
雇用并依靠 产品工程师。 他们具有构建产品所需的完整的技术技能以及对客户的痴迷。 是的，这意味着他们需要与用户交谈，进行用户访谈，招募新功能的测试人员，收集反馈，提供支持并响应事件。
-
阅读《Mom Test》。 它将教你如何与潜在用户谈论他们的问题。 一个关键的经验是两种类型的用户访谈：问题探索和解决方案验证。 第一个指导未来的产品决策。 第二个有助于改进你现在正在做的事情。
-
要充分利用 用户访谈，请了解你的用户是谁（ICP），他们如何使用你的产品以及你接下来要构建什么。 这样做将确保访谈可以阐明你在后续步骤中的重点，而不是分散你的注意力并使你感到困惑。
-
在你可能构建的所有东西中，支持请求是最“真实”的事情之一。 特定用户有特定问题。 当你解决它时，你只是改进了你的产品，其他更改不能说同样的话。
-
工程师提供支持鼓励对从构思到实施再到持续维护的产品的整个生命周期的所有权。 这些都建立在彼此的基础上，通过建立在真实的客户痛点和问题背后的代码的背景信息。
-
工程师提供支持 缩短了用户的问题与已发布的修复之间的循环。 无需支持人员、产品经理和计划流程的介入。 作为一个额外的好处，用户喜欢这样做。
-
使用你自己的产品，又名 dogfooding 帮助你更快地发布、在问题到达用户之前拦截问题、深入了解你的产品并培养对用户的同理心。 但它不会取代与用户交谈、获得真实世界的反馈以及跟踪真实的使用指标。
-
像我们的产品团队对访谈弹出窗口所做的那样，解决你自己的难题可以帮助验证用例。 如果你没有使用自己的产品，但应该使用，这是一个迹象表明出现了问题（你应该做些什么来改变它）。
-
伟大的产品构建者总是在原型设计和实验。 这意味着他们需要能够舒适地构建 MVP 和概念验证、发布未经润色的作品、获得反馈并在事情不顺利时进行转型。 这也意味着拥有从基础设施到设计的所有技能，可以从零开始构建。
-
成功运行 A/B 测试需要一个好的假设，解释你要测试什么以及为什么要测试它。 包括测试的背景、更改、指标和预期结果。
-
在运行产品实验时，要知道它们可能会失败并被删除。 这意味着你应该将其设置为删除（带有功能标志）并发布“足够好”的版本，而不是完美的可维护和可扩展的版本。 你可以在成功后稍后改进它。
-
产品实验可能比你意识到的要“愚蠢”得多。 例如，与其构建完整的功能，不如尝试一个假门测试。 这是你添加没有内容的选项或按钮来检查人们是否会点击它们的地方。
-
对于产品实验，失败不是世界末日。 在 Google，80-90% 的实验“失败”。 你可能会认为这是浪费时间，但是，从长远来看，10% 的成功可以超过所有失败的总和。 例如，Bing 如何显示标题的 A/B 测试使收入增加了 12%（当时超过 1 亿美元）。
-
在关注增长时，像增长工程师一样思考（并确定优先级）。 识别目标区域，找出代表该区域的指标，创建一个关于如何改进它的假设，并尽可能小地进行实验来测试它。
-
分析 几乎从不嫌早。 这对于_发布前_的产品是有意义的，但是由于“太早”而_发布_没有分析是一种错误的经济。 一旦你启动，优先级将从尽可能快地发布转移到尽可能快地发布正确的东西。
-
从分析开始时，从小处着手。 选择一个特定的产品或功能，使用自动捕获跟踪其使用情况，使用趋势和保留率图表可视化此数据，并尝试发布可以改进这些功能的那些功能。 “现代数据堆栈工业综合体”使这看起来比实际情况复杂得多。
-
不知道从哪个指标开始？ 我们建议将激活作为其他指标的上游，这是工程师可以直接影响的一个指标，并且在整个组织中都很有用。
-
除了激活之外，保留率是另一个关键指标，用于了解你正在构建的东西的影响。 跟踪每周的变化可以使你开始了解你的更改是否使使用者留下来。
-
要衡量产品与市场的契合度，请检查与用户增长相比，用户参与度是否呈指数增长，并且保留率是否趋于平缓（高于 0%）。 之后，检查 ICP 用户是否比非 ICP 用户保留得更好，以及你的付费客户是否属于该 ICP。
-
增长审查确保团队正在构建的东西正在对重要的指标产生影响，例如收入、产品分析和用户反馈。 这些是 PostHog 产品经理的主要职责。
-
如果你的公司构建多个产品，将每个产品视为一个小型创业公司。 这意味着他们自己的产品决策、定价、收入、成本以及与面向客户的团队的协调。
-
从事你感兴趣的产品。 正如 PostHog 联合创始人 James 在他的产品与市场契合度指南中所写：
“如果你对正在做的事情不感兴趣，那就转型。 这就是这么简单。 如果你正在做一件感觉属于你自己的事情，你会取得更多成就。”
Ian Vanagas 的话，他很高兴这次没有人建议阅读 50,000 个电子邮件地址。
我们越快达到 10 万，你就越快获得 100 多个经验教训。 分享以实现这一目标。