一個優秀的運營,到底需要有多懂“產品”?

本文作者黃有璨,三節課聯合創始人。

今天我們來聊一個普遍且比較有共性的運營問題。如果聊完你們覺得還不錯,以後我們可以以類似的方式來試著每週聊一次。

一个优秀的运营,到底需要有多懂“产品”?

在互聯網圈裡有句話是這麼說的——好產品要懂運營,好運營也要懂產品。

印象中,幾乎超過90%以上的產品和運營大牛們都提到過這句話。

然而,對於很多工作經驗一兩年的產品和運營小朋友們而言,聽到這句話的時候,很可能是一臉懵逼的——運營要懂產品,具體是要怎麼個懂法?要有多懂?懂了能解決什麼問題或創造什麼價值?

同一個問題換到PM身上,也是同理。

所以今天這篇,我們想要稍花一點篇幅來聊下這麼個問題:既然人人都說好運營需要“懂產品”,那到底需要怎麼個懂法?以及,理解了哪些跟產品有關的信息之後,能給你的工作帶來具體明確的幫助?

我試著總結了下,這裡應該可以分成4個方面來聊,我來一個個講。

第一,運營理解了產品經理的科學工作方法和流程後,甚至部分掌握了一些產品經理的思考方法和邏輯後,可能會降低你的無腦吐槽或提出無腦需求的比例。

參加過三節課課程的同學都應該知道,對於一個合格的產品經理而言,“用戶、需求、場景”永遠是其在進行產品設計和需求分析時必不可少的3要素,簡單來說,我們必須對於某個需求背後的具體場景和具體使用對象有非常清晰的捕捉,才能判斷這個需求是否靠譜,是否切實存在,否則,這個需求很可能是在YY。

舉個例子,三節課的在線教室作業區中有人提出說想要上線一個“搜索”功能,我們試比對一下如下兩種思考和表達——

A:

這一般的社區論壇都有搜索功能,我們肯定也得有啊,沒有這個功能太不方便了。反正這個必須要做!

B:

我們來看一下什麼人在什麼時候會產生“搜索”這個需求:比如我們現在開了一個500人的班級,在這個在線班級的作業區中,假如有200人提交了作業,助教也完成了對於作業的批改之後,這時作業區內就存在了海量的信息,可能會長達20頁,並且這個時候助教或班主任還會經常到班級群內告訴大家每週哪些同學的作業是很優秀的大家可以去觀摩,於是這個時候對於想要前去觀摩的同學們就產生了一種“想把那些優秀同學們的作業找出來”的需求。

如果這樣的事情在為期8周的課程中每週都存在,這應該是一個值得做的需求。

對比如上A和B的兩種思考表達,是不是感覺B的表達更靠譜?

不僅如此,在“用戶、需求、場景”的基本邏輯下,還有助於我們更進一步判斷,這個需求值不值得做,是否存在更好的解決方案。

比如說,要是針對B的這個“其他用戶想看優秀作業”的需求,我們是否有可能專門設置一個“優秀作業區”,讓助教對於作業可以打“優秀”標籤,然後被標註“優秀”的作業會自動進入到這個優秀作業區就好了?

遺憾的是,就我個人的經驗來看,這類相對理性成熟的“產品型思考”,在絕大多數2歲以內的運營身上並不存在。

第二,身為一名運營,假使你能夠時刻擁有一種“尋找合理高效的產品機制來為運營服務”的思考,這種思考會帶給你更大的可能和便利。

我們都知道,很多運營同學在做的事情都是一種類似於“依靠個人的人肉時間投入來輔助產品運轉式”的工作,典型比如審核、打標籤、人肉發各種優惠券、做活動啥啥啥的,但如果你長時間做的都是這一類工作,無疑是沒有前途的。

我個人的觀點是,運營做到了一個階段後,一定需要時刻擁有某種產品層面的思考,才會擁有更大的可能,即:面向我當前存在的具體運營需求,如何可以藉由一些產品機制的變化來幫我更好更有效的實現之?

