Nguyên tắc xây dựng MVP "phi chính thống"

Những bài học từ sách vở sau khi được gọt dũa từ những bài học thực tế

Khi xây dựng MVP (phiên bản khả dụng tối thiểu) của một số sản phẩm, mình nhận ra những nguyên tắc tưởng chừng như đúng hoàn toàn thực ra lại không đem lại hiệu quả như mong đợi nếu áp dụng máy móc vào việc phát triển MVP với một team nhỏ, nơi tốc độ và sự lăn xả mới ảnh hưởng trực tiếp lên sự thành bại của một sản phẩm mới. Và mình xin nói trước những kinh nghiệm này lấy được từ bối cảnh xây dựng MVP ở một startup nhỏ, nó không phù hợp cho việc làm những chức năng hay MVP ở công ty lớn, sản phẩm đã đạt được product-market fit (trạng thái khi một sản phẩm hoặc dịch vụ đáp ứng đúng nhu cầu của một phân khúc thị trường cụ thể).

Trong phần này mình sẽ nhắc đến những nguyên tắc như xây dựng bản MVP nhanh nhưng trong “tốc độ cho phép”, tìm kiếm sự thật thay vì an toàn đi theo cách làm của những công ty lớn, và cuối cùng là phải cam kết trước khi bắt tay xây dựng. Để cho cả những bạn đọc mới làm sản phẩm cùng hiểu, mình sẽ chia sẻ chi tiết cả những nguyên tắc “gốc” và những nguyên tắc mình đúc kết được. Các bạn cùng đọc nhé.

I. Xây dựng bản MVP nhanh nhất… trong mức độ rủi ro lên danh tiếng thấp nhất

Trong những bài viết hoặc những quyển sách về quản lý sản phẩm, phần lớn tác giả đều khuyên đưa bản MVP của một sản phẩm ra ngoài thị trường nhanh nhất có thể. Nguyên tắc này cực kì hợp lý khi bạn nhìn ở một góc nhìn lưỡng cực, tức là bắt buộc phải chọn giữa xây dựng cực nhanh hay xây dựng cực chậm? Khi xây nhanh, dù là sản phẩm chưa được hoàn thiện nhưng ít nhất bạn đã có những dữ liệu đầu tiên và chắc chắn về thị trường. Ví dụ như khi ý tưởng về một ứng dụng hẹn họ nghiêm túc được đưa ra thị trường mà những người dùng rất không hài lòng về hình thức kết đôi một trai một gái của ứng dụng, những người sản phẩm lúc này (tuy buồn nhưng) ít nhất đã có những dữ liệu rất đáng tin cậy khi sản phẩm tương tác với thế giới bên ngoài. Khi bạn là một người theo chủ nghĩa hoàn hảo và đòi hỏi sản phẩm theo những quy chuẩn khắt khe bên ngoài thị trường, quá trình tích lũy insight (thông tin sâu sắc) sẽ chứa nhiều rủi ro khi không được xác thực bởi thế giới bên ngoài, thường là người dùng và cả thị trường. Chưa tính đến hai rủi ro căn cơ của quan điểm này:

1. Đội ngũ nội bộ chưa chắc đã có đủ kinh nghiệm và bài học thực tế để lựa chọn được những quy chuẩn “vừa sức” nhất với sản phẩm trong giai đoạn hiện tại

2. Dù có xác thực được rằng vấn đề người dùng mà sản phẩm tập trung giải quyết rất đáng để xử lý (tỉ lệ thành công vốn đã thấp), việc đảm bảo giải pháp giải quyết được vấn đề lại là một chuyện bất định đáng kế khác.

Hậu quả thì chắc chắn là không quá khó để tìm, đã có vô vàn sản phẩm ngoài thị trường nhìn đẹp mắt, những thông điệp truyền thông rất dễ hiểu, nhưng lại không đạt được kết quả như những bạn founder đã dốc hết tâm huyết để mơ.

