在國(guó)內(nèi)，同已經(jīng)比較成熟的企業(yè)內(nèi)部工具或 SaaS 產(chǎn)品來(lái)說(shuō)，低代碼還是比較新的領(lǐng)域。作者結(jié)合自己的實(shí)戰(zhàn)經(jīng)驗(yàn)，從五個(gè)維度與大家探討關(guān)于低代碼的業(yè)務(wù)操作思路，希望對(duì)你有所幫助。

我在大廠做低代碼（我在大廠做低代碼怎么辦）

聲明：本文所有觀點(diǎn)，僅代表個(gè)人

前幾天的春季發(fā)布會(huì)上，飛書(shū)正式推出了業(yè)務(wù)三件套，其中就包括飛書(shū)自研的低代碼平臺(tái)：飛書(shū)應(yīng)用引擎。

恰好至今年 3 月 9 日，我加入字節(jié)跳動(dòng)整整一周年，也在飛書(shū)做低代碼產(chǎn)品整整一周年。在我們?nèi)ψ佑幸痪湓挘凶鲎止?jié)一年，人間三年，以此來(lái)形容字節(jié)跳動(dòng)工作的繁重和壓力。

對(duì)我來(lái)說(shuō)，這漫長(zhǎng)的一年確實(shí)有許多值得回顧和復(fù)盤(pán)的地方，雖然在一年的時(shí)間節(jié)點(diǎn)上幾乎沒(méi)有任何儀式感，因?yàn)橐恢庇邢聜€(gè)重要的任務(wù)等著你去完成，但從個(gè)人成長(zhǎng)的角度來(lái)說(shuō)，這個(gè)特殊的節(jié)點(diǎn)是值得紀(jì)念的，而紀(jì)念它的最好方式，莫過(guò)于寫(xiě)下這樣一篇文章了。

我知道字節(jié)、飛書(shū)、產(chǎn)品經(jīng)理，都是互聯(lián)網(wǎng)圈子里的流量詞匯，在許多自媒體或是職場(chǎng)社交平臺(tái)，都能看到與之相關(guān)的內(nèi)容。但這篇文章并不會(huì)將過(guò)多的筆墨放在字節(jié)、飛書(shū)、職場(chǎng)、大廠的話題，我會(huì)更關(guān)注我在這一年的真實(shí)收獲，那就是在做低代碼產(chǎn)品這件事上的收獲。

為什么呢？

在字節(jié)跳動(dòng)這樣一個(gè)超大型組織內(nèi)，每天都會(huì)有很多事情剝奪你的精力，平臺(tái)的光環(huán)也好、盛傳的裁員危機(jī)也罷，這些消息就像精神鴉片，吸食起來(lái)很爽，卻幾乎沒(méi)有益處。

相反的，你正在做的事情，事情背后體現(xiàn)的能力，能力背后蘊(yùn)含的基本功，反而是每天忙碌的會(huì)議背后，更容易被忽略的東西。對(duì)個(gè)人來(lái)說(shuō)，這些東西才是我們?cè)谄脚_(tái)之外所獨(dú)有的，真正屬于我們自己的東西，說(shuō)白了：

這是可以帶走的東西。

一、關(guān)于產(chǎn)品

我在飛書(shū)做的是低代碼產(chǎn)品，雖然這個(gè)領(lǐng)域在大類上屬于 to B 產(chǎn)品，但同已經(jīng)比較成熟的企業(yè)內(nèi)部工具或 SaaS 產(chǎn)品來(lái)說(shuō)，低代碼在國(guó)內(nèi)還是比較新的領(lǐng)域。

這個(gè)「新」體現(xiàn)在：

不同公司對(duì)低代碼的理解和策略可能都不一樣，沒(méi)有一個(gè)成熟而公認(rèn)的從 0 到 1 的演進(jìn)模式，產(chǎn)品的形態(tài)基本都跟公司對(duì)低代碼的定位有關(guān)；
少有成熟的方法論可借鑒，只能從現(xiàn)有的產(chǎn)品去倒推底層的產(chǎn)品設(shè)計(jì)理念；
圈子很小，5 年以上的低代碼產(chǎn)品經(jīng)理很少很少，招聘候選人很多是 B 端其他業(yè)務(wù)領(lǐng)域的產(chǎn)品，或者是國(guó)外 PaaS 平臺(tái)的產(chǎn)品（如 Salesforce）

