目前这个网站的产品主管少一点，技术产品就更少了。所以，作为一个已经在云计算技术产品坑里呆了整整10个月的校园，我想招小白来告诉你这里的水有多深。
很有可能大家对云计算技术行业不太了解，云计算技术的产品也看的比较少。如果非要另说，可以给他们两个关键词:B端技术。
首先，实质是一致的。不管所有的形容词都加在产品签名上，比如XX产品，那么本质上一定是一样的。产品的本质是找到用户的烦恼，展示通用优雅的解决方案。
其次，如何理解B端？但是，用户是公司，企业价值评估的传递倾注了大量的心血；c端是向终端设备的客户展示服务项目或使用价值。
还是那句话，怎么理解技术？就是做所有和技术相关的产品。技术的范畴很广。从云计算技术厂商的角度来看，主要是一些底层的基础产品，比如云计算技术的五大要素(计算、存储、互联网、数据信息、应用)。比如RD用的云主机就是典型的测量产品，后来的GPU，FPGA等。都是与测量相关的产品。
最后，云计算技术产品和非B端非技术产品在工作能力上确实有一定的区别。如果你想转行做云计算技术产品或者你是学生想走这类岗位，非常好。你对简历有过担心的第一点是，你有电脑，有电脑。如果你毕业于计算机技术专业的大学，恭喜你。你在硬知识体系里大概还行。第二，看看你是否读过代码是很好的。Java/Python/PHP/Ruby/Go/Rust/C/c#/C/Matlab/Hadoop都不错，javascript/css/node.js/html也可以大大增加。第三，看你的产品专长，大家都知道是什么。
BB这么多年都没写过文章正文。肯定是假正经的产物。是的，我每天都很认真的写产品文本文档。其实我就是想找个本地BB。那又怎样~
大家认真进入正题吧！简单说说我是如何在新员工入职的前三个月推出一个从零到一的新产品线的。
一、追本溯源：需求最开始来自哪儿？先说一下情况:2016年7月，新员工上任不久，大哥跟我说要做一个消息队列产品，主要是市场拓展需要。请先“了解一下”。刚收到的时候，我真的是一脸懵。消息队列？什么？业务流程必须？什么？什么？什么？
第一，作为一个企业管理大学毕业的技术“很弱”的产品(PS，这么说吧，就是怕RD埋伏在这里)。消息队列已被听到但未被使用！更不用说业务流程中的生活实践了。可以说我的心其实是碎的。第二，市场扩张是必要的。我们是要完善产品绿色生态，扩充产品线，还是用户反馈的具体需求？本宝宝表现出完全不懂。
因此，这里有两个关键问题:
消息队列是什么？它解决了什么问题？哪些业务场景用的数最多？最重要的要弄清楚这一需求是最开始是哪里来的？用户的真正需求是啥？其实很简单。你需要掌握尽可能多的信息。关于第一个问题，关键在于自我学习和交流。这里就不赘述了。简而言之，就是收集各种信息并进行尝试的全过程。关于第二个问题，一定要和老多数沟通，多请教，多请教用户。你和你大哥沟通过吗？问用户其实都是大学问。
二、拨云见雾：如何掌握用户的真正需求？真正需求的唯一解决方案是用户。如何打动你的用户？探索真实需求是非常非常关键的专业技能。
首先有人说，用户采访调查！可以打电话，发邮件，写问卷！如果你真的在第一时间想到这种祝贺的话，那你一定是新手产品。但是，你很可能不适合个体户的云服务公司。作为个体户的云服务器厂商，用户规模相对有限，能使用消息队列产品的用户规模普遍较大。从统计学的角度来说，如果你只关心你现有的用户，那么你的样本数量真的很少，你无法从零碎的需求中抽象出产品的形态。因此，传统的用户调查、访谈等。，虽然仍然特别关键，但有很大的局限性。
其次，有人说自己用户不够多，所以总有其他方法去接触用户。还有其他有价值的方法。从对产品的思考方式来说，毫无疑问都是由近及远，由浅入深。就我个人而言，除了现有用户，更大的需求数据是我们公司自己收集的，实际上是针对我们其中一个更大的客户。有鉴于此，作为一家互联网公司，每个业务流程的需求通常都是很有象征意义的。从技术设计部门到各个工作组，都能接触到相关的真实应用领域，他们的需求、烦恼、解决方案都非常值得效仿。和这个业务流程和分布式数据库的精英团队聊天很有收获。对我来说，有推广的作用。
又有人说，你的公司到底是谁的？这意味着一切吗？答案肯定是肯定的。尽管它的规模很大，业务类型很多，但并不是每个人都做所有的事情。不代表为群众 *** 劳，那还能怎么办？作为云计算技术产品，真正应用你产品的人其实是RD。摸RD最好的方法就是“在对手内部战斗”。其实他们真的很蠢。业余团体喜欢在技术社区论坛上发帖讨论技术问题。然后，你无疑可以通过去各种技术社区论坛找到它们。如果你愿意在这里努力，会有很多意想不到的收获。
最后，有人说了，有没有其他方法可以发现低效率？其实做好“参考产品主管”很重要。你的各种同龄人非常非常值得效仿！云服务商中，开山的AWS，中国风的元素阿里巴巴，都是值得学习的。
事实上，如果你是一个看似“萌妹”类型的女性产品总监(在自己工作不久的情况下，你还是超级可爱可爱的)，你坚信身边很多技术大神、朋友、师兄都很帮忙，互相探讨技术。
最后可以说，要想把握住用户的真实需求，就要“藐视世界”。
三、解决方法：怎样雅致地处理需求呢？用一句话总结就是:以最小的成本和利润匹配用户需求，实现利润最大化，节省可扩展的室内空房间。
第一个，简单来说，其实就是产品的本质。然而，在实践中，有太多的领域需要做出决定。你做的所有决策，你明确提出的所有解决方案，都必须尽可能贴近自己的用户，与企业的发展战略相匹配。
这么多BB，其实有两点:一是在更高的层面上处理用户的问题，二是找到最优的处理方式。
就拿栗子来说吧！
消息队列产品本身有两个关键形状，一个是中小企业使用的时髦架构，一个是各个公司开发的分布式系统消息队列方案。就第一个，还会有业界流行的兔子MQ/火箭MQ/卡夫卡/河马/Tube/ActiveMQ/ZeroMQ。其中不包括redis等使用方法。第二种，由公司开发，比如亚马逊的SQS，阿里巴巴的MQS/ONS，Mafka和NuclearMQ。其中，功能、特色、便利性与用户的餐饮水平相同。
根据对各领域的综合考虑，我们决定向用户展示可快速部署、易管理、可扩展、可伸缩、高可用性和实用性、可处理各种业务场景的消息队列产品。所以我们有了现阶段大家做的一个100%兼容rabbitmq的消息队列产品。该产品不同于业界分布式系统的消息队列，具有非常典型的人性化特征。100%兼容rabbitmq、主备架构、镜像系统序列等特性。完成了服务平台的差异化营销，很好的匹配了用户的需求。
在这里怎么见面我没怎么解释。简而言之，我觉得自己老了。我的心好累...
四、计划方案实践活动：新项目全面启动做了这么多，终于到了产品最幸福的境地，能够刚开始一个新项目。
1、编写产品文本文档不用说，大家都会遇到。这个网站很多文章都很好，一直在学习。题外话，我刚开始做产品的时候还在用Axure，但是从去年年底就掉进了sketch的坑里(顺便安利了sketch，真的很厉害)。先感受一下当初的柔情吧哈哈哈哈哈哈~
2、产品审查，包含內部审查和外界审查此时此刻，我们需要再次确认我们之间的友谊。还好我们的朋友都很好，所以我们没有向他“哭诉”。前提是已经和技术负责人比较过大概的技术可行性分析，必须完成分布式数据库的产品方案，产品研发的成本也是产品方案的关键影响因素。
3、技术审查这个全过程需要重点的技术方案，这个时候就需要非常仔细的去听，去理解。不然连个坑都找不到。最后补坑会更尴尬。
4、进到新项目排表订单交货时间，每个自然环境的发布时间。
5、工程验收发布每个人都有自然交付环境，接口测试1~4等多轮认证，每个基础都可以最终发布给用户。悄悄告诉你，挂不上的测试不是好产品。
五、公布提前准备：新项目起动后，产品也有许多要提前准备如果你以为可以歇歇脚，那就太年轻太天真了。不用说，项目的进展有各种各样的困难。还是说说产品，做好本职工作吧。
新产品系列必须提前准备的项目:
朝向用户的产品文本文档/API文本文档/产品首页/ *** 作说明等着你都你准备好了吗？宣传策划用的banner和pr稿件你都做好准备？经营短消息和电子邮件你准备好了吗？标价做好准备？使用对策想可以了嘛？检测、工程验收了？压测过去了吗？上年，产品是做兼职检测的。自然，大家现在有十分技术专业的检测精英团队了市场销售、在线客服、营销培训干了吗？…六、发布后要做的事儿之后的用户追踪，产品反馈的迭代更新，业务反馈的追踪才刚刚开始。以上是万里新征程的第一步…
七、结语作为一个B端技术产品的新手，感谢大哥给我一个机会做一个新产品线的新手。从零到一的整个过程，需要我收获很多，这是我不能和大家分享的。和所有产品新手一样，我会努力去摸索如何做好一个产品，做好一个产品主管。产品之路是个深坑，但我一直喜欢高校用来形容老图的一句话:海阔凭鱼跃，路漫漫其修远长。
这是我第一次在产品社区论坛和大家分享我的一些经验和想法。由于时间和考虑，如果有任何问题，请给我们您的意见。在这里O(∩_∩)O谢谢大家。
文章作者为@janezhang，未经批准严禁截取。
注:阅读相关网站基本建设方法的文章，请移至网站建设教程频道栏目。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）