做低程式碼產品經理半年後,我有哪些思考

在轉行後,或許會有很多需要學習與改進的地方,也免不了會在當中遇到一些問題。作者透過分享自己轉行低程式碼產品經理的一些思考,幫助與同樣在迷茫中轉行的你找到正確發力的解決方案。

做低程式碼產品經理半年後,我有哪些思考

今年三月份我轉行做了低程式碼平臺的產品經理。最近剛剛過了半年試用期,也在覆盤自己入職以來的表現。客觀來說,這半年的產出並不符合我的預期,我希望自己可以發揮出更大的價值,但看起來事實並不如所願。

我在想,到底是哪裡出了問題。

最近自己有了一些思考結果,也跟更高階的產品同學有了一些交流,希望在這篇文章中能將這些成果分享出來。也許我周圍有一些轉行的產品經理正在經歷我一樣的心情,我希望透過對自己工作的深刻剖析,給他們一些鼓勵和方法,在「迷茫」的情緒中找到「知道該如何發力」的解決方案。

關於覆盤,我會給自己提三個問題:

你認可自己在做的這件事麼

你有沒有找到正確的方法

你是否足夠努力

理想情況下,對於自己負責的工作,我們應該是先找到價值,再尋求方法,最後付出努力。但事實上,很多人往往是先努力(加班),再從或有效或無效的努力中提煉出方法,最後再慢慢找到價值。

兩種路徑都可以,第一種方法更容易做得開心,因為構建起了正反饋。價值是最基礎的保障,正確的方法可以讓努力變得更有回報,於是更加認可事情本身的價值。而第二種方法更容易上手,因為相比找到價值,努力反而是不需要思考的。

我們所說的價值,是這項事業本身所具備的價值,比如對低程式碼平臺來說,就是它對現有的 SaaS 模式的影響。而絕非那種普遍適用的價值,比如這份工作讓我能夠生活得很好,有不錯的社會地位。

當然我們不是否定第二種價值,只是這樣的價值讓我們更容易放棄眼前的工作,或者更不容易找到工作本身的樂趣。因為這種價值不是這個工作所獨有的,這恰恰才是關鍵。

二、我認可低程式碼這個方向麼?是的,毫無疑問

起初我認可這個方向,是因為我覺得這個崗位要求的業務抽象能力,是我所推崇的產品設計理念。但現在我會覺得,格局小了,認識太淺了。

《矽谷鋼鐵俠》這本書提到,在建立 space X 早期,馬斯克制定火箭製造計劃時,往往會從物理學的角度判定一件事是否可行。如果在底層邏輯上這件事是跑得通的,剩下來的就是方法和執行力的問題。

同樣的,低程式碼這個方向如果在底層邏輯上跑得通,剩下的就是從業者們如何找到方法並付出執行力的問題。

在我眼中,低程式碼的價值依託於一個被普遍驗證的經濟學規律:科斯定律。通俗地說,誰能把資源用得好,資源就歸誰。

我們再回顧下低程式碼產品和其他產品的區別,可以理解為下面這張圖。

做低程式碼產品經理半年後,我有哪些思考

對於大多數產品來說,它是圍繞著需求而生的,從業務/使用者需求到產品需求,從產品需求到產品;而對於低程式碼產品來說,它是圍繞著產品而生的,從業務/使用者需求到產品,從產品到搭建產品的工具。

兩種模式的差異在於,前者將最寶貴的資源投入在業務/使用者需求到產品的這個階段,而後者將最寶貴的資源投入在從產品到搭建產品的工具這個階段。

在企業數字化早期,業務/使用者需求差異性較大,通用化的解決方案几乎不存在,於是資源投入在第一個階段是可行的,因為回報最大。

後來 Salesforce 帶來了 SaaS 這種新興的模式,但我一直認為這更多的是商業模式的變化,而不是應用生產模式的變化。例如對於國內 SaaS 廠商有贊來說,依舊會根據不同的行業開發出不同的版本,「資源投入在業務需求到產品」的本質沒有變。

