1. 权衡的艺术-产品经理如何把产品做成功？
2011-1-8 来源：网络
那其实就是一门权衡的艺术 ~并且我觉得产品经理 和架构师的处境类似~产品经理 需要和架构
师多沟通才行~(当然这么说的话就针对比较“大”的产品了~对，本文不针对“小”产品)
产品经理如何把产品做成功呢？这个是大多数产品经理每时每刻在思考的问题。
“做正确的事”和“把事情做正确”这两个要素对于一位优秀的产品经理而言，因该是双向的，“做正确的
事”更多时候是把握产品的方向和蓝图；在一些产品体系健全的公司，这项工 作主要是由公司的产
品线经理 或者产品总监去完成。而在现实的中国 IT 企业中，这项工作往往是由产品经理去完成。
那对于产品经理 而言“做正确的事”，究竟应该怎么做呢？
如果想把一个产品做正确，就必须把握清楚这个产品的需求 ，这个需求主要从 N 个方面进行一
个描述：
客户的需求 对 于一些有甲方的企业来说，客户需求是放在第一位的，因为他们很清楚一件事，如
果客户不满意，那还有何用户可言，客户对你的产品不肯定、产品不能满足客户的 需求；那这 个
产品问世的可能性不大。所以说客户的需求尤其重要。所以产品经理在做产品蓝图规划时，必须要
弄清楚客户空间想要什么，并想清楚客户的这个要求，如何在我 的这个产品里 做体现，更优秀的
产品会考虑的更长远一些，及如何把客户的需求与产品完美结合。如果你的产品方向或思路得到客
户的认可，对于后台的产品推广方面，将会得到 客户的更多关 注和支持。
公司的内部需求公司的内部产品需求，要从 N 个方面去阐述。
公司高层对产品的期望 产品经理 必 须要弄清楚，公司的高层对你所规划的产品，持有怎么样的

2. 期许，在公司的战略规划里，你的产品的方向和里程碑式的目标又是怎么？你所设计的产品如何给
公司带 来 最大化的利益？你所设计的产品是否与高层的期望是一致的？这些疑问都是产品经理要
去解决的，通过与高层的不断沟通，必须要弄清楚高层对于产品的深层次需求 是什么，当你 的产
品规划案得到公司高层的认同时，你的产品工作就又上了一层台阶，在产品的天平上又增加了一块
生要的法码。
公司的运营部门的需求有些公司的产品建设完成后，要交由公司的运营部门的，运营部门要去完
成产品上市后的一系列运营 事务。因为你的产品做出来后，是要给运营部门来运营的，你的产品设
计是否合理，有一项重要指标就是运营人员 在使用了你设计的产品之后，相关的转化率有没有提
高？有没有有效的降低了运营的成本。产品经理必须要弄清楚运营部门需要解决什么样的问题？要
实现什么样的目标？你所设计的产品有没有有效的解决运营部门的问题，就显得尤为重要。
公司技术支撑部门 的需求有些人不禁会想这个产品做出来后是给运营部门去运营的，技术支撑部
门的需求真的需要考虑吗？这里的答案是肯定的。技术支撑部门对于产品的设计更多时候有自己的
想法，有 时是降低产品的开发成本，实现重用性。
用户需求说到这儿，估计很多 UED 团队的朋友要跳出来，可能会大声疾呼：“这哥们到底懂不懂啥
叫以用户为中心的产品设 计啊？”当然“以用户为中心的产品设计”，是产品人员所追求的一个 目标。
对于一些没有甲方的客户，UED 团队 当然是设计以用户为中心的设计。
我曾经遇到过一些情况，在充分以用户为中心的产品设计后，用户在体验上确实得到了一些改善，
用户是用得爽了，但是运营部门却无法完成他的指标。也没有 达到高层的满意。 这种情况时常发
生，所以对于产品经理而言，“做正确的事”这个方向上是相当有挑战的，有经验的产品经理可以很好
的把这些需求点进行梳理和统一规划，很清晰 的完成操作。
当产品经理把产品牵涉相关的需求都考虑在内的话？那么成功的方向就离我们不远了？

