Từng bước tạo một MVP: ba cách build và những thứ được cắt bỏ

1. Từ ý tưởng tới MVP, không ngồi sáu tháng dưới tầng hầm

Rob Walling mở đầu bằng một tình huống: bạn là founder một startup, có ý tưởng sản phẩm nhưng không biết bước tiếp theo là gì. Hoặc bước tiếp theo của bạn là ngồi dưới tầng hầm và build trong nhiều tháng, vì đó là việc bạn thấy thoải mái.

Anh mong rằng tới cuối video (đăng ngày 10/03/2024), bạn sẽ hình dung rõ cách đi từ ý tưởng tới một minimum viable product theo cách không bắt bạn ngồi dưới tầng hầm sáu tháng để đoán xem tiếp theo nên build gì. Anh cũng hứa kể về một minimum viable product khá khéo léo, từng được dùng để kiểm chứng (validate) ý tưởng của một công ty mà về sau được bán với giá hơn một tỷ đô la (theo lời anh trong video đăng ngày 10/03/2024).

2. MVP là gì

Câu hỏi đầu tiên của bạn có lẽ là: MVP, minimum viable product, là gì? Định nghĩa của Rob (video đăng ngày 10/03/2024): minimum viable product là thứ tối thiểu bạn cần build để cho khách hàng xem, hoặc để khách hàng dùng, nhằm kiểm chứng giả thuyết (hypothesis) tiếp theo của bạn.

Theo anh (video đăng ngày 10/03/2024), MVP không nhất thiết phải là phần mềm. Và nhiều khi nó cũng không phải là một bản đơn giản hơn, hay bản cuối cùng, của sản phẩm cuối cùng mà bạn nhắm tới.

Mục đích của MVP, theo Rob (video đăng ngày 10/03/2024), là tìm ra hai điều: vấn đề bạn đang cố giải quyết có đáng giải quyết hay không, và cách tiếp cận bạn đang cân nhắc có đi đúng hướng hay không.

3. Không có MVP là đang đoán

Rob nói (video đăng ngày 10/03/2024) rằng nếu không build MVP thì bạn đang đoán rất nhiều. Giả sử bạn đã nói chuyện với khách hàng tiềm năng và họ bảo họ cần giải quyết một vấn đề. Bạn vẫn không biết họ thật sự cần nó tới mức nào, vì người ta sẽ vô tình nói dối bạn, hoặc nói điều gì đó cho bạn thấy dễ chịu.

Còn việc cho người ta xem mock-up, hay hỏi họ "nếu tôi build cái này thì nó có giải quyết vấn đề của anh chị không?", theo anh (video đăng ngày 10/03/2024) chỉ cho ra dữ liệu lộn xộn (messy data).

Thêm nữa, ngay cả khi làm khảo sát (survey) hay phỏng vấn khách hàng, theo Rob (video đăng ngày 10/03/2024) bạn vẫn không bao giờ thật sự biết cho tới khi đặt một thứ gì đó trước mặt khách hàng và xem họ phản ứng ra sao: một thứ thật sự cố giải quyết vấn đề của họ, theo cách tối thiểu mà vẫn dùng được (minimally viable).

4. Khi nào nên build một MVP

Bạn có thể tự hỏi khi nào nên build MVP. Theo Rob (video đăng ngày 10/03/2024), thường là khi bạn đang cố giải quyết một vấn đề mà bạn nghĩ là có tồn tại, nhưng chưa chắc lắm đó có phải là một nỗi đau cấp thiết (desperate pain point) hay không.

Hoặc, theo anh (video đăng ngày 10/03/2024), bạn khá tin đó là một pain point. Hy vọng là bạn có chút dữ liệu để chống lưng cho niềm tin đó: qua các cuộc nói chuyện, hoặc bạn đã tận mắt thấy nó ở một nơi làm việc, hoặc nghe ai đó phàn nàn về nó rồi kiểm chứng lại với những người khác. Nhưng bạn chưa chắc lắm về cách đúng để giải quyết nó.

Ý tưởng đằng sau MVP, theo Rob (video đăng ngày 10/03/2024), là bỏ ra lượng thời gian tối thiểu để tới được điểm mà bạn nhận lại dữ liệu và thông tin từ khách hàng, thứ không chỉ là những cuộc trò chuyện. Tất nhiên nói chuyện với khách hàng là quan trọng, nhưng MVP là bước kiểm chứng tiếp theo.

5. Đã có 10 người chờ thử, anh vẫn build MVP

Rob nói (video đăng ngày 10/03/2024): nếu anh đang build một startup vào thời điểm đó, và anh biết có một desperate pain point, và có 10 người xếp hàng chờ thử sản phẩm của anh, nói đúng hơn là thử giải pháp anh định build, thì anh vẫn sẽ build một MVP. Anh sẽ build minimum viable product để kiểm chứng bước tiếp theo đó.

Lý do anh đưa ra (video đăng ngày 10/03/2024): vấn đề của phần lớn founder startup là chúng ta quá tự tin rằng mình biết cái gì sẽ chạy, biết đó là một vấn đề, biết cách giải quyết nó. Trong khi thực tế, mọi thứ nên được coi là một giả thuyết cho tới khi được chứng minh ngược lại. Và đó là việc MVP có thể giúp bạn làm.

Anh nhắc lại (video đăng ngày 10/03/2024): MVP có thể không cần chút code nào. Và MVP thường không chỉ là một phiên bản đơn giản hoá của giải pháp cuối cùng mà bạn hình dung.

6. Cách 1: human automation

Rob nói về ba cách tiếp cận khác nhau để tạo một MVP (video đăng ngày 10/03/2024). Cách thứ nhất anh gọi là human automation. Một số người gọi nó là cách tiếp cận Wizard of Oz, theo câu trong phim Wizard of Oz: "pay no attention to the man behind the curtain" (đừng để ý tới người đứng sau tấm màn).

Về bản chất, theo Rob (video đăng ngày 10/03/2024), đây là khi bạn có một dịch vụ trông như được tự động hoá, có thể trông như phần mềm, nhưng thật ra bạn nhận một input rồi có người ở phía backend làm việc. Có con người đang cắt video, hoặc phân loại và lập danh mục (catalog) các thứ, rồi trả kết quả về.

Ví dụ anh đưa ra (video đăng ngày 10/03/2024): giả sử anh muốn bán sales lead cho các freelance web developer, và định đi crawl, scrape internet để lấy các lead này giao cho freelancer. Anh có thể build một scraping engine khổng lồ và tốn rất nhiều thời gian cho nó. Hoặc anh có thể dùng đúng nghĩa đen là con người, có thể là vài trợ lý ảo (virtual assistant) ở Philippines hoặc một nơi nào đó chi phí tương đối thấp, để họ tự tay lùng trên internet rồi gom các lead vào một Google Sheet hay một file CSV.

Cách đó có scale được không? Có sinh lời không? Rob trả lời (video đăng ngày 10/03/2024): không, rất có thể là không. Nhưng việc bạn đang làm là kiểm chứng giả thuyết. Có ai trả tiền cho thứ này không? Người ta có tiếp tục duy trì subscription không? Nó có giải quyết một desperate pain point không? Tất cả mà không phải ngồi sáu tháng dưới tầng hầm build một scraper.

7. Cách 2: no-code, ví dụ tool quản lý dự án audio và video

Đó là human automation. Cách tiếp cận thứ hai để build MVP, theo Rob (video đăng ngày 10/03/2024), là dùng no-code.

Ví dụ anh nghĩ tới, khi dùng no-code thay vì build hẳn một sản phẩm phần mềm đầy đủ (video đăng ngày 10/03/2024): một tool quản lý dự án cho audio và video, thứ bạn có thể dùng để sản xuất một podcast hay sản xuất video YouTube. Đây không phải chuyện edit hay catalog chính các video hoặc file audio. Đây là một tool quản lý dự án để bạn cộng tác với một editor.

Theo mô tả của Rob (video đăng ngày 10/03/2024), tool này có rất nhiều thao tác create, read, update, delete, trỏ tới một số file trong Dropbox. Editor làm xong phần của mình, đặt trạng thái thành publish, rồi một người khác đưa nó lên WordPress và publish, hoặc đưa lên YouTube. Vậy nên nó chỉ là rất nhiều flag được bật tắt, và rất nhiều email notification gửi đi để báo cho mọi người biết bước tiếp theo trong workflow.

