【猎云网（微信：ilieyun
）】4月1日报道（编译：Muki）
编者注：本文作者Daniel是Earnest（旧金山科技公司，致力打造突破传统的现代银行）的产品总监。在这之前，他在谷歌担任产品经理。Daniel曾获得哈佛大学的计算机科学学士学位。
首先，什么是产品管理？
这个问题其实很难回答，不是简单两句话能说清楚的。
最常见的解释大概像下图这样：
产品经理究竟是什么？
如果有人问你“自由女神像是什么？”你会回答“它被曼哈顿、泽西城和总督岛环绕”吗？
这类信息的方向是对的，但是不完整。所以产品经理到底是做什么的？
别担心，没人知道
在谷歌，这个难以明说的含义感觉像是不言而喻的玩笑。
“产品经理职责表现出来的模糊性，其实已经接近它的本质，”产品经理Dan Schmidt在The Product Management Triangle 里写道，“即使是公司内部，产品经理的职责也可能大幅的快速变化。”
BCG顾问Yves Morieux认为当代组织管理者在构建组织结构时过分强调“可度量性、可说明性、明确性”，这实际上是对生产力的一种阻碍。他认为如果我们光考虑失败时候怎么找出该追究的人，会因此错失团结协作带来的成功机会。
Yves Morieux：工作中设太多规定将阻碍任务的完成。
按照Yves的说法，产品经理是否该归属技术部门？如果是这样，那这样的定义是不是就把它衔接其他板块功能的“胶水”作用给抹掉了？
产品经理的种类
到底怎样的产品管理才是我们需要的？
这是一个重要的问题，会关系到以下方面：
♦ 怎样带动一个产品经理团队？
♦ 怎样给他们分配工作？
♦ 怎样评估工作绩效？
♦ 其他部门要怎样相辅相成？
对初创公司来说，“产品人”（创业公司很少会有明确的“产品经理”职位）的职责大概就是公司中缺哪补哪。比如，很多没有设计师的技术团队全靠产品经理设计用户界面。
然而，对发展中的公司来说，调节产品经理团队的职能需要考虑足够长远。管理者必须在技能、学识和经验的不同组合间，做出较大的、持续有效的取舍。那么问题来了，当设计、财务和商业发展等多个团队出现来弥补公司缺陷时，产品经理的职能是什么？
Quora 知名的产品领域写手Dan Schmidt通过如下图所示的“产品三角”表明了他的主张，他认为产品经理终究会通过职能的重叠交叉，连接这些不同的板块。
构建产品的可视化语言——Dan Schmidt
但问题是并不是所有板块衔接的方式都是一样的，每一个都需要个人能力、工作风格和核心价值观的不同组合。鲜有产品经理能做到这样自由调整个人特质，睿智而熟练地完美填补这些空隙。（如果你真的遇见这样的奇才，一定要介绍给我！）
更普遍的是那些能力不平衡的产品经理，在某些方面特别强，但某些方面又能力不足。我们可以用一个可视化模型来理解其中一些常见的倾斜情况。
#1：用户至上的产品经理
用户至上的产品管理：理解用户需求，然后满足他们的需求
很多这类的产品经理来自设计背景，比如UX职位，或者像IDEO那样的设计顾问。他们的方法更多的是线框图、焦点小组和众包。
从我的经验来看，他们会展现出这些关注倾向：
♦ 速度——为什么这么慢？
♦ 数据反复利用——用户真的必须再填一次这个信息吗？
♦ Bug修复——我们不能把那样含糊的错误提示甩给用户！
♦ 理解——1-7的分值设置真的可以帮助用户理解这点吗？
♦ 用户的要求——所有被调查的用户都想要更多邮件提醒......
这类方法在用技术解决问题的领域（工具类App）来说最合理，但从商业模式上来说可创新的空间有限。在我看来，任务管理就是一个贴切的例子。再拿教育技术举个例子，主要就是利用数字科技来展现内容。最后再比如像Slack那样的聊天应用。
#2：业务至上的产品经理
业务至上的产品管理：确定一个机会，然后充分发掘它
我所认识的有这个倾向的产品经理大都来自MBA项目，或者综合管理岗位（包括投资创业公司）。这类产品经理通常很喜欢进行成本效益分析。
我发现这些人倾向于关注：
♦ 收益 ——对于这个新产品特性我们可以多收20%的费用！
♦ 有竞争力的产品特性——所有其他公司都提供免费送货！
♦ 商业发展机会—— 我们可以整合这所有的API来获得更多数据！
♦ 增长空间—— 我们来想个办法增加主页的转化率。
♦ 投资者的要求——Paul Graham 想在这个流程自动化后再跟我们谈。
这种方法最适合时刻有商业模式创新的领域，这类创新建立在为人熟知的经验和商品技术水平上。你或许会立刻想到Wunwun这样的概念。如果他们真的实现了当地物品的免费送货，运费从与制造商和商人的创造性合作中来，那么用户就会忍受繁琐、不直观，或完全没有兴奋点的App。其中原因跟他们会忍受宜家的长队伍一样：他们想要你提供的东西，而你是唯一一家。
#3：技术至上的产品经理
技术至上的产品经理：确定一个强大的技术革新点，然后利用起来
这些产品经理大致都有技术背景，比如软件工程或者计算机科学类的职位。他们倾向于使用原型、任务管理，以及流程图。
我发现这些人会更关注：
♦ 盯紧每一次发布——这种情况可不可以只报一次错？
♦ 功能点重复利用——我们能不能不另外开发一个标签的文本框，而是直接在备注框里利用标签符展示标签？
♦ 最小化无用功——既然这个系统下个月就要换新了，我们就别管这个bug了吧......
♦ 扩展性——加了这个功能点，将来拍照和扫描就方便了！
♦ 技术用语的一致性——如果它将来会有P2P教育项目的话，我们就不能叫它“学校”。
“技术至上”用在用户体验比较简单，且商业模式比较成熟的情况下效果最好。大部分谷歌的成功产品都属于这一类。你真的没法找出比一个搜索框更简单的用户界面了，而且根据你搜索的内容来投放广告，这种模式早已在谷歌进入这个市场前就有了。
注意不断变化的需求
The Innovator’s Dilemma带来的启发中最直观一点就是，产品工作中各种能力的重要程度会随着时间转变。技术宅的说法是，硬盘容量在达到最大利用值之前都比物理大小来的重要。
这个重要的规则不仅可以应用在硬盘性能上，还可以应用到这三个产品维度的平衡上。Gmail就是一个有趣的例子，从技术类产品起家，扭转格局的产品特性（超大存储空间，高质量搜索），为人熟悉的界面（跟其他网页邮箱类似），和传统互联网商业模型（积累用户，为后续营收打下基础）。但当根基深厚的竞争者，比如iCloud和Hotmail出现的时候，其关注重心就从技术转移到了设计上，Mailbox（被Dropbox收购）的成功也表明了这点。
小结
优秀的产品经理都做些什么，去哪里能够找到他们，其实根据你的产品定位和策略来说会有很大不同，同时这些还会随着时间而产生变化。尽管差异总是存在，但优秀的产品经理总能无形地连接起不同职能领域，带领产品走向成功。
