产品需求是为了解决用户在某个场景下的操作，需求发生的具象是故事，产品经理需要学会将具象的故事抽象为产品需求。
产品经理太不容易了，就想桥梁工程师一样，除了把桥梁的设计搞定，还要监督实施工作，跟进具体的项目进度，以确保把自己的思路能够完整的执行下来。
所有的产品设计想法都是用户（这个用户可能是你产品的用户、产品经理、项目组同事、老板以及竞品）的故事，把用户故事简化为需求就是产品设计的过程。
而通过把需求实现的过程，产品经理需要依托于迭代和开发，不可能一口气把产品能够做到尽善尽美的。需求通过迭代释放，迭代完成需求的积累和搭建。需求就像一口水井，版本就是盛水器，通过版本和迭代来控制盛水的容量，这就是产品开发的节奏。
迭代视角的产品经理必须在认知和行为上都了解这个过程，这样才能保证产品的质量和速度兼顾。当水井里面的水越来越少，盛水器所需要的线就越来越长。同样，对于产品经理来说，形成的压力也会越来越大。
有时候产品经理会寻求一个大的版本来释放更多的需求，但是这时候产品经理没有能力去承接这个大版本规划，导致出现该版本迭代的周期越来越长，一旦加快速度，则质量也会越来越差。渐渐地，感觉到产品力不从心，违背了自己的初衷和主观意愿。（往往产品经理在这个阶段扛住了就成长了，没扛住就会否定了自己的能力。）
从某种意义上来看，产品经理应该在需求管理上做到严格的把控，当需求池的内容增多时，应该对需求进行优先级排序，让紧急重要的需求优先开始做，把其他的需求先放一放，因为在做产品的同时，我们应该去习惯来自不同的需求，并且做好甄别的方式和方法。
产品经理的职责并不是去消灭需求池，而是针对于需求做出符合用户预期的产品。
其实产品经理都应该很清晰，我们在做产品的核心版本时，核心版本的成功率会随着时间周期的延长而下降，一般根据John的经验，APP核心版本开发上线最好不要超过两个月，小程序产品的核心功能开发上线不能超过1个月。
有些小伙伴在问：为什么产品经理要做好版本管理和项目管理？其实版本管理和项目管理是保证产品能够成功交付，以及后面产品经理做自我回溯的（方便存档用）。
如果版本管理没有控制好，导致核心版本的需求特别大，那么承载的周期就特别长。所以笔者建议：先砍掉核心流程不相关的功能，把核心流程实现出来就可以了。那么针对于核心流程or第一版本开发，产品经理也可以用MVP（最小可行性产品）的模式来迭代开发。
根据个人的经验，除了核心流程的开发，MVP的模式主要是在讲述用户故事上做简单化处理。给用户讲一个最能理解的故事，然后把这些故事的主要功能提炼出来进行开发，在开发完后交给用户使用。（先让用户跑起来）按照道理来说，MVP的迭代应该是最好的一种迭代方式。故事脉络清晰，功能点燃烧层次分明，容错和纠错成本最低。
举个例子：原来在做电商产品的时候，前期挑选符合种子用户的商品，通过积累用户的数据后，找到用户的精准画像，针对商品的频次和客单价维度，GMV达到了1000W后，然后上线了优惠券系统和增加商品维度以及促销体系，一步步迭代，节奏还是挺适中的。
但是我们在做产品的同时，我们需要去思考版本的核心点，这个核心点是需要去寻找产品的核心用户和做产品的核心功能。这里笔者建议需要寻找的用户够精准，方便MVP产品版本做减法，达到最优化。
所以MVP是最小可行化产品：最小能保证速度，能够在最小版本内快速开发迭代。可视化保证的是用户能感知到，是做给用户的产品，而不是非功能性产品。要让用户感受到产品的快速变化，小步快跑，快速迭代。
产品的节奏来说，肯定是从不完美变得日臻完美的。也就是笔者经常说的，产品前期一定是可用的，然后变成易用，最后到好用，直至让用户疯狂的。
但是针对于MVP化产品来说：
- MVP产品就是小版本快速试错找方向，能够直接感知产品能不能被用户快速接受；
- MVP纠错成本低，每次独立模块的迭代，也能减少开发成本；
- 产品规划的问题后面看，小范围跑起来达到一定的效果后，再回头看产品具体规划的模块和细节；
- 不要怕产品死亡，快速迭代化的死亡是能降低时间成本，半死不活最可怕。
互联网产品公司与传统软件公司最大的区别就是产品小步快跑，快速迭代。
或许产品经理做产品的过程就是不断踩坑的，当然，后面能填坑的产品经理才是优秀的。
作者：John，产品狗一枚，产品狗聚集地。欢迎一起沟通交流。
本文由@John 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash, 基于CC0协议。
,