Vậy tại sao không tăng tốc đến mức những người lái giật ngửa ra sau 45 độ? Ai không có tư duy xác suất cũng biết phần trăm gặp được người thân ở phía bên kia là rất cao. Tương tự với rủi ro đó, đây là một số hậu quả của việc xây sản phẩm “quá tốc độ”: Sản phẩm có giao diện xấu đến mức cẩu thả dù được xây dựng trên những khái niệm rất thực tế, sản phẩm gặp vô vàn lỗi ngay từ những luồng sử dụng cơ bản, sản phẩm không sử dụng bất cứ một biện pháp bảo mật nào, có thể truy cập vào bất cứ dữ liệu nhạy cảm nào mà không cần xác thực…

“Phải mất 20 năm để xây dựng danh tiếng và năm phút để hủy hoại nó” ( “It takes 20 years to build a reputation and five minutes to ruin it” - Warren Buffett). Và đây chính là 5 phút mà mình vừa nhắc tới. Cho dù bạn có nói trước với người dùng và công chúng rằng đây chỉ là bản thử nghiệm của sản phẩm, bạn không thế chối cãi một điều là sản phẩm này được làm ra từ chính tay bạn. Khi phần lớn những early adopters (người trải nghiệm sớm) thường là người quen biết, rủi ro này càng trở nên nghiêm trọng hơn vì nó trực tiếp ảnh hưởng đến danh tiếng cá nhân. Điều này đặc biệt quan trọng trong bối cảnh những sản phẩm MVP “underground”, nơi các nhà sáng lập thường tự mình chịu trách nhiệm phân phối và giới thiệu sản phẩm, chứ không thể nấp sau uy tín của một thương hiệu lớn. Cộng thêm việc, mức tối thiểu được thị trường chấp nhận ngày càng cao, áp lực về chuyện “làm nhanh nhưng không cẩu thả” trở nên rõ rệt hơn.

Tóm gọn lại, nguyên tắc này có thể diễn đạt đơn giản: chỉ làm nhanh đến mức mà rủi ro đối với danh tiếng vẫn nằm trong giới hạn chấp nhận được. Chi tiết hơn thì dù có chiến lược làm nhanh, có những quy chuẩn tối quan trọng mà bạn phải đề ra để tránh tiếng tăm của sản phẩm chết yểu ngay khi nó còn chưa ra đời. Một vài trong số đó có thể kế đến: Xác thực thông tin người dùng, giữ thiết kế sản phẩm ở mức trung bình, giữ cho các luồng hoạt động chính trơn tru (chấp nhận những luồng hoạt động ngoại lệ có thể lủng)... Đôi khi những luồng hoạt động ngoại lệ người dùng còn chẳng dùng đến, khi làm sản phẩm A Little Optimism, có những lỗi đến vài tuần sau chúng mình phát hiện ra nhưng chưa ai thèm sờ vào chức năng đó cả. Và tụi mình thường nói vui với nhau rằng (nhớ là nói vui nhen): “Khi nào người dùng mắng thì sửa”. Nhưng riêng luồng hoạt động chính thì không dám thỏa hiệp với bất cứ một lỗi hoạt động nào.

Để cho các bạn hiểu rõ hơn ý mình nói, mình sẽ lấy ví dụ trên lựa chọn thiết kế của MyCabin, một sản phẩm chăm sóc sức khỏe tinh thần mà mình đang xây dựng tại Seesaw. Từ trái sang phải là ý tưởng rất phức tạp đến quá đơn giản, và mức an toàn là thiết kế ở giữa.

