三年来产品失败的教训，对我的启发！
成功的产品遍地开发，失败的产品更是野蛮生长，本文和大家一起聊聊失败的产品有哪些因素。
一、文章前沿
每个成功的产品背后有着无数个角色的支撑，当然失败的产品背后隐藏的事件并不比成功的少。
其中可能包含着领导层面的希望、有产品经理废寝忘食想出的方案、有工程师没日没夜的敲出一行有一行的代码，还有设计师上线了不知改过几稿的效果图。
可是以我最近几年做产品的经验来看，C端产品百分之80的产品都是不赚钱的。
做出一款成功的产品难，做出一款赚钱的产品更难，做出一款持续赚钱的产品难上加难！
近几年大家都知道国家层面大力支持数字化转型，从而来延伸出来很多B端软件服务商，领导何尝不知再从用户身上赚钱变的非常苦难。
不如做软件服务商，为各大企业和政务部门做定制化服务，只要合作一次基本就可以养活一段时间，也就出现了大众级现象“半年不开张，开张吃一年”的说法。
后面又想从B端领域中延伸出SaaS服务，这样既可以为大客户提供定制化，又可以为小客户提供按需求收费。
这种情况延伸至今，不知道大家有没有想过这种模式如果也赚不钱了怎么办？
我也不知道，但是总会有人开阔新的路子，就像BI，元宇宙，又或者是Web3.0。
未知的先讨论到这里，文章接下来会告诉你这几年来做产品失败的一些原因，希望可以在你工作的过程有一丝的帮助。
二、产品现象
近几年我拜访过很多互联网公司，团队模式都差不多唯一不同的可能是着重点不一样。
有的是——产品驱动，另一种则是——运营销售驱动。但一般来说销售驱动产品的占大多数。
当我询问他们目前还存活产品时，为了避免企业销声匿迹都会举例出一两个，但是当我深入产品看的时候，大多也会以数据不足和还在优化中推辞掉。
有些公司做的是正式的商业模式，有些是非正式的。
但无论哪种方式无非都需要归结到最后的三件事：
- 它会赚多少钱？
- 需要花费多少事件和金钱？
- 做成的概率有多大？
一旦一个想法排在首位，产品经理第一件要做的时间就是与利益者交谈，充实这一想法并提出合适的“需求”。
一旦收集到需求，用户体验团队（假如有这样的团队）自己来规划产品方案，与领导层面来探讨方案，接着与开发，设计沟通，然后再交付产品要求和规范交给工程师。
还有一种现象，有的公司在某一领域做的时间久了，会缺乏创新，即使创新，也会出现抱怨缺乏创新以及创意到客户的手中需要很长的时间。
PM可能会认识到，虽然现在市面上都是跟随敏捷开发，但实际的问题反而会出现更多。
我们要做的就是为企业连接这些点，本文的观点会告诉你为什么常见的工作方式，实际上是导致大多数失败产品的根本原因。
1. 团队构建的不同
其实在工作当中我们会发现很多有趣的事情，虽然产品经理加上来经理二字，但是实际工作中有权利的人屈指可数，更多的是当需求的搬运工ing，角色之间的传话筒。
公司当中有产品总监，技术总监，有的完善的还会有项目经理，呃这么多角色，想找个背锅的人都找不到，你会发现很多时间产品总监交代的产品交付和技术总监的想法是不一致的。
为什么？因为他们的角色权重不一样，产品总监需要把产品变成钱，变成可持续利用的摇钱树。
但技术总监就不一样，他首先要考虑的是：技术难度和时间周期。
用大白话展示就是两个角色“尿不到一壶”更别说项目经理。
建议：如果该公司是产品驱动，那就把全部的权利交给产品总监，不管是开发设计还是运营测试。
这样有什么好处？让目的达成一致，让各部门之间的协作更加无障碍。
2. 商业路线路
很多公司做了一段时间没发现商业模式走的通，想要快速发现，我实际上赞成做成商业案例的。
因为如果需要融资这是非常好的路子，但是这个路子就是有一种，那就是风险，好比赌博，你压大还是压小。
因为在这个阶段谁也不知道会出现什么情况，还是文章开头的一个观点在这个过程中，你会花多少钱，赚多少钱。
在这个阶段我们对于这些可以说没有任何线索。我们不知道我们能赚多少钱，因为这在很大程度上取决于解决方案的效果。
如果团队做得很好，这可能会非常成功，并从字面上改变公司的发展方向。
另一方面，事实是许多产品创意最终一无所获。这并不是夸大效果，字面上没什么。
无论如何，产品中最重要的一课就是知道我们不知道的东西，而在这个阶段我们只是不知道我们会赚多少钱。
同样，我们不知道建造成本是多少。在不知道实际解决方案的情况下，这对于工程来说是非常难以预测的。
大多数有经验的工程师在这个阶段甚至会拒绝给出估计，但有些人被迫采用旧的“T 恤尺寸”折中方案——只要让我们知道这是“小号、中号、大号和超大号”。
但是公司真的想要那些优先的路线图，为了得到一个他们需要某种系统来评估这些想法，所以人们玩商业案例游戏。
建议：在这个过程中，可以先增加试点，比如你是为零售行业做数字化支持的，发现手中已经有了一些忠实客户，可以先询问他们的意见，先让一些客户免费使用这些产品。
如果到时候真的可行那么继续延伸，如果不行也不会有什么损失。
3. 产品经理的角色
这其实是一个和设计角色类似的故事，为什么在实际工作中其他部门会时常Diss你，对你的方案视而不见。
因为你在他们心目中并不能得到认可，一开始的不认可会让你很难受，因为这些工作都需要他们来完成。
因为你看起来并不是那么成功，说不定只是个纸上谈兵的理想。
我凭什么听你的。比如领导下发来一个需求，让你这周搞出来，你看了一眼手里的方案，又看了看已经三天没休息加班的同事，你于心不忍，但老板并不领情。
你还是要去得罪人，到时候项目上线一堆BUG，效果图难看至极，可是没办法，老板让上线。
最后毫无疑问产品失败了，领导对你的印象又有了新的定义，
你说你会不会被辞退呢？大概率会。建议：询问机制，当有新的需求产生时，先想几个问题？
- 为什么要做这个需求？
- 需求什么难点？
- 完成这些我需要什么资源？
事件开始钱必须要想清楚这些问题，盲目的开展必将失败，如果你担心觉得领导觉得你不专业，你可以先不管他，一定要把自己的方向弄清楚。
有需要你还可以不停的追问它，我想他不会说你很烦，即使有管他呢，我也是为了工作（这个观点有风险，谨慎使用）概率在1：6吧。
希望你听说过精益创业方法，这是替代方案的核心。
关键原则是减少浪费，最大的浪费形式之一是设计、构建、测试和部署一个功能或产品，结果却发现它不是我们需要的。
具有讽刺意味的是，许多团队认为他们正在应用精益原则。
但他们遵循我刚刚描述的这个基本过程。然后我向他们指出，他们实际上是在以我们所知道的最昂贵，最慢的方式之一来尝试想法。
三、写在最后
我学到的关于产品的最重要的事情之一是，无论你多么聪明，都无法逃避这些事实。
而且我有幸与许多真正出色的产品团队合作。真正的区别在于你如何处理这些事实。
如果您的公司仍在运行这个陈旧且过时的流程，那么希望您能对此有所了解并开始向未来过渡。
并且希望你能在你发现自己被一家能够比你更快、更有效地行动的初创公司或竞争对手打乱之前做到这一点。
作者：王秀琴，微信公众号：产品有个洞；智慧产品产业、SaaS企业高级产品总监
本文作者 @王秀琴 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
