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

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

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

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

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、你是否足夠努力

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

干就完了。