技术开发
　　技术开发阶段，这方面产品的工作相对较少。
　　这一阶段，主要是技术在开发过程中遇到问题，产品经理需要一起沟通解决，针对一些技术实现难度大或不合理的地方，需要去想办法解决。另外，我觉得这阶段重要的一点是，需要定期的和技术进行沟通。因为在技术开发过程中，通常也是阶段或者一个模块一个模块的完成的，所以每完成一个模块，产品经理有必要去对完成的模块进行测试检查。
　　这阶段，如果能够尽早的发现问题，改动的成本是小的。在技术开发阶段，不闻不问的产品经理实在是不太好。对，说的是我~自我反省 ing……
　　之所以这一点要重视，是因为技术在实现的过程中，一些看似不起眼的改动可能是需要进行大的框架改动的，甚至代码需要重构。因此，在产品的规划设计之时，框架一定要确保尽可能的无误，并且要跟技术沟通，尽可能的为后续的一些想要实现的功能留有余地。虽然不可能完全避免，但总归是可以减少很多无用工作。尽可能的定期与技术沟通，并且对开发完成的功能模块进行测试检查。及早的发现问题
　　测试
　　测试阶段，一般主要是发现产品开的一些 bug。虽然主要是由专门的测试人员负责，但产品经理也需要参与测试，主要是去发现功能上的一些问题。比如是否有功能缺失，是否有重大的 bug。一些测试发现的问题，也需要产品经理去决定怎么处理，是需要立即处理，还是可以暂时忽略。另外，因为整个功能是由产品经理进行规划设计的，所以实际上，产品经理参与测试，才能够判断产品的实现是否有按照当初的规划进行。
　　这次的代金券功能的测试，仔细回忆了下，我并没有比较好的进行。所以，后面发现，没有自己走一遍功能，有些地方的实现，测试也很容易忽略~
　　不过，虽然有测试，但要知道，测试只是减少 bug 的产生，有很多东西也是测试阶段不能发现的。
　　上线
　　产品在经过了上面的一系列过程之后，需要上线进行使用了。上线通常会有一个内测阶段，例如几个人进行小范围测试，或者邀请一些用户参与内测。上线前，通常产品经理需要做一些准备工作，包括对相关人员的培训，针对相关人员输出操作说明等。我觉得上线前的试用期好是能够长一点，因为这期间能够发现很多的问题，需要快速的迭代改进，才能够拿出一个差不多的版本。
　　在这次的代金券功能上线后，我发现了挺多问题。由于身份角色的不同，产品经理并不是终的使用者，再设计产品时，考虑的角度都是完美情况，但实际的使用中，基本不存在这种完美情况。因为你是产品的设计者，所以你觉得整个使用过程很简单， 没有觉得有什么不能理解的地方。但 too young too naive，事实上，当真正的使用者在使用的时候，一定会喷死你的。“这什么鬼啊”、“怎么是这样的啊”、“产品经理这个傻逼”……表示到现在我还记忆深刻。
　　由于这次正式上线的时间很紧迫，在交付使用时，发现了很多问题。例如在创建代金券的时候， 有一个使用条件字段，我在规划的时候，使用条件有一个专门的样式，所以没发现什么问题。但实际上，运营在填写这个字段时，输入的内容跟设想的差不多少。所以我被吐槽了~更坑的可能是指定投放做的是内部的条件筛选机制，而实际上运营是从外部导入名单的，因此他们一个用户名一个用户名的搜索，然后去投放。 我想，那个时候他们一定是崩溃的。但老实说，在初的规划设计时，真的没人提过这个外部导入功能啊。。。而且，由于时间紧迫，外部导入功能也并不能马上加入。
　　所以，我觉得，产品在正式的上线时，先投入使用一定的使用周期；发现问题后，能够预留一段时间进行。如此反复几次，在进行终的上线， 是比较好的方式。预留较长的一段时间，进行反复的测试迭代，在进行终上线当然，这也印证了我前面说的，只有当产品上线后，实际使用才能发现产品设计的很多不足，很大程度上这是受限于你的身份角色，毕竟实际的工作流程你并不是真正的熟悉，所设计的会有很大出入，而使用者也很难表述自己真正需要的是什么，所以快速的先做出一个小的可用产品投入使用，不要考虑太多的复杂细节和功能。只有在使用过程中，才能发现真正的问题。
　　反馈
　　反馈阶段是产品在使用过程中，不断地寻找发现不足，包括一些测试时没有发现的 bug，没有考虑到的功能，一些功能的设计问题等。这些都需要在使用过程中，不断地收集。可以说反馈是迭代的主要需求来源。
　　结语
　　做产品需要不断的审视自己，不断地反思总结。产品的设计事实上不存在完美的使用情况，你所设想的只是你自己认为的一种理想环境，这种理想环境通常都是不存在的。