這些也導(dǎo)致我們?cè)谧鲞@款產(chǎn)品的時(shí)候，也面臨了很多的不確定性。

在這種不確定下，必然會(huì)導(dǎo)致討論→結(jié)論→推翻→討論的無(wú)限循環(huán)，這對(duì)于一線產(chǎn)品經(jīng)理來(lái)說(shuō)某種程度上是一種消耗和傷害。

但另一方面，也正是在這樣的無(wú)限討論中，我們才能對(duì)自己所做的事情有更多理解，更深刻地認(rèn)識(shí)到它的價(jià)值和做事情的正確方法。

在這一年的時(shí)間里，我從完全不了解低代碼，到開(kāi)始能用低代碼平臺(tái)搭建應(yīng)用，再到逐漸了解每個(gè)平臺(tái)背后設(shè)計(jì)的理念，這其中最深的感觸只有一條，我姑且把它叫做：用戶分層。

二、用戶分層

凡是做產(chǎn)品經(jīng)理的，一定會(huì)對(duì)一個(gè)問(wèn)題非常敏感：我們的用戶是誰(shuí)。而對(duì)低代碼產(chǎn)品經(jīng)理來(lái)說(shuō)，這個(gè)問(wèn)題又顯得稍微抽象一些。

廣義上，低代碼的用戶是開(kāi)發(fā)者，但開(kāi)發(fā)者是誰(shuí)，他們和企業(yè)的關(guān)系是怎么樣的，低代碼又如何為他們提供了不可替代的價(jià)值，這些都是我們?cè)谧鲞@款產(chǎn)品時(shí)，需要去思考的問(wèn)題。

經(jīng)過(guò)一年的探索，我發(fā)現(xiàn)去研究開(kāi)發(fā)者這個(gè)群體時(shí)，也需要用到用戶分層理論。

我最早接觸到用戶分層，是在美團(tuán)做會(huì)員產(chǎn)品經(jīng)理的時(shí)候，無(wú)論是 VIP 體系，還是等級(jí)體系，本質(zhì)上都是按某種標(biāo)準(zhǔn)對(duì)用戶做分層，目的是在不同的層次下，匹配不同的功能和資源，從而達(dá)到整體收益最大化。

開(kāi)發(fā)者也同樣需要并且可以分層。這個(gè)群體大致可以分為三個(gè)層次：

1. 無(wú)代碼開(kāi)發(fā)者

典型畫(huà)像是中小型公司內(nèi)的業(yè)務(wù)人員，他們的訴求是希望通過(guò)一款好用的工具，快速搭建出一個(gè)業(yè)務(wù)系統(tǒng)。

這種業(yè)務(wù)系統(tǒng)一般是經(jīng)典的四件套：數(shù)據(jù)表格、詳情、表單和報(bào)表，例如最簡(jiǎn)易的圖書(shū)借閱系統(tǒng)。包括所有圖書(shū)的列表、單本圖書(shū)的詳情、借閱申請(qǐng)表單和借閱數(shù)據(jù)統(tǒng)計(jì)，再輔以簡(jiǎn)單的審批流程和權(quán)限控制，基本上就能搭建出一個(gè)最簡(jiǎn)單的圖書(shū)借閱管理后臺(tái)了。

大多數(shù)無(wú)代碼開(kāi)發(fā)者很少具備寫(xiě)代碼的能力，因此提供給他們的產(chǎn)品需要足夠好用，易用性需要足夠強(qiáng)，才能被他們喜歡。

具體來(lái)說(shuō)，在產(chǎn)品設(shè)計(jì)上，既需要保證一定的抽象性，功能不能太定制化，否則就偏離了 PaaS 的定位，同時(shí)也要屏蔽開(kāi)發(fā)者無(wú)需感知的功能細(xì)節(jié)。

以按鈕的樣式配置為例，對(duì)無(wú)代碼開(kāi)發(fā)者來(lái)說(shuō)一般需要的是封裝好的快速的樣式配置：藍(lán)底白字無(wú)邊框的按鈕，一般用在強(qiáng)提示場(chǎng)景下，例如表單的提交；白底黑字有邊框的按鈕，一般用在弱提示場(chǎng)景下，例如頁(yè)面的返回。

