我很幸运，很多问题在深度思考后都会有一个自己的答案，让逻辑自洽，也让自己更为清晰透彻。虽然不知道其他产品狗们会不会和我一样遇到过这些诡异的问题，但我还是想把这些问题和我的答案拿出来，抛砖引玉，期待更为精彩的答案。
做产品几年了，每天都在思考问题和解决问题。在这期间，有一些奇怪的问题让我非常痛苦、非常纠结，甚至整个周末都趴在床上思考这些诡异的问题。有的问题，让我联想到宇宙起源，就如我之前那篇文章《深挖需求，我看到了宇宙起源》；有的问题让我看到了产品生命周期和产品方法论的关系，如《我们需要站在产品生命周期上再谈方法论》；还有的问题，让我看到了人性、哲学、做事的方法论，如《破解纠结症｜决策的时候犹豫不决，如何破？》。这些问题出现时如此奇妙，思考时非常艰难，而通透时又感觉到进入另一个世界。
问题描述：
这个问题我觉得可能大部分产品经理都思考过，即“一切皆产品”。当然其他岗位的同事肯定也有类似思考，譬如设计师（如设计大师贺迈）肯定也思考过“一切皆设计”。
我的答案：
世界上的一切，如一块石头、一个木头、一份炒饭，在没有用产品思维去思考，用产品方法去运作的时候，它们只是石头、木头和炒饭。
但是，如果我们用产品思维去看他们，你会发现：石头可以满足人们建筑的需求、木头可以满足人们铸造家具的需求、而炒饭则可以满足饥饿的人吃饱的需求。它们用自身价值满足人们的需求并获得回报。这和我们现在所做的产品并无本质不同，都是在满足我们目标人群的需求从而达成我们所期望的目标，无论这个目标是否是商业目标、道德目标、还是政治目标。而产品经理们还可以给石头、木头和炒饭赋予灵魂与生命，实现产品经理的目标。
譬如，我国最贵的石头“东坡肉”，被收藏家发现后，与翠玉白菜、毛公鼎并称台北故宫的“镇馆三宝”，价值不可估量；木头，可以在匠人手中被雕刻成艺术品而身价百倍；炒饭，也可以在香港食神戴龙的手中成为绝顶美食。这些普通的事物，在“产品经理”们的运作下即满足了目标人群的需求，更实现了价值的飞越。所以，一切皆产品，但运用之妙，存乎一心。
第二个难题：互联网产品经理到底是做什么的？
问题描述：
既然说到一切皆产品，那我们和那些把石头、木块和炒饭变成产品的“产品经理”们的本质区别在哪里？我们自诩为互联网产品经理，那这个岗位到底是做什么的？为什么我们要研究交互、要画原型等等。
我的答案：
首先，我们必须要明白我们的产品是什么？它不是石头、木块或炒饭、它是互联网产品，和大产品是不一样的。
互联网产品的使用平台是在电脑上、pad上或者是在手机上，是虚拟的，这个和传统的实物产品有本质区别；所以我们要掌握各平台交互规范，学习交互设计精髓，让产品在这些平台上有更好的易用性。
其次互联网产品由公司创造，公司的目标是盈利，所以互联网产品的目标也是盈利，其需要有商业产品，而其他产品的目标则可能是为了公益、社会或单纯的造福人类等等。
最后，现今互联网拥有强大能力，如云存储、云计算、大数据、以及信息链接一切等，这些强大的能力同时会赋予给互联网产品。
所以，互联网产品经理是：利用互联网特有的强大能力，在电脑、pad、手机等平台上规划、设计、及运营商业化互联网产品。
第三个难题：功能脑图、feature list、axure原型站点地图之间的关系？
问题描述：
在产品规划时，我们先会出功能脑图，再出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技术集成的可视化功能组件，所有的互联网产品都是由控件来组成的，所以控件是功能的载体。一个产品分成了很多页面，控件分布在不同的页面上，所以页面是控件的载体。有时候一个功能包含很多小功能，则需要多个控件来完成；也有时候功能很复杂，需要跨很多页面。也有时候，一个大控件上包含很多小控件，可以实现多个功能；一个页面包含多个控件，也可以实现多个功能。
你有答案吗？
以上五个问题，是我思考过、头疼过，甚至要走火入魔的五大难题。最后，我有了自己的答案，这些答案让我暂时通透，但未必一定正确。希望有爱思考的小伙伴们也可以针对这些奇怪的问题提出自己的答案，有可能你的答案就能拨开许多人头上的一层迷雾。