8. Ngày nay việc đó build được bằng no-code

Rob nói (video đăng ngày 10/03/2024): năm hay mười năm trước thời điểm đó, nếu anh bảo bạn đi build cái tool ấy, kể cả chỉ build một MVP, có lẽ bạn sẽ mở text editor lên và bắt đầu viết Python hoặc viết Rails. Nhưng theo anh, ngày nay (tính đến video đăng ngày 10/03/2024), với một thứ là workflow create, read, update, delete khá đơn giản cộng với notification như vậy, bạn có thể build bằng no-code.

Anh biết điều đó vì anh và nhóm đã làm vậy (theo lời anh trong video đăng ngày 10/03/2024). Producer của anh đã build cả một hệ thống sản xuất podcast lẫn một hệ thống sản xuất video YouTube, tất cả trên nền Airtable. Người đó không phải developer, nhưng đã build một hệ thống khá vững, được anh và nhóm dùng để sản xuất hàng trăm tập podcast của anh và hàng trăm video YouTube.

Ý ở đây, theo Rob (video đăng ngày 10/03/2024): tuỳ vào MVP bạn cần build, có lúc human automation là cách tốt nhất, có lúc no-code là cách tốt nhất.

9. Các nền tảng no-code lớn

Nếu bạn chọn hướng no-code, Rob nói (video đăng ngày 10/03/2024) rằng có hàng trăm tool no-code, nhưng những nền tảng chính mà đa số mọi người dùng, những tay chơi lớn trong mảng này, là Bubble, Airtable, Zapier và Make.

Theo anh (video đăng ngày 10/03/2024), bạn sẽ thấy mình có thể build những tool khá vững trong các app no-code này, nhất là các tool kiểu quản lý dự án.

10. Cách 3: full code, và khi bạn không phải developer

Cách tiếp cận thứ ba để build MVP, theo Rob (video đăng ngày 10/03/2024), dĩ nhiên là full code. Nếu bạn là developer, muốn bỏ vài tháng build một thứ gì đó, và đó là cách tối thiểu khả thi để làm, thì có thể bạn phải xắn tay áo lên và viết code.

Còn nếu bạn không phải developer, Rob nói thật (video đăng ngày 10/03/2024): cơ hội đang nghiêng về phía chống lại bạn. Tìm một co-founder là developer có lẽ là con đường mà cá nhân anh sẽ theo. Nếu cuối cùng bạn muốn build một SaaS startup thì đúng vậy, có lẽ bạn sẽ muốn có một co-founder.

Thuê một developer hay một agency, theo anh (video đăng ngày 10/03/2024), cũng có thể thành công. Nhưng thực tế, điều anh hay thấy là nếu bạn không phải developer, bạn không biết cách đánh giá một developer hay một agency. Nên bạn tin họ khi họ nói họ build được phần mềm tốt. Mà đa số người ta không build ra sản phẩm tốt.

Thế là sau sáu tháng hay 12 tháng, theo Rob (video đăng ngày 10/03/2024), bạn có cả đống technical debt, phải làm lại từ đầu, viết lại từ con số không. Anh nói anh đã thấy nhiều founder không có nền tảng kỹ thuật phải trải qua chuyện này. Anh không nói là đừng làm, anh chỉ nói cơ hội đang chống lại bạn.

11. Làm sao biết MVP đã sẵn sàng

Khi build một MVP, làm sao biết nó đã sẵn sàng? Theo Rob (video đăng ngày 10/03/2024), thường là khi bạn tin rằng nó giải quyết được pain point tối thiểu mà ai đó có thể sẵn lòng trả tiền, hoặc ít nhất có thể sẵn lòng tương tác (engage) với bạn quanh nó. Có thể họ chưa sẵn lòng trả tiền, nhưng như anh nói, đó là mắt xích đầu tiên của sợi xích.

Bạn phải nghĩ xem, theo Rob (video đăng ngày 10/03/2024): thiếu cái gì thì bạn không thể ship? Tính năng cốt lõi, hay những tính năng cốt lõi, mà bạn cần là gì?