如果我們將按鈕的 CSS 樣式全部開(kāi)放給無(wú)代碼開(kāi)發(fā)者，他們可能會(huì)覺(jué)得沒(méi)有必要且非常難用，因?yàn)樗麄兊臉I(yè)務(wù)系統(tǒng)對(duì)靈活性要求沒(méi)有那么高。

但這樣的限制在某種程度上也同時(shí)限制了業(yè)務(wù)系統(tǒng)本身的天花板。

2. 混合開(kāi)發(fā)者

典型畫(huà)像是大型企業(yè)里的業(yè)務(wù)人員，他們一方面渴望一個(gè)好用的應(yīng)用搭建系統(tǒng)，另一方面希望這個(gè)希望滿足一定的靈活性，哪怕是通過(guò)寫(xiě)部分簡(jiǎn)單的代碼實(shí)現(xiàn)。為此，也要求他們懂得一些基礎(chǔ)的編程知識(shí)。

對(duì)大型公司的復(fù)雜業(yè)務(wù)系統(tǒng)來(lái)說(shuō)，完全無(wú)代碼的搭建幾乎很難滿足自己的需求，而對(duì)公司內(nèi)的業(yè)務(wù)人員來(lái)說(shuō)，完成比完美更加重要。

他們更看重的是能不能實(shí)現(xiàn)，其次再是體驗(yàn)好不好。對(duì)他們來(lái)說(shuō)，如果能力上無(wú)法實(shí)現(xiàn)，即使產(chǎn)品再好用，價(jià)值也等于零。

對(duì)這部分開(kāi)發(fā)者，在產(chǎn)品設(shè)計(jì)時(shí)需要盡可能避免黑盒邏輯，盡可能白盒化展示。更通俗一點(diǎn)來(lái)說(shuō)，從易用性出發(fā)，需要做一些邏輯封裝，但這種封裝邏輯需要在產(chǎn)品上展示出來(lái)，最終目的是方便開(kāi)發(fā)者可以自主修改。

還是以按鈕的樣式為例，在產(chǎn)品設(shè)計(jì)時(shí)既要考慮將通用的 B 端業(yè)務(wù)領(lǐng)域經(jīng)驗(yàn)沉淀為快速的封裝配置，同時(shí)這種封裝邏輯的底層應(yīng)該是原子化的。

例如，對(duì)強(qiáng)提示場(chǎng)景下的「藍(lán)底白字無(wú)邊框」按鈕來(lái)說(shuō)，這種封裝應(yīng)該體現(xiàn)為「背景 = 藍(lán)色」、「文字 = 白色」、「邊框?qū)挾?= 0 px」等原子化配置。開(kāi)發(fā)者在 90%以上的場(chǎng)景下不需要關(guān)心底層的邏輯，但是需要修改時(shí)，例如「公司內(nèi)部的設(shè)計(jì)規(guī)范要求，強(qiáng)提示場(chǎng)景下的按鈕必須用黃色」，可以快速進(jìn)行修改。

與無(wú)代碼開(kāi)發(fā)者相比，給混合開(kāi)發(fā)者提供的產(chǎn)品功能在天花板上是更高的，但因?yàn)楸┞兜漠a(chǎn)品細(xì)節(jié)也要多很多，因此在易用性的設(shè)計(jì)上挑戰(zhàn)更大。

但有一個(gè)原則我認(rèn)為是需要達(dá)成共識(shí)的，對(duì)這部分用戶來(lái)說(shuō)，他們往往并不喜歡黑盒邏輯，他們的訴求是：

我可以不用，但你不能不告訴我。

3. 低代碼開(kāi)發(fā)者

典型畫(huà)像是獨(dú)立軟件開(kāi)發(fā)商（Independent Software Vendors）的 IT 人員，他們對(duì)平臺(tái)的要求是提供最大程度的開(kāi)放性。他們?nèi)粘５墓ぷ魇腔诘痛a平臺(tái)提供的能力去做二次開(kāi)發(fā)，對(duì)他們來(lái)說(shuō)，大部分的應(yīng)用搭建過(guò)程其實(shí)還是寫(xiě)代碼的過(guò)程。

