最近总是在瞎忙，糊里糊涂的，对照着技能树一看，技能点加歪了，思考了下，决定先把主线技能强化一下，于是诞生了个想法，写一个产品设计系列的文章，分别是要不要做，如何做，如何做好。
市面上有很多类型的产品经理，虽说title都一样，但实际上做的事情可能相差很多。
虽然很多时候低LV的产品是没有决策权的，但准确的来说应该是不同LV的产品经理决策颗粒度是不一样的。
比如CEO决策的力度可能是在生意层面，要不要做什么事， VP/总监决策的颗粒度在战略层面，通过什么样的路径去做，高级产品经理决策的颗粒度在战术层面，通过什么样的方式去达成这个路径。
更低LV的产品决策的颗粒度就在这个东西要怎么做，文档怎么写，用什么交互方式，按钮放左边还是右边，文案用什么…
Title不重要，重要的是肯定有那么一个或几个人在决策着上面说的那些事。低LV的产品可以通过攒经验值和观摩高LV的产品是如何做事、如何思考的来提升自己的LV。
回到决策上来，虽然你不一定能决策战略战术，但对于需求你还是有一定决策权的吧，比如XX部门提了个XX需求，或者客服反馈来XX用户要求我们做XX，这个时候你是怎么做的，直接就做么？
这个时候就回到了源头，先看要不要做这个事情，然后再看如何做，做都不做的话，那后面就没有必要浪费时间继续聊这个事情了。
我个人理解的要不要做，分为两部分，首先是要不要做，其次是能不能做。
简单举个例子，承接一个单子，能稳定有30%的收入，要不要做，你心想肯定要做啊，稳定30%啊。
这个时候你一看订单金额5千万，需要提前垫付20%的资金，如果你能满足条件，那这个事就能做，不行的话，这个事就没办法做，你再想做也不行。
要不要做
很简单，看这个事的前置条件是否成立，以及利大于弊还是弊大于利。
放到互联网行业里来，那就是需求本身是否存在，市场大不大，做之后的价值如何，需要付出怎样的成本，下面我们来分别看下。
需求分析
这部分又可以分为3个层面，分别是需求本身是否存在，是否是需求的全过程，以及需求价值是否一致。
首先来看下第一个问题，需求本身是否存在，毕竟这才是想要解决问题的源头。
不再赘述，3+1理论直接砸上来。
- 什么人在什么场景下的什么问题？
- 是否是目标用户？哪一类人？在产品中的优先级如何？
- 高频么、大众么、刚需么？
- 解决之前用户是怎么处理的，解决之后呢，反应在数据上会有什么变化？
第一个问题默认已经有结论了，再来看第二个，啥叫全过程？
以电商为例，对用户的核心价值就是能选到自己心仪的商品，然后物美价廉的买到。
那用户需求被满足的过程就是：看到商品》浏览商品》下单》支付》收到商品
这就是满足用户需求的主流程，在这个主流程被满足之后，再考虑其他分支流程。
优先级最高的事情，肯定是和这个主流程相关的事情。主流程都没有打磨好的情况下，什么换肤啊，小游戏啊，下拉进二楼啊这些乱七八糟的功能最好先别考虑。
最后是需求价值是否一致。
这个问题就是上面那个问题的延伸，比如现在要做换肤功能了，虽然有一定的价值，但是和产品提供的主价值并不相符。
这个时候就需要结合着产品的阶段再来看需不需要做这样一件事，是继续满足同一群人的不同需求，还是满足有相同需求的不同人群。
价值判断
假定需求是成立的，这个时候我们需要看的就是这个事有没有价值，以及价值有多大。
从整个模式的角色来看，有用户、产品、公司。对用户而言，就是用户价值，对产品而言就是产品价值，对公司而然就是商业价值。
如果产品仅有一个角色的话，那只需要考虑这一个角色的价值即可。如果有多个角色的话，那就需要考虑多角色之间的价值变化。
对C端用户而言，最直接的价值就是多、快、好、省以及have fun。
就是字面意思，更多的选择，更高效的需求满足，更优质的解决方案以及更便宜，然后是好玩、有趣。
假定我们做了这件事，和没做之前对比，用户能不能感受到上面说的那些价值。
如果是多个角色的话，就多角色分析，C端用户同上，其他的角色可能有名誉、利益的诉求，这个时候就需要判断做这个事情对多方价值的影响。
最好的结果当然是价值都增，最坏的结果是多方价值都减，有增有减的情况下，需要看的就是平台的价值观，以及认为哪些用户比哪些用户更重要。
产品价值就是能不能加强产品的服务能力，提高数据指标、效率和用户体验，以及强化产品的壁垒。
商业价值无非就是能不能直接赚钱，能不能间接赚钱，比如提高品牌知名度、提升组织的效能。
成本估计
主要就是技术成本、运营成本、推广成本、时间成本、机会成本…
以用户昵称这个功能点为例，功能看起来很简单是不，不就用户换换昵称嘛。
实际上，这个功能重要且复杂。
凡是用户自定义的东西都可能会出事，所以昵称要接敏感词库的吧，有的公司还需要专门有审核团队来审核用户的昵称，有时动不动再开个什么会，这个时候昵称是不支持修改的，这个还需要能够支持动态配置。
用户频繁的修改昵称就会出现上面那一系列的问题，这个时候让不让改？不让改的话，一个月让改几次，未认证和认证的用户是否有差异？
不能改的话，用户肯定会过来问，会过来投诉，客服团队要处理的吧，对应的产品和技术也都要处理的吧？
另外是否支持运营人员给用户改昵称，支持的话，都要给哪些人这个权限，运营修改的昵称和用户自己修改的重复或者冲突了怎么办？
看上去是个简单的功能，但后续的这些处理起来都是有成本的，这些是都需要综合考虑进去的。
需求存在，有价值，成本合理可控，再来看能不能做这个事。
能不能做
一方面是自己能否做这个事，另一方面是在外部环境的约束下能否做这个事。
自己能不能做，主要就是看能力储备了，一是能力，二是意愿。
能力就是技术、产品、运营和资金，意愿就是比较虚的使命、愿景、价值观。
能力意愿兼备最好，再不济也得占一样吧，两样都不占，那这个事成的希望很渺茫。
外部环境，主要就是竞争、市场和时机。
竞争就是当前的环境，毕竟不同的格局下可以采用的实现方式和要求的速度是不同的，而且需要明确的是和对手相比，自己的优势和能建立的壁垒在哪里。
传统行业可以几年甚至几十年不变，但互联网行业，竞争是非常大的一个变量。
市场一方面是容量，另一方面是存量还是增量。容量在需求分析的部分已有初步的结论，存量和增量则会影响着增长速度和竞争格局。
时机就不用说了，往大了说是所谓的风口，浪潮，往小了说是产品阶段，节奏。
综合考虑内外部因素，再加上潜在的政策、技术等影响来判断这个事自己能不能做。
最后
结合着要不要做和能不能做之后，就能有一个初步的判断了，在确定要做之后，才是如何去做，也就是下一篇文章的主要内容。
