终于决定从《银行互联网创新的七宗罪》这篇文章延展一下，慢慢开始梳理系列文章，结合银行的移动金融产品及互联网产品的管理经验，理出踩过的坑，管用的招，供银行互联网金融项目管理的同僚交流。
定位，是一个产品出发的原点，本篇我们只说定位之战。
一、谁的痛点
一般来说，领导总会在生活的某个不经意间，感触到一些细微的需求，心想“啊，如果是这样就好了”，于是这个痛点被通过微信也好，短信也好，快速的扩散到项目的潜在负责人手中。这样的痛点之争，不仅限于自己的领导，也同时涉及到部门B端客户的领导。
而普遍项目的潜在负责人，一定会高度重视领导诉求，于是哪怕是一个小功能需求，也会当做重点项目来剖析，于是，一个项目需求出现了。
其实普遍来说，领导的需求会比较碎片化，更适合做OKR的管理目标，然而项目负责人却很有可能把领导需求揣测为一个以KPI为基础的业务发展目标。
我相信很多企业都是以领导痛点为基础的，但是领导痛点与用户需求之间并不能完全划等号，举个例子，领导觉得面粉是必要的，但人人都一定是要吃面条吗？不一定。还有面包、包子、馒头、饺子等一系列的需求在排队。
但你要说领导觉得“人人都要吃馅饼！”，先不说领导说出这话是否合情合理合身份，但作为一个项目经理却不加以引导指正谏言，那就有点“扯犊子”了。
有时候在需求原点分析的时候，最怕的就是妄加揣测，不是以市场诉求为出发点，而是以“听力理解”的方式来分析，这样的痛点，与得了皮炎后搔挠几下无异。
尤其在面向B2B2C这种业务模式的时候，中间的B端领导通常会有更高的需求，但是这种需求是随着你的业务新增出来的，最终的C端是否买账其并不直接负责，往往最终C端的实际需求实在是难以与前面两个B端的领导规划完全一致，最终不是项目推动不下去，就是C端不买账中间B端单方面下架。
这种坑不仅是我，还有很多朋友都踩过，痛不欲生。
因此B2B的业务或者B2C的业务其实都比B2B2C的业务要容易，而要达成B2B2C的模式，确实是需要很多技巧去平衡痛点来推动的。
同时一个真正优秀的项目管理，一定是自下而上帮助领导厘清核心逻辑的，自上而下的项目除非事关生死存亡，否则还没见到有哪个掀起过大的波澜的。
二、SWOT
SWOT分析是项目管理里面的基础模型，其实大家早在上学的时候就被折磨得够呛，然而我们即便不用那么刻板的把S.W.O.T画一个田字格一个个罗列出来，也起码应该拿出来与参加项目建设的所有人员一起分析一下。
起码你在出牌前，就算你不去分析别人手中可能有哪些牌，也得先看看自己有那些牌吧，闭着眼睛出牌就实在有点说不过去了。
S.W.O.T
我们已经有的资源是哪些？
这些资源能够被我们调动到什么程度？
目前这条资源链是否通顺？
这条资源链上面的协调方的需求是什么？
这条资源链对于我们的项目还需要补充哪些资源？
资源的获取渠道有哪些？
新资源获取过程中需要协调的关系方有什么需求？
用户与现有资源及新增资源间的关系如何？
我们与潜在竞争的业务关系如何？
我们的业务壁垒有哪些，是否能够在一段时间内抵御新增竞争？
当然我们发现很多银行项目，并没有真正理清楚这条路，这就有点接近在黑暗森林蒙眼狂奔，没撞到树全凭运气，或者也可能是因为根本就没跑起来。当然朝一个方向瞎跑和没跑都不算是最可怕的，最可怕的是反方向跑，往返跑，绕圈跑等等。
我们曾经就经历过，需求确实存在，场景确实优质，然而当开发完成后，才发现，场景的切入具备强烈的行业门槛，这种门槛不仅是技术上的，还有核心从业背景上以及行业信用上的，最终开发成本已经支出，但是市场推动遇阻，而重新熟悉市场的过程中，产品已经逐渐被市场淘汰。
因此SWOT不是为了充实一份报告篇幅用的，是真的需要放在战略位置上去深入思考的。
三、时间敬畏
就算上面的SWOT我们全都思考了一遍，我们也应该将视线再次往远处看，项目的近中远期要做什么。我们提出了点线面的进阶式分析考量。
如果是以点为基础，那就是类似工具型服务，做好一个细分服务；
如果是以线为基础，那就是交互性服务，做好与一类业务集合的连接服务；
如果是以面为基础，那就是平台化服务，做好与各类关联子集的整合与数据协同服务。
这样的划分也并不是说点线面谁好谁差，而是不同的方向起点均有不同的发展路径，面向未来我们都需要准备好不同起点的可能方案。在精益创新的体系之下，从点带线扫出平面似乎是更好的规划流程。我们遇到了很多产品经理项目经理，更多的只是在意最终的产品形态，而忽略产品形态发展过程中的时间维度，动辄就要甩出“我们要做XXX行业的XXX”这种不负责任的"片汤儿话"，或者很多银行项目总是心想着，项目做完就完了，项目不就是这样吗。
然而一个移动互联网项目，投产上线只是最最初级的事情，真正最难的反倒是在时间维度中根据每个节点的市场情况不断打磨，不断的根据市场反馈去找到真实契合自身的战略方向，而在这个过程中，时间是永远都不可忽略的。
所以即便我们去看对手，也不能只看最终形态，而要看起点和所经历的各种事件。
因此，如果阿里没有淘宝，你让它在现在这个阶段凭空做出一个支付宝，也一样是极其艰难的任务，如果微信没有QQ，让他现在做出一个微信，同样的结果。
四、盈利考量
银行项目由于混业经营限制，普遍没有丰富的收入科目，导致了银行项目多数并不太多的考虑盈利性，而是将产品与银行业务的直接营销效果进行关联。
但是每一个移动应用的背后，都是一整套靠流量经营思维支撑的业务模式，我倒是认为，是否收钱是一回事，而具备商业价值的资源设计却必不可少。
回归到上述第二点，我们不仅需要了解现有资源，还需要了解在项目执行过程中我们能够创造多少新的资源，这些资源有时候不是为了项目开发而设计的，却是为了整个项目的市场格局以及未来运营而服务的。
“不以结婚为目的的谈恋爱就是耍流氓”，不以盈利为目的的商业组织比流氓还流氓。不管你如何定义自己，盈利都是第一要务，只是在实现的过程中盈利的路径，谈判方法不一样。
就算你敢仿照互联网说你的项目早期不盈利，那对于银行的互联网金融项目也应该和所有人说明白中远期是怎么盈利的，为什么能盈利。
五、市场定义
市场定义这件事情，其实更考验的是项目管理者的心术，我们通常听到一个项目自我评价颇高，然而市场反响平平。如果发生了这样的事情，不如让自己回归项目的原点，好好考问一下，自己是谁？项目是什么？
大部分的项目管理者在项目规划管理的时候，给自己赋予了过于明确的身份定位，同时项目的样本普遍还是周围的这一波职人，整来整去终究是一类人，一类人看待一个项目的看法往往是从组织内出发的，因此项目定义这件事情，你会发现从口吻到实质定义都是一个内部定义。
这种内部定义对外界，对市场，普遍是无感的，一个越是无感的事物，它的沟通成本也就越高，这种沟通成本早期或许不会体现，但在未来会愈发明显的体现在开发，推广，运营等各个层面，让你苦不堪言，欲哭无泪。
我总是觉得，无感是比讨厌更可悲的一种状况。
其实我们每个人都是市场中的一个普通个体，然而是否能够卸掉自身的角色，让自己回归一个最普通的用户，往往是最难的，所以我也觉得产品经理可能更需要学习的不是产品，而是人性。
关于定位方面的内容，大概就是这些，如果非要简而言之的话，就算你嫌麻烦，看不上各种定位分析，那最最起码应该弄清楚以下几点：
我到底是什么？
我需要什么？
我能给予什么？
（本资讯于 2017-07-04首次发布）
