5 thứ cần bỏ đi trước khi ra mắt — MVP là phép trừ, không phải phép cộng
Sản phẩm đầu tiên, tôi nhồi vào 12 tính năng. Mất 6 tháng. Người dùng chỉ dùng 2 trong số đó. Toàn bộ thời gian bỏ ra để làm 10 tính năng còn lại đã chìm hẳn. Cốt lõi của MVP nằm ở chữ "tối thiểu", vậy mà chúng ta lúc nào cũng chỉ bám vào chữ "sản phẩm".
5 thứ cần bỏ đi trước khi ra mắt — MVP là phép trừ, không phải phép cộng
Sản phẩm đầu tiên, tôi nhồi vào 12 tính năng. Mất 6 tháng. Người dùng chỉ dùng 2 trong số đó. Toàn bộ thời gian bỏ ra để làm 10 tính năng còn lại đã chìm hẳn. Cốt lõi của MVP nằm ở chữ "tối thiểu", vậy mà chúng ta lúc nào cũng chỉ bám vào chữ "sản phẩm".
Với MVP (sản phẩm khả dụng tối thiểu), điều khó nhất không phải là làm ra, mà là quyết định những gì sẽ không làm. Với người kinh doanh một mình, thời gian là nguồn vốn duy nhất, và thời gian đã bỏ vào một tính năng không ai dùng thì sẽ không bao giờ quay lại. Những MVP được làm tốt đều mạnh tay cắt bỏ.
1. Dropbox — tung video trước thay vì sản phẩm
Trước khi làm xong tính năng đồng bộ, Dropbox đã công bố trước một video demo trông như thể sản phẩm đã chạy được. Thứ họ kiểm chứng bằng video không phải là sản phẩm, mà là giả thuyết "Nếu làm được thế này thì tốt nhỉ?". Danh sách chờ tăng vọt chỉ sau một đêm.[^1]
Điểm mấu chốt là họ đã xác nhận nhu cầu trước mà không cần một dòng code nào.
Câu hỏi cho việc kinh doanh của bạn: Thứ tôi đang định làm, liệu có thể kiểm chứng trước bằng video, landing page hay vận hành thủ công mà không cần code không?
2. Instagram — cắt bỏ 99% tính năng
Tiền thân của Instagram là một ứng dụng check-in tên là 'Burbn'. Nó có quá nhiều tính năng. Nhìn vào dữ liệu, các nhà sáng lập phát hiện người dùng chỉ dùng mỗi chia sẻ ảnh, nên họ cắt bỏ toàn bộ phần còn lại và dồn hết vào ảnh.[^2]
Biết cách bỏ khó hơn biết cách thêm.
Câu hỏi cho việc kinh doanh của bạn: Tính năng duy nhất mà người dùng của tôi thực sự dùng là gì? Nếu bỏ hết phần còn lại thì sẽ ra sao?
3. "Có thì tốt" và "không có thì không được"
Nhìn vào bản kế hoạch, tính năng nào cũng được gắn nhãn "có thì tốt". Điều nào cũng đúng nên muốn đưa vào hết. Thế là MVP phình to.
Lời giải là một cách phân loại không khoan nhượng. Chia mọi tính năng vào đúng hai ô — thiếu nó thì sản phẩm không đứng được và phần còn lại. Lần ra mắt đầu tiên chỉ có ô thứ nhất. Ô thứ hai thì làm khi người dùng yêu cầu.
Cách làm: Trước mỗi dòng trong danh sách tính năng, hãy hỏi "Thiếu cái này thì người dùng có bỏ đi không?". Nếu là "Không", hãy bỏ nó khỏi lần ra mắt đầu tiên.
4. PMF không phải cảm giác, mà là đo lường
Nếu đánh giá độ phù hợp sản phẩm – thị trường (PMF) bằng "cảm tính", ta sẽ luôn lạc quan. Rahul Vohra của Superhuman đã biến điều này thành con số. Anh hỏi người dùng "Nếu không được dùng sản phẩm này nữa, bạn sẽ tiếc đến mức nào?", và nếu "rất tiếc" đạt từ 40% trở lên thì coi đó là tín hiệu PMF.[^3]
Ngưỡng 40% này do Sean Ellis đề xuất, và trở thành kim chỉ nam cho câu hỏi "giờ nên làm thêm gì" sau khi ra mắt.
Câu hỏi cho việc kinh doanh của bạn: Trong số người dùng của tôi, tỷ lệ nói "không có cái này thì rất tiếc" là bao nhiêu %? Tôi đã từng đo chưa?
5. Hãy viết yêu cầu theo 'vấn đề', đừng viết theo 'màn hình'
Bản kế hoạch của người mới thường mở đầu bằng "cần có màn hình như thế này". Khi đó ta bị nhốt trong giải pháp. Một yêu cầu tốt bắt đầu bằng "người dùng bị bí vì không làm được gì, trong tình huống nào". Màn hình sẽ đi theo sau.
Cách làm: Viết lại mỗi dòng yêu cầu thành "[Ai đó] trong [tình huống nào] muốn làm [việc gì] nhưng bị chặn vì [điều gì]".
Một câu xuyên suốt cả 5 điều
MVP không phải là một sản phẩm nhỏ. Đó là thử nghiệm nhỏ nhất để học nhanh nhất.
- Dropbox: kiểm chứng nhu cầu bằng video trước khi có sản phẩm
- Instagram: cắt bỏ 99% tính năng không được dùng
- Phân loại: lần ra mắt đầu tiên chỉ gồm những thứ không thể thiếu
- PMF: đo mốc 40%, không dựa vào cảm tính
- Yêu cầu: viết theo vấn đề, không theo màn hình
Với người kinh doanh một mình, đây là một lợi thế. Doanh nghiệp lớn không bỏ được những gì đã làm ra, còn chúng ta có thể bắt đầu nhỏ ngay từ đầu.
Nếu hôm nay chỉ làm một việc
Hãy lấy danh sách tính năng bạn đang định làm ra, và ghi bên cạnh mỗi dòng "Thiếu nó thì người dùng có bỏ đi không? Y/N". Nếu N chiếm từ một nửa trở lên, MVP của bạn vẫn còn quá lớn.
Đăng ký tư vấn miễn phí → Cùng bạn chọn ra những gì cần bỏ khỏi danh sách tính năng.
Nguồn (✅ đã kiểm chứng 3/3, WebSearch 2026-06-01)
[^1]: Video demo của Dropbox (2007~2008) → danh sách chờ tăng vọt từ 5,000 lên 75,000 người chỉ sau một đêm (lan truyền trên Hacker News·Digg, 0 quảng cáo). — Nguồn thứ cấp (mmtm.io). Phần thân bài chỉ mô tả là "tăng vọt", không nêu con số. https://mmtm.io/articles/dropbox-go-to-market-story/ [^2]: Burbn (tối đa 100 người dùng) → chỉ giữ lại chia sẻ ảnh mà người dùng đang dùng, cắt bỏ các tính năng còn lại → Instagram (loại bỏ khoảng 50~60% tính năng ban đầu). — Startup Archive (Systrom). https://www.startuparchive.org/p/how-kevin-systrom-pivoted-a-failed-check-in-app-into-instagram [^3]: Với câu hỏi "Không được dùng sản phẩm này thì bạn tiếc đến mức nào?", "rất tiếc" từ 40% trở lên = tín hiệu PMF. Sean Ellis đưa ra năm 2009 sau khi phân tích ~100 startup, Superhuman (Rahul Vohra) áp dụng vào vận hành. https://learningloop.io/glossary/sean-ellis-score
Bài viết này là bài chủ lực của mảng hoạch định dịch vụ của STAR-T. Cả 3 số liệu đều đã được kiểm chứng.
Nếu bạn chưa biết nên bỏ đi điều gì trước,
Bạn có thể dùng bài chẩn đoán 2 phút để xác định điểm cần cấu trúc hóa trước tiên ngay lúc này. Bạn chỉ cần trả lời trong phạm vi thấy thoải mái là được.
Tương tác
Lượt xem và phản ứng được lưu làm tín hiệu nội dung nội bộ.
Tóm tắt chính
- •Với MVP, điều khó nhất không phải là làm ra mà là quyết định những gì sẽ không làm, và thời gian bỏ vào tính năng không được dùng thì không quay lại.
- •Trước khi làm xong tính năng đồng bộ, Dropbox đã công bố trước một video demo trông như sản phẩm đã chạy được, qua đó xác nhận nhu cầu mà không cần code.
- •Burbn, tiền thân của Instagram, có quá nhiều tính năng; các nhà sáng lập nhìn dữ liệu thấy người dùng chỉ dùng chia sẻ ảnh nên đã cắt bỏ phần còn lại.
- •Chia mọi tính năng vào hai ô: 'thiếu nó thì sản phẩm không đứng được' và 'phần còn lại'; lần ra mắt đầu tiên chỉ gồm ô thứ nhất.
- •PMF được đánh giá bằng đo lường chứ không bằng cảm tính; tiêu chí do Sean Ellis đề xuất và Superhuman áp dụng là tỷ lệ trả lời 'rất tiếc nếu không được dùng sản phẩm này nữa' có đạt từ 40% trở lên hay không.
Câu hỏi thường gặp
Nên đưa những tính năng nào vào MVP?
Tôi đề xuất hỏi ở mỗi dòng trong danh sách tính năng: 'Thiếu cái này thì người dùng có bỏ đi không?', và bỏ những mục trả lời là không khỏi lần ra mắt đầu tiên. Chỉ giữ lại những gì mà thiếu nó thì sản phẩm không đứng được, phần còn lại làm khi người dùng yêu cầu.
Đo PMF như thế nào?
Hỏi người dùng 'Nếu không được dùng sản phẩm này nữa, bạn sẽ tiếc đến mức nào?' và xem tỷ lệ trả lời 'rất tiếc'. Ngưỡng 40% do Sean Ellis đề xuất đã được Rahul Vohra của Superhuman áp dụng vào vận hành, và nó trở thành kim chỉ nam để quyết định làm thêm gì sau khi ra mắt.
Nên viết yêu cầu như thế nào?
Nếu bắt đầu bằng 'cần có màn hình như thế này', bạn sẽ bị nhốt trong giải pháp. Tôi khuyên hãy viết theo vấn đề, kiểu '[Ai đó] trong [tình huống nào] muốn làm [việc gì] nhưng bị chặn vì [điều gì]', rồi mới quyết định màn hình.
Đừng chỉ đọc — hãy kết nối tới dịch vụ hoặc buổi tư vấn phù hợp và bắt tay vào việc.
Khi đã hiểu vấn đề qua các bài viết, bước tiếp theo là quyết định cấu trúc thực thi. Hãy chuyển thẳng sang dịch vụ liên quan hoặc buổi tư vấn miễn phí.
Buổi gặp / tư vấn miễn phíSTAR-T
Chuyên gia tư vấn trưởng của STAR-T
Là chuyên gia lập kế hoạch và thiết kế dịch vụ IT, tôi nghiên cứu và chia sẻ những câu chuyện thành công từ nhiều startup và doanh nghiệp.
Hành động
Đừng chỉ đọc — hãy kết nối tới dịch vụ hoặc buổi tư vấn phù hợp và bắt tay vào việc.
Khi đã hiểu vấn đề qua các bài viết, bước tiếp theo là quyết định cấu trúc thực thi. Hãy chuyển thẳng sang dịch vụ liên quan hoặc buổi tư vấn miễn phí.