這裡我舉個最近看到的例子吧。試想一下,假如你是知乎Live的運營負責人,當前面臨的具體需求是要拉昇知乎Live的整體用戶報名數,你可能會怎麼做?

我猜有人可能會說要做活動大促,有人可能會說我們做更多站內站外的推廣和曝光,等等。

然而,知乎是怎麼做的呢?

知乎的做法遠比大多數人能想到的更為輕巧,簡單說,他們上線了一個“Live主講者可以直接給其他人贈票”的功能。

這個功能的使用,是Live主可以在自己的Live頁面下點選“送票”按鈕,然後選擇要贈送的對象,於是,對方就會收到一條私信。比如知乎大V劉飛給我贈送了一場他的Live,我收到的私信就是這樣的:

一个优秀的运营,到底需要有多懂“产品”?

這個時候,我點擊劉飛發給我的這個鏈接,就直接可以報名這場Live了,報名過後,“黃有璨報名了劉飛的XXXlive”的消息就會出現在所有關注了我的用戶的知乎Feed流裡。

這樣一來,假如我有一天要開一場Live,我是不是也可以通過給蘇傑劉飛張亮等等大V們贈票來更好實現我這個Live的推廣了?這樣是不是比以前我要一個個私信他們“求幫轉一下”要來得方便和順暢了很多?

且,這個機制上線後,我預計既可以帶動Live整體數據的上升,又不會給運營帶來很大的工作量和壓力。

所以,能夠時刻從產品層面去思考,現在是否可以存在某些更合理高效的產品機制來解決你的具體需求,是一種可貴的習慣。

第三,懂得某些產品的邏輯、架構,甚至能夠粗略對於實現成本有一些評估之後,會有助於大大降低你與產品經理和研發之間的溝通成本。

我們都知道,在廣大互聯網公司內部,經常存在著各種產品被運營坑,運營被產品和研發矇騙了的段子。

比如說——

運營:我們要做一個活動,很簡單的balabala……這麼簡單後天能做出來嘛?

產品&研發:&……%¥#……&

又比如說——

運營:我們要做一個活動,大概想這麼這麼搞,你們評估一下這個東西多久能做出來?

產品&研發:臥槽,你這個目測至少要搞一個月才能搞出來啊。

運營:啊,這麼久?為啥呀。

產品&研發:哎呀,這個是技術問題了,反正說了你也不懂。

運營:*&……%¥#@

其實,類似這樣的尷尬,假如運營能夠有一些常識,對於產品方面的實現邏輯和成本都可以做出一些預估,甚至可以跟產品和研發討論一些實現問題的時候,這樣是完全可以避免的。

試想一下,假如產品和研發跟你說XX需求實現不了的時候,你可以義正辭嚴的回覆:「怎麼就做不了了?!這樣這樣這樣不就行了嘛。。。你看,prd在此,拿去嫖!看完有什麼問題再統一回復我吧」

這該是一副多美的畫面……

以及,假如運營能夠理解更多產品和研發層面的實現邏輯時,也會有助於你的思考更加縝密,大大降低與對方之間的溝通理解成本,成功贏得產品和研發夥伴們的好感。

試比對一下以下兩種表達——

運營A:產品產品,我們準備要做一個“買得越多就多送用戶禮品”的活動,你來幫我們想想怎麼實現吧。

運營B:產品產品,我們準備做一個促銷的活動,這個活動想通過“當日下單隨機送禮品”的方式來實現,我們目前有3種禮品可以拿出來送,我想了下,是不是可以這樣實現——訂單尾號為5就送禮品1、尾號為8送禮品2、訂單尾號為3就送禮品3,你來幫我們評估一下這個需求靠譜不靠譜?

感覺一下,運營A和B,哪一個更容易受到產品汪和程序猿們的認可和喜愛?