而低程式碼帶來的恰恰就是應用生產模式的變化,從業務需求到產品的任務不再落到產品經理和研發工程師的身上,而落到了開發者的身上。

在第一種模式下,不同業務間即使具備了某種底層相似性,產品設計依舊要做多次。所以,如果存在一個假設:企業數字化轉型是否給不同行業間帶來了更多的底層相似性,那這種模式的邊際收益註定是逐漸降低的。

而低程式碼模式下,業務間的底層相似性,被抽象為通用的工具,透過工具可以更快地搭建出滿足業務訴求的應用,生產邊際成本極大降低,相對的,邊際收益就提升了。

總的來說,我認可一個假設:企業數字化轉型給不同行業間帶來了更多的底層相似性,同時我認可一個經濟學定律,最終推匯出,我認可低程式碼這個方向的價值。而這個假設是否成立,值得我們一起去思考。

二、如何找到正確的方法

我今年是做產品經理的第五年,對我來說,找到正確方法的最大阻塞恰恰是過去的經驗,過去是怎麼把事情做成的,在做低程式碼的時候會不自覺地產生路徑依賴。

要破除這種依賴,首先要想清楚:低程式碼產品經理跟其他產品經理有什麼不一樣。

從上面的介紹中不難看出,低程式碼產品經理會經歷的特殊階段叫做「從產品到工具」,這要求我們同時具備兩種能力:紮實的業務知識和產品抽象能力。所以,低程式碼產品經理需要時時刻刻平衡好「具體和抽象的關係」。

對其他產品經理而言,他們的抽象能力一般發揮在從業務需求到產品需求的抽象中,例如銷售希望可以更好地管理手頭的潛在客戶和簽約客戶,於是產品經理給他們提供了一套 CRM系統。

但低程式碼產品經理的抽象能力要求他們能夠將 CRM 系統再做拆解,從後端的資料模型到前端的頁面搭建,這對於抽象能力的挑戰無疑是巨大的。

從最終狀態來說,低程式碼產品經理的抽象能力應該成為他們的制勝武器,他們應該花更多的時間在這種能力的培養上。但從我半年多的經歷來說,這個原則往往會帶來一個誤區,只關注抽象,而輕視業務。

我們所說的抽象,應該是從業務抽象到產品抽象,所以在早期,低程式碼產品經理一定是要投身於業務中,他們必須具備了一定的業務理解能力,再去談抽象。

拋開業務的抽象,只是一種邏輯遊戲,說嚴重點,是一種自嗨。就像那句話說的,如果沒有看過這個世界,又何談世界觀呢。

我最近在做CRM專案的時候,這種體會非常深刻。

起初我接到的任務是完成CRM 系統中一些複雜表格的搭建,後來我發現,如果不能理解表格背後的資料,包括資料來源是哪裡,表之間的關聯關係如何,現在的 CRM 系統中每張表格的作用是什麼,呈現的資訊關係是怎麼樣的…

如果不懂這些,單純地就是想著如何用無程式碼的方式搭建出眼前看見的這個表格,那一定是走不通的,並且也會做得很痛苦,很懵逼。

總結下來就是一點,在剛剛做低程式碼產品的階段,我們一方面要了解到這個角色與其他產品經理在能力要求上的不同,但另一方面也要清楚需要從業務中培養抽象能力。

三、決定要不要做一件事的決策模型至關重要

我在產品評審的時候,經常會面對的一個問題是:為什麼要做這個需求。同時,也會受到幾種挑戰:1、有業務場景麼;2、有業務提出這個場景麼;3、競品有做麼。

首先,有場景是必須的,沒有業務場景的需求,很可能是偽需求。舉個不恰當的例子,我如果做一個表格放大閃入的載入動效,是一個需求麼,是的,但有業務場景麼,沒有,那這件事就不應該做。

但挑戰在於,需要區分你沒有看到場景和沒有場景這兩件事。如果我們把沒有了解到這樣的場景,當作沒有場景,那這個產品的天花板就會受到你認識的侷限。那該怎麼辦呢?

