在把最后一个按键弹窗交互做完后，便匆匆地上传更新到蓝湖，甚至自己都没来得及多看两眼，便马上准备着如何在十多分钟后给开发人员去讲整个模块的设计思路了，这种情况，像这样似乎总工作在慌忙中的工作状态，已经持续了半年多了。
之后，凭借自己在该模块做了较长的时间而强硬性地看似一帆风顺般地将自己的思路和字段对应的数据来源娓娓道来，好像终于把这个模块给交付完成了。殊不知，后面实际开发中，却总是会被问到些奇奇怪怪的问题，然后，发现好像有个地方没有考虑到...
于是，对于已经交付出去的项目模块，你又不得不时常停掉自己中途正在做的项目，去一个个地处理上一个项目出现的问题，因为菜，有些涉及后端数据库的问题你还不能自己做主，转头去向上司产品总监帮助，在他的一顿分析和建议下，仿佛一个更大的漏洞和好多的没有考虑完成的点一点点暴露出来。
可是，你想不明白，在当初做时，不光自己做的已经很累了，也在尽自己的努力去把这个模块做好，还不时地向对应的用户人员去寻求建议帮助，可为什么，还是会出现这种在开发人员正开发中时相继出现这种情况呢？状态总是没能考虑完全，界面体验没能发挥到更好。
就这样，在工作之余，你看着自己画的原型，想看看自己在最一开始是怎样的思考方式将结构和界面布局按如此方式进行设计，在这个模块上面花费了这么久的时间，前前后后设计的思路有什么转变。从起初接收到这个项目的大致轮廓，还不知要做什么，到后面自己去捋逻辑或结构若有不懂的点询问上司或其他人员到自己终于知道要做什么时，再到最后完成的界面草稿提交获得通过时，中途自己都做过了什么，那些重复返工和时间效益很低的中间环节究竟是如何产生的，自己又是犯了什么错，没能在第一时间处理和考虑好，后面再做其他模块时这样的错误还会不会重犯，如果现在重来，从一开始接受到项目后，我又会怎么做。
或许，会先看一些竞品，而且要透过竞品的界面本身，看内部的不仅仅只是分类，字段和操作等等方面，将自己有疑问和不好的点提前做好记录。可以去向用户寻求帮助，不光能把不懂的问题解决掉，还能熟悉他们的工作业务流程和背景，能避免后续设计时有些不确定的点和状态设计时自己都没有信心去这样对他人讲设计的原因是什么。之后将需求进行分类和梳理，完善功能架构图和业务流程图，再开始界面的布局和设计。如果这次重来，自己将不光在进行界面绘制时变得思路清晰，方向明确，还能在后续完成界面交付前有更多的时间去一遍遍地浏览自己的原型，将体验和细节做到更细。
所以，产品经理工作的方法非常重要，就像高中的化学方程式一样，开头试剂加错了，那反应结果就是完全不同的两个东西。
在讲产品方法之前，需要先询问自己几个问题？
你会因为感觉时间很紧急，而急于想着先把简单的原型界面画出来吗？
你会在模块构思前期，就因为一些数据来源太广，或者状态太多，就觉得需要更多的table栏来展示它们吗？
你会在还没有把功能架构图梳理完全，考虑细致的情况下，就开始画原型图了吗？
...
如果你有，那慢慢再继续看下去，看看你犯过的错是不是如此的真实。
产品经理是一个产品的头部，老话说不要用战术上的勤奋弥补战略上的懒惰，根本就不是一个层级的东西弥补不了。方向调错了，执行力越高反而让结果离成功越远，所以产品掌舵好产品的方向是多么地关键！
我们可以这样来推想：产品要朝着既定的方向开发——原型需求不能出错——需求分析、需求对接不能错——对竞品分析，领略功能的要义——明白开发相关功能的目的和作用——知道业务、操作背景，业务上的痛点痒点——参考别的竞品，综合分析，再提炼。呃，似乎又回到起点了，你要对你要做的东西实际用处有了解，要解决的点是什么。
可以发现，无论你参考竞品也罢，自己去梳理采集需求也好，都有个前提：
你自己对于业务背景要有自己的理解，知道业务上的痛痒点。
通常情况下，对于一个业务背景的理解程度为0的情况是几乎不存在的，要么有项目经理会带领大家一起探索真伪需求，要么产品可以实地地到真实业务场景去采集体验。通常情况下，对于竞品的理性挖掘，是高效而实用的采集需求的方式，特别是对于还处于初版，开始设计的项目来说，成本小开发周期短。
那么竞品我们如何去看待呢？
竞品，是已经成熟而且商用化较为成功的在线商品，它的功能可能很复杂体验也很完善，但是，你要从中判断出哪些功能才是这个商品最底层和重要的功能，这部分功能才是你目前开发的项目中，最需要去分析和考察的。竞品诸多的数据和功能结构会为你在业务背景熟悉方面有很大的帮助，并且对于整体无论是宏观上的概念还是末节上的信息都能起到参考警示作用，不至于遗漏掉一些重要但不太容易考虑到的地方。
之后，当对整体宏观上的流程有大致了解后，结合自己采集和收集到的需求，结合实际情况，分析业务场景。在边整理梳理功能模块的同时，画出业务流程图。
业务流程图：对于熟悉的模块，会非常轻松容易。但对于半熟悉甚至相对陌生的领域，业务流程图的梳理将会非常耗费精力，你不知道会有什么操作，操作后会有什么情况，异常，然后怎么处理，怎么解决等等在你都不了解的情况下，即使去看过竞品和网上查阅资料或者简单地询问相关人员，得出的流程图方向错误的概率依旧非常大。
因此：此时我们在梳理业务流程图时，面对不太熟悉的模块和领域，我们应当尽量按最小功能可实现来开发MVP。通过用尽量少的成本失去产品上线，在真正的上线过程中获取真实的用户数据，再来改进设计时，方向感和目标感就会非常明确清晰。造成的后果也将尽可能地小。
综合所述，对于产品经理来说，工作方法的正确引导，在工作任务上其实是在做减法，在工作效率上是减少后续持续的推倒更改而做加法。这一正一反，将极大加快产品的工作进度，并且项目有着极高的韧性，后续的调整改进会非常方便。而且，即使出现错误和偏差，也至于造成非常严重的后果。
1.梳理出最小，最通用的业务背景，其他异常情况下视情况做简单的处理；
2.提炼出核心功能，重要功能，非必须功能等；
3.整理出最小业务功能架构图；
4.原型绘制......
这，就是最简单的产品工作方法，持续在这样的工作方式中，后续需求分析，结构思维，逻辑思维等等都 将随着更多的项目和对业务背景的了解，而自然逐步提升。
