从何而来
我理解的产品，它一定是一个解决方案。产品必定有它必须存在的理由，要么是需求方给的，要么我们自己挖掘到用户有需求。这个过程中，最关键的步骤是要非常了解需求，我们才能做出最合适的产品！用户调研，非常重要。大部分toC的产品，我们自己本身就是产品的用户，所以这个时候，我们从自身就可以找到产品的大部分需求；但是这个时候，往往会把产品做到合适“我们自己”使用，而不是大部分用户使用的产品。所以，在需求准备的时候，也一定要扩大调研范围，最起码调查样本的足够大，才能避免在设计开发的过程中，闭门造车，自我感动。另外，如果是toC产品的话，那更加需要做深入的用户调研！连需要用户的使用场景、要解决的问题都不清楚，那怎么提出解决方案呢？而且，这个情况下，最理想地是，用户的每个产品使用场景，发生的频率，发生的起因，经过，结果，都能了然于心。
怎么来
有了需求的list，从零开始，要在短时间内，快速产出第一个迭代的版本，来验证想法和收集信息，非常重要。因为常常在项目初期，很多方向或者需求，其实并不明朗，而且，也不可能明朗。只有把实际的产品做出来，投入到实际场景中，才能看出价值。这个阶段的关键字，我认为是快和精。快就是快速设计，快速开发，然后投入测试。精，有点类似MVP的意思，就是抓住产品的核心功能，只实现主要的任务流，产出一个“最小可用的产品”。投入使用，收集信息，验证想法，计划下一步。
去哪里
把产品推广到哪里去？给谁用？当然是用户啊！如果是有需求方找我们的话，那可能会好办一点，因为我们不用找就已经有用户了，毕竟需求发起方就可以帮我们解决大部分用户问题。那么如果没有需求方，我们要自己去把产品推到他们手中。从一开始的需求调研，我们就已经可以暂时圈定我们的目标用户，这时候没有想到其他更好地办法，唯有通过线上或者线下，“粗暴”地推出去，首先是让目标用户知道我们在解决他们的问题，然后是通过礼物或者其他福利吸引他们使用，再不行，只有直接邀请他们去使用了。
怎么维护
这里就涉及到运营和产品迭代。说实话，我自己对运营实在是，没什么概念，所以就不班门弄虎了。关于迭代，在前几次迭代中，我们可以只关注主要使用场景，在迭代和用户使用过程中，不断挖掘更多需求，但是我会觉得，把一开始的“MVP”做顺做好之后，才进行另一个需求的叠加。因为在这个阶段，收集的信息和需求越多，团队的思维就容易分散，所以在每个迭代，都需要牢牢地抓住一根主线，按照优先级进行设计和开发。每个迭代版本发布出去之后，一定要想办法去验证这次迭代的效果和价值，有助于快速调整方向。
总结
上面说的，可能因为经验不足以及每个产品都有其自身的情况，不能一概而论，所以说的有点空泛。不管怎样，在产品的任何阶段，我们都要想到，怎样在有限的资源下，最大程度的解决用户的问题。只要能解决问题的产品，就不怕没有用户。
