五个让我走火入魔的产品难题，你有答案吗？思维导图

这个问题我觉得可能大部分产品经理都思考过，即“一切皆产品”。当然其他岗位的同事肯定也有类似思考，譬如设计师（如设计大师贺迈）肯定也思考过“一切皆设计”。

世界上的一切，如一块石头、一个木头、一份炒饭，在没有用产品思维去思考，用产品方法去运作的时候，它们只是石头、木头和炒饭。

但是，如果我们用产品思维去看他们，你会发现：石头可以满足人们建筑的需求、木头可以满足人们铸造家具的需求、而炒饭则可以满足饥饿的人吃饱的需求。它们用自身价值满足人们的需求并获得回报。这和我们现在所做的产品并无本质不同，都是在满足我们目标人群的需求从而达成我们所期望的目标，无论这个目标是否是商业目标、道德目标、还是政治目标。而产品经理们还可以给石头、木头和炒饭赋予灵魂与生命，实现产品经理的目标。

譬如，我国最贵的石头“东坡肉”，被收藏家发现后，与翠玉白菜、毛公鼎并称台北故宫的“镇馆三宝”，价值不可估量；木头，可以在匠人手中被雕刻成艺术品而身价百倍；炒饭，也可以在香港食神戴龙的手中成为绝顶美食。这些普通的事物，在“产品经理”们的运作下即满足了目标人群的需求，更实现了价值的飞越。所以，一切皆产品，但运用之妙，存乎一心。

既然说到一切皆产品，那我们和那些把石头、木块和炒饭变成产品的“产品经理”们的本质区别在哪里？我们自诩为互联网产品经理，那这个岗位到底是做什么的？为什么我们要研究交互、要画原型等等。

首先，我们必须要明白我们的产品是什么？它不是石头、木块或炒饭、它是互联网产品，和大产品是不一样的。

互联网产品的使用平台是在电脑上、pad上或者是在手机上，是虚拟的，这个和传统的实物产品有本质区别；所以我们要掌握各平台交互规范，学习交互设计精髓，让产品在这些平台上有更好的易用性。

其次互联网产品由公司创造，公司的目标是盈利，所以互联网产品的目标也是盈利，其需要有商业产品，而其他产品的目标则可能是为了公益、社会或单纯的造福人类等等。

最后，现今互联网拥有强大能力，如云存储、云计算、大数据、以及信息链接一切等，这些强大的能力同时会赋予给互联网产品。

在产品规划时，我们先会出功能脑图，再出feature list，最后落实到axure原型站点地图。他们之间的关系曾让我非常纠结，我不知道他们三者是不是要完全一致，还是一对多，多对一，亦或其他。譬如我之前规划邮件APP，收件箱邮件列表和文件夹邮件列表里都有批量操作，并且功能完全一样，那我在功能脑图、feature list及axure站点地图我要怎么放置这两处的批量操作？

对于这个问题，首先我们要弄清楚功能脑图、feature list和原型站点地图是给谁用，实现什么样的目标。脑图，主要是给我们自己用的，使用脑图可以让我们完全发散式的思考，遍历一款产品可能有的所有功能，然后筛选出本次迭代的功能。

在确定了的迭代功能后，我们需要记录这些功能到feature list，让开发人员知道本次迭代有哪些功能，而开发人员会根据feature list来拆分任务及安排开发计划，这个开发计划是产品经理跟进项目的依据和指引。

接着，开发人员会对照feature list和axure原型的站点地图来找到原型，并对照原型开发产品。所以，在我之前规划邮件APP产品时，我会在功能脑图里，分别在收件箱邮件列表和文件夹邮件列表写上“批量操作”，即两个地方都要写，告诉自己这两个地方都要做此功能。但在feature list上我只会写一个批量操作，而同样在axure站点地图上也只写一个批量操作，只需在原型稿里体现两个地方均有此功能即可。

所以，脑图和feature list并不需完全1对1，feature litst可以整合脑图中几个一样的功能为一个功能，这样给开发人员传达信息时也比较明确清晰，只需在原型中详细说明哪几个地方也需要此功能即可。而因为开发人员会feature list和axure站点地图来安排开发，所以feature list和axure站点地图最好是一样的。

《用户体验要素》说在战略层要做用户分析，我们在实际中也会在产品规划前做竞品分析。但用户分析和竞品分析真的只在产品设计之初吗？

正如问题描述那样，我们习惯性的在产品或功能规划之前做用户分析和竞品分析。但其实这是远远不够，我们不仅需要在战略层考虑到用户和竞品，也需要在产品设计的每一个阶段考虑到用户和竞品。

举一个例子：在结构层，我们设计产品的交互框架时，我们需要考虑到我们用户的交互偏好与交互认知；也需要考虑到对比于竞品，我们的交互框架的优势与劣势。

所以，在产品设计的每一个阶段我们都要心怀用户，分析这个阶段我们应该如何为用户做设计；同样，我们也要考虑到相对于竞品，我们在此阶段的优劣及该如何取长避短。所以，用户分析和竞品分析需贯穿整个产品设计。

需求和功能是什么关系，我们常说做了一个功能是为了满足用户的一个需求，但大功能可以拆分成小功能，那用户的大需求可以拆分成小需求吗？需求和功能一一对应吗？；而功能、控件和页面又是什么关系？

需求&功能：一个需求可以分解为很多小需求，一个功能也能分解为很多小功能，每个小功能都对应着一个小需求，譬如存储客户资料是用户的一个需求，但其实这个需求包括存储客户名称的需求、存储客户昵称的需求、存储客户电话等等小需求。

功能&控件&页面：控件是IT技术集成的可视化功能组件，所有的互联网产品都是由控件来组成的，所以控件是功能的载体。一个产品分成了很多页面，控件分布在不同的页面上，所以页面是控件的载体。有时候一个功能包含很多小功能，则需要多个控件来完成；也有时候功能很复杂，需要跨很多页面。也有时候，一个大控件上包含很多小控件，可以实现多个功能；一个页面包含多个控件，也可以实现多个功能。