Đừng bắt đầu SaaS bằng MVP: hãy build một MVO

1. Bước bị bỏ qua trước khi build MVP

Người dẫn video mở đầu bằng hai câu hỏi: bạn có giống phần lớn các founder không, và bạn có sắp phí nhiều tháng trời để build một MVP không? Theo người dẫn video (video đăng ngày 14/10/2025), phần lớn founder làm theo playbook của lean startup một cách hoàn hảo: build thật tối giản, launch thật nhanh, lấy feedback, rồi iterate. Nhưng anh cho rằng có một bước then chốt nằm trước việc build bất cứ thứ gì, và việc bỏ qua bước đó là lý do khiến 90% MVP thất bại (con số anh đưa ra trong video đăng ngày 14/10/2025).

Anh tự giới thiệu là Victor; dòng chữ trên màn hình ghi anh là người sáng lập (founder) của SaaS Mastery (theo video đăng ngày 14/10/2025). Anh nói rằng sau khi đã dẫn dắt hơn 300 founder, anh thấy cùng một khuôn mẫu lặp đi lặp lại. Trong video này, anh nói sẽ chỉ rõ vì sao cách tiếp cận MVP đã hỏng, những sai lầm tốn kém mà nó buộc bạn mắc phải, và những founder thành công làm gì thay vào đó.

Theo Victor (video đăng ngày 14/10/2025), nếu bạn sắp build một MVP, những gì anh nói có thể thay đổi hoàn toàn cách bạn tiếp cận.

2. Vì sao người ta vẫn build MVP, và vì sao cách cũ hết hiệu quả

Victor đặt câu hỏi thay cho người xem: nếu build MVP không đáng, tại sao người ta vẫn build? Câu trả lời của anh (video đăng ngày 14/10/2025): vì bản thân ý tưởng nghe rất thông minh. Đầu tiên bạn build một phiên bản cơ bản của sản phẩm. Bạn đưa nó vào tay người dùng, phần lớn là khách hàng thật, càng nhanh càng tốt. Bạn lấy feedback của họ, bạn iterate, và bạn tìm ra product-market fit.

Nghe thì hay, phải không? Victor gọi đó là một giấc mơ người ta đang bán cho bạn. Nhưng rồi bạn nhận ra rằng đó thực ra là cách cũ (theo Victor, video đăng ngày 14/10/2025).

Trớ trêu là, theo anh, cách này từng hiệu quả vào thời việc làm ra một MVP còn khó, và vì khó nên khách hàng cũng không có nhiều lựa chọn. Thời đó, người build MVP thường là founder kỹ thuật, những founder là developer, làm thêm ngoài giờ (moonlighting), và thời gian của chính họ không tốn kém bao nhiêu (theo lời kể trong video đăng ngày 14/10/2025).

Victor kể anh đã ở trong những cộng đồng như MicroConf và SaaS Academy hơn một thập kỷ, theo dõi thành công của những người này và làm việc với nhiều người trong số đó (theo video đăng ngày 14/10/2025). Nhưng cách đó đã không còn hiệu quả. Thị trường đã thay đổi: có nhiều người làm việc này hơn rất nhiều, và có nhiều lựa chọn hơn hẳn.

Theo Victor (video đăng ngày 14/10/2025), đó chỉ là một trong các lý do. Nhưng điều đó không có nghĩa là hết cơ hội. Anh nói SaaS vẫn còn rất nhiều cơ hội, bạn chỉ cần hiểu cách tiếp cận chúng. Và để hiểu vì sao không nên build MVP ngay, anh nói bạn cần biết bốn lý do chính.

3. Lý do 1: hầu hết MVP thất bại

Lý do thứ nhất, theo Victor (video đăng ngày 14/10/2025): hầu hết MVP thất bại, ít nhất là MVP đầu tiên. Lý do là phần lớn founder nghĩ: "mình sẽ launch MVP rồi nhanh chóng đạt product-market fit". Người ta đánh giá thấp chuyện đó.

