老实说，我个人很不喜欢那种对着工程师叫嚣“我只要结果”的产品经理。除非你是公司的CEO或者CFO，否则我不认为你有理由回避过程的复杂性。最起码的要求是，相关产品在用户面前所呈现的业务信息量，产品经理应该100%地了解。举个简单例子：如果校内网的产品经理无法向用户解释“如何将一个好友添加为‘特别好友’”，那就太失职了，至少我认为是失职的。
在我自己控制的产品中，我一定是要了解所有业务细节的。由于项目繁忙，我也曾将手头已经拿到的项目转手外包给第三方开发团队，自己做起“产品经理”。作为产品经理去领导工程师，如果高高在上的提出一个粗略的要求就像等结果，99%会荒废掉这个项目。和工程师打交道，“尊重”两个字最重要。你能想象一个工程师是这样工作的么：
(虽然是老图了，感谢Fenng的及时分享)
具体实施起来，除了基本的劳动报酬尊重外，更需要尊重对方的，是明确的需求和时间表（Schedule）描述：一定要面对面对着屏幕将需求说清楚，细化到每一个按钮点击后的效果，并且制定好时间表，否则工程师提交回来的成品八成是一个“四不像”。
而作为工程师或者Vendor，我很难说服自己去会为一个不懂HTML的产品经理效劳。结合06年到现在许多项目的经验来看，至少在我coding的时候，是希望能有一个规范的阶段需求说明的。产品经理毕竟不是PR、市场总监，没有必要把大把的时间和精力放在产品之外的地方；产品经理也不是创意总监，不需要每天都有新点子冒出来，而程序逻辑更是严谨的算法实现，再flexible的架构也无法满足所有的业务需求，简单点说，你不能今天让我开发一个Twitter明天就让这玩意像Facebook那样工作。即便是Prototype阶段的开发也做不到。当然，工程师对于尊重自己的产品经理，则应以“责任”为报答。
总之，“产品经理”这个title已经被滥用了：越来越多不适合做产品经理的人开始做起了产品经理。这是一种事倍功半的分工：他们对公司赋予产品的期望一无所知，又不知如何与工程师们沟通、交代需求。往往一个很不错的点子胎死腹中。真正优秀、称职的产品经理，其工作强度绝不亚于研发工程师。如果一家公司的工程师都忙得加班到凌晨转钟，而产品经理们还在家里睡大觉的话，八成这家公司离死亡不远了。只可惜我们的工程师没有“罢工意识”：“长痛”肯定比“短痛”更痛苦的。
PS，近期更新缓慢，我真的很累，附图一张。大家猜猜墙上是什么：）
揭秘：墙上其实是一个ActionScript类。由于太大，而且历经多个版本的修改，因此我将一个历史版本贴到了墙上，laptop上小字看起来实在太累：（看来还是有不少朋友猜对呢，哈哈：）
