我写过很多产品的内容和文档，多到我甚至已经能够准确地判断什么时候我或者身边的其他人是在做与产品管理无关的事情。
你很难找到一个组织，可以让你按照最初的设想构建产品。通常，你需要做出一些妥协（有时甚至是很大的让步）来适应组织并维持自己的收入。
你会发现有一些人总在妥协，而他们的特点也非常明显。一种是灭火达人。 产品着火了，利益相关者上火了，产品经理也火烧屁股了。他们每天被战火纷争的会议塞满，却完全没有交付价值，只是被推着不停修复 Bug 并匆忙上线。
另一种是产品交付师。 他们的主要工作是交付，而不是思考。他们与完美无缺的待办列表和精美的用户故事一起工作，一个接一个地发布功能；没有价值评估，也不收集反馈，只是不断地发布、发布、发布……
不要变成他们，他们已经被抨击得够多了；你应该努力尝试摆脱它们。这两种是很容易识别的错误类型，你都不需要阅读其他文章来了解它们。今天，我想说明一些不那么容易识别的错误示范——它们看起来很像产品管理，但其实不是。
你通常可以在产品成熟度较高的公司中发现它们，而且很少有人愿意指出或批评这些问题，因为这会触动一些人的神经。但，管它呢，我爱干这种事。
第一类：产品学者 Product Scholar
这是一个经典类型，可以在 Medium 或 LinkedIn 上找到（很多）。产品学者总是讲很多，但交付得很少。 讲学是一件相当容易的事情，但他们似乎忘了「知道怎么做」并不等同于「能够做得到」。
产品学者们经常会在会议上丢出知识炸弹，比如「我们不能依赖假设」或「我们必须确保向用户交付价值」。之后，他们挥一挥衣袖，消失在迷雾中，而工程师和设计师则被留下做真正的决策。
他们大力提倡「持续发现」和「价值主张设计」，却没有可以展示的 KPI；只提供理论和指导，然后让小组里的 Tech Lead 或设计师为其工作。产品学者是产品经理里的「嘴强王者」，在业务上的表现却相当糟糕。
第二类：探索经理 Discovery Manager
与产品学者相比，探索经理说得并不多。事实上，他们非常害羞——他们会将话语权范围限制在创造假设上，从不承诺解决方案。这种类型的行为红线是，一个人应该与问题作伴而不是与解决方案。谈论「要交付什么」似乎成了他们的禁忌。
他们对任何事情都没有信心，从不承诺；他们避免大规模交付，因为他们没有承担风险的能力。 这些专业人士让业务内非技术垂直部门的同事不喜欢「探索」这个词。
探索经理将拥有一个美丽的机会解决方案树，但他们永远不会把它交付出去。他们只实现那些被告知要做的事情，或者到处灭火。
第三类：数字经理 Data Manager
不要将它和数据产品经理弄混，后者很好。数字经理是盲目追随数据的产品经理；如果没有数据，他们就无法完成工作。
如果说「灭火达人」和「产品交付师」是一种极端，那么「数字经理」和「探索经理」则是另一种极端。任何没有数据支持的反馈都该阅后即焚，不管它是客户要求的、老板指定的，还是从知识中获取得到的。
数字经理没有恶意，但他们常常因为缺乏灵活性，而对存在于数字外的机会和问题视而不见。数据驱动是指尽可能地诉诸数据，而不是完全依赖数据。
许多我们今天认为很棒的产品都不是建立在大样本 A/B 测试上的，它们也没有庞大的用户群组可以用于行为跟踪；而数字经理似乎忽视了这一事实。
第四类：产品巨星 Product Superstar
这是一个复杂的类型。理论上，产品巨星做的一切都是对的，问题出在他们的目标/出发点。
产品巨星对向用户提供价值，为业务负责并不感兴趣，他们关心的是「哪些交付能让他们成为焦点」。 有时候这两件事是一致的，但有时候不是。
产品巨星有耀眼的 KPI 可以展示，通常是基于技术细节的对象。尽管企业有负面新闻但 NPS 异常高，或者一个产品不为人知却增长惊人，都可能是由产品巨星掌控的。
不要误会，在工作中寻找发光的机会是可以的。产品巨星的问题在于，他们将这种雄心壮志视为优先级矩阵的一部分。并非所有发光的机会都是充满吸引力的，而巨星们永远不会去碰这些。
第五类：产品狂热者 Product Zealot
产品狂热者也是产品经理；事实上，还是很好的产品经理。他们的过错不是提供了预期外的表现，而是不能接受——如我开头所指出的——在工作中妥协和让步。
在科技行业大裁员之前，他们处于相当安全的位置。托 Cagan、Perry、Ries 和 Torres 的福，非技术部门不得不忍受他们以「用户价值」和「增长」为由，否决大部分功能和需求。
现在，世界变了，那些曾经遭受压迫的人重新拿到了话语权。创新和增长失去了在谈判桌上的位置，而那些真正能够带来稳定的、可靠的收入的人成为了交易者。
产品狂热者常常忽略一件事情：产品团队创造的所有增长和价值，只有在用户愿意为它买单时才有意义。 有时候你不得不因为大客户的一句话，就去灭火或者交付一个未完成的功能——没关系的！亚马逊被认为是最好的产品领导组织之一，哪怕是他们，也会在老板的命令下推出失败的产品——Fire Phone。
写在最后
在这些原型中看到其他人很容易，但你自己能「对号入座」吗？我很确定，你很可能是其中一个或多个类型的结合体（就像我自己一样）。
不需要遮遮掩掩，我们都是一样的。成为一个小小的「学者巨星」会让你有更多的机会；在组织中，当一名「数字经理」或「探索经理」也可能完全够用，不要为此感到沮丧。
无论你是否认为自己是产品经理，想要获得团队和整个组织的身份认可，下面这三点非常重要：
1. 承担起负责任的风险，抓住机遇。
2. 实现高效和有效的交付。
3. 与其他部门沟通和同步风险及交付情况。
（原文作者：Antonio Neto；文章出处：Medium)
LigaAI@oschina 还将持续分享研发提效、个人成长、职场进阶等更多实践干货和经验分享，欢迎关注我们。
关注 LigaAI – 新一代智能研发协作平台，申请试用我们的产品，与 LigaAI 一起做大变强！
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
文章和代码已经归档至【Github仓库：https://github.com/timerring/java-tutorial 】或者公众号【AIShareLab】回复 java 也可获取。 程序框架图 代码实现 数据库 — 创建满汉楼的数据库 CREATE …