Victor nói rằng sau khi làm việc với hàng trăm founder, thực tế anh thấy là product-market fit cần rất nhiều vòng iteration. Và chi phí iteration trên một phần mềm hoàn chỉnh (full-blown software), dù đó chỉ là một MVP, vẫn cao (theo Victor, video đăng ngày 14/10/2025).

Ở giai đoạn này, doanh thu từ subscription thường không đủ trang trải chi phí. Victor nói có người gọi giai đoạn này là "slow, long SaaS ramp of death", con dốc dài và chậm chết người của SaaS. Theo anh, đó là lý do thứ nhất khiến hầu hết MVP thất bại hoặc mất nhiều thời gian để thành công hơn người ta tưởng (video đăng ngày 14/10/2025).

4. Lý do 2 và 3: phần mềm rất đắt, và chưa có bằng chứng

Lý do thứ hai, theo Victor (video đăng ngày 14/10/2025): build phần mềm cực kỳ tốn kém. Thuê developer giỏi tốn cả một gia tài. Nên nếu bản thân bạn không phải developer, bạn có thể dễ dàng tiêu nhiều chục nghìn đô la chỉ để đưa ra được một phiên bản làm dở dang (half-baked).

Lý do thứ ba, theo Victor (video đăng ngày 14/10/2025): bạn làm tất cả những việc đó mà không có bằng chứng thật nào cho thấy khách hàng muốn thứ bạn đang build. Về cơ bản, bạn đang đặt một canh bạc lớn và đắt đỏ, trong khi có một việc đơn giản hơn rất nhiều mà bạn có thể làm.

5. Còn Zoom, Slack thì sao? Airbnb và Atlassian

Victor nói người xem có thể tự hỏi: "Victor, thế còn Zoom? Thế còn Slack? Họ cứ build một thứ, tung ra, và thành công ngay." Anh trả lời (video đăng ngày 14/10/2025): lý do là những công ty này có kiến thức sâu từ bên trong ngành và những lần thử nghiệm trước đó để dựa vào. Đó là những người đã ở sẵn trong một ngành, hoặc hiểu sâu nỗi đau mà chính họ đã trải qua. Theo anh, Zoom và Slack đều như vậy, và anh nói sẽ đi sâu hơn vào chuyện này ngay sau đó.

Còn những người build MVP mà không có hiểu biết từ trước thì, theo Victor (video đăng ngày 14/10/2025), có một con đường rất dài và gian nan phía trước.

Anh lấy Airbnb làm ví dụ (theo lời kể trong video đăng ngày 14/10/2025). Các nhà sáng lập Airbnb là designer, về lý thuyết là chuyên gia phần mềm, chuyên gia sản phẩm, nhưng họ không phải người trong ngành khách sạn. Vì thế ý tưởng cung cấp đệm cho người lạ của các nhà sáng lập cấp tiến tới mức suốt bốn năm, họ chật vật, pivot, và suýt phá sản nhiều lần trước khi sự kiên trì cuối cùng được đền đáp.

Ví dụ thứ hai là Atlassian, công ty đứng sau Jira (theo lời kể trong video đăng ngày 14/10/2025). Các nhà sáng lập không phải chuyên gia quản lý dự án. Họ chỉ đang tìm những khoảng trống trên thị trường. Phải mất nhiều năm iteration đau đớn họ mới tìm được nhịp của mình, và cuối cùng dẫn tới IPO hơn một thập kỷ sau khi bắt đầu.

Từ đó Victor hỏi: vậy thay vì build MVP thì nên làm gì? Anh dùng ví dụ Slack để trả lời (video đăng ngày 14/10/2025).

6. Câu chuyện Slack và khái niệm minimum viable offer

Theo lời kể của Victor (video đăng ngày 14/10/2025), Slack hoàn toàn không khởi đầu như một ý tưởng tỷ đô. Nó khởi đầu là một prototype nội bộ. Một nhóm developer đang build một trò chơi điện tử tên là Glitch, và họ bực bội với email. Vì thế họ tự build một công cụ chat nội bộ để liên lạc với nhau tốt hơn qua nhiều múi giờ. Công cụ đó là phiên bản đầu tiên của Slack.