這類開(kāi)發(fā)者往往基于低代碼平臺(tái)去構(gòu)建復(fù)雜的業(yè)務(wù)系統(tǒng)，包括 CRM、ERP、HRS 等常見(jiàn)的 SaaS 產(chǎn)品，都有可能是 ISV 基于低代碼平臺(tái)開(kāi)發(fā)完成的。

面向這類用戶去做產(chǎn)品設(shè)計(jì)時(shí)，往往需要考慮更底層的通用性，有時(shí)候甚至是代碼級(jí)別的通用性。舉幾個(gè)例子：

平臺(tái)自帶的數(shù)據(jù)模型模塊和外部數(shù)據(jù)源，能否作為一個(gè)統(tǒng)一的數(shù)據(jù)查詢端口供前端頁(yè)面調(diào)用，這種情況一般發(fā)生在系統(tǒng)遷移中。復(fù)雜的業(yè)務(wù)系統(tǒng)遷移很多時(shí)候是頁(yè)面先行，數(shù)據(jù)基座不變。

如果客戶公司有一套獨(dú)立的組件設(shè)計(jì)規(guī)范，那這套規(guī)范在接入低代碼平臺(tái)的同時(shí)，能否復(fù)用平臺(tái)已有的組件能力，包括屬性、樣式、事件、動(dòng)作、方法等能力。

這些復(fù)雜的場(chǎng)景都需要產(chǎn)品經(jīng)理在設(shè)計(jì)某個(gè)模塊的時(shí)候，前置地去考慮更多開(kāi)放能力的接入，而這對(duì)低代碼產(chǎn)品經(jīng)理的考驗(yàn)是巨大的。

甚至，可能只有產(chǎn)品架構(gòu)師才能完成面向低代碼開(kāi)發(fā)者的產(chǎn)品設(shè)計(jì)。

如上可得，即使我們的用戶都叫做開(kāi)發(fā)者，但這個(gè)群體的角色、身份、所在公司不同，對(duì)平臺(tái)的訴求是不一樣的，沒(méi)有一套統(tǒng)一的標(biāo)準(zhǔn)可以描述低代碼產(chǎn)品應(yīng)該怎么做，原因大概就在這里。

三、關(guān)于方案設(shè)計(jì)

做低代碼產(chǎn)品，對(duì)需求文檔的要求非常高。

復(fù)雜的需求文檔，一般會(huì)有兩個(gè)階段：1、需求概要；2、需求方案描述。

在需求概要中，產(chǎn)品經(jīng)理需要描述清楚問(wèn)題的背景和價(jià)值、競(jìng)品調(diào)研、核心方案。

背景和價(jià)值說(shuō)明了為什么要做這個(gè)需求，為什么要在現(xiàn)階段做這個(gè)需求。低代碼產(chǎn)品的技術(shù)復(fù)雜度很高，因此說(shuō)清楚需求的價(jià)值無(wú)論對(duì)于資源的分配，還是后期的跨團(tuán)隊(duì)協(xié)作，都是十分重要的事情。

在這一年的時(shí)間里，我也經(jīng)歷過(guò)著急忙慌地把需求方案趕出來(lái)，最后因?yàn)闆](méi)有對(duì)齊價(jià)值，導(dǎo)致在評(píng)審會(huì)上被質(zhì)疑，最后使得需求被降級(jí)或取消，這樣的事情對(duì)產(chǎn)品經(jīng)理來(lái)說(shuō)是非常致命的資源浪費(fèi)。

在價(jià)值證明階段，最容易出現(xiàn)的矛盾是產(chǎn)品自身的規(guī)劃與用戶反饋之間的沖突。例如在很早期的階段，低代碼產(chǎn)品大多都很難用且天花板也比較低，共創(chuàng)客戶可能會(huì)有非常多的負(fù)向反饋。那這時(shí)候，到底是先提升能力還是先提升體驗(yàn)，就非?？简?yàn)產(chǎn)品 leader 的判斷能力。

很多人會(huì)說(shuō)，就不能「既要也要」么。

如果資源充足，當(dāng)前可以。

