<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>产品经理 on AxerZone</title><link>https://enchanting-vacherin-946011.netlify.app/tags/%E4%BA%A7%E5%93%81%E7%BB%8F%E7%90%86/</link><description>Recent content in 产品经理 on AxerZone</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><copyright>© 2026 Weiming</copyright><lastBuildDate>Mon, 18 May 2026 10:20:00 +0800</lastBuildDate><atom:link href="https://enchanting-vacherin-946011.netlify.app/tags/%E4%BA%A7%E5%93%81%E7%BB%8F%E7%90%86/index.xml" rel="self" type="application/rss+xml"/><item><title>重读 Ben Horowitz：好产品经理，坏产品经理</title><link>https://enchanting-vacherin-946011.netlify.app/posts/ben-horowitz-good-product-manager-notes/</link><pubDate>Mon, 18 May 2026 10:20:00 +0800</pubDate><guid>https://enchanting-vacherin-946011.netlify.app/posts/ben-horowitz-good-product-manager-notes/</guid><description>&lt;p&gt;作者：Ben Horowitz&lt;/p&gt;
&lt;p&gt;原文链接：&lt;a href="https://a16z.com/good-product-manager-bad-product-manager/" target="_blank" rel="noreferrer"&gt;Good Product Manager/Bad Product Manager&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Ben Horowitz 的《Good Product Manager/Bad Product Manager》是一篇语气很硬的产品管理文章。它不像很多产品文章那样温和地讲用户、体验和协作，而是直接给出一组对照：好的产品经理如何行动，坏的产品经理如何找借口。它读起来甚至有点苛刻，但正因为苛刻，才把产品角色的责任边界讲得很清楚。&lt;/p&gt;
&lt;p&gt;这篇文章值得放进博客，是因为它不仅适用于产品经理，也适用于所有需要为结果负责的人。工程师、设计师、创业者、内容创作者，都可以从中看到一个核心问题：你是在拥有问题，还是只是在参与流程？你是在推动结果，还是在解释为什么结果不是你的责任？&lt;/p&gt;

&lt;h2 class="relative group"&gt;产品经理首先要拥有上下文
 &lt;div id="产品经理首先要拥有上下文" class="anchor"&gt;&lt;/div&gt;
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"&gt;
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e4%ba%a7%e5%93%81%e7%bb%8f%e7%90%86%e9%a6%96%e5%85%88%e8%a6%81%e6%8b%a5%e6%9c%89%e4%b8%8a%e4%b8%8b%e6%96%87" aria-label="锚点"&gt;#&lt;/a&gt;
 &lt;/span&gt;
 
&lt;/h2&gt;
&lt;p&gt;文章中最重要的标准之一，是好的产品经理理解上下文。他知道公司目标、用户需求、竞争格局、技术约束、收入模式、团队能力和时间压力。他不是只收集需求，也不是只写文档，而是在复杂约束中形成判断。&lt;/p&gt;</description></item></channel></rss>