如果你正著手打造自己的創業項目,那么通常會希望產品能盡快被用戶接受,并帶來實際的回報。這意味著你要以最小形態來發布產品,并確保用戶樂于為之付費。接下來,你可以基于用戶的更多需求和期望來設計和開發新的功能,而不是根據你自己的想象替用戶決定哪些是他們想要的。本文中,我將根據自己的實際經驗為各位介紹一下怎樣以真正最小的形態發布產品,并通過不斷傾聽用戶的聲音來使你的產品逐漸成熟起來。
怎樣確定第一版的必備功能
我們可以以很小的形態作為起點,但你仍然需要規劃清楚哪些功能是產品所必需的,哪些功能可以為用戶帶來價值并使他們樂于付費。建議你考慮以下兩個主要的問題:
你的目標用戶是誰? 你的產品可以幫他們解決怎樣的問題?
對于我們自己的產品來說(Perch),目標市場是那些設計代理公司及自由設計師。具體來說,我們的產品是一款CMS(內容管理系統,例如Wordpress、Drupal、Joomla等),不過我們沒有意圖將它打造成某種傻瓜式的建站工具。我們的目標用戶就是那些我們曾經合作過的人:小型設計代理公司和擁有HTML、CSS代碼能力的自由設計師。他們需要的不是復雜的建站系統,而是能夠幫他們管理作品內容的工具。我們的CMS同樣會面向那些有能力開發小型站點的人,不過我們并沒想成為Drupal的競爭對手。所以歸納起來,我們的目標用戶就是那些有一定前端開發技能的,需要建立小型站點的獨立設計師或設計代理公司。
我們很了解這個群體,而且他們也了解我們。我總是建議,如果你要打造一款新產品,那么所面向的最好是你自己已經樹立起名聲和口碑的那部分市場;這會讓你的產品更容易傳播,因為人們已經對你有所了解和信任。
我們希望這個產品能解決兩個主要的問題。第一,它的部署方式要足夠的快速和簡單;一個小型站點不該需要用戶花費幾天的時間來創建頁面模板。第二,我們希望提供一種足夠純凈的代碼方案,在HTML、CSS和JavaScript中沒有任何不必要的東西出現,以便設計師們可以100%控制CMS的代碼輸出。
以上就是我們的產品所要面對的用戶群體以及所要解決的主要問題。接下來,我們產生了大量的功能概念設想,但是我們始終把目標用戶和核心價值記在心里,所以反過來又無情的砍掉了很多想法,直到我們覺得剩下的功能可以支撐起一個最小形態的產品。最初版本的Perch花了我們四周的時間去設計和開發——當時我們還在幫客戶做著其他項目。然后我們又用了差不多相同的時間去搭建推廣網站以及用來發布產品的必要基礎。
充滿自信地發布產品
一切就緒之后,你要充滿自信的將產品發布出去。也許你有一份包含大量功能設想的清單,希望把他們都做到產品當中,但是用戶不知道這些。沒關系,只要你的目標用戶有困難需要解決,而你敏銳的識別到了這些問題,并在產品中提供了解決方案,那么它就應該可以賣的動。快速發布最小化產品的方式有一個重要的好處,就是你可以在投入大量資源設計開發更多功能之前對產品的核心價值進行驗證。
在“最小化”和“可行”之間找到平衡點,傾聽用戶的聲音,驗證你的想法,持續改進。
不要因為你給用戶帶來了僅包含很少功能的產品而道歉,只管去推廣好了,注意要準確的將產品的功能范圍及專注解決的問題告訴潛在用戶。假設人們已經購買并開始使用你的產品,那么你很快就會收到新功能需求的反饋建議,而且其中有些建議很可能會讓你感到驚訝——雖然用戶提出的需求當中會有一些是你已經設想過的,但就我個人的經驗來說,他們所提到的一些需求會是你從來沒有想到過的。
我們并沒有聽到過哪些用戶覺得我們的最小化產品是缺斤短兩缺乏誠意的,因為我們在推出產品并進行宣傳的時候就已經明確的讓市場知道了我們的特色,我們的營銷策略與產品自身是保持一致的。而且我們發現,最初的那些用戶會因為我們在改進產品的過程中傾聽了他們的意見而感到非常開心;如今我們有很多忠實用戶已經使用Perch創建了大量的站點,他們當中的多數都是最早的那部分用戶。
精益創業代表了一種不斷形成創新的新方法,它源于“精益生產”的理念,提倡企業進行“驗證性學習”,先向市場推出極簡的原型產品,然后在不斷地試驗和學習中,以最小的成本和有效的方式驗證產品是否符合用戶需求,靈活調整方向…
傾聽那些愿意購買產品的用戶的聲音
本文一開始就提到過關于盡快讓用戶接受產品、為之付費的目標。人們總是會不遺余力的告訴你應該免費提供怎樣的功能,而那些愿意為你的產品掏錢的用戶所帶來的反饋和訴求則更加有價值。付費的過程改變了用戶與產品及產品團隊的關系,用戶變成了消費者和客戶,他們會覺得有責任提出自己期望的功能與服務。
做那些能夠為最多的用戶帶來最大不同的事情
一旦你成功發布了包含最少量功能的最小化產品,并且很快從用戶當中得到了功能需求方面的反饋,那么這真心不壞。不過有時這類反饋會讓你覺得鋪天蓋地。你該從何處入手來增加這些新功能?怎樣向一部分用戶解釋為什么他們熱忱的期望無法得到滿足?
為功能方案進行優先級排序,對多數用戶有價值的、能解決普遍性問題的功能更加優先。
我們一直對用戶保持透明,對能夠使絕大多數用戶獲益的那些功能方案進行優先級規劃。我們會將用戶在論壇、郵件、Twitter或當面交流當中提出的功能需求整理起來,另外還會研究用戶在實際當中是怎樣使用我們的產品的,以發現那些有可能的“隱藏功能需求”。有時我們會觀察到用戶以非常復雜的方式試圖完成一些我們的產品無法做到的事情;如果我們逐漸看到越來越多的用戶在這樣做,那么我們會認為這可能是個需求點。這類可以幫到多數人的功能點會擁有最高的優先級。而且我們總是發現,一旦我們確認采納一個需求量最大的功能方案,很快就會有另一個人氣最高的需求爬到優先級的頂端。
定義用例
要向產品中增加功能,你需要為其定義某種普遍適用的用例。你不能像給客戶制作定制化功能那樣做產品,功能必須面向足夠多的用戶解決某種足夠普遍的問題,這樣的功能才值得投入成本去進行設計和開發。當廣大用戶希望我們的產品增加某種功能時,我們會向他們提出請求,讓他們幫我們解釋這種功能的實際用例。我們想要了解他們需要解決的具有普遍性的問題,而不是他們自己遇到的某種特定問題。
我們發現,在與用戶就某個特定的用例進行溝通和探索時——在論壇里,有類似需求的用戶也會逐漸加入討論——慢慢的,這類原來只有很小范圍的需求和用例就會變得具有足夠的普遍性,值得我們去進一步思考。
有時,某個用戶提出的一點功能需求雖然具有很強的特殊性,但不會破壞產品的核心用例,而且開發起來相當簡單,那么我們也樂于在下一個版本中增加這樣的小功能,并讓這些有需求的用戶知道。做屬于自己的產品時,有一個很棒的地方,就是你可以決定讓一些用戶感到愉悅,做一些非常規的事情來為他們提供幫助。
考慮那些樂于使用產品的沉默用戶
我們在打造產品的過程中與用戶進行了良好的溝通,并很好的聽取了他們的建議,不過要記住,這部分用戶很可能只是很小的一部分。看看客服系統當中的數據,有多少用戶是主動來尋求支持和交流的。對我們來說,這部分用戶占到總數的25%,也就是說,我們聽到的聲音只來自于全部用戶的25%,而另外75%的沉默用戶可以說是在比較開心的用著我們的產品——至少沒有不開心到覺得有必要尋求客服幫助或是提出功能需求。
將這部分理想用戶牢記在心,這對你來說也是很有幫助的。我們有時會在人們付費購買我們的產品之前告訴他們,我們并不能確認這款產品對他們來說是真正合適的,但他們仍然會購買。然而接下來他們就會抱怨各種問題,例如系統沒有自帶主題模板,或是他們必須自己寫HTML代碼等等。雖然這不是好事,但你也要記得,他們并不是你的理想用戶,你的產品并不是針對他們進行設計開發的。所以,要抗拒你內心當中為非目標用戶增加各種功能的欲望。
然而有時,你的核心用戶群當中發出的一些噪音也會讓你誤以為大部分的目標用戶需要某種特定的功能。你可以對此加以判斷,如果這類功能會使產品走向新的方向,或是改變重要的功能流程,那么建議你向數量更多的沉默用戶征詢意見。我們發現,當我們在自己的博客、播客和Twitter當中宣布某些有可能增加的新功能時,很多我們從未見過和交流過的用戶會浮出水面提出自己的看法。如果你的統計數據或銷售數據可以根據用戶進行細分,那么你應該可以識別出那些非常活躍但很少表達自己觀點的用戶,并與他們進行溝通。喜愛你產品的用戶會很樂于看到你向他們征求反饋意見。
微博是用于收集用戶簡短回饋的絕佳平臺。
當你向用戶征求反饋意見時,要提出一些具體的問題,而不是問他們怎樣看你的產品。如果你正在規劃一次重大的改版,那么試著提前向用戶解釋改版的原因,并讓他們設想在使用新版本的時候有可能產生怎樣的問題。
保護你的核心用例
充分理解你的核心用例,也就是你的產品所要解決的最首要的問題——這對于后續功能的決策是至關重要的。我們的產品距離初次發布已經四年了,盡管它已經進化到第二個大版本,各方面功能比起剛剛發布時的最小形態來說也完備了很多,但用戶使用它的基本方式并沒有發生變化。
如果某個新功能會使基本用例變得復雜,那么除非有很好的理由,否則不要添加它。有時你需要告訴用戶,他們想要的功能并不適合這個產品,并且你要意識到,部分用戶可能因此而選擇其他產品。你沒法讓所有人都開心,你最核心的目標用戶也不會希望你試圖讓產品滿足所有人。
新功能對我們銷售業績的推動并不大
我花了很長時間才了解到,增加新功能的做法并沒有對我們的產品銷售起到非常大的推動作用。這些年來,我們在Perch當中增加了一些很大的、呼聲很高的功能,其中有一些的開發時間甚至和當初我們做整個產品所花費的相仿。然而,這些新功能的上線并沒有在我們的銷售報表上添加漂亮的尖峰,曲線仍然是平穩增長的,而且沒有明確的跡象表明哪一個增長期是由于某個特定的功能上線而導致的。
文章轉載請保留網址:http://waterplane.cn/news/solutions/1567.html