廣泛地體驗不同行業裡的SaaS產品,CRM、ERP、WMS等等,如果我們需要用低程式碼支撐起各種複雜的企業應用,我們至少要知道這些應用現在長什麼樣子,這同時也驗證了一點,在早期要投入到不同行業裡,攢業務經驗。

如果我們現在對接的業務沒有提出這樣的場景,我們要不要做。

我始終堅信一點,對於真正有價值的訴求,如果發現了再做,那我們很可能比SaaS產品的迭代速度更慢,因為我們只是完成了從工具到產品,而從產品到解決方案,還需要開發者或者實施團隊的努力。

那如果做了,且在很長時間內發現沒有業務用,到底是因為這個需求是偽需求,還是因為我們還沒有找到真正服務的客戶呢,這都是我們應該去考慮的問題,遺憾的是這樣的問題並沒有標準答案,只有不斷擴大自己對行業、對業務的瞭解,才能做出更接近事實的判斷。

四、分工不是邊界

我們的團隊會按照產品模組有不同的分工,每個同學在這樣的分工下又有自己更精細的責任,但分工不是邊界,一個模組的工作能不能做好,有時候依賴於你有沒有搞懂另一個不屬於你責任範圍內的事情。

比如在上面提到的 CRM 專案中,我負責的是表格搭建部分的工作,但深入瞭解後我發現,如果搞不懂表格背後的資料結構,那表格搭建方案根本就無法落地。

我有個很明顯的體會,之前我以為我只需要參與表格前端展示效果相關的 gap 梳理,但後面發現數據源、資料加工和資料展示之間是一體的,前兩者搞不懂,方案設計就是不完整的。

打破邊界是為了獲得更多資訊,從而提高效率,但提高效率的行動往往容易帶來對問題定義的忽視。為了加快進度,我們在工作中往往更重視找解決方案,但解決方案如果跟問題的定義是矛盾的,便只能帶來短期收益。

前面說了,表格搭建時需要去了解資料來源、資料加工和資料展示之間的關係,而我們遇到的實際問題是,受到資料來源本身特性的一些影響,後端需要補充一些資料加工能力,但這些能力在後端開發的成本比較大,而專案週期緊,所以大家就想到這部分工作是不是前端也可以做。

遇到這些問題的時候,我的第一想法是,前端能解決麼,如果可以的話,成本大麼,如果不大的話,那為了專案按時上線,就去做吧。

雖然討論的時候我也覺得,似乎後端負責資料加工,前端負責資料展示是更符合直覺的,但如果我不做,是不是會顯得我不夠“配合”。因為害怕揹負上這個標籤,於是想辦法從前端去搞定。

後來跟老闆溝通下來,發現我之前的思考並沒有觸及到問題的本質。如果這一次前端處理了,那後續遇到這樣的情況,且資料來源特徵更復雜,是不是都是前端來做。其背後真正的問題是:

整個低程式碼產品在搭建複雜應用的過程中,面臨這種複雜的資料情況時,前後端應該如何分工,才更符合整個產品長期的規劃。

短期內針對一個問題的解決方案有很多種,但對於未來應該要做成什麼樣子,大家的理解應該是一致的。

這種討論也許會影響一些工作效率,但確實是十分必要的。

五、接下來聊聊關於如何努力的問題

半年來,我對任務和目標頗有一些體會。在新人 landing 階段,雖然也需要去制定自己的工作目標,但這些目標往往是依附於任務而存在的。

比如我剛來的時候,分到的任務是負責圖表模組,那時候我的目標,也是圍繞如何做好圖表目標而去制定的。這個階段是有必要的,因為資訊不夠,還在學習,從一個具體的任務開始是明智且踏實的。

但這個階段不能持續太久,如果目標總是服務於任務,那我們所有的價值感和目標感都是依賴於具體的事情,而容易忽略我們自身的成長。

我自己就有過這樣的體會,Q2 的時候針對圖表後續的規劃做了很多調研,梳理了很多想法,但 Q3 開始我被告知,圖表需要轉交給其他團隊,這讓我在某個時刻突然陷入了一種空虛當中,好像一下子失去了目標。

