如何從0到1做一條雲計算的新產品線?

目前，在本站上的產品經理偏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潛伏在這裡）。消息隊列聽說過沒用過呀！業務上的生產實踐就更不用說了。可以說，我的內心其實是奔潰的。其二 ，業務發展需要，是我們自己需要完善產品生態而拓充產品線還是用戶反饋的實際需求？本寶寶表示根本不懂。

所以，這裡有兩個關鍵問題：

1. 消息隊列是啥？它解決了什麼問題？什麼業務場景用的最多？
2. 最重要的要搞清楚這個需求是最初是哪裡來的？用戶的真實訴求是什麼？

從這裡開始就要儘可能多的去掌握更多的信息。關於第一個問題，主要靠自我學習和交流。這裡就不細講了，反正就是各種信息收集過程和嘗試。關於第二個問題，需要與老大多溝通多請教，多問用戶。與老大溝通沒，問用戶其實都是一門學問。

二、撥雲見霧：怎麼了解用戶的真實需求？

了解真實的需求的唯一解是用戶。怎麼去接觸你的用戶?探索真正的需求絕逼是一項非常非常重要的技能。

首先，有人就說，用戶訪談調研呀！電話你會打吧，郵件你會發吧，問卷你會寫吧！如果你第一時間真的是想到這些恭喜你，你肯定是一個已經入門的產品。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了。暫時不說項目推進中的各種困難。就說說產品本職工作內容吧。

新的產品線需要準備的東西：

1. 面向用戶的產品文檔/API文檔/產品主頁/操作指南等你都準備好了嗎？
2. 宣傳用的banner和pr稿件你都準備好了？
3. 運營簡訊和郵件準備好了嗎？
4. 定價準備好了？
5. 試用策略想好了嗎？
6. 測試、驗收了？壓測過了嗎？去年，產品是兼職測試的。當然，我們現在有非常專業的測試團隊了
7. 銷售、客服、運營培訓做了嗎？
8. …

六、上線後要做的事情

後序的用戶跟進、產品反饋迭代、運營反饋跟進等等才剛剛開始。以上才是萬裡徵程跨出的第一步……

七、結束語

作為一個B端技術產品新人，非常感謝老大給我一個機會去做一條新的產品線入門。從0到1這個過程讓我收穫很多很多，無法一一跟大家分享。我和所有的產品新人一樣，都在努力、探索如何做好一個產品，做一個好產品經理。產品之路是一個大坑，但是我一直很喜歡我們學校用來形容老圖的一句話：路漫漫其修遠兮，吾將上下而求索。

這是我第一次在產品論壇上把我的一些經歷和想法分享給大家，由於時間和精力有限，如果有欠妥的地方請大家多多包涵。先在這裡O(∩_∩)O謝謝各位親們。

 

本文由 @janezhang 原創發布於人人都是產品經理。未經許可，禁止轉載。