Cách đúng để build MVP cho một app

1. MVP là gì, và có cách đúng lẫn cách sai để xây nó

Forrest Knight mở đầu bằng một nhận xét nói thẳng với người xem là lập trình viên: nhiều khả năng bạn đã từng có những ý tưởng sản phẩm hay ý tưởng kinh doanh mà bạn rất muốn build. Một SaaS, một platform, thứ gì cũng được.

Theo Forrest (video đăng ngày 20/12/2022), nếu bạn đã làm trong ngành một thời gian, bạn hiểu rằng cách tốt nhất để bắt đầu xây một sản phẩm là build trước một MVP, tức minimum viable product. Theo định nghĩa anh đọc lên, MVP là phiên bản của sản phẩm có vừa đủ tính năng để người dùng sử dụng, nhằm kiểm chứng một ý tưởng sản phẩm mà không phải đầu tư nhiều thời gian và nguồn lực ngay từ đầu.

Rồi anh đặt câu hỏi: nếu anh nói với bạn rằng có một cách đúng và một cách sai để build MVP thì sao? Anh nói đó là điều video hôm nay bàn tới, kèm theo một số ví dụ thực tế nổi tiếng. Anh muốn nói về cách thật sự nên build một MVP, chứ không phải cách hiểu lệch (misconstrued understanding) mà theo anh, tính đến lúc video đăng ngày 20/12/2022, nhiều người đang có về nó.

2. Ý tưởng MVP vốn đúng, nhưng bị biến thành cái cớ để làm ẩu

Vậy MVP có vấn đề gì? Theo Forrest (video đăng ngày 20/12/2022), ý tưởng tổng thể của MVP thì hợp lý. Được ship một sản phẩm đã lược bớt (stripped-down), thử với khách hàng thật, và đo mức thành công của nó trên thị trường mà không phải build một ứng dụng đầy đủ: anh gọi đó là giấc mơ của developer.

Theo lời kể của Forrest trong video đăng ngày 20/12/2022, vào đầu những năm 2000, ý tưởng MVP này được đón nhận rộng rãi. Những người áp dụng nó sớm bắt đầu gặt hái lợi ích: tiết kiệm thời gian và tiền bạc, và nhận được feedback của người dùng một cách nhanh chóng.

Nhưng theo anh (video đăng ngày 20/12/2022), theo thời gian, một vấn đề xuất hiện. Thay vì dùng MVP vì những lý do vừa kể, các product manager, developer và designer lại dùng MVP làm cái cớ để lười. Họ đi đường tắt (cut corners), bỏ đi những tính năng cần thiết, và hy sinh trải nghiệm người dùng nhân danh việc giữ cho gọn nhẹ (lean) và ship.

Theo Forrest (video đăng ngày 20/12/2022), điều đó bắt nguồn từ một hiểu lầm phổ biến: cho rằng MVP là chuyện ship một sản phẩm nhanh và rẻ hết mức có thể. Rồi người ta gặp những câu hỏi kiểu: thế còn tính năng này, tính năng kia thì sao? Bỏ. Thiết kế trải nghiệm người dùng (user experience design) thì sao? Không, không có thời gian cho cái đó. Chạy được tàm tạm là được. Còn code thì sao? Cứ nối tạm một mớ spaghetti code, refactor sau cũng được.

Theo Forrest (video đăng ngày 20/12/2022), đây chính xác là cách các sản phẩm thất bại.

3. Cách đúng: giữ chất lượng, chỉ giới hạn scope

