傳統行業如何轉型互聯網?(入門知識篇)
轉型到互聯網領域,會充滿對未知的恐懼和想像,會希望有一只夢幻團隊。
我在“在行”上有個項目是“傳統行業如何轉型互聯網”,一直無人問津,最近破了處,并從中了解到:
- 傳統行業的成功者對互聯網領域覬覦已久;
- 對市場有大量一廂情愿;
- 非常重視之前缺少的技術環節。
有野心是好事。身為一個創業者,絕對不能沒有“野心”,因為這是你與一般人唯一的分別。如果你連強大的企圖心都沒有,那就絕對不適合創業。但誤區也是客觀存在,不得不指出來。
很多年以前我也寫過程序,認識一些技術大牛,大家根本不在乎小白們會不會用,只在乎其他人覺得我的東西屌不屌,追求的是用最少的代碼,用最屌的方法,把這個功能寫出來,至于功能本身能不能幫別人解決問題,我一點也不在乎,因為那是產品經理的責任。我的大腦要用在更有意義的地方,像是去研究更新、更屌的技術。
如果創始人不懂技術,又一味追求技術負責人的技藝高超,很容易找到一些“純粹”的工程師。而問題是,大多數用戶根本不知道技術是什么,對他們來說這個東西也一點都不重要。Paul Graham寫了幾十年的程序后,提出一項真知灼見:“不要開發聰明的東西,而要開發人們想要的東西?!?/p>
過去十年,技術發展十分迅速,大量公開的代碼和工具可以幫助設計出強大的程序。如此一來,現在大家都可以設計出聰明的東西,但卻不易聚焦于開發人們想要的東西。但現在是一個以產品為中心的世界,也就是拚命為用戶打造最好的產品,他們并不關心是不是用C語言寫的,只在乎速度快不快,而且希望界面操作合乎直覺,清楚明了。
若要打造最好的產品,必須了解使用者是誰。經常關注和滿足使用者的需求,這一點至為重要,為什么?因為人們的品味和流行事物都瞬息萬變,競爭激烈,除非用心了解使用者的改變、成長和發展方向,否則不可能創造出跟上他們腳步的產品。此外,如果沒有把這種DNA植入公司里,則很難融入公司每個人每天在做的事里頭。
有的人會疑惑——到底是應該先有內容,再有平臺;或是應該先有平臺、 再找內容。這就好比該先把生產線設備都準備好,再接訂單;還是先接到訂單,再來搞定這些設備。其實答案是很簡單的——沒有哪個公司,會在不知道自己要生產什么產品前,就大興土木蓋工廠。也沒有哪個客戶,會在不知道你葫蘆里面賣的是什么膏藥前,就把寶貴的訂單下給你。所以,重點是先找到那個能夠幫客戶解決問題的產品,而且最好是個痛點,那么訂單和生產線,都只是時間的問題罷了。
也就是說,建立平臺要在殺手應用之后。如果不是打車達不到、拒載這些迫切的問題,打車應用也不會迅速竄紅;如果不是在上網的交互體驗上有所突破,iPhone也不會在市場上熱賣。而平臺化,都是之后的事情。所以,平臺大夢雖好,但沒有殺手應用帶來的第一批用戶都是白搭。
為了創造殺手應用,你必須想出好的產品功能,快速開發,與小部分的用戶一起測試,搜集數據。接著,要是有個新功能提高了一項關鍵指標(例如人們使用的頻率、時間或花費增加),你就將此功能提供給所有用戶。如果產品某功能改良后效果不佳,則必須調整或刪除,很簡單。
數據不會說謊,在此過程中沒有太多出錯的空間,除非你不擅長:
- 想出可供測試的產品改良方法;
- 厘清如何評估產品改良的成效;
- 判定手中產品功能的相關數據會讓核心指標提高或降低。
轉型到互聯網領域,會充滿對未知的恐懼和想像,會希望有一只夢幻團隊。在理想世界里,你在早期階段真的雇用到了這些人,但在現實中恐怕辦不到。我們只能先看看理想的團隊結構,以確認前進的方向無誤,這時候最好先深入研究誰能提供下列三個關鍵問題的答案:
- 你正在開發什么產品?
- 該產品是否解決真正的問題?
- 我們在為誰(目標用戶)解決問題?
尚未打磨出符合市場需求的產品前,團隊里專門負責產品的人不太可能超過一位(理想情況下,還會有一位出色的設計師)。只有等到產品上軌道,才需要擴大產品團隊的規模。打車類的產品相對復雜:由乘客和司機組成,兩個應用必須同時運作,才能到達產品符合市場需求的階段,所以需要的開發量比較大。如果應用不復雜,只需要一位產品經理就好,最好把錢花在聘請工程師,全心為公司開發更好的技術。會遭遇的瓶頸通常不是產品功能的點子不足,而是如何快速讓用戶使用所有的產品功能。
在開發過程中,通常還會突然冒出其他問題:
- 這個應用看起來如何?
- 這個應用使用起來如何?
- ……
負責回答這些問題的是設計團隊(通常隸屬于產品團隊的一部分)。也許你只有聘請一位兼職設計師的預算,但為了提供殺手級產品,你必須與設計師更密切合作——理想情況下,如果負擔得起應該選擇全職設計師。
所有產品人員其實都是在回答開發“什么”的問題,有的團隊劃分產品經理、設計師、用戶體驗專員等,對早期團隊既無聊又沒意義。實際上,應該團隊齊心協力,密切合作。每個人的專長的確不同,但到頭來,大家都是應用的使用者,而且許多領域會重疊,應該鼓勵所有人注重整個產品經驗,而非單一的部分。
所以一般來說,團隊成員會包括:創始人人引領產品愿景和管理;理想上,另一位創始人是工程師,有天使資金后,應該至少再招另一位工程師(或兩位)加入。你可能無法聘請一位出色的全職設計師,但至少每周要能交流一次,此時大概也無法聘請一位全職的QA人員。實際上,確認應用運作無礙的重任,落在僅有一人的產品部門上。
綜上所述,團隊成員共為五、六人。如果應用較為復雜,需要建立一個較大的團隊。需要全職設計師、iOS工程師、安卓工程師、幾位后端工程師、幾位外包人員以支援開發,最后再找來一位QA,這樣團隊成員約為十到十二人。
人有了,一般來說會采用敏捷開發的模式進行具體工作。所謂敏捷開發,是指在一段固定的短時間內,提供有價值的功能或改良,一般持續一或兩周,目標是從頭開始,提供某個有價值的東西(一個特定功能)讓用戶使用。為什么它很普及?因為每兩周就可以為用戶提供新功能或改良,代表每兩周用戶能測試新功能,讓你評估是否要留下這個功能。自然地結合了使用者對產品改良后的回饋,和你原先規劃要他們測試的新產品功能。
敏捷團隊的定義,是指一群人完全獨立自主,采用、執行、測試、配置一個產品功能,最后讓用戶使用。這個概念相當棒,如果團隊規模小,運作成效會很好。這里很重要的一點是,團隊成員應該在同一個地方,尤其是只有產品/設計/開發等少數成員的小團隊。原因如下:
我們先從理想情況開始,如上所述,組織(目前小規模)產品開發團隊的真正目標,是讓他們有能力快速推出應用的新版本,這件事仰賴有效溝通,過程并不容易。為了能經?!巴瞥鲂鹿δ堋?,就要持續改善代碼,等用戶使用后提供反饋,再看看應用是否因此變得更好,你必須在每個可能的層面上追求效率。也就是說,要讓整個產品/設計/開發/品控團隊都在同一個地點,隨時待命。如果其中一位或多位成員在遠地工作,只會讓溝通效果不佳,少了大家在同一個房間面對面溝通的機會,也無法隨時私下交流。目前你的團隊規模還太小,尚無法各自為政。但如果你的應用在之后以瘋狂的速度成長,溝通絕對仍是關鍵,因此你現在所建立的溝通文化,未來將得到豐厚的成果。
把應用開發出來只是萬里長征第一步,更重要的是如何讓用戶來用。基本上沒有經驗的人的答案千篇一律:“我們會用盡各種方法推廣。”這和什么都沒說一樣。每個創業者都非常努力在推廣他們的應用,但最終真能在市場上獲得海量活躍用戶的屈指可數。所以非常努力去推廣,是基本的工作,但不是一種致勝策略。
沒有用戶,心目中想達成的遠景再美好也是白搭,所以除了有愿景,還有要務實、按部就班的市場策略。首先是思考競品是誰?如果說什么是最大的競品,我會說是游戲產業,這不是玩笑,只因為一款應用上市在這個紅海中的紅海最先決的條件就是被找到,找不到的應用沒有價值,當游戲把各種應用市場的榜單占滿時,你連最基礎冒頭的機會都沒有了。再舉個例子,假設你制作了一款鬧鐘,想的可能是放在生活類別,但詳細觀察當你將鬧鐘放在生活品味這個類別后,會發現什么房屋出租、二維碼之類都在此類,而這些都是你所謂的競爭對手。那么在曝光這個角度上,競爭對手并不是類似功能的產品,而是放在同個類別、能占據用戶手機時間的應用都是你的競品。
要想一上來就對所有用戶產生網絡效應,在大的公司恐怕也沒辦法做到。但如果先針對幾千人、幾萬人的小群體,而后漸漸擴展,則是小團隊做得到的,也是絕大多數成功公司最初使用的策略。Facebook從校園開始流行、知乎從互聯網/媒體圈開始發展,都是一個道理。問題只是說,哪個小圈子最能從你的第一版產品得到價值,而累積這些用戶后,又能夠延展到哪里去。
如何獲取用戶?很多人一定會立刻想到社交媒體。社交媒體是窮人的原子彈,但要提醒的是,玩社群是非?;ň徒疱X的,叫原子彈是因為人與人的互動具備散播性,而當切中角度,后續發酵將超乎預期,所以產品上線前,先問問自己各類媒體的發布與運作是否都準備好了。
另外,作為創業者,生存就是一切,所以當產品上線后要根據市場反饋情況,在最快的時間修正完成,只要市場喜歡什么就做什么,拋開一切原則,迎接市場才是。
最后,如果你做的是需要在短時間內大量用戶來沉淀的產品時,就沒辦法等待社群慢慢的發酵,只能用用廣告大量、精準的取得用戶。這也是一門深奧的技巧,且背后需要耗費大量的預算,如果沒有學費可以繳的話,建議先在大公司的類似部門先工作幾年再出來創業,或者找到一個能把這塊搞定的合伙人。
很多時候,往往我們開發多時的產品因為市場的不領情而膠著不前,而自己認為不可能火的小產品卻可能在市場大放光明,那么當你的產品在互聯網這個紅海中的紅海中被打撈起來之后,下一步就要思考這個應用對于用戶而言,到底將有怎樣的幫助,如果沒有實實在在的根基,并不是產品優化或者產品格局夠大市場就會接受的。想清楚了,成敗在天,無愧于心。
作者:孫志超,小米科技投資部,MIUI生態負責人,微信公眾號:weixinsunzhichao
本文由 @孫志超 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 unsplash
感覺停留在理論,而且跑題了,文章指出更多的是技術方面的探索認知,到傳統行業如何融入,怎么融入,并非幾個代碼,幾個軟件就改變的。