Tuy “xây nhanh” là nguyên tắc quan trọng, nhưng nhanh không có nghĩa là bê nguyên cách làm của các tập đoàn lớn vào sản phẩm của bạn mong cầu nó cũng thành công như vậy. Ở giai đoạn đầu, bạn không cần một hệ thống hoành tráng hay bảng dashboard phức tạp để theo dõi người dùng - bạn cần sự thật, cần đối thoại, cần chạm tay vào vấn đề. Những tập đoàn lớn có thể chờ dữ liệu hàng tháng để ra quyết định, nhưng với sản phẩm nhỏ thì 2 tháng có thể có thêm một chục đối thủ phát hành các chức năng tương tự ra thị trường. Nguyên tắc mình nói sau đây - “Nhỏ nhưng thật” - nghĩa là dám tự làm, dám sai, dám sửa, chứ không chọn phương án an toàn là sử dụng quy trình của công ty lớn.

II. Nhỏ nhưng thật - đừng xây MVP như một tập đoàn

Bạn hãy đọc những cách tiếp cận sau và đánh giá chúng có vấn đề gì khi áp dụng lên một sản phẩm mới:

1. Làm ra những chức năng, phát hành ra ngoài và ngồi chờ metrics nhảy số

2. Chỉ lấy những feedback thông qua những khảo sát hoặc tracking events (Những sự kiện theo dõi cách sử dụng của người dùng)

3. Chăm chăm kiếm đủ điểm dữ liệu cho những nhu cầu của người dùng thì mới bắt tay vào thực hiện

So hành vi này với việc đi ăn ở ngoài thì đây không khác gì học cách phục vụ của McDonald, KFC,… trong khi mình thì đang làm xe bánh mì ven đường. Mình quan sát có rất nhiều bạn học viên của tụi mình tại Breaking into PM khi đi thi những cuộc thi Product Management Trainee thường bắt chước những hoạt động thông dụng ở những công ty lớn hoặc những startup đã thành công. Và những hoạt động này chắc chắn không sai nhưng sai với những sản phẩm mới ở giai đoạn đầu. Những công ty lớn làm như vậy vì họ có vị thế để được làm như vậy, và đôi khi là… phải chấp nhận làm như vậy. Mình sẽ giải thích quan điểm đó bằng hai ví dụ bên trên. Đó là việc phát hành những chức năng ra ngoài, ngồi chờ metrics (thước đo, chỉ số) nhảy số và việc chỉ lấy những feedback thông qua những khảo sát, tracking events.

Thứ nhất, việc những công ty lớn làm ra những chức năng và trao lại trách nhiệm hoàn toàn cho đội marketing là họ có vị thế được làm như vậy. Chưa tính đến chuyện bạn có đủ tài chính để xây dựng cả một đội ngũ marketing hay không, việc làm cho người khác hiểu được một khái niệm mới khác với những sản phẩm ngoài kia là không hề đơn giản. Để hiểu độ khó của việc này thì bạn hãy thử mô tả sản phẩm hiện tại bạn đang xây dựng mới cho bạn bè khác ngành, hoặc nghĩ lại trải nghiệm của bạn khi giải thích những khái niệm trên facebook (bài đăng, bình luận, biểu cảm, chia sẻ…) cho bố mẹ thời kì họ mới sử dụng. Nhưng đối với một công ty lớn, chưa kể về lợi thế nhất định về mặt thương hiệu thì họ cũng đã có một tập khách hàng đáng kể sẵn sàng nghe họ nói rồi.

Phần tiếp theo sẽ giải thích tại sao phần lớn việc chỉ lấy những feedback thông qua những khảo sát hoặc tracking event là vì họ phải chấp nhận làm như vậy. Để rõ hơn nữa, mình sẽ kể lại một trải nghiệm khi mình làm khảo sát cho một MVP. Chắc hẳn khi làm sản phẩm một thời gian bạn cũng có nghe đến Importance vs Satisfaction Framework - một framework để đánh giá độ ưu tiên của những nhu cầu người dùng dựa trên độ quan trọng và độ không hài lòng của người dùng hiện tại. Sau khi đã khảo sát một số doanh nghiệp, mình may mắn có cơ hội được phỏng vấn trực tiếp cùng họ. Và may hơn nữa là nhờ tính đa nghi như Tào Tháo, mình đã dũng cảm xác thực lại xem con số họ trả lời trên khảo sát. Buồn thay, một nhu cầu họ đánh giá là rất không hài lòng (5/10) thực chất chỉ là cảm giác chủ quan của sếp trong khi quy trình và nhân viên của họ đang xử lý rất tốt nhu cầu đó. Khi đứng ở vị trí người trả lời, mình mới thấy sự bất cập nhất định của việc làm khảo sát: người trả lời không thực sự rất nghiêm túc suy nghĩ khi làm khảo sát, người trả lời không có động lực để tìm kiếm sự thật trong khi kết quả khảo sát đang phục vụ người khác… Nhưng để một công ty có 17 nghìn người dùng đi phỏng vấn thì tốn rất nhiều thời gian và công sức, chưa kể có khả năng cao phỏng vấn vào những người không phải tệp người dùng mục tiêu của họ nữa. Trong khi việc phỏng vấn, nói chuyện với từng người dùng của giai đoạn đầu tiên sẽ đem lại những sự thật rất đáng tin để có được những viên gạch đầu tiên đúng đắn nhất để xây dựng sản phẩm.

Việc làm ra một sản phẩm mới trên thị trường hay được ví với việc thay đổi cả một thực tại, Facebook thay đổi hoàn toàn cách mọi người kết nối, Figma đã thay đổi hoàn toàn luồng làm việc với designer và thậm chí góp phần nâng tầm quan trọng của công việc thiết kế trong quy trình làm sản phẩm. Quan điểm của mình về độ tương quan giữa kết quả và hoạt động là: một sản phẩm thành công có khả năng tác động lớn không thể chỉ dựa vào những hành động làm sản phẩm bình thường mà ai cũng sử dụng. Nó cần sự đầu tư, tỉ mỉ, tinh thần lăn xả và quyết liệt hơn những công ty đang được rót vốn với số tiền bạn có nằm mơ cũng không đếm được hết số 0. Ví dụ như thay vì chỉ đăng lên những mạng xã hội và chờ số chạy, mình thường nhờ những học viên thân thiết của mình sử dụng sản phẩm vì mình biết họ sẵn sàng cho mình phản hồi chân thực nhất. Trong khi người lạ thường có rào cản để nói ra trải nghiệm tiêu cực trực tiếp với mình. Thay vì đi cóp nhặt những bài đăng đang trên xu hướng và đăng lên một cách vô hồn thì mình tự đi nói chuyện với người dùng để hiểu những băn khoăn của họ rồi từ đó tạo ra chính những nội dung marketing giúp ích cho vấn đề ấy.

Cái khó của giai đoạn làm MVP là bạn phải vừa làm, vừa học, vừa chạy, vừa nghĩ. Nếu coi sản phẩm là một sinh vật sống, thì người làm MVP không phải nhà quản lý, mà là người chăm cây. Bạn phải chạm tay vào đất, nhìn màu lá, cảm được chỗ nào thiếu nước, chỗ nào cần ánh sáng. Những tập đoàn lớn có hệ thống tưới tự động, còn bạn ở giai đoạn này lại cần đôi tay thật. Sau khi thấy rõ được sợi dây kết nối từ những hoạt động trong quá khứ có thể dẫn ra những kết quả trong tương lai như nào, bạn sẽ có những bài học thấm thía dù kết quả trả về có là tích cực hay không. Từ đó, điều chỉnh lại cách làm, cách suy nghĩ chưa hợp lý để tăng tỉ lệ thành công ở những lần thử nghiệm tiếp theo.

III. Commit - Build - Measure - Learn