第四,深刻理解“產品”工作的本質,包括MVP、精益、敏捷、“少即是多”等等產品理念和工作方法之後,會有助於你可以用最合理的方法去推進很多工作的開展,能夠在整個業務鏈條中扮演更重要的作用,以及某些時候在與產品的話語權爭奪中佔據主導地位。

產品的本質是什麼?我的合夥人,三節課CEO Luke同志曾經給出過精闢的總結——所謂產品,無非一個橫向和一個縱向,其中橫向是業務流程,縱向則是信息架構。

所以,無論產品還是運營,最終的核心目標,都是圍繞著“打造一個長期穩定、可持續的業務流程,並不斷優化、調整及放大它的價值,從中獲得更多的收益或回報”來展開的。

在很多公司內部,產品的話語權往往要更大,就是在於產品因為天天要思考業務流程的梳理和關鍵環節上的信息組織,因此想得比運營要更深入具體,從而在討論到關鍵業務的時候,會給出更多有價值的思考和判斷,每逢此時,運營只能沉默。

但就我所知,在很多公司內部,當運營可以更好理解業務,也離業務鏈條更近,思考也更深入的時候,是會更容易拿到業務環節中的話語權的,這時候,一家公司內的分工關係,就變成了運營主導,產品配合和實現的模式,典型在很多電商類的公司比如京東內部,都很容易看到這樣的關係。

至於MVP、敏捷、精益等等就不用提了,我在拙作《運營之光》裡就曾分享過我使用“精益”的理念來節省了N多成本成功推進落地了一個項目的真實事例。

以及,我同樣還在《運營之光》中分享過一個理念:產品負責提供長期價值,運營則負責創造短期價值+協助產品完善長期價值+消費用戶價值獲得收入,且,只有長期價值明確、穩定的時候,創造短期價值以及消費用戶價值才是有意義的。

在我還在新浪工作的時候,在某次我認為老闆的方向不是那麼合理的時候,我就曾經通過這套邏輯完成過與老闆的溝通和說服,從而為我自己爭取到了更好的工作環境和空間,而不是老闆給了我一個事,我明明感覺它不靠譜,還必須得硬著頭皮上陣去搞。

好了 ,今天的思考就到這裡,希望能夠帶給你一些啟發。不出意外的話,下週四,我們會繼續重新思考一個“與產品和運營有關的問題”。

也特別感謝三節課學員群裡的同學們進行的大量討論也給我提供了很多思路,在此也把一些同學們的討論內容摘錄下來分享給你,供參考。

John Wu:

個人覺得“懂產品”可以從兩方面來理解。

一方面是瞭解產品設計&開發的基本規則和流程,比如一個產品方案大概長什麼樣,需要哪些元素,產品開發怎麼排期的,跟開發對接需要注意哪些細節甚至提高效率的辦法(比如做方案的時候想到有能copy以前代碼的地方自然就不需要再要求程序猿寫新代碼了),這種經歷其實是可以通過時間經歷來堆砌的,跟產品打交道久了,基本都會了解這些。

另一方面個人覺得比較核心的“懂產品”,是對自家產品的瞭解,因為產品跟產品真的差別太大,自家產品從一開始的定位滿足的需求出發到最終為什麼設計成這個樣子搞出這些功能而不搞其他功能,哪些功能是初衷認定的核心,哪些功能期望通過用戶反饋來高速迭代,肯定都是有背後思考的,能這樣“懂產品”的運營圍繞自家產品做事的時候也能清楚自己的核心“KPI”是啥不至於跑偏。

肖偉濤:

僅僅關注「KPI」容易損害當前產品用戶的既定利益(包括體驗)。比如為了提升銷售額的時候一般會要求加展示露出進行導量,但殊不知產品千辛萬苦搭建的「流暢體驗」在運營需求下灰飛煙滅。


分享到:


相關文章: