Chuyện làm Product: Mình đã học được gì từ việc xây dựng và launch một sản phẩm cá nhân?

Mar 24, 2024

Xin chào, mọi người có khỏe không?

Tuần rồi, mình có dịp đọc lại case studies của Figma, Miro, và Cascade.io để hiểu về hành trình thành công cũng như thất bại của họ. Thú thật, mình thích tìm hiểu chiến lược phát triển và vận hành các doanh nghiệp công nghệ, và việc tìm đọc các case studies này là một cách để mình bóc tách được nhiều insights thú vị cho hành trình xây dựng và phát triển sản phẩm của mình.

When I watch your interviews, what I’m looking for is not the differences, but the similarities — the principles and the practices that are used consistently by the best product companies.

— Marty Cagan, in Product Management Theater podcast with Lenny Rachitsky

Tạm dịch:

Khi xem các cuộc trò chuyện của bạn (với khách mời), điều tôi tìm kiếm không phải là những điểm khác biệt, mà là những điểm tương đồng — những nguyên tắc và phương pháp được các công ty sản phẩm hàng đầu áp dụng một cách nhất quán.

Trong quá trình đó, mình chợt nhớ đến Code Diagram — một dự án cá nhân mà mình đã xây dựng vào năm 2023-2024. Dù hiện tại sản phẩm không được phát triển tiếp nữa, nhưng những gì học được trong giai đoạn này đối với mình vô cùng quý giá.

Trong bài viết này, mình sẽ chia sẻ lại hành trình xây dựng và launch dự án này, cùng với những bài học mình rút ra được sau đó. Bài viết tương đối dài, có một vài phần hơi kĩ thuật do bản chất sản phẩm, và chỉ dành riêng cho các bạn có hứng thú về việc xây dựng và launch các sản phẩm công nghệ cá nhân.

Bài viết gồm có 4 phần:

Tổng quan về vấn đề giải quyết và ý tưởng thiết kế sản phẩm
Quá trình và kết quả launch sản phẩm với người dùng
Định hướng phát triển sản phẩm trong tương lai
Đúc kết cá nhân (key takeaways)

#1 Tổng quan sản phẩm: Code Diagram

Ý tưởng xây dựng Code Diagram bắt nguồn từ bạn-cùng-nhà của mình là Huy Vũ vào giữa năm 2023.

Tại thời điểm đó, tụi mình đang làm chung một project cải thiện hệ thống thanh toán tại Holistics. Vì tính chất phức tạp của hệ thống, tụi mình cần trực quan hóa logic dưới dạng diagram để hiểu rõ luồng xử lí hiện tại.

Ban đầu, team sử dụng các công cụ vẽ diagram phổ biến như Lucid Chart và Figjam để ghi lại logic xử lí trong codebase. Tuy nhiên, khi diagram lớn hơn, tụi mình gặp phải một vấn đề quan trọng: Sự thiếu liên kết giữa code files và diagram khiến team phải liên tục chuyển đổi ngữ cảnh giữa môi trường lập trình (IDE) và công cụ vẽ.

Đánh giá các giải pháp hiện hữu (Existing Solutions)

Khi tìm kiếm các giải pháp hiện có trên thị trường, mình nhận thấy chưa có giải pháp nào giải quyết chính xác vấn đề mà team đang gặp phải.

Nhóm 1: Các công cụ vẽ diagram tổng quát (Lucid Chart, Figjam, draw.io…)

Vì không được thiết kế đặc biệt để trực quan hóa codebase, các công cụ này không được tích hợp mượt mà với IDE của engineers.

Mặc dù draw.io có cung cấp một extension trên Visual Studio Code để người dùng mở song song diagram với code file, 2 files này không có sự liên kết nào cả. Engineers phải thủ công copy & paste các đoạn code vào biểu đồ, và không thể nhanh chóng định vị đoạn code cụ thể từ diagram.

Ngoài ra, trải nghiệm người dùng (UX) kém cũng là vấn đề khi dùng các tool này để visualize codebase, như thiếu code formatting và syntax highlighting thích hợp.

So sánh giữa đoạn code được highlight và đoạn code không được highlight

Nhóm 2: Các công cụ vẽ code diagram (CodeMap, CodeSee…)

Phần lớn các giải pháp hiện có lúc đó như CodeSee và CodeMap đều theo hướng tự động tạo diagram dựa trên codebase.

Đây một điểm mạnh rất lớn vì người dùng không phải vẽ biểu đồ thủ công, nhưng các diagram này được tạo dựa trên nguyên tắc của nhà phát triển, nên thường phức tạp hơn mức cần thiết và ít phù hợp với luồng suy nghĩ (thinking flow) của engineers.

Tụi mình muốn một tool cho phép người dùng chọn lọc và tổ chức các thông tin để trên diagram (theo cách có ý nghĩa), thậm chí có thể thêm chú thích riêng nếu cần.

Vấn đề giải quyết & Giải pháp

Trong quá trình tìm kiếm giải pháp cho team, tụi mình nhận thấy một vài điểm thú vị:

Trong quá trình lập trình, đặc biệt khi tìm và sửa lỗi (debugging), engineers sẽ có nhu cầu hiểu sâu về codebase họ đang thao tác. Nhu cầu này rõ rệt hơn nếu họ đang làm việc trên một file ít quen thuộc.

Việc vẽ diagram giúp engineers hiểu sâu hơn về codebase, nhưng các công cụ hiện tại không tích hợp tốt với IDE của họ.

Ngoài ra, việc cho phép chọn lọc những phần code quan trọng và tổ chức chúng theo cách riêng giúp engineers diễn giải codebase tốt hơn, phù hợp với luồng suy nghĩ của họ hơn.

Điều này dẫn đến ý tưởng về một công cụ tích hợp vào môi trường lập trình của engineers, cho phép tạo diagram ngay bên cạnh code họ đang làm việc. Họ có thể dễ dàng chọn và trích xuất (snip) các đoạn code quan trọng, thêm chú thích hoặc ghi chú khi cần thiết, và nhanh chóng điều hướng giữa diagram và code thực tế.

Giao diện của Code Diagram

Vì quỹ thời gian hạn hẹp, tụi mình quyết định xây dựng một sản phẩm đủ tốt để giải quyết vấn đề cốt lõi, thay vì nhắm tới một sản phẩm hoàn hảo. Ngoài ra, để giảm friction cài đặt cho người dùng, mình chọn build Code Diagram là một extension của Visual Studio Code (IDE phổ biến nhất hiện nay), thay vì một application độc lập.

MVP gồm có 4 tính năng chính:

Tạo diagram file trực tiếp, song song với code
Trích xuất (snip) code nhanh chóng từ các file thực tế
Khả năng điều hướng từ diagram đến file tương ứng
Cơ chế lưu diagram khi mở code files

Tụi mình mất khoảng 3 tháng để hoàn thành phiên bản đầu tiên, và bắt đầu kế hoạch launch sản phẩm vào 1 tháng sau đó (tháng 8.2023).

#2 Launch sản phẩm

Vì được xây dựng từ nhu cầu cá nhân, chưa từng validate ý tưởng với thị trường nên ban đầu mình không có ý định launch sản phẩm. Cho đến khi nhận thấy một vài người bạn engineer cũng gặp vấn đề tương tự khi debug, tụi mình mới nghĩ “Hay là cứ launch đi, xem có học được gì thú vị không?”

“Overthinking seems like the “smart” way to launch, but it’s far less effective. Super-successful people do the opposite—they take action first, get real feedback, and learn from that, which is a million times more valuable than any book or course. And quicker! Most people: Overthink first, act later. Every successful entrepreneur: Act first, figure it out later.”

— Noah Kagan, in “Million Dollar Weekend”

Tạm dịch:

Suy nghĩ nhiều trông có vẻ là cách thông minh để bắt đầu, nhưng thực tế lại kém hiểu quả hơn nhiều. Những người thành công thường làm điều ngược lại Họ hành động trước, nhận phản hồi thực tế, và học hỏi từ đó. Điều này có giá trị và phản hồi nhanh hơn gấp triệu lần so với bất kì quyển sách, hay khóa học nào.

Đa phần mọi người sẽ suy nghĩ quá nhiều trước rồi mới hành động. Nhưng người thành công sẽ hành động trước, rồi tìm ra giải pháp sau.

Batch 1: Launch trên VSCode Marketplace

Vì là extension của VSCode, đây là kênh đầu tiên tụi mình chọn để launch, và cũng là nơi tạo ra các users đầu tiên cho sản phẩm.

Một số tactic tụi mình đã làm để “leo rank” trên bảng xếp hạng:

Đặt tên sản phẩm dễ truyền đạt core value, và tối ưu cho công cụ tìm kiếm (”Code Diagram”)
Đầu tư xây dựng logo và landing page chỉnh chu
Lấy verification badge (tích xanh) của VSCode cho sản phẩm
Tích cực phản hồi feedback của users

Sau hơn một năm, hiện tại tụi mình gần như dominate hai từ khóa “diagram” và “code diagram”, có hơn 18K lượt download, và generate khoảng 90% users từ nền tảng này. Với lượt download tương đối đều đặn, tụi mình có thể để sản phẩm tự chạy mà không cần phải đầu tư thêm quá nhiều ở thời điểm hiện tại.

Batch 2: Launch trên Hacker News và Reddit

Mặc dù vậy, việc chưa có các kênh phát triển khác ngoài VSCode Marketplace là một rủi ro lớn cho sản phẩm. Có nhiều trường hợp business phụ thuộc vào một kênh phân phối duy nhất đã phá sản khi kênh này thay đổi chính sách hoạt động (ví dụ như việc Google Search thay đổi thuật toán tìm kiếm).

Vào đầu năm 2024, tụi mình lựa chọn launch sản phẩm trên Hacker News và Reddit (/webdev) — nơi người dùng mục tiêu (engineers) tập trung nhiều nhất — nhưng kết quả không mấy khả quan. Khi nhìn lại, tụi mình mới thấy bản thân đã quá cẩu thả khi launch trên các nền tảng này mà chưa chuẩn bị nội dung kĩ càng.

Bài đăng trên Hacker News của tụi mình không hề tuân thủ các gợi ý của YCombinator với tiêu đề thiếu ấn tượng, nội dung chưa làm rõ vấn đề sản phẩm giải quyết, đồng thời thiếu các giải thích chi tiết về sản phẩm.

Ngược lại, tụi mình may mắn “ngáp phải ruồi” khi vô tình làm rõ giá trị sản phẩm ngay trong tiêu đề bài đăng trên Reddit, đồng thời đính kèm video minh họa cách thức hoạt động của sản phẩm. Kết quả, bài đăng này thu hút được 114 upvotes và 16 bình luận, đồng thời tạo ra được các traffic và lead mới cho sản phẩm trong các ngày tiếp theo.

Batch 3: Xây dựng Growth Loop

Mặc dù lần launch trước có giúp tụi mình thu hút thêm một lượng users, đây vẫn là những traffic thiếu bền vững:

Lượng truy cập có thể tăng đột biến trong giai đoạn launch, nhưng sẽ giảm dần vào những ngày sau đó.
Việc duy trì launch trên các nền tảng này đòi hỏi tụi mình phải đầu tư công sức nhất định, tạm gọi là “có làm thì mới có ăn” 🤣

Vì nguồn lực có hạn, tụi mình đã dừng lại sau một vài đợt launch rải rác, và nghĩ tới việc xây dựng một mô hình tăng trưởng hiệu quả hơn: Growth Loop.

Growth Loop là gì?

Growth Loop là một framework khá phổ biến trong việc phát triển sản phẩm, ý chỉ mô hình tăng trưởng theo dạng vòng lặp khép kín. Trong đó, Input (đầu vào) sau khi trải qua 1 số giai đoạn hoặc thực hiện 1 số hành động sẽ tạo ra kết quả là Output (đầu ra). Output này sau đó lại trở thành Input của vòng lặp tiếp theo.

Mọi người có thể tìm hiểu thêm về framework này tại bài viết dưới đây của Reforge.

Xây dựng Growth Loop cho Code Diagram

Dưới đây là một số tính năng tụi mình phát triển để xây dựng mô hình này ở Code Diagram:

Đây là một chiến thuật được nhiều sản phẩm sử dụng khi muốn tăng user base.

Ở Code Diagram, tụi mình yêu cầu người dùng trả $4/tháng hoặc chia sẻ sản phẩm lên X (Twitter) của họ để “mở khóa” tính năng xem nhiều diagram file cùng lúc. Kết quả là phần lớn users đều chọn chia sẻ. 🤣

Trung bình 1 tháng tụi mình sẽ có vài lượt chia sẻ từ tính năng này. Con số tuy không lớn nhưng sản phẩm đã có thêm một kênh thu hút traffic bền vững hơn; đồng thời, góp phần giúp xây dựng độ tin cậy sản phẩm trong cộng đồng tốt hơn.

2. Tính năng “Chia sẻ diagram” với người khác

Ban đầu, Code Diagram được xây dựng để giúp người dùng cá nhân hiểu sâu về codebase, thường dùng cho mục đích tìm và sửa lỗi (debugging). Tuy nhiên, trong quá trình monitoring và lấy feedback từ users, tụi mình đã phát hiện một insight vô cùng quan trọng:

Người dùng ở lại (retained users) thường build những diagram rất lớn, và có nhu cầu chia sẻ với đội nhóm của họ.

Từ đó, tụi mình đã phát triển thêm các tính năng hỗ trợ chia sẻ như Export diagram, Shareable link, Lưu diagram dưới dạng code file, Mở diagram trực tiếp trên Github…

Tính tới nay, các tính năng này hiện thu hút khoảng 10% người dùng mới, và hoàn toàn có khả năng phát triển thêm nếu tiếp tục đầu tư vào mô hình này. Trong một viễn cảnh tươi đẹp, nếu làm tốt, thậm chí có thể hướng đến xây dựng mô hình Product-led Growth (PLG) bền vững hơn.

#3 Định hướng phát triển

Sau vài tháng theo dõi và nhận feedback từ người dùng, tụi mình quyết định dừng phát triển và để sản phẩm tự chạy từ giữa năm 2024.

Mình nhận thấy vòng đời sản phẩm có giới hạn, vì tỉ lệ retention rate trung bình của sản phẩm khá thấp (~16% so với benchmark 25% (theo tuần) dành cho công cụ làm việc), và tỉ lệ này xấp xỉ 0% sau 12 tuần. Điều này có nghĩa sản phẩm hiện tại chỉ mang lại giá trị trong thời gian ngắn (3 tháng), sau đó người dùng không còn nhu cầu nữa.

Sau khi bóc tách vấn đề, tụi mình nhận thấy nguyên nhân chính đến từ việc sản phẩm đang giải quyết vấn đề một lần, của một tập nhỏ người dùng cá nhân:

Mặc dù sản phẩm giúp người dùng hiểu sâu về codebase, các tính năng hiện tại của Code Diagram chủ yếu tối ưu cho mục đích tìm và sửa lỗi (debugging). Tuy nhiên, nhu cầu sử dụng công cụ vẽ diagram khi debug chỉ xảy ra nếu lập trình viên ít quen thuộc với codebase đó.
Ngoài ra, sản phẩm cũng chỉ tập trung giải quyết vấn đề của nhóm lập trình viên cá nhân, chưa hỗ trợ tốt người dùng nhóm hoặc doanh nghiệp.

Vậy, kế hoạch tiếp theo là gì?

Nếu vẫn muốn tiếp tục phát triển Code Diagram, mình phải lựa chọn điều chỉnh (pivot) sản phẩm.

Trong quá trình tương tác với users, tụi mình nhận thấy các feedback đang dần hướng sản phẩm về một use case lớn hơn là Technical Design & Documentation, cùng với tập người dùng mở rộng hơn là đội nhóm (team) hoặc doanh nghiệp (business).

Ngoài ra, tụi mình cũng nhận ra solution design hiện tại cũng là một trở ngại trong việc phát triển sản phẩm, khi người dùng phải snip code thủ công. Một giải pháp tiềm năng mà tụi mình có nghĩ đến là tích hợp AI vào sản phẩm để hỗ trợ người dùng tạo diagram theo ý muốn của họ.

Tuy nhiên, vì nguồn lực có hạn nên tụi mình quyết định không điều chỉnh gì thêm. Và vì sản phẩm vẫn có giá trị với người dùng nên tụi mình vẫn để sản phẩm tự chạy (thỉnh thoảng nhận được feedback tích cực cũng vui lắm đó! 😆)

#4 Lời kết

Mặc dù quá trình xây dựng và launch Code Diagram vô cùng “nông dân” và thiếu kinh nghiệm, đây là một số bài học mà mình đã tích lũy được trong giai đoạn đó:

Tìm cách validate ý tưởng với thị trường nhanh nhất có thể, thay vì dành nhiều tháng để xây dựng sản phẩm hoàn hảo. Launch sớm, theo dõi các chỉ số thường xuyên, và không ngừng hỏi feedback từ người dùng đầu tiên (early adopters) sẽ cho chúng ta nhiều insights (và niềm vui) hơn bất kì kế hoạch nào.
Tránh phụ thuộc vào một nền tảng growth duy nhất dù nó vô cùng hiệu quả. Một thay đổi nhỏ trong thuật toán hay chính sách của nền tảng đó cũng có thể khiến sản phẩm của chúng ta “sập nguồn” trong một đêm.

Tuy nhiên, khi đa dạng hóa nền tảng, cần hiểu rõ cơ chế hoạt động của từng kênh và điều chỉnh chiến lược launch phù hợp. (”One size does not fit all”)
Chuẩn bị kĩ càng và chỉnh chu về nội dung khi chia sẻ sản phẩm trên các nền tảng như Product Hunt, Hacker News, Reddit… Hãy đảm bảo nội dung chia sẻ có tính gãy gọn, trực quan, và nhấn mạnh vào giá trị cốt lõi của sản phẩm.
Để sản phẩm phát triển bền vững, cần xây dựng các cơ chế khiến việc tăng trưởng trở thành một phần trong trải nghiệm sử dụng sản phẩm. Trong đó, Growth Loop và Product-led Growth thường là các mô hình phát triển được nhiều công ty công nghệ lựa chọn.
Sẵn sàng pivot sản phẩm khi cần thiết. Đừng giới hạn bản thân phải stick với vấn đề đầu tiên bạn định giải quyết. Khi nhận ra sản phẩm không tạo ra giá trị bền vững hoặc có retention rate thấp, hãy can đảm pivot và thử nghiệm hướng đi mới.

Nếu thấy bài viết này hữu ích, mình sẽ rất vui nếu bạn để lại một ❤️ hoặc bình luận cho mình nhé. 😆