Sự thiếu tỉ mỉ và quyết liệt mình nhắc đến trong phần trước cũng gây ra một vấn đề lớn mà mình quan sát được từ những đội làm product mình tham gia cùng. Trong một process thông dụng là Build - Measure - Learn (Làm - Đo - Rút kinh nghiệm), phần lớn mọi người sẽ chỉ chăm chăm build, phần ít mọi người dành công sức để measure, một phần ít hơn nữa chịu learn từ quá trình build và chỉ một phần rất rất nhỏ là đặt ra một mục tiêu rõ ràng và follow nó suốt quá trình Build - Measure - Learn. Nếu bạn trả lời được những câu hỏi sau, thì mình nghĩ bạn sẽ không có vấn đề gì với nguyên tắc này cả:

• Giả thuyết của bạn đưa ra cho vấn đề mà các bạn đang giải quyết là gì?

• Sau khi build, bạn dựa vào thông tin nào để chọn cách measure?

• Sau khi measure, đâu là những bài học bạn nhận ra sau bao nhiêu công sức đưa chức năng/sản phẩm ra thị trường?

Chính mình và đội ngũ làm sản phẩm cũng thi thoảng quên đi hoạt động này. Hậu quả là cả đội sẽ chỉ cố gắng làm việc để cho ra được những chức năng, không hề biết được quy trình hiện tại có hiệu quả hay không, sự tập trung của mỗi người dường như nằm ở mỗi hướng khác nhau của sản phẩm (Hậu quả này còn được khai thác rõ hơn trong bài "When Everything is Important But Nothing is Getting Done"). Nếu chính bạn cũng không trả lời được câu hỏi có đang thành công hay không thì ông bụt nào sẽ hiện lên và chúc mừng bạn? Việc học phụ thuộc chủ yếu vào chuyện so sánh tương đối giữa kết quả và kì vọng, dù là bạn đang tập nói một câu tiếng Anh, tập chơi một nhạc cụ, hay là đang “chơi” một sản phẩm. Khi không xác định kì vọng thì dù có tập luyện bao nhiêu thì cũng chẳng định nghĩa được quá trình tập luyện đang sai hay đúng.

Việc học phụ thuộc chủ yếu vào chuyện so sánh tương đối giữa kết quả và kì vọng... Khi không xác định kì vọng thì dù có tập luyện bao nhiêu thì cũng chẳng định nghĩa được quá trình tập luyện đang sai hay đúng.

Trước đó mình cũng khá cự tuyệt với triết lý này với quan điểm rằng, việc làm ra một bản MVP thì vô vàn bất định, đặt mục tiêu rõ ràng sẽ làm mất đi sự sáng suốt trong khi thu thập những thông tin unknown unknown ngoài kia (những thông tin mình thậm chi còn không nhận thức được là mình không biết). Nhưng trong quá trình mình không đặt ra bất cứ một mục tiêu nào, việc learn của mình nó còn tệ hại hơn rất nhiều vì chẳng có bất cứ một kim chỉ nam nào nói cho mình biết insight nào quan trọng. Nội trong một user interview chừng 30 phút đã có thể có ít nhất 10 user insights mình có thể phân tích ra được, chưa kể tới tụi mình interview rất nhiều và còn nhiều hoạt động để lấy insight khác nữa. Hậu quả là mình loay hoay trong những đống vàng và “vàng” lẫn lộn.

Mình sau đó mới nhận ra bài học: Thà cam kết với một mục tiêu trong thời gian ngắn vừa đủ để học thật sâu xung quanh hệ quy chiếu đó, còn hơn cứ đi lắt léo rồi nhận ra mình chỉ đang đi vòng quanh hay thậm chí còn không nhận ra mình đang đi vòng quanh. Nó giống như việc chọn nghề nghiệp, thà kiến trì trải nghiệm một nghề hết sức mình trong vòng một năm còn hơn trải nghiệm đủ mọi nghề trong thời gian đó để rồi không biết mình phù hợp với công việc gì. Khi đặt ra mục tiêu cũng không nên quá cứng đầu về mục tiêu này mà vẫn xem xét lại độ ưu tiên định kì, đề phòng mục tiêu không còn hợp lệ hoặc có vấn đề khác cấp bách hơn cần xử lý.