Nhưng rồi trò chơi thất bại, và công ty sắp đóng cửa (theo lời kể trong video đăng ngày 14/10/2025). Nhóm nhận ra một điều: dù sản phẩm chính thất bại, prototype nội bộ của họ, công cụ chat nhỏ này, lại cực kỳ có giá trị. Và nó đã được chứng minh là chạy tốt. Vì vậy họ đi gặp bạn bè ở các công ty công nghệ khác, cho xem công cụ nội bộ đó, và đưa ra một lời đề nghị.

Lời đề nghị đó, theo Victor kể lại (video đăng ngày 14/10/2025): "Này, bọn mình build cái này cho chính mình, và nó đã thay đổi cách bọn mình làm việc. Các bạn có dùng không?" Câu trả lời là có.

Victor gọi đó là minimum viable offer, viết tắt MVO (chữ trên màn hình ghi "MVO, Minimum Viable Offer"). Theo anh (video đăng ngày 14/10/2025), MVO là việc thử nghiệm một lời hứa trước khi bạn build sản phẩm đầy đủ.

7. MVO kèm prototype, và những lợi ích của nó

Theo Victor (video đăng ngày 14/10/2025), xưa nay một MVO có thể chỉ là một landing page hoặc một video. Nhưng theo kinh nghiệm làm việc với các founder, anh thấy có một cách còn tốt hơn: làm một minimum viable offer kèm theo một prototype. Nhờ tất cả những công cụ AI mới, việc build một prototype trông và cảm giác như thật không còn là rào cản lớn nữa, kể cả với founder không biết kỹ thuật. Anh nói chính sự kết hợp này mới thật sự giảm rủi ro (de-risk) cho cả quá trình.

Theo Victor (video đăng ngày 14/10/2025), cách tiếp cận này mạnh một cách đáng kinh ngạc, vì mấy lý do.

Thứ nhất, theo Victor (video đăng ngày 14/10/2025), nó rẻ hơn rất nhiều và ít tốn thời gian hơn một MVP. Bạn vẫn có thể thuê một designer hoặc một developer giúp làm prototype, để không phải tự làm hay tự học hết các công cụ, nhưng bạn tránh được những khoản chi phí khổng lồ làm cạn tài khoản: viết code riêng, dựng server, và nhiều tháng phát triển phức tạp.

Thứ hai, theo Victor (video đăng ngày 14/10/2025), bạn nhận được đúng loại feedback ngay từ sớm. Đó là feedback trên một prototype đơn giản thể hiện ý tưởng cốt lõi của bạn. Điều này giúp bạn xác nhận rằng người ta thật sự muốn giải pháp của bạn, trước khi bạn phí thời gian và tiền bạc build những feature không ai yêu cầu. Anh nói feedback trên một sản phẩm người ta có thể cầm trên tay sâu hơn nhiều so với feedback trên một landing page hay thậm chí một video demo.

Thứ ba, theo Victor (video đăng ngày 14/10/2025), cách này thực sự hoàn hảo cho founder không biết kỹ thuật. Bạn có thể dùng các công cụ no-code (màn hình ghi "NO CODE TOOLS"), hoặc thậm chí vận hành một dịch vụ thủ công để làm prototype, nhờ đó thử nghiệm mô hình kinh doanh trước khi đầu tư nặng vào một đội kỹ thuật.

Thứ tư, theo Victor (video đăng ngày 14/10/2025), vì bạn chưa build nhiều, bạn có thể đổi hướng rất dễ dựa trên những gì hiệu quả. Nếu lời đề nghị chưa tốt, bạn có thể điều chỉnh nó, định vị lại (reposition), hoặc thử một thị trường khác trước khi build thêm feature. Anh nói việc này rất khó khi bạn đã có một MVP lớn. Anh chen thêm: "minimal" mà lại "lớn", anh biết, nhưng so với một prototype thì MVP rốt cuộc vẫn thành ra như vậy.

