一般来讲，互联网产品所谓产品设计与需求分析，大都是针对使用APP产品的用户而言。
而在实际的工作生活里，拷问你的却不仅仅是你的APP用户，还有
大 boss、小领导、运营、UI、项目经理、程序员（java开发工程师、iOS开发工程师、android开发工程师、前端开发工程师）。
一次完整的产品迭代，大约需要和以上所有人进行两到三轮的争辩、解说。
常言道，撕逼是产品经理的核心技能。
这样说不好。
之所以这样激烈的争论，也因为作为产品经理，不了解用户需求。
APP的使用者是你的用户，你会做用户调查、需求分析、数据统计，各种高品位、眼花缭乱的调研分析。
那么，为什么到最后，APP还是没能满足用户需求呢？
因为，首先没能满足：大 boss、小领导、运营、UI、项目经理、程序员（java开发工程师、iOS开发工程师、android开发工程师、前端开发工程师、XX开发工程师及XX开发工程师）的需求。 /真的不是在黑程序员/
在需求分析-业务流程梳理-原型设计-UI／UE设计-程序开发-测试-上线，这整条生产线上，一旦某一个人或环节的需求没能得到满足，最后的结果与初心就会错位，整条流程就扭曲。
到最终用户手里，APP已经不知道被扭曲成什么样子了。
是滴，APP的直接使用者，是最终用户。
在最终用户之前，还有第一轮用户、第二轮用户。。。。。。
其实，我认为产品经理才是最终用户。但是，先不废话。
首先让我们来应付一轮轮用户。
第一轮：大boss。
这事儿能不能做，全在大boss一句话。大boss的需求是什么？
名利。
这个词搁在产品上，那就是。
投入产出比。
干这事儿，需要多少钱，能赚回来多少钱。
投入产出比的计算需要什么呢？
需要运营数据的支撑，这事能增加多少的用户停留时长、新增多少用户注册、提升多少的用户活跃度。
然后呢？
投入产出比很好，你能保证实现么？
风险
风险控制，补救方案。
为什么需要版本控制呢？还不是出了问题可以追查问题的成因，乃至版本回滚。
所以风险点在哪里？时间、地点、人物、情节。
合适的时间、合适的地点、合适的人、做了合适的事。
合适有两点。
产品迭代过程，如何保障这个合适能合适，就是产品迭代过程中的风险。
产品上线后，怎么保障这个合适，就是产品运营过程的风险。
这个坑太大，不废话。
这里就有一个风险：大boss是不是同意你的产品迭代方案。
所以，要用PPT，而且PPT一定要写的漂亮，直观，不要废话。用图片、极简报表和大字来标示。
为什么要用PPT？
一大堆数字，谁看？
大boss可没功夫看你写的需求文档。
多长时间、多少人、花多少钱做了多少事。
以及：
多长时间、赚多少钱。
共：六个字段。
PPT要简约大气。
所有纷繁的表象一定可以用一句极其简略的话描述出来，如果你不能做到。就说明你没有看透表象，不能把握本质。
如果说认为自己把握到了本质，却组织不出语言／公式来表达，说明你没有抽象化世界的能力。换而言之，你太弱了。你没有实现用户需求的能力。
大boss要在最短的时间内，了解到这事花多少钱、又能赚多少钱。
第二轮：小领导
大boss说了，这事咱得做。
谁做？出事了谁负责？赚钱了谁分成？
背锅的先找好。
工作计划书
项目组人员安排，每个人在什么时间，做什么事。
工作流程前前后后关系。关键节点事件决策人是谁。安排好。
从这一步起，从战略开始执行，天上的云啊，要落地。
事儿相当的多。
倘若，没计划、没规矩。
结果就是一团乱麻。
每个人找不到自己的位置、发挥不了自己的能力，就只能是公路没画线、十字路口无指挥。
新司机七扭八歪的乱开车，老司机横着开车。
车祸现场，惨不忍睹。
这口锅，扣在你头上，那是跑都不要想跑。死路一条。
最好是个表。
不是买表，是excel表。
时间、地点、人物、事件。
把握好时间线。
这是一曲乐章。
每一个人都是一个音符，在恰当的时间，进入到恰当的位置。
各就各位。
第三轮：运营
时间节点备好了。
需求分析搞定了么？
运营说这个能有效果么？
这个不好看。
有人说，人人都是产品经理。
所以你个产品经理就悲剧了。
具体到页面，各有各的想法。每个人都指手划脚两三下。完蛋。一张白纸成了泼墨画。
这个没啥文档。只有弹药。
BAT这么搞的。行业惯例是这样子的。用户习惯了。你看iOS系统就这样子。
咱们抄的xxx的。用户想要。领导让这么干的。。。。。。
反正别说这是你的想法。
因为人人都是是产品经理。
当然，你要是能搞定运营的妹子，那随便你造。
运营的妹子需要啥？
啥都要。
各种各样的小工具，小公举。别增加工作量，没时间化妆。
我不想说了。下一轮。
第四轮：UI／UE设计师
一般，都是妹子。还比较好说话。
但是，想要优美的设计。
一定要跟妹子说清楚，层次感。
层次感。
原型图又称线框图。
重点就在线、框。留白。
字段要明确，页面结构要直观。
搞设计的都是好妹子，要爱护。
第五轮：程序员
不能黑程序员。
如果你说的话，程序员没听懂。
一定是你逻辑没理清。
是你的锅，没得跑。
程序员的路，若、则；若、则。
若，你说话，程序员没听懂，
则，你逻辑，没理清。
好好玩俄罗斯积木。
我也不会玩。
逻辑！逻辑！逻辑！
你要把一棵树上的每一个纹路都弄的清清楚楚，明明白白。
这样子，程序员们绝不会跟你废话。
他们认为把精力浪费在你身上是可耻的，还不如码会代码。
所以你是可耻的。
第六轮：测试
别较真。你不行。
先说系统崩溃没。
再说功能实现没。
然后看UI图对上没。
最后问还有多少bug没改。
别问什么时候能上线。
上线什么时候都行，主要是能不能用。
第七轮：项目经理
你把时间表做了，就没他什么事了。
这一轮为黑而黑。
第八轮：发发发
最终用户，伺候好了。
有钱花。
第九轮：你自己
这是正儿八经的最终用户。
产品的好与坏，你都跑不了。
这东西，你做的。
是你的勋章还是你的编号。
看你想打造一个什么样产品。
你就是你的产品。
你就是你的产品经理。
吐槽结束了。下面是正文。
产品经理的核心能力，是发现需求、满足需求。
万事万物皆在其中。
发现父母的需求，满足父母的需求。
发现女朋友、媳妇的需求，满足女朋友、媳妇的需求。
发现人性的需求，满足人性的需求。
发现自然界的需求，满足自然界的需求。
发现众生的需求，满足众生的需求。
这就是菩萨乘。
网友评论