Mở đầu — vì sao bài này quan trọng
Trong loạt bài case study về Product-Led Growth, Figma là một trong những ví dụ "kinh điển" mà bất kỳ người làm Growth nào cũng phải hiểu cho thấu đáo. Lý do không nằm ở chỗ Figma là một sản phẩm thiết kế đẹp, mà nằm ở chỗ Figma đã biến một hành vi vốn dĩ rất "cá nhân" — thiết kế giao diện — thành một hành vi tập thể, thời gian thực, diễn ra ngay trên trình duyệt. Chính sự dịch chuyển đó là động cơ tăng trưởng (growth engine) của họ.
Nếu ở các bài trước bạn đã học về viral loops (Bài 21), về network effects (Bài 22), hay về reverse trial (Bài 15), thì Figma là nơi tất cả những khái niệm đó hội tụ lại quanh một trục duy nhất: sự cộng tác (collaboration). Đây là điều khiến Figma khác biệt với Notion (workspace-led, Bài 29) hay Calendly (output-led, Bài 31). Notion lan tỏa qua việc chia sẻ tài liệu; Calendly lan tỏa qua việc gửi link đặt lịch ra ngoài. Còn Figma lan tỏa vì bản chất công việc thiết kế sản phẩm đòi hỏi nhiều người cùng nhìn vào một màn hình cùng lúc — designer, product manager, developer, marketer, thậm chí cả CEO.
Bài này sẽ giúp bạn giải mã: vì sao "collaboration-first" lại là một chiến lược PLG mạnh đến vậy, Figma đã thiết kế sản phẩm như thế nào để mỗi người dùng mới tự động kéo theo nhiều người dùng khác, và quan trọng nhất — bạn có thể rút ra bài học gì để áp dụng cho sản phẩm của chính mình, kể cả khi bạn không làm công cụ thiết kế.
Khái niệm cốt lõi
Nền tảng: Figma là ai
Figma được thành lập năm 2012 bởi Dylan Field và Evan Wallace, nhưng phải đến năm 2016 mới chính thức ra mắt công khai (public). Bốn năm "ẩn mình" đó không phải lãng phí — đó là thời gian họ giải một bài toán kỹ thuật cực khó: làm sao chạy được một công cụ thiết kế vector nặng nề ngay trong trình duyệt, mượt như phần mềm cài đặt trên máy. Đến năm 2022, Adobe tuyên bố mua lại Figma với giá khoảng 20 tỷ USD — một con số gây chấn động ngành phần mềm. Thương vụ này sau đó bị hủy vào năm 2023 do vướng rào cản chống độc quyền (antitrust) ở châu Âu và Anh, và Adobe phải trả Figma 1 tỷ USD phí hủy hợp đồng. Bản thân việc một "ông lớn" như Adobe sẵn sàng chi 20 tỷ để mua một đối thủ trẻ đã nói lên sức mạnh tăng trưởng của mô hình Figma.
Nhưng điều chúng ta quan tâm không phải lịch sử, mà là cơ chế PLG đằng sau con số đó.
Trụ cột 1 — Browser-first: xóa bỏ rào cản cài đặt
Quyết định nền tảng nhất của Figma là chạy hoàn toàn trên trình duyệt. Hãy hình dung đối thủ thời đó — Sketch — chỉ chạy trên macOS và phải cài đặt. Điều này tạo ra ba rào cản chết người với PLG:
- Người dùng phải tải về, cài đặt — một bước "ma sát" (friction) làm rớt rất nhiều người ngay từ đầu.
- Chỉ dùng được trên Mac — loại bỏ toàn bộ người dùng Windows, bao gồm phần lớn developer và PM.
- File nằm cục bộ trên máy — muốn cho ai xem phải export ra ảnh hoặc gửi file qua lại.
Trụ cột 2 — Multiplayer real-time: cộng tác là tính năng, không phải bổ trợ
Đây là trái tim của Figma. Nhiều người có thể cùng mở một file thiết kế và nhìn thấy con trỏ chuột của nhau di chuyển theo thời gian thực, giống như Google Docs nhưng cho thiết kế. Người ta gọi đây là tính năng "multiplayer".
Điểm tinh tế cần hiểu: cộng tác real-time không phải là một tính năng "thêm vào cho vui". Nó thay đổi bản chất của công việc. Trước Figma, quy trình thiết kế là: designer làm xong → export → gửi cho PM xem → PM phản hồi qua email/chat → designer sửa → gửi lại. Một vòng lặp chậm chạp, đầy hiểu lầm. Với Figma, PM và designer cùng ngồi trong một file, comment ngay tại vị trí cần sửa, developer mở chế độ "Inspect" để lấy CSS ngay. Công việc trở thành một không gian chung.
Hệ quả về mặt Growth rất sâu: khi công việc diễn ra trong một không gian chung, mỗi người tham gia mới đều phải có tài khoản Figma. Designer kéo PM vào, PM kéo developer vào, developer kéo QA vào. Đây chính là network effect nội bộ (Bài 22 sẽ đào sâu hơn) — giá trị của Figma với mỗi người tăng lên khi có thêm đồng nghiệp dùng nó.
Trụ cột 3 — Viral loop tự nhiên qua việc chia sẻ
Hãy ghép ba mảnh lại: browser-first (xem không cần cài) + multiplayer (làm việc cùng nhau) + bản chất công việc cần nhiều vai trò. Kết quả là một viral loop gắn liền với công việc (work-native viral loop):
- Một designer dùng Figma cho dự án.
- Họ cần feedback từ PM → gửi link → PM phải tạo tài khoản để comment.
- Developer cần lấy spec → vào file → tạo tài khoản để Inspect.
- Sang dự án sau, PM đó đề xuất "mình dùng Figma cho cả team luôn đi".
Trụ cột 4 — Free tier hào phóng cho cá nhân và nhóm nhỏ
Figma cho phép dùng miễn phí với số lượng file và collaborator giới hạn ở mức đủ để một cá nhân hoặc nhóm nhỏ làm việc thật. Sinh viên thiết kế, freelancer, startup nhỏ đều có thể bắt đầu mà không trả đồng nào. Chiến lược này (sẽ bàn kỹ ở Bài 38 — free tier hào phóng hay khắt khe) đảm bảo rằng tầng đáy của phễu luôn rộng: càng nhiều người làm quen với Figma từ khi còn miễn phí, càng nhiều người mang Figma vào công ty khi họ đi làm — và lúc đó công ty trả tiền.
Vì sao "collaboration-first" mạnh hơn "feature-first"
Điểm mấu chốt để bạn ghi nhớ: rất nhiều công cụ thiết kế khác cũng có tính năng tốt, thậm chí tốt hơn Figma ở vài khía cạnh. Nhưng họ thiết kế sản phẩm xoay quanh cá nhân designer. Figma thiết kế sản phẩm xoay quanh nhóm. Khi sản phẩm xoay quanh nhóm, mỗi lần sản phẩm được dùng là một lần nó tự nhân bản — bởi vì công việc nhóm không thể diễn ra nếu chỉ một người có quyền truy cập. Đó là khác biệt giữa một sản phẩm "có tính năng cộng tác" và một sản phẩm "lấy cộng tác làm gốc".
Tình huống thực tế
Ví dụ 1 — Startup fintech ở TP.HCM chuyển từ Sketch sang Figma
Một startup fintech tại TP.HCM (gọi là "Công ty A", khoảng 40 nhân sự) năm 2021 có đội thiết kế 3 người dùng Sketch trên máy Mac. Quy trình của họ: designer export màn hình lên Zeplin, dán link vào nhóm Telegram, developer tải ảnh về và tự đoán khoảng cách, màu sắc. Mỗi vòng feedback mất 1–2 ngày vì PM (dùng Windows) không mở được file Sketch, phải chờ designer export.
Khi một designer mới gia nhập đề xuất dùng Figma, mọi thứ thay đổi trong vài tuần. Vì Figma chạy trên trình duyệt, PM dùng Windows mở file ngay được. Developer dùng chế độ Inspect lấy thông số CSS chính xác thay vì đoán. Số lần sửa đi sửa lại do hiểu lầm spec giảm rõ rệt, theo ước tính nội bộ của họ khoảng 30–40%.
Điều thú vị về mặt PLG: ban đầu chỉ 3 designer cần tài khoản. Nhưng trong vòng hai tháng, có thêm 4 developer, 2 PM, 1 marketer (cần lấy ảnh thiết kế cho landing page) cùng vào Figma. Đội thiết kế 3 người ban đầu đã tự động kéo thêm 7 người — và khi nhu cầu vượt giới hạn free tier, công ty nâng cấp lên gói trả phí.
Bài học: Figma không cần đội sales gọi điện cho Công ty A. Sản phẩm tự lan từ 3 người ra 10 người nhờ bản chất cộng tác. Đây là PLG đúng nghĩa — sản phẩm tự bán chính nó thông qua việc được dùng.
Ví dụ 2 — Agency thiết kế và "khoảnh khắc khách hàng vào file"
Một agency thiết kế ở Hà Nội (khoảng 15 người) phục vụ các thương hiệu F&B. Trước đây họ gửi bản thiết kế cho khách bằng file PDF, khách phản hồi qua email kiểu "cái logo ở góc trên bên trái, dịch sang phải một chút" — mơ hồ và dễ sai.
Khi chuyển sang Figma, họ chia sẻ link "view + comment" cho khách hàng. Khách không cần biết thiết kế là gì, chỉ cần click vào đúng chỗ trên màn hình và gõ comment ngay tại đó. Mỗi khách hàng mới được mời vào file là một người mới tiếp xúc trực tiếp với Figma — và nhiều khách sau đó hỏi "công cụ này là gì, bên tôi cũng muốn dùng để quản lý dự án thiết kế nội bộ".
Bài học: Đây là viral loop ra ngoài tổ chức (cross-organization). Khác với Ví dụ 1 (lan trong nội bộ công ty), ở đây Figma lan từ agency sang khách hàng của agency. Mỗi link chia sẻ là một "hạt giống" gieo vào một tổ chức mới. Hãy để ý: agency không hề có ý định "marketing hộ" cho Figma — họ chỉ đang làm việc, nhưng cách làm việc đó tự khuếch tán sản phẩm.
Ví dụ 3 — Vì sao Sketch (giả định một đối thủ tương tự) tăng trưởng chậm hơn
Hãy lấy một đối thủ chạy trên desktop làm phản ví dụ. Giả sử công cụ X cũng đẹp, cũng mạnh, nhưng chỉ chạy trên Mac và file nằm cục bộ. Khi designer của Công ty A muốn cho PM xem, họ phải export ảnh — và PM không bao giờ chạm vào công cụ X. Vòng lan tỏa bị chặt đứt ngay tại điểm "chia sẻ". Mỗi người dùng X vẫn chỉ là một hòn đảo cô lập.
Hệ số lan truyền (viral coefficient, tạm gọi k) của X gần như bằng 0 ở tầng cộng tác: một người dùng mới gần như không kéo theo người dùng mới nào khác qua chính hành vi công việc. Trong khi đó k của Figma lớn hơn 0 một cách tự nhiên, vì mỗi file là một lời mời.
Bài học: Cùng một thị trường, cùng chất lượng tính năng, nhưng kiến trúc phân phối (distribution architecture) quyết định ai thắng. Browser-first + multiplayer không chỉ là lựa chọn kỹ thuật — đó là lựa chọn chiến lược tăng trưởng. Đây là lý do nhiều chuyên gia nói "Figma thắng không phải vì công cụ thiết kế tốt hơn, mà vì mô hình phân phối tốt hơn".
Hướng dẫn từng bước
Giả sử bạn muốn áp dụng tư duy "collaboration-first PLG" của Figma vào sản phẩm của mình. Đây là khung 6 bước:
Bước 1 — Tìm "đơn vị công việc cần nhiều người". Hỏi: trong sản phẩm của tôi, có hành động nào mà tự nhiên cần nhiều người cùng tham gia không? Với Figma là "file thiết kế". Với bạn có thể là một báo cáo, một tài liệu, một dự án, một dashboard. Nếu chưa có, hãy nghĩ cách biến công việc cá nhân thành công việc nhóm.
Bước 2 — Xóa rào cản truy cập cho người được mời. Người nhận lời mời phải xem/tham gia được mà không cần cài đặt, không cần trả tiền, gần như không cần đăng ký phức tạp. Đây là bài học browser-first. Hãy đảm bảo "chi phí để bắt đầu xem" bằng gần 0.
Bước 3 — Làm cho việc mời người khác là con đường tự nhiên để hoàn thành công việc, không phải một nút "Invite" ẩn đâu đó. Ở Figma, bạn không thể lấy feedback nếu không chia sẻ link. Hãy đặt lời mời ngay trên dòng chảy công việc chính.
Bước 4 — Phân quyền theo vai trò để hạ ma sát. Figma có view, comment, edit. Người chỉ cần xem thì không buộc phải có quyền edit (vốn tốn tiền). Quyền "nhẹ" giúp nhiều người vào hơn, mở rộng đáy phễu; quyền "nặng" (edit) là nơi bạn monetize.
Bước 5 — Free tier đủ rộng để công việc thật diễn ra. Đừng giới hạn chặt đến mức nhóm nhỏ không làm được gì. Mục tiêu của free tier không phải kiếm tiền — mà là gieo thói quen và lan tỏa. Tiền đến khi nhóm lớn lên hoặc cần tính năng quản trị.
Bước 6 — Thiết kế điểm nâng cấp gắn với "thành công của nhóm". Khi nào người ta trả tiền? Khi nhóm vượt giới hạn collaborator, khi cần quản lý quyền, khi cần các tính năng dành cho tổ chức. Hãy đặt "tường thu phí" (paywall) ở đúng điểm mà giá trị nhóm đã rõ ràng — chứ không phải chặn ngay từ đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi cộng tác là một tính năng cộng thêm. Nhiều đội thêm nút "Share" vào cuối hành trình rồi tự nhận "sản phẩm chúng tôi cũng có cộng tác". Nhưng nếu cộng tác không nằm ở trục trung tâm của sản phẩm, viral loop sẽ rất yếu. Mẹo: hãy hỏi "người dùng có bắt buộc phải kéo người khác vào để hoàn thành việc không?". Nếu câu trả lời là "không bắt buộc", loop của bạn còn yếu.
Lỗi 2 — Bắt người được mời đăng ký quá sớm/quá phức tạp. Nếu khách hàng của agency phải tạo tài khoản, xác thực email, điền form trước khi xem được thiết kế, đa số sẽ bỏ. Mẹo: cho phép xem trước, comment trước; chỉ yêu cầu đăng ký khi thực sự cần.
Lỗi 3 — Free tier quá khắt khe vì sợ "mất doanh thu". Đây là sai lầm tư duy phổ biến ở các đội Việt Nam. Free tier hào phóng của Figma không phải "cho không" — đó là chi phí marketing dưới dạng trải nghiệm sản phẩm. Mẹo: đo xem free user có lan tỏa không (mỗi free user kéo theo bao nhiêu người), thay vì chỉ đo họ có trả tiền không.
Lỗi 4 — Quên rằng collaboration-first chỉ hợp với một số loại sản phẩm. Không phải sản phẩm nào cũng có "đơn vị công việc nhiều người". Nếu sản phẩm của bạn vốn dĩ dùng đơn lẻ (ví dụ một app ghi chú cá nhân), ép cộng tác có thể phản tác dụng. Mẹo: đừng sao chép Figma một cách máy móc; hãy hỏi sản phẩm của bạn có "tính nhóm" tự nhiên không. (Bài 7 và Bài 55 bàn sâu về việc PLG có phù hợp hay không.)
Mẹo nâng cao — đo lường loop: Theo dõi chỉ số "số người được mời trung bình trên mỗi người dùng tạo nội dung mới" và "tỷ lệ người được mời trở thành người dùng hoạt động". Đây là hai con số cho biết viral loop kiểu Figma của bạn có thực sự chạy hay không.
Bài tập thực hành
- Phân tích loop: Vẽ ra sơ đồ viral loop của Figma trên giấy, bắt đầu từ "một designer mở file mới" và kết thúc ở "một tổ chức mới trả tiền". Đánh dấu ít nhất 4 điểm mà một người dùng mới bị "kéo vào" hệ thống.
- Áp dụng vào sản phẩm bạn biết: Chọn một sản phẩm SaaS Việt Nam mà bạn quen (Base.vn, Misa AMIS, hoặc bất kỳ công cụ nội bộ nào). Trả lời: sản phẩm đó có "đơn vị công việc cần nhiều người" không? Nếu một người dùng mời đồng nghiệp, người được mời có cần cài đặt/trả tiền để tham gia không? Loop của họ mạnh hay yếu so với Figma?
- Thiết kế lại một ma sát: Hãy chọn một sản phẩm bạn từng dùng mà việc chia sẻ rất phiền (phải export, phải gửi file, phải cài app). Viết ra 3 thay đổi cụ thể để biến nó thành "browser-first" như Figma, và dự đoán tác động lên viral coefficient.
- Tranh luận: Viết một đoạn 150 từ trả lời: "Nếu Figma tính phí ngay cả với người chỉ vào để xem và comment, điều gì sẽ xảy ra với tăng trưởng của họ?" Dùng các khái niệm về ma sát và viral loop trong bài để lập luận.
Tóm tắt
Figma là minh chứng rõ ràng nhất cho luận điểm: trong PLG, mô hình phân phối quan trọng ngang — thậm chí hơn — chất lượng tính năng. Bốn trụ cột tạo nên cỗ máy tăng trưởng của Figma là: (1) browser-first xóa rào cản cài đặt và mở rộng đáy phễu, (2) multiplayer real-time biến công việc thiết kế thành công việc nhóm, (3) viral loop work-native khiến mỗi file trở thành một lời mời tự nhiên không cần phần thưởng, và (4) free tier hào phóng gieo thói quen ở tầng đáy để thu tiền ở tầng tổ chức.
Điểm cốt lõi để mang theo: "collaboration-first" mạnh không phải vì cộng tác là tính năng hay, mà vì khi cộng tác là gốc của sản phẩm, mỗi lần sản phẩm được dùng là một lần nó tự nhân bản — designer kéo PM, PM kéo developer, agency kéo khách hàng. Đó là tăng trưởng được nhúng vào chính cách công việc diễn ra.
Khi áp dụng cho sản phẩm của bạn, đừng sao chép giao diện Figma — hãy sao chép tư duy: tìm đơn vị công việc cần nhiều người, xóa rào cản cho người được mời, đặt lời mời ngay trên dòng chảy công việc, và thu phí ở đúng điểm mà giá trị nhóm đã hiển hiện. Đó là cách bạn biến chính sản phẩm thành kênh tăng trưởng.