但經(jīng)濟(jì)社會(huì)的常態(tài)就是「資源永遠(yuǎn)稀缺」，否則就沒(méi)有成本的概念。當(dāng)一個(gè)選擇一定伴隨著成本時(shí)，優(yōu)先級(jí)的抉擇就成了產(chǎn)品經(jīng)理每天要面對(duì)的最大矛盾。

當(dāng)價(jià)值確定了，該怎么做就成了第二個(gè)問(wèn)題。

中國(guó)的低代碼市場(chǎng)整理來(lái)說(shuō)起步較晚，2008 年，Saleforce 的 PaaS 平臺(tái)已經(jīng)承載了上萬(wàn)個(gè)應(yīng)用時(shí)，國(guó)內(nèi)的 PaaS 平臺(tái)可能還在襁褓階段。

對(duì)于后來(lái)者來(lái)說(shuō)，追擊領(lǐng)先者的有力武器便是借鑒，你也可以理解為「抄」。我覺(jué)得抄并不是一件丟人的事情，當(dāng)我們對(duì)一個(gè)新事物的認(rèn)知真的很有限時(shí)，與其用并不科學(xué)的舊法則來(lái)套用，不如用現(xiàn)成的新法則來(lái)嘗試。

但這個(gè)過(guò)程中對(duì)產(chǎn)品經(jīng)理最大的挑戰(zhàn)不是搞清楚別人是怎么做這個(gè)功能的，而是搞清楚別人是怎么解決這個(gè)問(wèn)題的，以及為什么是這樣的解決方式。

圍繞問(wèn)題而不是圍繞功能，這是低代碼產(chǎn)品做競(jìng)品調(diào)研的核心。

當(dāng)然，正如用戶分層里說(shuō)到，不同的產(chǎn)品針對(duì)的目標(biāo)用戶是不同的，因此他們?cè)O(shè)計(jì)的理念也是不一樣的。

做競(jìng)品調(diào)研時(shí)，找到值得研究的競(jìng)品比調(diào)研本身可能更重要。只有你的產(chǎn)品和研究對(duì)象在目標(biāo)用戶分層中基本保持一致，這樣的調(diào)研才更有參考價(jià)值。

最后就是核心方案，這部分的首要原則是解決核心問(wèn)題的邏輯需要自洽。寫(xiě)核心方案其實(shí)并不需要太多的筆墨，但難點(diǎn)在于推導(dǎo)過(guò)程是否邏輯自洽，是否是跑得通的。

在這一年的前半程，我的概要方案很多時(shí)候總會(huì)在若干個(gè)特定的點(diǎn)上沒(méi)有跑通，比如權(quán)限問(wèn)題沒(méi)有考慮，跟其他系統(tǒng)的協(xié)作沒(méi)有考慮，跟正在開(kāi)發(fā)的其他需求之間的沖突沒(méi)有考慮等。

因此要做到邏輯自洽，無(wú)其他更好的方式，只能不斷使用自己的產(chǎn)品，對(duì)產(chǎn)品的所有模塊都非常了解。這樣在一個(gè)復(fù)雜需求里，你才能在一開(kāi)始就知道涉及到的重點(diǎn)有哪些。

只要在一開(kāi)始沒(méi)有硬傷，后續(xù)的細(xì)節(jié)都是可以慢慢打磨的。

如果概要沒(méi)有問(wèn)題，那更具體的方案設(shè)計(jì)就基本沒(méi)有問(wèn)題，只是依據(jù)不同產(chǎn)品經(jīng)理的水平不同，有的人可能寫(xiě)得很細(xì)致，這樣開(kāi)發(fā)過(guò)程中的溝通會(huì)更高效，有的人可能寫(xiě)得比較粗略，那過(guò)程中的溝通就會(huì)更頻繁。

四、關(guān)于項(xiàng)目管理

雖然團(tuán)隊(duì)里有 PMO 這個(gè)角色，但是很多時(shí)候需求的項(xiàng)目管理角色都會(huì)由產(chǎn)品經(jīng)理?yè)?dān)當(dāng)，在復(fù)雜的需求里，項(xiàng)目管理能力有時(shí)候可能比產(chǎn)品設(shè)計(jì)能力更為重要，因?yàn)樗_保了交付成果。

