Tại Sao Hầu Hết MVP Thất Bại Trước Khi Ra Mắt

Hơn 100 sản phẩm đã ra mắt trong sự nghiệp của cả hai sáng lập viên. Và dạng thất bại hầu như luôn giống nhau. Không phải stack công nghệ sai. Không phải đội phát triển tệ. Một cuộc họp lập kế hoạch, sáu tuần trước deadline, nơi ai đó nói "trong khi làm, hãy thêm vào…" và không ai phản biện.

Vấn đề định nghĩa

MVP có nghĩa là Minimum Viable Product — Sản phẩm Khả thi Tối thiểu. Không phải Bộ Tính năng Khả thi Tối thiểu. Không phải "mọi thứ chúng tôi nghĩ chúng tôi cần trừ hai thứ." Tối thiểu. Thứ nhỏ nhất chứng minh giả định cốt lõi của doanh nghiệp.

Hầu hết các nhóm xác định MVP bằng cách bắt đầu với mọi thứ họ muốn và loại bỏ những thứ có vẻ rõ ràng là không cần thiết. Điều đó là sai. Bạn kết thúc với một sản phẩm mất bốn tháng để xây dựng, là 70% những gì bạn tưởng tượng và vẫn chưa kiểm tra điều duy nhất quyết định doanh nghiệp có hoạt động hay không.

Lý do thực sự các tính năng được thêm vào

Không ai thêm tính năng vì bất cẩn. Họ thêm vì cảm thấy vô trách nhiệm nếu không làm. "Chúng ta không thể ra mắt mà không có thông báo — người dùng sẽ không quay lại." "Chúng ta cần dashboard báo cáo hoặc khách hàng doanh nghiệp sẽ không tin." "Đối thủ có tính năng này — chúng ta phải theo kịp."

Mỗi câu nói đó đều có lý. Không câu nào được kiểm chứng. Chúng là giả định được ngụy trang thành yêu cầu. Và mỗi cái kéo dài timeline thêm một tuần, rồi thêm hai khi bạn tính đến sự phức tạp nó đưa vào các tính năng liền kề.

Tính năng bạn thêm vào "phòng hờ" là cái làm trì hoãn việc ra mắt ba tuần và bị loại bỏ trong bản viết lại v2 dù sao.

Bài kiểm tra mọi tính năng phải vượt qua

Trước khi thêm bất kỳ tính năng nào vào phạm vi MVP, nó phải trả lời câu hỏi này: "Nếu chúng ta không đưa vào, chúng ta có thể vẫn kiểm tra liệu đề xuất giá trị cốt lõi có thực hay không?"

Nếu câu trả lời là có, tính năng đó không thuộc về MVP. Nó thuộc về v2. Mục tiêu của MVP không phải là gây ấn tượng. Mà là học hỏi — nhanh nhất và rẻ nhất có thể — liệu thứ bạn đang xây dựng có giải quyết vấn đề mà mọi người sẽ trả tiền không.

Các tính năng hầu như không bao giờ thuộc về MVP:

• Lọc và tìm kiếm nâng cao (năm người dùng không cần Elasticsearch)
• Hệ thống thông báo email (email thủ công hoạt động cho đến khi bạn có 50 người dùng)
• Dashboard báo cáo cho quản trị viên (xuất bảng tính sống được qua ba tháng đầu)
• Tour onboarding và tooltip (thay vào đó hãy trực tiếp nói chuyện với người dùng)
• Ứng dụng di động (web app responsive ra mắt trong nửa thời gian)
• Tích hợp với công cụ bên thứ ba (nếu sản phẩm cốt lõi không hoạt động, các tích hợp không quan trọng)

Timeline nói dối, và bạn tin vào nó

Dạng thất bại thứ hai là chấp nhận timeline không thể chịu được tiếp xúc với thực tế. Một developer nói một tính năng mất hai ngày. Nó mất bốn ngày. Nhân điều đó với build 12 tuần và bạn đã mất ba tuần trước khi dòng CSS đầu tiên được viết.

Giải pháp không phải là ước tính chính xác hơn. Ước tính sẽ luôn sai. Giải pháp là xây dựng theo giai đoạn với các cổng phạm vi cứng. Tuần thứ tư, bạn demo những gì tồn tại. Nếu không có ở đó, nó bị cắt — không bị trì hoãn. Timeline là cố định. Phạm vi di chuyển.

Quy trình MVP hoạt động trông như thế nào

Chúng tôi đã ra mắt sản phẩm trong tám tuần đang hoạt động trên thị trường, tạo ra doanh thu, trước khi phiên bản "đầy đủ tính năng" mà khách hàng ban đầu mô tả sẽ được làm xong một nửa. Đây là quy luật hoạt động:

• Bắt đầu với một hành trình người dùng — cái kiểm tra giả định cốt lõi. Mọi thứ khác là tiếng ồn.
• Chỉ xây dựng những gì hành trình đó yêu cầu. Vạch ranh giới trước khi bắt đầu xây dựng và giữ vững nó.
• Ra mắt cho năm người dùng thực trước khi thêm bất cứ điều gì. Phản hồi của họ đáng giá hơn bất kỳ tính năng nào bạn đã lên kế hoạch.
• Coi v1 là công cụ nghiên cứu, không phải sản phẩm. Bạn đang mua thông tin, không phải xây dựng phần mềm.
• Quyết định v2 trông như thế nào dựa trên những gì bạn học được trong v1 — không dựa trên lộ trình bạn viết trước khi ra mắt.

Sự thật khó chịu hơn

Phần khó nhất của việc xây dựng MVP không phải là việc xây dựng. Mà là kỷ luật không xây dựng. Đó là nhà sáng lập phải nói không với ý tưởng của chính họ. Product manager phải làm thất vọng một bên liên quan. Developer phải phản biện một yêu cầu nghe có vẻ hợp lý nhưng thêm ba tuần.

Sự kỷ luật đó là điều tách biệt các nhóm ra mắt và học hỏi với các nhóm dành sáu tháng xây dựng thứ mà không ai muốn, đúng theo cách họ tưởng tượng.

MVP ra mắt trong tám tuần và thất bại dạy bạn điều gì đó. MVP ra mắt trong sáu tháng và thất bại chỉ tốn bạn sáu tháng.