Các khả năng là cần thiết cho một tính năng hoàn thiện nhưng không cần để
xác nhận dự đoán ban đầu về giá trị. Chỉ khi nhu cầu đầu tiên đã được xác
nhận, chúng tôi mới đầu tư thêm công sức phát triển để xây dựng những tính
năng phụ.
NHỮNG PHẢN ĐỐI PHỔ BIẾN VỀ MVP
Khi việc tiến hành xây dựng sản phẩm tối thiểu được chấp nhận nhiều hơn ở
các đội ngũ khác mảng trong Microsoft, tôi đã gặp một số phản đối phổ
biến:
Phản đối: Khách hàng của chúng ta đặt kỳ vọng cao hơn ở chúng ta, vì vậy
chúng ta không thể tung ra một MVP.
Hồi đáp: Tung ra MVP không có nghĩa là chúng ta đang cung cấp một trải
nghiệm lỗi. Thiết kế và tính năng có thể đạt chất lượng cao, chúng ta chỉ hỗ
trợ ít tính năng hơn. Nếu giả thiết của chúng ta là đúng, chúng ta đang mang
đến giá trị nào đó cho khách hàng và tiếp tục bổ sung thêm nhiều giá trị hơn.
Nếu giả thiết của chúng ta là sai, chúng ta đang cung cấp một tính năng phụ
không có giá trị thay cho một tính năng chính vô giá trị.
Tôi đã hoàn toàn dừng sử dụng thuật ngữ “sản phẩm khả thi tối thiểu” khi
nói chuyện với các đội ngũ nội bộ của Microsoft. Đơn giản là vì mất quá
nhiều thời gian để giải thích rằng MVP không đồng nghĩa với chất lượng
kém. Thay vào đó, tôi mô tả những gì chúng tôi làm là “Phát triển theo định
hướng giả thiết”, cụm từ đó nhấn mạnh vào việc xác nhận các ý tưởng hơn
là chất lượng sản phẩm.
Phản đối: Chúng ta phải hỗ trợ tất cả các nền tảng.
Hồi đáp: Nếu chúng ta xây dựng một tính năng chỉ dành cho Android, và
không có ai sử dụng nó, liệu chúng ta có nên nghĩ rằng thật tệ vì mình đã
không xây dựng tính năng vô ích đó cho cả iOS, Windows Phone và hệ điều
hành MacOS hay Windows 8?