Trong thời gian làm sản phẩm đầu tiền, mình cùng co-founder

Thomas To

đã rất máu lửa khi đã có ý tưởng để làm sản phẩm về luyện tập lòng biết ơn. May mắn thay trong những buổi thảo luận cùng mentor của mình, anh đã nhắc đi nhắc lại chúng mình phải đặt ra những giả thuyết và xác thực nó liên tục trong quá trình phát triển. Cũng rất khó để chúng mình kiềm chế lại cái tôi đang hừng hực của những founder chưa xây sản phẩm bao giờ, may sao tụi mình vẫn còn đủ tỉnh táo để chuẩn bị được hệ thống phân tích và đặt ra metrics cho sản phẩm (số ngày người dùng luyện tập lòng biết ơn liên tục). Thời gian đầu phát hành là thời gian nhận được những cái tát đau điếng khi theo dõi những con số bất động. Nhưng cũng chính trải nghiệm đó đã giúp phát hiện ra vấn đề trong cách cài đặt thông báo của sản phẩm, tụi mình đã kịp thời xử lý yếu tố cản trở này thông qua việc gửi hướng dẫn cho người dùng từ các kênh thông tin: Email, bài đăng Facebook, onboarding flow (luồng giới thiệu sản phẩm). Từ đó, tụi mình tiếp tục nhận diện thêm nhiều điểm nghẽn khác, điều chỉnh dần và đạt được tỷ lệ quay lại (retention rate) gần 30% chỉ sau 5 tháng đầu tiên (tất nhiên, không chỉ nhưng thay đổi này đủ tạo nên kết quả).

Mục tiêu mà bạn commit (cam kết) có thể là giả thuyết lớn của bạn về vấn đề người dùng, có thể là về giải pháp cho vấn đề đã được xác thực, có thể là một thang đo cụ thể nào đó mà bạn coi là phù hợp với chiến lược sản phẩm. Và mình muốn lưu ý nhỏ về chuyện nên cân bằng giữa lagging và leading, nếu bạn có hứng thú thì có thể tìm hiểu thêm ở bài viết Leading vs. Lagging Indicators. Ở phạm vi bài viết này mình chỉ muốn nhấn mạnh sự quan trọng việc commit, nếu không có nó thì có thể bạn đã bắt đầu lạc ngay từ bước build chứ chưa nói đến measure và learn.

IV. Kết luận

Từ những trải nghiệm thất bại lớn nhỏ, mình nhận thấy một trong những rào cản lớn nhất khi đặt mục tiêu là nỗi sợ phải thừa nhận sai lầm. Có lẽ nó không chỉ là rào cản cho nguyên tắc Commit - Build - Measure - Learn, mà còn làm mọi người sợ “làm thật”, cố gắng núp sau những con số và những quy trình thông dụng. Tuy sự thật đôi khi được mang ra làm ảo ảnh trong một số trường hợp với ý định xấu nhưng việc bản thân tự tìm sự thật cho mình lại là một việc tự làm đau cần thiết cho quá trình sản phẩm. Cũng như việc mình đã trải qua nhiều biến cố nhất định khi xây sản phẩm quá nhanh mới mở ra được những góc nhìn này, để cho chính sản phẩm của mình không phải học lại bài học này thêm lần nào nữa. Và mong các bạn cũng vậy!

---

Hầu hết những kinh nghiệm đúc kết ở trên đến từ quá trình đập đi xây lại, đăng xuất rồi “tái nạm” của MyCabin - ứng dụng giúp bạn nhìn rõ bài học, suy nghĩ của bản thân sau những trải nghiệm đáng nhớ. Trong 2025 vẫn đang miễn phí, nên nếu tò mò thì bạn đăng ký tại đây nhé, nếu có chức năng nào chưa tốt thì tụi mình cũng rất muốn lắng nghe cảm nhận của các bạn thông qua những thông tin liên hệ trong biểu mẫu đăng ký.