作为一名产品经理，就是为了解决问题而生的，同样的问题不同的人有不同的解决方法，无法统一。著名产品经理纯银在自己的微博内曾经说过，产品经理的成长没有固定的方法论可言，话虽如此，但是我觉得到各种不同具体的小事情上，都是有固定的方法可参考以至于偷懒的，譬如类似于业务报表之类的小需求。
往往从业务方了解到了需求以后，产品经理要做的事情就会很简单，去确定如下三件事情：做不做？怎么做（包括谁来做）？什么时间做？
我觉得作为一名产品经理，就应该要有自己独立的判断能力，即使是在level比较低的时候，遇到的需求或者问题，都应该先主动给出方案，体现出自己的思考，（哪怕要做的时候再跟领导确认）而不是在自己没有答案的时候，就去询问别人怎么做，那样是会一直没有成长的。回到我们关于业务报表的需求上来，这个需求也是可以按照这样的方法和步骤来做的。
1.做不做？
首先，就是要去了解这个事情究竟要不要做？那么，如何去确定这个事情究竟值不值得去做呢？
答案很简单—投入产出比，也就是说，如果我要做这个事情，我需要投入多少资源去做，做完了以后，我会获得多少的收益？
要回答上面的问题，我们就又要去了解：
这个报表需求产生的原因究竟是什么？
为什么要做这个报表？
这个问题重要吗？有没有更好的（低成本、更快的、方便的）解决方法？
其实这个思考的过程，就是一个内部资源整合的过程，就是考验产品的功力，即如何用最少的资源做出价值更高的事情。每多问自己一个问题，安排资源去做的时候，就会越快。
2.怎么做？
其次，就是这个事情究竟应该如何去做的问题，这些问题我将其分为如下三个纬度：明确定义、把握输入输出、验证结果
2.1.源头：明确定义
从数据报表的角度来说，我们一定要确定每个数据的含义，以及产生这个数据的业务操作。譬如说，如果需要做进销存的报表，报表里面有一个叫做商品售价的字段，就一定得先定义好数据的含义：商品售价究竟是商品实际销售的价格，还是商品在吊牌显示的价格。在业务上，商品吊牌价格是远远大于实际售价的，很少有商品按照定价销售，所以这两者的业务含义差别非常之大。虽然很简单，但是如果没搞明白，做出的报表肯定就会是完全错误的。
2.2.过程：把握输入输出
绘制泳道图的时候的一个原则是，每个角色的任务，一定要有明确的输入和输出。类比于数据报表，定义完成每个表的含义以后，我们就需要了解，这些数据是否可以拿到？我的报表会对这些数据进行什么样的处理？处理的规则是什么？最后就是，处理的结果是什么？如何展示？
这些东西很简单，但都是必须要做的时候明确的，否则在研发执行过程中可能就会出现由于研发不了解业务，导致的开发不符合预期的问题，增加沟通成本。
2.3.结果：验证结果
我们得到了一份报表，那么我们就可以确定这个报表的数据就是正确的嘛？不是的。拿到数据以后，我们也得设计验证的规则来进行验证，譬如说我们在报表内计算的规则是：C=A+B，同时按照业务规则E+D也可以等于A，这个时候业务规则就是我们用来验证结果是否准确的试金石，有了这个验证以后，我们才能较为确定的说，我们的数据结果是没有问题的。
3.什么时间做？
因为资源永远是不够的，可要做的事情却总是做不完，如何给要做的事情排序，是个比较大和好玩的话题，我们可以单独再写一篇文章来说它，但是如果简单的说，其实是有一个基本方法，说到这个方法，大家可能都会比较熟悉，它就是所谓的四象限法则，这个方法的原则是，重要事情的排序大于紧急的事情。不过在使用这个方法的时候，大多数人都会遇到一个问题：不知道什么叫做重要的事情。
从个人管理的角度来看，关于重要的事情究竟是什么，得看你的长期目标，所以这个定义就不一而足了。从企业产品研发的角度来说，对于新功能的研发，多半的长期的目标无外乎降低成本和多赚钱。
降低成本的方法，应用到产品上来说，多数都是提高工作效率，所以在做功能的时候就得进行取舍，提高效率的话，这个功能是提高什么角色的工作效率，这些角色的成本是多少？能够降低多少成本？这些都是可以简单测算出来的
多赚钱就更不用说了，肯定是比降低成本更优先级的任务，因为任何企业，总是爱挣钱大于省钱。赚钱和节省成本一样，也有个投入产出比的优先级差别的。