Anh nói rõ (video đăng ngày 20/12/2022): anh thật sự tin rằng sự hoàn hảo không nên trở thành kẻ thù của tiến bộ (perfection shouldn't be the enemy of progress). Dù vậy, nếu làm theo kiểu trên, bạn sẽ ở thế bất lợi so với việc làm đúng cách.

Theo Forrest (video đăng ngày 20/12/2022), những MVP hiệu quả vẫn giữ chất lượng cao: chất lượng code, chất lượng thiết kế, chất lượng trải nghiệm người dùng, chất lượng nội dung. Chúng đơn giản là giới hạn scope.

Anh đặt hai cách tiếp cận cạnh nhau để thấy sự khác biệt (video đăng ngày 20/12/2022). Cách sai giống như cứ chắp vá một thứ gì đó cho xong rồi cầu mong mọi chuyện ổn. Cách đúng để build MVP là build một phiên bản sản phẩm có scope giới hạn, giải quyết ít nhất một vấn đề cho một nhóm người dùng (audience) theo một cách độc đáo.

4. MVP là một thí nghiệm: bốn đặc điểm cần thỏa

Theo Forrest (video đăng ngày 20/12/2022), nếu sản phẩm không giải quyết được ít nhất một vấn đề cho một nhóm người theo cách độc đáo, thì chẳng có lý do gì để ai quan tâm tới nó cả. Anh nói mục đích của MVP là tiến hành một thí nghiệm. Về cơ bản, bạn đang làm usability testing để xem giả thuyết (hypothesis) của mình có chính xác không.

Và để kiểm tra độ chính xác ấy, theo anh (video đăng ngày 20/12/2022), có một vài tham số, hay đặc điểm then chốt, mà MVP của bạn cần thỏa mãn. Bạn muốn xem MVP:

• có phục vụ ít nhất một nhóm người dùng cụ thể, có mục tiêu rõ ràng hay không (theo video đăng ngày 20/12/2022);
• có giải quyết ít nhất một vấn đề then chốt, hay một pain point, của nhóm người đó hay không (theo video đăng ngày 20/12/2022);
• có một trải nghiệm người dùng riêng biệt, được thiết kế tốt, hoạt động được, dễ dùng và dễ chịu (functional, usable, and comfortable) hay không (theo video đăng ngày 20/12/2022);
• và có thể được build và launch nhanh hay không (theo video đăng ngày 20/12/2022).

Theo Forrest (video đăng ngày 20/12/2022), có một lý do cụ thể cho bốn đặc điểm này: kể cả khi một trong bốn đặc điểm then chốt bị lệch, hoặc thiếu hẳn, thì kết quả thử nghiệm của bạn sẽ bị sai lệch. Kết quả đó sẽ dẫn tới những quyết định thiên lệch và có thể dẫn tới thất bại của sản phẩm, vì người dùng không thật sự nhận được thứ bạn muốn mang tới cho họ.

5. Giữ tính năng nào, bỏ tính năng nào

Nói tất cả những điều trên rồi, khi thực sự bắt tay vào build MVP, làm sao biết nên đưa tính năng nào vào và để tính năng nào ra ngoài? Theo Forrest (video đăng ngày 20/12/2022), đôi khi chuyện này không rạch ròi như ta tưởng. Để quyết định, bạn phải trả lời vài câu hỏi:

• Audience của bạn là ai? (theo video đăng ngày 20/12/2022)
• Pain point của họ là gì? (theo video đăng ngày 20/12/2022)
• Trong những pain point đó, cái nào dễ giúp nhất mà lại tạo tác động lớn nhất? (theo video đăng ngày 20/12/2022)
• Và họ có đủ khả năng chi trả cho giải pháp của vấn đề đó không? (theo video đăng ngày 20/12/2022)

6. Khi tính năng mới nảy ra giữa chừng: hỏi lại trước khi ship

Theo Forrest (video đăng ngày 20/12/2022), khi đang ở trong quá trình phát triển, các tính năng và ý tưởng mới chắc chắn sẽ nảy ra, kiểu: ồ, cái này có thể giúp ích lắm, cái kia cũng có thể giúp ích lắm. Nhưng trước khi ship, bạn cần tự hỏi: mình có thể ship mà không có những tính năng này không? Scope giới hạn của bạn có bị phình ra trong quá trình đó không? Vì vậy, anh khuyên hãy chắc chắn rằng bạn hỏi lại câu hỏi đó.

Anh nhắc (video đăng ngày 20/12/2022): bạn hỏi câu này từ góc nhìn của người dùng, không phải từ góc nhìn của developer, của designer hay của product manager. Câu hỏi là: nếu launch mà không có tính năng này, mình có còn giải quyết được vấn đề chính không?

7. Tính năng không scale cũng được: làm thủ công trước, tự động hóa sau

Theo Forrest (video đăng ngày 20/12/2022), chính câu hỏi này, và cả quá trình phát triển, có thể cho thấy bạn đang đi ngược với những thứ bạn nghĩ là giúp tiết kiệm thời gian, nhưng thực ra không giúp. Ít nhất là chưa.

Anh lấy ví dụ tự động hóa (video đăng ngày 20/12/2022): tự động hóa giúp quy trình gọn hơn và tiết kiệm thời gian, đúng không? Anh nói: đúng, về lâu dài. Nhưng để build được phần tự động hóa đó thì tốn rất nhiều thời gian và nguồn lực, để rồi mới tiết kiệm được thời gian về sau. Nên nếu bạn đang có timeline chặt, có lẽ nên tạm gác phần tự động hóa lại.

Theo Forrest (video đăng ngày 20/12/2022), đưa những tính năng không scale (features that don't scale) vào MVP là chuyện ổn. Anh biết điều này nghe có vẻ ngược đời, nhưng làm thủ công lúc đầu vẫn mang lại giá trị mà bạn muốn cung cấp, mà không tốn thêm thời gian và nguồn lực phát triển.

Anh lấy ví dụ (video đăng ngày 20/12/2022): thay vì tự động hóa quy trình hiển thị một câu hỏi mới mỗi ngày, hay gửi câu hỏi đó qua email cho ai đó, anh có thể làm việc đó bằng tay vào một giờ cố định. Với người dùng, mọi thứ vẫn có vẻ như tự động, nhưng thực ra không phải. Nếu ý tưởng chạy được, lúc đó bạn mới tự động hóa.

8. Twitter: một dự án nội bộ đăng trạng thái qua SMS

Nói về giả định thế là đủ, anh chuyển sang câu hỏi: chuyện này vận hành thế nào trong thế giới thật? Một trong những ví dụ anh thích là về một công ty mà, theo lời anh trong video đăng ngày 20/12/2022, năm 2022 vừa được bán với giá 44 tỷ đô la. Anh nói: đúng rồi, bạn đoán ra rồi đấy, Twitter.

Theo lời kể trong video đăng ngày 20/12/2022, Twitter khởi đầu là một dự án nội bộ của nhân viên Odeo (anh còn chêm vào: "nếu phát âm như vậy là đúng"). Nó có một chức năng cốt lõi: đăng cập nhật trạng thái (status update) qua SMS. Nó không có tất cả các tính năng mà bạn biết tính đến lúc video đăng. Anh nói, trời ạ, nó còn chẳng có cả giao diện web.

Theo lời kể của Forrest (video đăng ngày 20/12/2022), vì thấy chính mình dùng nó thường xuyên đến thế, họ nghĩ có lẽ người khác cũng sẽ thích. Thế là họ launch Twitter cho một thị trường lớn hơn, rồi về sau tạo ra giao diện web thay cho SMS, và phát triển Twitter thành thứ mà mọi người biết tới tính đến lúc video đăng.

9. Uber: UberCab và một dịch vụ

Uber là một ví dụ khác. Theo lời kể trong video đăng ngày 20/12/2022, Uber có một đợt beta launch vào năm 2010 cho app iPhone, nhưng app đó không làm những gì Uber làm tính đến lúc video đăng, nhất là vào năm 2010.

Anh giải thích (video đăng ngày 20/12/2022): ý anh là, bạn định thuyết phục một đám người lạ đăng ký vào app để lái xe của họ đi khắp nơi, đón những người lạ khác, và mong những người lạ đó vui vẻ bước lên xe của một người mà với họ cũng là người lạ? Anh nói: ừ, chuyện đó sẽ không xảy ra ngay từ đầu.

Theo lời kể trong video đăng ngày 20/12/2022, ứng dụng khi ấy mang tên UberCab, cung cấp một dịch vụ: kết nối người dùng với tài xế taxi, kiếm tiền qua in-app purchase, trong một giao diện cực kỳ đơn giản. Nó kiểm chứng ý tưởng rằng mọi người cần tiếp cận chuyến xe dễ dàng hơn, và từ đó họ build thành Uber mà bạn biết tính đến lúc video đăng.

10. Điểm chung của các MVP thành công

Theo Forrest (video đăng ngày 20/12/2022), anh có thể nói mãi về những ví dụ như vậy, như Shopify, Dropbox, Zappos và Buffer. Mỗi công ty có hành trình riêng để trở thành như tính đến lúc video đăng, nhưng tất cả có một điểm chung: họ đã build một MVP để chứng minh ý tưởng của mình chạy được.

Theo anh (video đăng ngày 20/12/2022), bạn có thể mang những bài học này vào việc build MVP của riêng mình. Hãy nhớ rằng MVP không nằm ở chuyện build một sản phẩm gây tiếng vang lớn ngay từ đầu, mà nằm nhiều hơn ở chuyện làm một việc thật, thật tốt.

Anh nói rằng luôn còn nhiều điều để học, nhưng anh hy vọng những thông tin anh chia sẻ trong video có thể giúp bạn trên hành trình làm sản phẩm. Lời cuối của anh (video đăng ngày 20/12/2022): giờ thì lên đường, hãy build một MVP cho ý tưởng vẫn luẩn quẩn trong đầu bạn, theo đúng cách.