對(duì)于產(chǎn)品經(jīng)理工作的考察，大家都有一個(gè)共識(shí)，只有真正上線的需求，才算是一個(gè)產(chǎn)品經(jīng)理的成績(jī)，在此之前的所有內(nèi)容，都只能算是過(guò)程。

沒(méi)有一個(gè)產(chǎn)品經(jīng)理在寫(xiě)簡(jiǎn)歷的時(shí)候會(huì)說(shuō)，我上一段工作經(jīng)歷中共寫(xiě)了多少篇需求文檔，一共包含多少個(gè)字。大家在聊的都是，上線的需求對(duì)實(shí)際業(yè)務(wù)到底帶來(lái)了多少價(jià)值。

關(guān)于項(xiàng)目管理的標(biāo)準(zhǔn)流程，就不必多說(shuō)了，在這里想分享一些推進(jìn)大型復(fù)雜需求時(shí)，在標(biāo)準(zhǔn)流程之外的發(fā)力點(diǎn)。

1. 前置溝通

雖然從流程上來(lái)說(shuō)，需求在設(shè)計(jì)完后就是評(píng)審，但為了評(píng)審順利，是需要做很多工作的。尤其是對(duì)低代碼產(chǎn)品來(lái)說(shuō)，由于這是個(gè)新事物，且團(tuán)隊(duì)里的很多人可能之前就不是做低代碼相關(guān)的領(lǐng)域，因此在認(rèn)識(shí)上對(duì)齊就顯得更為重要。

溝通的內(nèi)容與概要中的內(nèi)容基本一致，也都是做這件事的價(jià)值和大致思路。

有溝通就有分歧，面對(duì)分歧時(shí)，需要產(chǎn)品經(jīng)理提供足夠的參考信息，主要是競(jìng)品的參考信息和用戶的反饋，在因?yàn)橹饔^認(rèn)識(shí)不同而導(dǎo)致的分歧中，這樣的客觀信息反而能在求同存異時(shí)發(fā)揮更大的用處。

2. showcase

對(duì)復(fù)雜需求來(lái)說(shuō)，最大的成本可能就是返工成本。為了避免返工，在流程中可以增加一環(huán)叫 showcase，即面向研發(fā)、產(chǎn)品、設(shè)計(jì)展示冒煙用例，在提測(cè)之前將已有的問(wèn)題盡可能暴露，這樣在研發(fā)階段中可以增加一個(gè)質(zhì)量監(jiān)督節(jié)點(diǎn)，確保最終交付的需求是符合業(yè)務(wù)預(yù)期的。

3. 需求范圍管理

復(fù)雜需求往往牽一發(fā)而動(dòng)全身，雖然 B 端產(chǎn)品不能像 C 端產(chǎn)品那樣快速交付持續(xù)迭代，但對(duì)于低代碼這個(gè)新領(lǐng)域來(lái)說(shuō)，如果產(chǎn)品還在商業(yè)化之前的基建階段，我的建議是找到共創(chuàng)客戶，快速敏捷地交付獨(dú)立模塊。

對(duì)于低代碼平臺(tái)來(lái)說(shuō)，只有真正能搭建出實(shí)際的應(yīng)用，并經(jīng)受住真實(shí)用戶的考驗(yàn)，它才算是一個(gè)合格的低代碼平臺(tái)，而平臺(tái)背后的產(chǎn)品經(jīng)理，也才算是真正的低代碼產(chǎn)品經(jīng)理。

因此，明確管理每個(gè)需求的范圍，在指定時(shí)間內(nèi)交付指定的功能給到用戶，接收真實(shí)業(yè)務(wù)場(chǎng)景的考驗(yàn)，并拿到真實(shí)的反饋，可能才是低代碼平臺(tái)向前迭代的最踏實(shí)的道路。

五、關(guān)于低代碼業(yè)務(wù)

最后，聊聊我個(gè)人對(duì)低代碼業(yè)務(wù)的理解。

很早之前，我在讀吳軍的《浪潮之巔》時(shí)看到過(guò)這么一個(gè)觀點(diǎn)，如果某種技術(shù)對(duì)生產(chǎn)力的提升是 10 倍以上，那這個(gè)技術(shù)的誕生很有可能會(huì)顛覆某個(gè)領(lǐng)域。

