把问题从开放转向封闭，是创业者做产品定位过程中最重要的能力，最艰难的不是做什么，而是不做什么。事实上，在产品设计过程中，关于优先级分歧是普遍存在的。反复讨论和分歧的解决有利于后续开发顺利进行，但评判标准是什么呢?硅谷顶级工程师Nicholas C. Zakas为评判产品设计中的优先级建了一个坐标系，初衷是解决工程师与产品负责人评判标准不一致带来的沟通障碍。但对于创业者而言，它值得反复琢磨，因为大多数人没有想清楚自己在做的事是不是现阶段最值得做的事。
每一个创业团队也许都经历过这样的挣扎：
A重要 耗时X月
B重要 耗时Y月
C重要 耗时Z月……
在资源有限、竞对环伺的情况下，ABCD到底该怎么排序呢?
Nicholas C. Zakas 现任职于 BOX，他曾是雅虎首页前端主管，编写过包括《Maintainable JavaScript》在内的多本技术书籍。 作为顶级工程师，深度参与产品设计开发，Nicholas多次看到工程师花大量时间在一些他看来非常小的细节上。这些细节的重要性与其所占据的优先级并不匹配，本不应被分配如此大的注意力。
事实上，在产品设计过程中，做与不做的分歧是普遍存在的。分歧不是坏事，反复讨论和分歧的解决有利于产品后续开发顺利进行。但分歧出现后，最终该以什么标准拍板，做与不做的评判标准似乎并不明晰。
Nicholas思考了产品负责人会遭遇的初始问题，他的答案是人尽皆知的两个指标 —— 投入的成本和产出的价值。但他将二者作了详细拆分：
获得的价值是什么?
对不同人的标准可能不一样，对于产品负责人来说，它界定的对象是产品所有可能功能，评估的要点是一项功能对用户、产品或公司整体是否提供了有意义的点。在一个健康的组织里，产品负责人会根据市场情况、自身优势来综合判断价值。
价值意味着这些：
1.竞争优势
产品负责人应该创造出用户有需求的东西，这意味着着他们不会选择用其他的方式(比如竞争对手们在做的)来满足自己的需求。
2.销售量
这项工作能让你所在的企业获得更多的用户，或者拿到更大的订单量。
3.用户满意度
触到用户的痛点，不管是通过解决Bug还是通过增加新功能。这是确保现存用户留存，同时赢得良好的声誉的关键。
4.战略
你想做的东西能否会让公司在一个更大的战略层面取得一个领先地位，比如，公司可能想进入新的领域或者进军新的地区。
当然，判断价值可能还有其他的参考标准，但上述标准将是主要的驱动因素。如果你无法从任何一个点来定义它的价值，那就不要做无用功了。
付出的成本是什么?
付出对不同的人意味着不同的东西，但从根本上说，它意味着完成一项任务所需要的工作量。它的衡量指标有：
1. 需要的人力
一个2人耗的任务毫无疑问比一个1人耗的任务工作量更大。当然，工作量的增加可能并不意味着人数也要随之倍增，可以通过一些尝试让需要多人协同的工作更有效地开展，从而减少人力投入。
2.需要的时间
当给出了合适的人力之后，它需要花费多少时间来做这事?当没有足够的人力时，它需要多久?如果事情进展并不顺利的话，它又需要花费多久?掌握工作的每一个条块需要花费多久非常关键。
3.复杂性与风险
工作的难度不完全由时间来衡量。越复杂的工作，产生或留下BUG的可能性越高。一个变动的复杂度越高，带给系统的风险就越大，谨慎程度也应随之升级。
计算一项任务的工作量时，可能还应该考虑其他因素，但基本上以上是主要的参考点。
多年以来，Nicholas一直用下图这个坐标系来考量工作中的一些抉择。纵轴是该项工作所提供的价值量，它延长的方向代表价值的提升。横轴代表工作所需要耗费的工作量，轴线往右工作量越大。
最有趣的地方在于，分析一项工作分别投射在价值线和努力度上的位置。
上图有四个象限，他们因投入产出比不同分为四类：
1. 唾手可得
这指的是只需要付出一点努力就能完成的低价值度工作。落到这个象限的事务类型通常会人带来这样的感觉，“不妨一做”，它需要付出的工作量等同于得到的价值，所以这是值得做的。
2.妙手生花
这指的是只需花费少量努力就能得到极大价值的事情。它可能不会经常出现，但当做了这件事后反馈回的结果天壤之别。Nicholas有过的经验是，当他在雅虎时，作为工程师他曾同某些Ajax请求的性能问题作斗争。“当时我们发现由于一个错误配置Ajax响应没有被压缩。这个例子中，只需要花费几分钟时间我就能解决这个问题，它对性能带来的改变则是巨大的，甚至是天翻地覆。”
3.苦心孤诣
这指的是需要花费很多努力从而得到较大价值的事务类型。比如重新设计一个应用或者升级一些底层架构等。把时间花在这些事情上可能不是最有趣的，但它是有价值的。
4.差劲透顶
就像它的名字所暗示的，这指的是低价值但需要耗费较多精力去完成它。它付出的工作量远超该工作量所获得的价值，这意味着你在浪费时间(同等工作量情况下，如果有更高价值回报的事务，你可能更应该去做那些)。
有75%的事情值得做
落到具体执行时，问题就出现了。在产品开发中，很有可能，工程师和产品负责人分别有自己认定的坐标轴。工程师可能会知道这项工作需要花费的时间，产品经理可能知道它能提供的价值。如何确定某项工作会落在这张图的哪个部分呢?
让产品负责人和工程师给自己的那部分进行赋值，分数的区间分别在1~10.你有75%的机会得到结论，这个工作是可以接受的以及是值得做的。
而从创业者角度来看，分清自己做的事处于哪一象限至关重要。
在工作量上，它们的排序如下：唾手可得≈妙手生花
,