後來我開始投入在表單相關的任務中,也是給自己定了針對於這個任務的目標,但由於自己低估了任務的難度,最終跟團隊一起評估下來,目前全力推進這個任務並不是時候,於是暫緩推進了。再一次地,我有一種失去了目標的感覺。

後來我自己開始反思,目標不應該服務於任務,目標應該是大於任務的,它應該去決定我在這家公司希望變成一個什麼樣的人,目標是跟我這個人的狀態相關聯的,而不應該受制於具體的任務。

當我有了目標之後,我可以制定不同的任務去服務於目標,我可以或主動或被動地去調整目標下的任務,但目標之於人,就像北極星指標之於產品增長,是具有引領價值的。

六、擺脫“被動”,提前做準備

在大廠我能感覺到,身邊都是非常優秀的人,大家的背景、專業度和溝通方法,在從業者中都是佼佼者。

以前在小公司的時候,我覺得自己要成為那個環境中最優秀的那一批人;來到大廠之後,我的內心總是充滿著一種隱隱的自卑感,甚至一段時間祈求自己可以順利度過試用期,這在以前是不可想象的。

似乎大廠的產品經理們從不用別人去 push 他們要努力,會議、文件、專案、彙報、OKR,這些就足夠產生強大的推力,推著我們向前走。

我曾經認為,只要自己能夠做好努力這件事,就能生存下來。但後來我發現,更重要的是找到為了什麼而努力的答案。

上文說的從目標到任務,就是一種找到為了什麼而努力的方式,而半年來我的另一個感受是,需要對產品充滿好奇心。

剛剛入職的時候,就聽人說起過,表單在現在的配置體驗讓人感覺到很奇怪,不理解為什麼要這麼做。因為我不在負責表單功能的團隊,所以這樣的說法聽了也就聽了,並沒有很好奇。直到後來表單相關的任務來了,我才不得不從零開始研究表單功能。

我在想,如果早一點可以去研究表單,是不是自己能夠為後來的任務做好更充分的準備;可又一想,是什麼會驅動我去做這樣的研究呢。那應該就是好奇心了,除了好奇心,我想不到有別的驅動力。

我所說的好奇心不是指“我知道是怎麼回事”,而是真正理解產品背後的基本原理以及它存在的價值。

七、忙碌的工作中,如何鑽研其他產品

我問過自己,平時那麼忙,哪有時間去鑽研不是自己團隊的產品呢。

我的一個體會是,一定要跟不同團隊的產品經理保持一定頻率的交流,這種交流不能僅侷限於跨團隊的需求,更好的方式是拋開需求,更開放而自由的交流。

現實情況是,也許這只是我的一廂情願,因為我看大家的日程,好像每個人在工作日是真的很忙,但如果有人願意找我瞭解一下關於元件的一些問題,我是很願意的。

當然我希望他們也帶著自己負責的模組,來一場知識的交易。

另一方面,低程式碼產品經理需要跟研發有更多的溝通。我瞭解到很多公司都有自己的低程式碼平臺,發起人往往是技術團隊,低程式碼在技術視角下和產品視角下,並不完全相同,所以需要更多的交流。

上週末我參加了美團線上技術沙龍,裡面有一個版塊是關於美團和阿里的低程式碼技術分享,我立刻將獲取到的資訊發給了我對接的前端同學,我不知道大週末的打擾人家是不是合適,但那一刻確實想分享一些東西。

他也及時回了我,帶了一些他了解到的資訊。我能感覺到他對於低程式碼這個領域的熱愛,有時候交流會傳播這樣的熱愛。

最後,我選擇在這個節點輸出這樣的覆盤,更多的是對於自己的激勵和鞭策。還記得那三個問題麼:

你認可自己在做的這件事麼

你有沒有找到正確的方法

你是否足夠努力

我對這三個問題都給了自己的回答,那接下來就只剩一件事:幹就完了。

專欄作家

大力哥呀,微信公眾號:大力哥,人人都是產品經理專欄作家。一個90後產品經理,已經寫了6年的公眾號,透過輸出獲得了許多意料外的成長。

本文原創釋出於人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基於CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部