12. Những thứ MVP không cần

Có rất nhiều tính năng bạn không cần trong một MVP, kể cả khi bạn đang build phần mềm (theo Rob, video đăng ngày 10/03/2024). Danh sách anh kể:

• Billing: theo Rob (video đăng ngày 10/03/2024), bạn không cần nó, bạn có thể chạy billing thủ công. Đúng nghĩa đen là để người ta chuyển tiền cho bạn qua Venmo, đăng ký một subscription PayPal, gửi bạn một tấm séc, hoặc gửi họ một Stripe payments link. Bạn không cần viết code billing để có một minimum viable product.
• Refund: theo Rob (video đăng ngày 10/03/2024), bạn không cần có khả năng làm refund (hoàn tiền).
• Password reset: theo Rob (video đăng ngày 10/03/2024), bạn không cần.
• Nút delete: theo Rob (video đăng ngày 10/03/2024), nhiều khi bạn không cần nút delete ở đâu cả, bạn có thể tự tay vào xoá.

Theo anh (video đăng ngày 10/03/2024), có rất nhiều chỗ bạn có thể đi tắt trong một MVP mà vẫn có một sản phẩm khả thi (viable).

13. Viết scope ra giấy và giữ nó nhỏ

Rob nói (video đăng ngày 10/03/2024): dù build MVP theo cách nào ở thời điểm đó, human automation, no-code hay viết code, anh cũng sẽ muốn viết scope của MVP ra thành văn bản.

Anh cũng sẽ muốn nói chuyện với khách hàng để kiểm chứng rằng thứ này sẽ giải quyết một vấn đề mà họ nghĩ là đáng giải quyết, theo một cách mà bạn nghĩ họ có thể muốn trả tiền. Sau đó lên scope, cố giữ nó nhỏ, rồi build ra (theo Rob, video đăng ngày 10/03/2024).

14. Build MVP mất bao lâu

Có người hỏi build một MVP nên mất bao lâu. Câu trả lời của Rob (video đăng ngày 10/03/2024): dĩ nhiên là tuỳ. Có người đưa được MVP ra trong một cuối tuần. Anh nhắc tới những ví dụ hay mà bạn từng nghe, kiểu tung ra một AI wrapper nhanh trong một cuối tuần để chat với các file PDF của bạn. Theo anh, đó có lẽ là một MVP.

Những lúc khác, theo Rob (video đăng ngày 10/03/2024), bạn có thể mất vài tháng làm buổi tối và cuối tuần để chắp vá ra một thứ gì đó.

Anh nghĩ (video đăng ngày 10/03/2024) rằng nếu bạn bỏ ra hơn, anh nói là không chắc, hai hay ba tháng để dựng một MVP, thì còn tuỳ bạn đang làm buổi tối và cuối tuần hay làm full-time. Nhưng một khi đã lên tới hàng trăm giờ để build một cái, thì hoặc bạn đang giải một vấn đề quá phức tạp, hoặc bạn đang build MVP quá tay (overbuilding).

15. Zappos: một MVP khéo léo

MVP mà Rob thấy thật sự khéo léo là Zappos (theo lời kể trong video đăng ngày 10/03/2024). Founder của Zappos muốn kiểm chứng thị trường bán giày online. Nên ban đầu người này tới các cửa hàng giày địa phương, chụp ảnh hàng tồn kho của họ rồi đăng lên mạng. Khi có khách mua một đôi, anh ta mua đôi giày đó ở cửa hàng với giá đầy đủ rồi tự gửi thẳng cho khách.

Theo Rob (video đăng ngày 10/03/2024), cách này đã kiểm chứng được mô hình kinh doanh và sự quan tâm của người tiêu dùng mà không cần một khoản đầu tư lớn từ trước vào hàng tồn kho hay một hệ thống e-commerce phức tạp. Anh gọi đó là cách tiếp cận kết hợp no-code và human automation để kiểm chứng Zappos, một công ty mà sau đó được bán cho Amazon với giá 1,2 tỷ đô la (theo lời kể trong video đăng ngày 10/03/2024).

Rob cảm ơn mọi người đã xem.