Cách xác định phạm vi cho bản phát hành đầu tiên mà bạn thật sự ra mắt được

Một bản phát hành đầu tiên kéo dài tám tháng hiếm khi là do đội ngũ làm chậm. Gần như luôn là do một phạm vi ngay từ đầu đã không thể sống sót, được thống nhất trong một căn phòng nơi việc cắt bớt bị coi là bi quan.

Xác định phạm vi tốt là một kỹ năng, và chủ yếu là kỹ năng quyết định không xây thứ gì trong lúc mọi người còn đang lạc quan.

Bắt đầu từ một vòng lặp duy nhất

Sản phẩm nào cũng có một vòng lặp cốt lõi: chuỗi hành động người dùng lặp lại và tạo ra giá trị. Với từ điển là tra, đọc, hiểu. Với sàn giao dịch là đăng, khám phá, giao dịch.

Hãy viết vòng lặp của bạn ra thành một câu. Rồi phân loại mọi tính năng được đề xuất vào hai nhóm: bắt buộc để vòng lặp chạy được, và tất cả những thứ còn lại.

Nhóm thứ hai gần như luôn lớn gấp bốn năm lần mức người ta tưởng, và đó là nơi tiến độ của bạn biến mất. Không phải vì những tính năng đó tệ, mà vì không cái nào chịu lực và cái nào cũng được lên lịch.

"MVP" đã mất nghĩa

Thuật ngữ này giờ bao trùm hai thứ không tương thích: một sản phẩm cố tình nhỏ nhưng thật sự tốt ở một việc, và một sản phẩm rộng nhưng làm ẩu. Cái thứ hai mới là thứ phần lớn đội ngũ thật sự ra mắt, và nó thất bại vì người dùng tha thứ cho sản phẩm hẹp chứ không tha thứ cho sản phẩm hỏng.

Một cách diễn đạt hữu ích hơn: hẹp và hoàn chỉnh. Ít thứ hơn, mỗi thứ được làm tử tế, gồm cả trạng thái lỗi và trạng thái rỗng. Một bản đầu làm trọn một việc sẽ giành được quyền có bản thứ hai. Một bản làm tám việc ở mức 60% thì không.

Hãy cắt phạm vi, đừng cắt chất lượng. Cắt chất lượng thì vô hình trong bản kế hoạch và cực kỳ hữu hình với người dùng.

Những thứ thường nên cắt

Những thứ có vẻ thiết yếu và gần như luôn đợi được:

• Tài khoản, nếu giá trị vẫn chạy được mà không cần. Đăng ký là điểm rơi lớn nhất trong phần lớn phễu. Hãy để người ta dùng thử, thêm tài khoản khi có trạng thái đáng lưu.
• Giao diện quản trị. Bạn không phải người dùng. Một trình khách cơ sở dữ liệu hay một script là đủ trong nhiều tháng.
• Cài đặt. Mỗi tuỳ chọn là một nhánh hành vi phải xây và phải test. Hãy chọn một mặc định hợp lý; thêm nút gạt khi có người hỏi.
• Luồng hướng dẫn ban đầu. Một tour thường là miếng vá cho giao diện chưa đủ rõ. Hãy sửa giao diện trước.
• Nền tảng thứ hai. Web trước rồi mobile, hoặc một nền tảng mobile rồi tới cái kia. Làm cả hai cùng lúc còn hơn gấp đôi khối lượng và giảm một nửa tốc độ nhận phản hồi.
• Đa ngôn ngữ. Trừ khi một thị trường cụ thể chính là thị trường ra mắt. Dịch một sản phẩm còn đang đổi hình dạng nghĩa là sẽ phải dịch lại.

Ba thứ không nên cắt

Cắt những thứ này trông giống tốc độ và thực chất là khoản nợ lãi suất cao.

1. Các luồng không suôn sẻ

Trạng thái lỗi, trạng thái rỗng, trạng thái đang tải, offline. Chúng chiếm khoảng một phần năm khối lượng và phần lớn cảm nhận về chất lượng. Một sản phẩm xử lý thất bại một cách nhã nhặn cho cảm giác chắc chắn ngay cả khi còn nhỏ. Một sản phẩm hiện màn hình trắng khi có sự cố cho cảm giác hỏng, bất kể luồng suôn sẻ tốt tới đâu.

2. Đo lường

Ra mắt mà không có analytics thì bản đầu tiên chẳng dạy bạn điều gì. Bạn sẽ không biết phần nào được dùng, người ta dừng ở đâu, hay vòng lặp có khép lại không. Bạn không cần một kho dữ liệu; bạn cần biết vòng lặp cốt lõi có hoàn tất không và nó đứt ở đâu.

3. Khả năng deploy nhanh

Nếu ra một bản sửa mất một ngày làm thủ công, bạn sẽ ra ít bản sửa hơn, mà những tuần đầu sau ra mắt lại chính là lúc bản sửa quan trọng nhất. Một pipeline cơ bản tốn vài ngày và hoàn vốn trong hai tuần đầu.

Chia lát theo hành trình người dùng, không theo tầng

Sai lầm lập kế hoạch phổ biến nhất là xây theo chiều ngang: xong hết mô hình dữ liệu, rồi hết API, rồi hết màn hình. Không gì chạy được cho tới khi mọi thứ chạy được, và bạn không học được gì cho tới tận cuối.

Hãy chia lát theo chiều dọc. Xây trọn một đường đi từ đầu tới cuối, mỏng nhưng thật, rồi mở rộng nó. Sau tuần thứ hai bạn đã có thứ bấm được. Điều đó chuyển cuộc trò chuyện từ tưởng tượng về sản phẩm sang phản ứng với nó, và đó là nơi phản hồi hữu ích nằm.

Một hình dạng thực tế

Với một bản phát hành đầu tiên tập trung, đại khái:

Tổng tám tới mười sáu tuần cho một thứ hẹp và hoàn chỉnh. Nếu kế hoạch của bạn ghi sáu tuần cho một thứ rộng, thì sai ở phạm vi chứ không sai ở ước lượng.

Ghi lại những gì đã cắt

Một thói quen không tốn gì và ngăn được một cuộc tranh cãi lặp đi lặp lại: giữ một danh sách "không có trong v1" rõ ràng, ai cũng thấy, mỗi mục kèm một dòng lý do.

Nó biến "chúng ta quên" thành "chúng ta đã quyết", chặn việc mỗi tháng lại lôi cùng một tính năng ra bàn lại, và trở thành backlog v2 đã được sắp xếp sẵn theo cuộc thảo luận diễn ra lúc bạn nắm rõ bối cảnh nhất.

Phép thử cho một phạm vi tốt

Hai câu hỏi, và bạn cần trả lời có cho cả hai:

• Nếu chỉ xây đúng chừng này, có ai dùng không? Nếu không, bạn đã cắt mất thứ chịu lực.
• Chúng ta có xây được chừng này một cách tử tế, gồm cả các luồng không suôn sẻ, trong thời gian đang có không? Nếu không, hãy cắt tiếp.

Phần lớn kế hoạch trượt câu thứ hai và không ai nói ra cho tới tuần thứ mười.