目前，在本站上的产品经理偏B端的略少一些 ，技术产品就更少了。因此，作为一个入云计算技术产品坑恰好满10个月的校招菜鸟来告诉你这里的水有多深。
大家可能对云计算领域了解不是特别多，云计算的产品更是见到的更少了。如果一定要来个解释，那么可以给他两个关键词：B端+技术。
首先，本质一致。不管在产品签名加任何修饰词，如：XX产品，那么他们的在本质上肯定是一样的。产品的本质就是寻找用户痛点并提供通用优雅的解决方案。
其次，怎么理解B端？是面向的用户是企业，更多的专注在企业价值传递；C端更多的是向终端消费者提供服务或者价值。
再次，怎么理解技术？就是做的都是与技术有关的产品。技术的范围很广，从云计算服务商的角度来讲，主要是底层的一些基础产品，比如：云计算的五要素相关（计算、存储、网络、数据、应用）。举个栗子，RD们用的云服务器就是非常典型的计算产品，之后的GPU，FPGA等都是计算的相关产品。
最后，云计算产品和非B端非技术产品的能力要求方面确实是有一定差异的。如果你想转到云计算做技术产品或者你是学生想投这一类的岗位，那么好，我们过滤简历的第一点就是有没有计算机背景，如果你是计算机相关专业毕业，那么恭喜你，你可能在硬知识结构上是ok了。第二点，看你是否有写过代码，Java/Python/PHP/ruby/go/rust/c/c#/c++/matlab/hadoop都是极好的，javascript/css/node.js/html也能加分。第三点，看你的产品技能，这个大家都知道是啥。
BB了这么久还没有写正文，这肯定是一个假正经的产品了。是啊，每天都非常严肃的在写产品文档，其实就是想找个地方BB一下。so what~
下面还是严肃的进入正题吧！简单的讲一下我是怎么在入职的前3个月从0到1把一条新产品线做上线的。
一、 追根溯源：需求最初来源于哪里？
先交代一下背景：16年7月份入职不久，老大告知我要做一款消息队列产品，主要是业务发展需要，你先“熟悉一下”。刚接到的时候，真的一脸懵的状态。消息队列？what？业务需要？what？what？what？
其一，作为一个管理学毕业的技术“非常弱”的产品（PS暂且这么说吧，怕有RD潜伏在这里）。消息队列听说过没用过呀！业务上的生产实践就更不用说了。可以说，我的内心其实是奔溃的。其二 ，业务发展需要，是我们自己需要完善产品生态而拓充产品线还是用户反馈的实际需求？本宝宝表示根本不懂。
所以，这里有两个关键问题：
消息队列是啥？它解决了什么问题？什么业务场景用的最多？
最重要的要搞清楚这个需求是最初是哪里来的？用户的真实诉求是什么？
从这里开始就要尽可能多的去掌握更多的信息。关于第一个问题，主要靠自我学习和交流。这里就不细讲了，反正就是各种信息收集过程和尝试。关于第二个问题，需要与老大多沟通多请教，多问用户。与老大沟通没，问用户其实都是一门学问。
二、拨云见雾：怎么了解用户的真实需求？
了解真实的需求的唯一解是用户。怎么去接触你的用户?探索真正的需求绝逼是一项非常非常重要的技能。
首先，有人就说，用户访谈调研呀！电话你会打吧，邮件你会发吧，问卷你会写吧！如果你第一时间真的是想到这些恭喜你，你肯定是一个已经入门的产品。but，你可能不太适合一家创业型的云服务公司。作为一个创业型的云服务厂商，用户体量有限，而且能够用到消息队列产品的用户体量一般都比较大。从统计学的角度来说，如果你仅仅关注自己的已有用户，那么你的样本量实在太小，势必不足以从零碎的需求里面抽象出产品的形态。所以，传统的用户调研、访谈等虽然依旧特别特别重要，但有较大局限性。
其次，有人就说，自己的用户不足，总有别的渠道可以接触用户吧。确实还有其他的一些渠道是很有价值的。从产品的思考路径来说，肯定都是由近至远，由易到难。就我而言，除了已有用户，最大的需求信息采集的就是我司本身，其实我司是我们最大的一个客户。我司，作为一个大体量的互联网公司，各个业务方的需求往往是非常有代表性的，从技术工程部到各个事业群，你都可以接触到相关的真实应用场景，他们的需求、痛点以及解决方案都非常的有借鉴价值。和这些业务团队和中间件团队聊绝逼是超级有收获的，对我而言，有着升华的作用。
再次，有人就说，你司是谁啊，能不能代表全部呀！答案肯定是。虽然我司的体量大，业务类型多，但是我们也不是啥都做。不能代表劳苦大众，那么还能怎么办。作为云计算产品，真正在使用你产品的人其实是RD。接触RD，最好的方法是“打人敌人内部”。其实他们真的很纯粹，业余就喜欢去技术论坛发发帖，探讨技术问题。那么，去各大技术论坛就肯定可以找到他们。在这里只要你肯去深耕，绝对会有超多意料之外的收获。
最后，有人说了，这么找效率低，还有别的办法吗？其实做一个好的“参考型产品经理”很重要呀。你的各种友商就很值得借鉴呀！在云服务商里面，AWS这种鼻祖型的，阿里这种中国风的都值得学习。
番外，其实如果你是一个外表“萌妹子”型的女产品经理（本人刚刚工作的时候还是很萌、很可爱的），相信好多身边的技术大牛啊、同事啊、师兄呀，都非常“乐于助人、共同探讨技术”。
最后可以说，要了解到用户的真实需求需要“无所不用其极”。
三、解决方案：如何优雅地解决需求呢？
总结为一句话就是：以最小的代价 最大化的匹配用户需求实现利益最大化并保留可拓展空间
第一条，说的简单一点，其实是产品的本质。但是在现实中，需要取舍的地方，需要做决定的地方太多了。你做的所有的决定，提出的所有解决方案都需要尽可能的去贴近自身的用户、匹配企业战略。
BB这么多，其实就两点：一是去最大程度的解决用户问题，一是寻找解决的最优路径。
还是举个例子栗子吧！
消息队列产品本身有两种主要形态，一种是中小企业用的比较多的一些流行框架，一种是各企业自研的分布式消息队列方案。光第一种，业界主流的就有rabbitmq/rocketmq/kafka/hippo/tube/activemq/zeromq等等。其中还不包括redis等这种用法的。第二种，企业自研的，比如亚马逊有SQS、 阿里有MQS/ONS、我司有Mafka和NuclearMQ。其中功能、性能、易用性、与用户贴合程度各部一样。
通过各个方面的综合考虑，我们决定为用户提供可以快速部署、易于管理、可以弹性伸缩，具备高可用、高易用、并可以解决多种业务场景需要的消息队列产品。于是就有了我们目前做的100%兼容rabbitmq的消息队列产品。这款产品和业界的分布式消息队列都不一样，有着非常典型的个性化特征。它是100%兼容rabbitmq、主备架构、镜像队列等特点的产品。实现了平台的差异化战略，又非常好的匹配了用户需求。
这里如何去撕逼各方就不再赘述了，反正做完感觉自己老了一圈。心好累……
四、方案实践：项目正式启动
搞了这么多，终于到了产品最幸福的时候，可以开始启动项目了。
1、撰写产品文档
这个不用多说，大家都会。本站的好多文章都非常好，一直在学习中。说个题外话，刚刚开始做产品的时候还是用的Axure，从去年年底是掉入sketch的坑了（顺带安利一下sketch，真心好用）。大家来感受一下当年的青涩，哈哈哈~
2、产品评审，包括内部评审和外部评审
这时候就要再次证实撕逼各方了，好在我们的同事都非常nice，所以没有“哭”给他们看。前提是，大致的技术可行性已经和技术leader对过了，并且中间件的产品方案需要可实现才行，且研发成本也是产品方案的一个重要影响因素。
3、技术评审
这个过程就要过细节的技术方案了，这个时候就要非常非常仔细的去听，去理解。不然有坑你都发现不了。到最后再来补坑就比较尴尬了。
4、进入项目排期
订交付时间，各个环境的上线时间。
5、验收上线
我们有交付环境，测试环境1~4等一轮一轮的验证，每个通过才能最终上线交付给用户。偷偷的告诉你，不能压挂的测试，不是好产品。
五、发布准备：项目启动后，产品还有好多要准备
如果你觉得你可以松口气了，那就too young too naive了。暂时不说项目推进中的各种困难。就说说产品本职工作内容吧。
新的产品线需要准备的东西：
面向用户的产品文档/API文档/产品主页/操作指南等你都准备好了吗？
宣传用的banner和pr稿件你都准备好了？
运营短信和邮件准备好了吗？
定价准备好了？
试用策略想好了吗？
测试、验收了？压测过了吗？去年，产品是兼职测试的。当然，我们现在有非常专业的测试团队了
销售、客服、运营培训做了吗？
…
六、上线后要做的事情
后序的用户跟进、产品反馈迭代、运营反馈跟进等等才刚刚开始。以上才是万里征程跨出的第一步……
七、结束语
作为一个B端技术产品新人，非常感谢老大给我一个机会去做一条新的产品线入门。从0到1这个过程让我收获很多很多，无法一一跟大家分享。我和所有的产品新人一样，都在努力、探索如何做好一个产品，做一个好产品经理。产品之路是一个大坑，但是我一直很喜欢我们学校用来形容老图的一句话：路漫漫其修远兮，吾将上下而求索。
这是我第一次在产品论坛上把我的一些经历和想法分享给大家，由于时间和精力有限，如果有欠妥的地方请大家多多包涵。先在这里O(∩_∩)O谢谢各位亲们。