例如從馬車到汽車的進(jìn)化，從汽車到飛機(jī)的進(jìn)化，每一個(gè)新物種的出現(xiàn)，都帶來(lái)了產(chǎn)業(yè)革命性的變化。

低代碼是這樣一個(gè)新物種么？很遺憾，我認(rèn)為并不是。

至少在目前來(lái)看，低代碼對(duì)于生產(chǎn)力的影響，并不足以達(dá)到 10 倍以上。目前天花板級(jí)別的低代碼產(chǎn)品，也只能實(shí)現(xiàn)說(shuō)「所有通過(guò)寫(xiě)代碼而生產(chǎn)的應(yīng)用，都可以通過(guò)拖拉拽簡(jiǎn)單的代碼實(shí)現(xiàn)」，況且能實(shí)現(xiàn)這個(gè)目標(biāo)的產(chǎn)品，屈指可數(shù)。

既然不是新物種，無(wú)法出現(xiàn)突變式的演進(jìn)，那就必然要遵循 B 端產(chǎn)品已有的客觀規(guī)律，漸進(jìn)式演進(jìn)。

在團(tuán)隊(duì)內(nèi)部的全員大會(huì)上，我向「飛書(shū)應(yīng)用引擎」的負(fù)責(zé)人提過(guò)一個(gè)問(wèn)題：如果說(shuō)有一條原則需要所有的低代碼產(chǎn)品、研發(fā)、設(shè)計(jì)、業(yè)務(wù)人員都去遵循，那這個(gè)原則是什么？

答案依舊是：客戶第一。

與 SaaS 產(chǎn)品不一樣的是，低代碼產(chǎn)品的客戶并不會(huì)來(lái)自一個(gè)特定的行業(yè)，甚至并不是應(yīng)用使用方本身，那這時(shí)候，客戶第一的原則背后就有一個(gè)更大的命題：誰(shuí)是我們的客戶。

這個(gè)命題在商業(yè)化之前就變得尤為關(guān)鍵，到底是根據(jù)現(xiàn)階段種子用戶的反饋去迭代，打造滿足他們的產(chǎn)品，還是根據(jù)我們對(duì)產(chǎn)品的定位找到更適合的客戶，我相信沒(méi)有絕對(duì)正確的答案，但這個(gè)問(wèn)題需要每個(gè)低代碼產(chǎn)品經(jīng)理反復(fù)去思考。

做產(chǎn)品久了，會(huì)發(fā)生很多時(shí)候并不是沒(méi)有解決辦法，而是解決辦法太多的時(shí)候，選擇哪一條路去進(jìn)行下去，就顯得尤為重要了。

六、結(jié)語(yǔ)

很早的時(shí)候，我問(wèn)過(guò) flomo 創(chuàng)始人少楠一個(gè)問(wèn)題：

背景：

我們現(xiàn)在做的工具處于早期，面臨很多上手門(mén)檻問(wèn)題，但體驗(yàn)優(yōu)化不能帶來(lái)工具天花板的提升，我們想要做的進(jìn)階和復(fù)雜功能，在競(jìng)品中都有，但是否要投入資源去做，團(tuán)隊(duì)希望產(chǎn)品經(jīng)理可以給要做的新功能想場(chǎng)景搏資源。我很怕陷入自嗨的詛咒里，最后做出了一個(gè)大家并不會(huì)用的功能。

問(wèn)題是這樣的：

1、如果做工具產(chǎn)品時(shí)，目標(biāo)是提升工具的天花板，那產(chǎn)品經(jīng)理是否需要為想要做的功能去想象場(chǎng)景。這些場(chǎng)景是目前的業(yè)務(wù)方?jīng)]有提出來(lái)的，但產(chǎn)品經(jīng)理也不知道用這個(gè)工具的業(yè)務(wù)在什么時(shí)候會(huì)遇到這樣的場(chǎng)景。

2、進(jìn)一步地，如果從邏輯（或者從競(jìng)品分析）中判斷這個(gè)新功能是合理的，但它基于這個(gè)新功能的場(chǎng)景在上線很長(zhǎng)的一段時(shí)間內(nèi)（比如半年）都沒(méi)有出現(xiàn)在實(shí)際業(yè)務(wù)中，那這個(gè)新功能是不是一個(gè)偽需求。

少楠的回答簡(jiǎn)單而堅(jiān)定：