Eric Ries là đồng sáng lập IMVU, một mạng xã hội avatar 3D ra đời năm 2004. Ông và đồng đội bỏ sáu tháng xây một phần mềm chat tích hợp với các mạng nhắn tin có sẵn, ra mắt đúng kế hoạch — và không ai dùng. Khách hàng không muốn kéo bạn bè cũ vào; họ muốn một nơi riêng để gặp người mới. Toàn bộ sáu tháng đó là lãng phí, trừ một thứ: bài học. Từ trải nghiệm ấy, cộng với cách nghĩ của hệ thống sản xuất tinh gọn Toyota, Ries viết cuốn sách này năm 2011, và nó trở thành ngôn ngữ chung của cả một thế hệ người khởi nghiệp.
Định nghĩa của ông về khởi nghiệp là điểm xuất phát cho mọi thứ còn lại: một tổ chức được lập ra để tạo sản phẩm hoặc dịch vụ mới trong điều kiện bất định cực độ. Bất định là từ khoá. Kế hoạch kinh doanh truyền thống giả định bạn đã biết khách hàng là ai và họ muốn gì; khởi nghiệp thì chưa biết cả hai. Nên phương pháp phải khác — không phải bớt kỷ luật, mà là một loại kỷ luật khác, dành cho việc học.
Ries phản bác hai quan niệm phổ biến. Một là khởi nghiệp thành công nhờ thiên tài và may mắn, nên không cần quy trình. Hai là áp quy trình của công ty lớn vào thì sẽ ổn. Cả hai đều sai theo cùng một cách: chúng coi bất định là thứ cần né, trong khi bất định chính là điều kiện làm việc. Cần một cách quản trị chấp nhận rằng phần lớn giả định ban đầu sẽ sai, và tối ưu cho việc phát hiện điều đó thật nhanh, thật rẻ. Toàn bộ cuốn sách là bộ công cụ cho việc ấy.
Ở IMVU, đội của Ries đã "tiến độ" rất tốt theo nghĩa truyền thống: đúng lịch, đúng tính năng, mã chạy được. Nhưng nếu thứ bạn làm không ai cần thì làm đúng hạn chỉ là thất bại đúng hạn. Ries đề xuất đo tiến độ bằng "học có kiểm chứng": những điều bạn biết thêm về khách hàng, được chứng minh bằng dữ liệu từ khách hàng thật chứ không phải từ phòng họp. Một tuần biết được khách hàng không muốn tính năng X đáng giá hơn một tháng xây tính năng X hoàn hảo. Đây là thay đổi đau nhất cho những người làm kỹ thuật, vì nó nói rằng mã đẹp không phải giá trị; điều học được mới là.
Vòng lặp trung tâm của sách: xây thứ nhỏ nhất đủ để thử một giả định, đo phản ứng của khách hàng, học rồi quyết định bước tiếp. Sức mạnh nằm ở tốc độ đi hết một vòng, và cách rút ngắn là "sản phẩm khả dụng tối thiểu". Ba ví dụ Ries kể đã thành kinh điển: Dropbox làm một video ba phút mô tả sản phẩm chưa tồn tại, danh sách chờ tăng từ năm nghìn lên bảy mươi lăm nghìn qua một đêm. Zappos khởi đầu bằng cách người sáng lập chụp ảnh giày ở cửa hàng địa phương rồi đăng bán, chỉ đi mua khi có đơn — thử xem người ta có mua giày qua mạng không trước khi ôm kho. Groupon bắt đầu là một blog WordPress với phiếu giảm giá dạng PDF gửi tay. Không cái nào là sản phẩm hoàn chỉnh; cái nào cũng trả lời được một câu hỏi.
Hiểu lầm phổ biến nhất về MVP là "làm cho có". Ries định nghĩa nó chặt hơn: phiên bản nhỏ nhất cho phép thử giả định rủi ro nhất, với ít công sức nhất. Đôi khi đó là một video; đôi khi là "MVP người hầu" — ông kể chuyện Food on the Table, dịch vụ lên thực đơn, khởi đầu bằng việc người sáng lập đích thân đến nhà một khách hàng duy nhất mỗi tuần để phục vụ bằng tay, trước khi viết một dòng mã nào. Nỗi sợ thường gặp — "khách hàng sẽ đánh giá thấp mình" — Ries cho là hiếm khi đúng với người dùng sớm; họ tha thứ cho sản phẩm thô vì họ mua tầm nhìn, không mua độ bóng. Còn nếu lo đối thủ sao chép ý tưởng, ông nhắc rằng đối thủ thường không đủ nhanh để bắt kịp một đội học nhanh, và ý tưởng chưa được kiểm chứng thì cũng chẳng đáng để trộm.
Tổng số người dùng, lượt xem trang, số lượt tải — Ries gọi đây là "số ảo": chúng đi lên theo thời gian bất kể sản phẩm có tốt hơn hay không, và ai cũng thích trình chiếu chúng. Số hành động thì khác: nó cho biết một thay đổi cụ thể có làm động cơ tăng trưởng chạy tốt hơn không. Công cụ của ông là phân tích theo nhóm — so những người đăng ký tuần này với những người đăng ký tuần trước, xem tỉ lệ đi tiếp có tăng không — và thử nghiệm tách đôi. Ba tiêu chuẩn cho một chỉ số tốt: dẫn tới hành động được, ai cũng truy cập được, và kiểm chứng được. Phần này Ries gọi là "kế toán đổi mới", và nó là câu trả lời cho câu hỏi khó nhất của mọi nhà sáng lập: làm sao biết mình đang tiến bộ hay chỉ đang bận.
Đến một lúc, dữ liệu sẽ nói rằng giả định nền tảng sai. Khi đó có hai lựa chọn: kiên trì hoặc "xoay trục" — đổi hướng có cấu trúc để thử một giả định nền tảng mới, giữ lại những gì đã học. Ries liệt kê nhiều kiểu xoay: thu hẹp một tính năng thành cả sản phẩm, mở rộng sản phẩm thành một tính năng, đổi phân khúc khách hàng, đổi từ ứng dụng thành nền tảng. Ông kể chuyện Votizen của David Binetti xoay nhiều lần trước khi tìm ra thứ chạy. Câu hỏi không phải "chúng ta có xây được không" mà là "chúng ta có nên xây không". Và một cách đo thời gian còn lại đáng nhớ: không phải bao nhiêu tháng tiền, mà là còn bao nhiêu lần xoay trục.
Công cụ cuối cùng mượn từ Toyota: khi có sự cố, hỏi "tại sao" năm lần liên tiếp để đi từ triệu chứng tới nguyên nhân gốc. Máy chủ sập — tại sao? Vì một thay đổi mã lỗi. Tại sao lỗi lọt qua? Vì không có kiểm thử. Tại sao không có? Vì kỹ sư mới chưa được hướng dẫn. Tại sao chưa? Vì không có quy trình đón người mới. Đến đây, cái cần sửa không phải máy chủ mà là cách đón người mới. Ries thêm một quy tắc: đầu tư sửa lỗi tỉ lệ với mức nghiêm trọng ở mỗi tầng — lỗi nhỏ thì sửa nhỏ, đừng biến mọi sự cố thành cải tổ. Đây là cách một tổ chức khởi nghiệp học từ chính mình mà không bị tê liệt vì quy trình.
Cách duy nhất để thắng là học nhanh hơn bất kỳ ai khác.
Chưa ai bình luận. Bạn có thể là người mở lời.