Và cuối cùng, theo Victor (video đăng ngày 14/10/2025), nó cho bạn rõ ràng hơn về việc cần làm. Một MVP hỏi: "Bạn có dùng sản phẩm này day-to-day không?" Còn một MVO kèm prototype hỏi: "Bạn có muốn sản phẩm này không?" Anh nói điều này chuyển trọng tâm từ một sản phẩm sang một "promise transformation".

8. Cái bẫy: phần mềm có giá trị với bạn chưa chắc có giá trị với người khác

Trước khi nói quy trình nên trông thế nào, Victor dặn (video đăng ngày 14/10/2025): đừng rơi vào cái bẫy nghĩ rằng nếu phần mềm có giá trị với bạn và tăng năng suất của bạn, thì nó cũng sẽ như vậy với mọi người.

Theo anh (video đăng ngày 14/10/2025), đôi khi điều đó phụ thuộc vào cách các doanh nghiệp khác được tổ chức, cách họ tăng trưởng, họ có những nguồn lực nào và thiếu những nguồn lực nào, và ban lãnh đạo của họ có hiểu biết và tầm nhìn về công nghệ hay không. Đôi khi chi phí chuyển đổi (switching costs) và việc quản lý thay đổi (change management) có thể khiến việc bán phần mềm của bạn trở nên rất khó. Anh nói anh đã chứng kiến đủ cả.

Theo Victor (video đăng ngày 14/10/2025), đó là chỗ một prototype thực sự có giá trị: kể cả khi bạn biết một thứ chạy tốt với bạn, bạn có thể thử xem nó có chạy tốt với người khác không trước khi bỏ ra những khoản tiền lớn.

9. Roadmap: prototype, MVO, rồi mới đến MVP

Vậy roadmap của bạn bây giờ nên trông thế nào? Làm sao đi từ ý tưởng tới khách hàng trả tiền mà không quá nhiều đau đớn? Victor đưa ra ba bước (video đăng ngày 14/10/2025).

Bước một, theo Victor (video đăng ngày 14/10/2025): quên MVP đi và build prototype. Đây là lúc bạn biến ý tưởng thành một thứ bạn có thể dùng nội bộ, hoặc đem cho người khác xem, để nó chạy được. Nó có thể được build trên Lovable, hoặc thậm chí là một dịch vụ thủ công, nơi bạn tự mình làm ra kết quả ở phía sau. Anh nói mục tiêu chính ở đây là cho thấy (show), không chỉ kể (tell), vì điều này cho phép người dùng thử nhanh hơn, nghĩa là feedback nhanh hơn và iteration nhanh hơn.

Victor kể đó cũng là cách anh bắt đầu công ty trước của mình (theo lời kể trong video đăng ngày 14/10/2025). Trước khi anh và nhóm build nền tảng phần mềm, anh và nhóm kết nối developer với các team một cách thủ công, để chắc chắn đây là thứ người ta muốn và người ta muốn nó theo cách nào.

Bước hai, theo Victor (video đăng ngày 14/10/2025): build MVO. Đây là lúc bạn đóng gói giải pháp thành một lời đề nghị rõ ràng và thử xem người ta có sẵn lòng cam kết không. Nếu có, bạn đã xác nhận được nhu cầu (validated demand), và có khi còn thu được doanh thu trả trước. Tuyệt.

Bước cuối, theo Victor (video đăng ngày 14/10/2025), mới là build MVP. Khi đã có một danh sách chờ gồm những khách hàng trả tiền, bạn có tín hiệu bật đèn xanh rõ ràng: một concept đã được xác nhận, những người dùng đầu tiên, và doanh thu để giúp tài trợ cho việc phát triển. Anh nói: đến lúc đó, và chỉ đến lúc đó, bạn mới nên nghĩ tới việc build phần mềm.

Victor tóm lại roadmap cuối cùng (video đăng ngày 14/10/2025): một, prototype; rồi MVO kèm presale; rồi MVP. Theo anh, đó là mô hình MVP đã hỏng và playbook mới để thay thế nó: đi từ chỗ đánh cược thời gian và tiền bạc vào một sản phẩm, sang build một doanh nghiệp có thể dự đoán được và một lời đề nghị đã được xác nhận.

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