基本上多数论坛说教都在讲“如何做产品经理，成为产品经理的方法”等诸如此类的观点，但真正讲到其核心的是非常之少，也时常局限在“title”本身，对于大多数没有判断力的用户来说，完全是误导，抛开实际的产品、业务、逻辑、市场去谈如何做产品经理完全是耍流氓，鸡血类的文章看看就得了。

衍生的例子也诸如“如何做一个优秀的CEO”，实际上真正优秀的CEO考虑的都是如何做好公司。也就说想做好某个具体的职位，那么应该以职位范畴的项目为出发点，而非停留在title本身，毕竟过于理论化的东西只是基本的层面，也并非按部就班，下面进入主题。

现在所存活的优秀产品，基本都建立在良好的业务规范、解决问题的需求、优秀的用户体验、强大的运营手段等综合因素。也存在大量的死掉的产品，但这也不足以表明背后的策划者就是没水平的，毕竟不确定因素太多。

对于产品经理本身而言，每个阶段都有其重点的目标去实施，但有两个基础的点是必不可少的：对需求的把控以及业务的深入理解。前者为策划的来源，后者为策划的实施，相辅相成。

---

对需求的把控：

每个项目策划的背后都有一个需求池，如果没有，请完善建立。需求池基本会融入不同角色（运营、市场、用户、老板等）的产品需求，那么在每个迭代节点具体做哪些方案就取决于其优先级，这种优先级完全是根据状况分析而来，而并非某个角度或产品经理本身直接判断所得。

说白了，就是如何说服团队成员去做这个功能，这个迭代方案。可能很多产品经理考虑自己本身就是策划者，认为无需被干涉，但这种想法基本是比较极端的。就像建筑师一样，如果没有说服为什么要如何这样的方案，那么基本上相互之间很难理解，甚至可能怨声不断，盖不好一座房子。

但考虑到没有不可能满足所有人的观点、需求，因为作为产品经理而言，至少要进行迭代方案的缘由阐述，让大家理解即可。

对于杂乱的需求池，如何筛选需求？有个实操的方式：

1.将本次迭代的外部需求+上次遗漏的需求整理成列表；

2.对每个需求进行需求来源、需求场景、需求解决的问题重点分析说明；

3.根据分析所得，进行优先级的排列，并进行简要说明；

这样好处是对每个需求都有仔细的判断与分析，同时又保证各个来源需求的完善处理。

---

对业务的理解：

一旦本次迭代的需求确定了，那么对业务的理解能力就需要足够到位。假如把迭代的方案比作“人体”的话，那么从骨架到造型、从细胞到血液，精确到最小颗粒度，产品经理也能完全讲明白任何细节性的功能，同时对整体的扩展牵连又需具备良好的囊括意识。

如果在策划阶段，产品经理出现细节性的差错或遗漏的地方，那么补“坑”是件很麻烦的事情，策划后与设计、技术的对接出现问题，十有八九是业务出现问题。

不要遗漏需求，不要出现业务混乱，不要没考虑好就进入迭代开发。对业务理解的越透彻，进度与质量越顺畅。

对于不同形式的业务来说，如何保证基本的规范？

1.整理每期迭代的所有功能逻辑；

2.梳理每个功能涉及的元素、事件、交互方式；

3.进行关联业务与扩展的说明。

一个简洁而见效的方式是：以用户实操的角度，从头到尾走完迭代的所有业务，使用完所有的功能，这自然会发现很多业务问题。

---

上面所谈的“做”产品只是其中的几个点，目的只是让大家多去想想产品业务本身，而且只是盯着“title”去看，而真正的产品从0到1会涉及非常多的事物。

基本上你懂得如何“做”产品，也就明白如何做产品经理，title真的没想象的重要，好比历史的将军，优秀只会注重如何打好每次战役，而非如何一味学习如何做好将军。

---

“Timekr”文章均为一线原创，禁止转载、摘录等，尊重原创，阅读价值信息。