3. 话虽这么说~但是这样做很难~先来看一张图：
涉众利益相关人的影响
上图其实是架构师的处境(图片来自 SoftWare Architecture in Practice 一书)~非常生动展示了架
构师因为不同涉众利益人提出的各种要求而崩溃了~
The Architecture Business Cycle 对一个软件持续发展的影响就体现在了图中~一个软件一个产
品一种软件架构不仅涉及上面所提及客户，高管，技术人员的影响~~并且在产品的后期 持续性的受
到运营人员 维护人员 市场推广人员的 影响~我所谓的影响就是需求的抛出~

4. 在公司里产品经理会时不时的对技术人员提出某个需求~而产品经理的上头会有一堆人对他提出
需求~~这么看来技术人员是最辛苦也是最核心的人员了~呵呵~高级技术人员可以抑或说架构师，他
们又凌驾在一般程序员之上~对产品进行整体蓝图规划。然后产品（软件或者说软件的架构）在完成
开发之后~再运营维护阶段必然对运营人员~维护人员等产生 influence~然后有返回来影响到这个产
品~~
这个就是所谓的 The Architecture Business Cycle！简称 ABC
The Architecture Business Cycle！

5. 最后我们回到本文的主题：产品经理如何把产品做成功？
根据 ABC 原理 一个成功的产品是具备 可维护性 易用性 可测试性 等重要质量属性的！所以不
能在产品的初期只是更具业务需求来规划产品。不然后期维护可能会很吃力~就是说需要在产品规划
的初期对客户的需求进行考虑之外 还需要对后期维护可能会发生的问题进行科学的搜寻规划~（其
实这些学科在国外都已经很发达~SEI早就有相关的Golden Practice-CMM CMMI 等 后面的文章我
会介绍~）
并且在自己的公司环境下~在权衡所有环节的情况下着重突出最需要的产品设计~这个绝对值一
门艺术 ~而不是科学了~因为这个没有可重复性实践的可能~每个公司都不一样的环境就会导致不
同的环境~即使客户需求一样~不同的工作环境就有不一样的总体需求！就会有不一样的最终产品~
我引用一句话：If it is true that, given the same technical requirements for a system, two different
architects in different organizations will produce different architectures, how can we determine if

6. either one of them is the right one?
这句话就是我上面所说的：即使客户需求一样~不同的工作环境就有不一样的总体需求！就会有
不一样的最终产品~
所以产品经理要想把产品做成功不仅需要充分理解显性需求，还需要充分挖掘自己所处的环境所
带来的隐性需求！并且做出在不同隐性需求之间的权衡~很清楚~这已经不是科学~就是艺术~
把产品做成功是一门权衡的艺术！
什么是产品？传统意义上的产品大概是功能已经定型，可以大批量几乎自动化生产
的东西吧。产品应该功能比较完备，至少是解决所针对问题域的大多数问题。
我们经常听到这样的抱怨：需求又变了，又要增加或修改已有的功能了等等——自己
也抱怨过，呵呵
似乎，我们始终无法产品化的一个原因就是，迅速变化的需求，这让我们始终陷在项
目的泥潭中——软件天生的易变性。
可是，我们为什么不改变一下自己的看法试试？软件的易变性正是其优越于其他传统

7. 产品的地方。
比如，一个主板设计，有一个设计缺陷，在工程样本阶段没被检出来，那么生产出来
的产品就得全部召回。再如，一个主板生产出来后，还能再大幅修改，增强其生命力
吗？
也就是说，我们能否换一种思路，不那么激进，更多的关注于如何做好项目上？关键
点是如何令我们的开发更为迅速，修改更为容易。
需求表述清晰，产品原型：最好需求越清楚越好，然后做界面原型，这个原型最好
是跟技术不是很相关的部门来做，主要从客户的思维和操作习惯、易用性去考虑。给
需求部门演示，如果通过再来进行下步的系统设计。
保持清醒的头脑和理智的判断没有完美的产品该简就简该砍就砍.