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

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

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

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

關于複盤，我會給自己提三個問題：

1. 你認可自己在做的這件事麼
2. 你有沒有找到正确的方法
3. 你是否足夠努力

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

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

我們所說的價值，是這項事業本身所具備的價值，比如對低代碼平台來說，就是它對現有的 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，這些就足夠産生強大的推力，推着我們向前走。

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

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

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

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

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

七、忙碌的工作中，如何鑽研其他産品

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

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

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

當然我希望他們也帶着自己負責的模塊，來一場知識的交易。

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

上周末我參加了美團線上技術沙龍，裡面有一個版塊是關于美團和阿裡的低代碼技術分享，我立刻将獲取到的信息發給了我對接的前端同學，我不知道大周末的打擾人家是不是合适，但那一刻确實想分享一些東西。

他也及時回了我，帶了一些他了解到的信息。我能感覺到他對于低代碼這個領域的熱愛，有時候交流會傳播這樣的熱愛。

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

1. 你認可自己在做的這件事麼
2. 你有沒有找到正确的方法
3. 你是否足夠努力

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

專欄作家

大力哥呀，大力哥，人人都是産品經理專欄作家。一個90後産品經理，已經寫了6年的公衆号，通過輸出獲得了許多意料外的成長。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部