自己的项目这周四被公司正式停掉，项目组也被撤掉。尽管老大在找我谈话的时候，委婉地说只是暂停对这个方向的探索，团队转而去做能带给公司直接盈利的方向。但我知道，我们的项目已经黄了，我们手环在IoT领域、在to B方向，一年半以来的探索宣告失败。
老大单独聊天的时候，还真没什么感觉，只是觉得有点可惜。但是下午团队核心成员开会梳理项目当前资源的时候，看着手头的一个个产品，心里真不是滋味。整个会基本上都没说一句话，只是看着tower里的项目list，想着我们这一年半以来做的种种事情。
这两天晚上总是失眠，一直在反思这个被我做黄的项目。毕竟作为全程参与这个项目的PM，对项目的失败有着无法推卸的责任。
“是不是我推项目推得更快点，项目就不会黄？
是不是我对产品稳定性要求再高一些，项目就不会黄？
是不是我们明确领域后能专注一些，项目就不会黄？
……”
明显这些对自己的设问，都被自己否定了。似乎我们探索的很多方向都是一厢情愿的孤注一掷，总是在考虑我们能做什么，每当被质疑现有方案可能更好的时候，我们总会用看似美好后续愿景来麻痹自己。确实没想出来，我们项目在不挣钱的前提下，有什么理由不被公司砍掉。
或许如团队其他同事所说，我们这个方向从立项开始就迟早会被砍掉；或许真的如老大所说，我们在这个方向探索的太前沿，起步的太早，外界的接受度与理解度还没到达一个可以真正产品化的程度；或许如我想的，我们还是没有尽到自己最大的努力……
但是，有些方面是可以总结，以后避免再犯的：
-
to B的产品经理有一半精力在做项目经理
to B的产品很多业务涉及到合作方，彼此都有明确的deadline。一旦项目推进不利，不单单影响自己的产品节奏，还会给合作方带来损失。
这就要求产品经理要及时把控项目进度，明确团队不同角色成员的任务交接点，把一个deadline拆分成多个有明确负责人的deadline。并且在得知遇到问题的时候，能够从产品想办法，及时协助同事解决问题，保证项目的进度不被耽误。
一旦项目遇到不可避免的拖延，需要及时更新同步项目文档，并且告知合作方说清缘由。反正个人体会的项目推进原则就是及时同步各位同事的进度，让团队清楚每一个相关同事的工作进度。
-
to B的产品经理还有一半精力在做商务经理
to B的产品经理少不了要与合作方打交道，往往初期与合作方都是天马行空的聊可能性。当然聊得时候还需要察言观色，了解合作方背后的诉求，不要被别人的大饼所迷惑。另外也不要明确否定别人的意向，毕竟大家都是动态发展的，有些现在还不成熟的条件，后续双方可能还有合作的机会，用开放的心态去了解彼此的能力与诉求。
但是到了具体业务的落地，一定要清楚自己手中的资源，与开发leader在会上明确可行性。同时产品经理一定要清楚，这个合作的点在我们整体项目中的阶段，是不是现在就可以介入，而不影响现在已经开展的工作。
另外不要每个客户都去参与会议，实在是太花时间。先让真正的商务经理帮着挡一下，筛选一遍，开这种会真的真的花时间花经历！
-
to B产品要从一开始就考虑自身在整个产业链上的角色
to B产品在立项之时，就需要考虑清楚以什么角色进入这个行业。我们是提供什么形态的服务？我们做这块有什么优势？我们做这块的弊端是什么？我们应该找谁来合作推进？
这些说起来似乎对各种工作都通用，但是对to B产品尤为重要必不可少，一旦没有思考清楚这些，在合作时候就很难明确自身的定位，也容易对产品形态的边界产生疑惑。
-
SaaS形态的产品需要从一开始想清楚向对方收费的模式
SaaS形态产品往往对接的都是to B客户，业务从一开始就是收费的。并且使用了我们服务的用户也会向其他人收费，所以整个业务模式可能就是to B to B或者to B to C。如果自身的产品合作收费方式非常单一，没有考虑到合作方的收费模式，在没有完全主导权的合作业务上就比较麻烦，对方就会仅仅因为收费模式的问题干扰到后续的合作。因为这种产品外的原因失去潜在合作机会是非常可惜的。
-
在没有完全验证需求可行性的前提下，产品够用即可
其实这点傻子都知道。但是能否顶住压力把控住团队资源，不要浪费在未验证可行性的产品打磨上，在实际的工作中，还是非常困难的。因为产品在上线验证前，老大总会用MVP的原则要求快速上线，怎么快怎么上线。但是一上线，老大就会对产品的效率、bug……苛刻要求。尤其是交付给合作方的产品，一有问题都会在群里反馈，老大看到了也会心烦。这时候产品经理能否把控住验证核心需求的主线就很重要了，该砍得就砍，该后续跟进的就跟进。千万不能被老大的压力干扰了判断，因为老大没有你对项目更清晰。
现在说起来容易，其实这块在真正做的时候非常难。顶住老大的压力真的很难！有个办法，但是比较耗时间——每一个验证，PM在认为已经足够判断值不值得后续投入的情况下，及时写报告发给老大及大家。用尽可能的客观数据来告诉大家你的判断，并且让老大拍板后续的投入。
-
to B的产品设计逻辑重于细节
to B产品的受众少，并且可以直接触及用户，边界的交互场景不需要像to C产品一样去死磕。to B产品在设计上要死磕主线操作的逻辑流程，把主线的逻辑流程死磕通之后，边界场景不要太过于纠结。ui设计上也是同理，做得漂亮不足以把产品卖出去，大方可用就好，不要扣细节。
-
及时跟领导汇报沟通
这不是拍马屁，也不是去邀功。to B产品的方向，作为一枚产品经理真的无力把控方向。不像to C的产品，可以跟着用户的反馈去迭代去改进。to B产品方向的决策大部分需要领导拍板，及时同步项目的进度与进展，以便于领导决策。
其实，有时候真的希望领导能够及时给予方向上的决策反馈！在没有肯定的方向下推进产品，真的感觉很不舒服。
-
切记不要为了做事而做事
极度讨厌部分大公司出来的员工，为了做事而做事，从来不考虑资源浪费的问题。做得事情都是政治正确的事情，肯定没错，但是却在赤裸裸浪费团队资源，错过时间上的潜在机会成本。
没有验证清楚场景需求，加强系统稳定性、提升系统并发数有什么意义？受众客户还没有100个，在设计初期就考虑千万级别的系统架构有什么意义？
做有意义的事，不要为了KPI、为了工作量去做无意义的事情！
-
有了基础功能，承诺的附加功能等合作方有订单再做
to B业务做久了，会发现很多合作方只是看中彼此结合的宣传噱头，为了软文、为了发布会展示。这些合作方前期经常会表现的非常积极、非常配合，然而对业务真正的落地并不上心。这些合作就需要认真来辨别，尽量拿已有的基础功能跟合作方合作，承诺的后续功能不要着急去做，等合作方后面真的愿意配合推广、有真正的实际订单再去开发新功能。
这些能落在合同上就尽量落实在合同上。to B的合作业务开展，合同是个好东西。
絮絮叨叨扯了这么多，没什么逻辑，也很乱。还有很多细碎的想法，现在的状态也没法通通写出来，找时间慢慢梳理一下吧。
我一直认为PM有四个阶段：
第一个阶段：执行力好，能做好已经明确的产品改进；
第二个阶段：能根据用户反馈、竞品动态、业界潮流等，发现甄别需求，进而把该需求落实到产品中；
第三个阶段：能带团队！做新产品，能按部就班的完成产品模型的验证，能做好新产品的冷启动；做成熟产品，能根据手中资源带出产品与运营的节奏；
第四个阶段：找到适合自身产品的商业模式，变现挣钱；
现在觉得自己还是在第二阶段到第三阶段的过渡期吧，已经可以很顺利的完成产品模型的验证与冷启动，但是如何从内部说服老大要到资源、从外部更明确量化验证需求可行性，把产品做大做强还需要更多的历练。
感谢这一年半的IoT场景的to B产品经历，让我接触到更多有趣的垂直行业；让我开始从硬件、固件、软件……各方面思考产品；让我在技能上可以一个人肩负项目、产品、交互、视觉、测试的相关初期任务；让我开始从更高的维度去思考产品的定义与节奏。尽管项目以失败告终，但这次项目学习到的东西都是之前做纯粹to C的大体量产品无法涉及的，对个人成长有很大的帮助。
毕竟这是自己做黄的第一个项目，有着如初恋一般的纪念意义。我还是坚定的相信我们这个失败项目的初衷，相信未来的某一天会继续把这个项目捡起来，我依然还会全身心的扑上去！
Team
网友评论