Hầu hết các lộ trình sản phẩm bị bỏ xó chỉ trong vòng một quý sau khi viết ra. Không phải vì các nhóm thiếu kỷ luật, mà vì lộ trình được xây trên nền tảng sai: những mốc ngày cố định, danh sách tính năng, và mong muốn của các bên liên quan được đóng gói thành một kế hoạch. Khi thực tế chắc chắn lệch đi — một tính năng mất nhiều thời gian hơn, nhu cầu khách hàng thay đổi, đối thủ có động thái mới — lộ trình trở thành hư cấu, và các nhóm thôi nhìn đến nó.
Một lộ trình mà mọi người thực sự tuân theo không phải là biểu đồ Gantt khoác áo chiến lược sản phẩm. Đó là một tài liệu sống, thể hiện suy nghĩ tốt nhất hiện tại của nhóm về thứ tự các vấn đề cần được giải quyết, và được cấu trúc để trung thực về điều đã biết và điều chưa biết.
Trước khi thiết kế một lộ trình, cần làm rõ mục đích của nó. Một lộ trình làm ba việc: truyền đạt định hướng (chúng ta đang đi đâu và vì sao), buộc phải ưu tiên (không thể làm tất cả, vậy cái gì đi trước), và tạo nền tảng để đồng bộ (để kỹ thuật, thiết kế, bán hàng và hỗ trợ cùng hướng đến những mục tiêu chung).
Lộ trình không đảm bảo ngày giao. Nó không cam kết những tính năng cụ thể. Và nó không thay thế nhu cầu khám phá (discovery) liên tục. Nếu các bên liên quan coi lộ trình như một lời hứa, đó là vấn đề về quy trình — không phải lý do để nhồi độ chính xác giả tạo vào tài liệu.
Định dạng lộ trình bền vững nhất với hầu hết các nhóm là mô hình ba chặng thời gian. Nó trung thực về sự không chắc chắn: các mục ở "Bây giờ" là cam kết, các mục ở "Tiếp theo" đã lên kế hoạch nhưng chưa chốt, và các mục ở "Sau này" đúng về hướng đi nhưng có thể thay đổi khi bạn biết thêm.
Hãy để ý rằng mỗi mục không chỉ nêu nó là gì, mà còn nêu vì sao nó nằm đó. Một lộ trình không có lý do chỉ là một danh sách. Khi các thành viên hiểu vì sao từng mục được chọn, họ có thể ra quyết định tốt hơn khi mọi thứ thay đổi — và có những cuộc trao đổi hiệu quả hơn khi khách hàng đề nghị một thứ không có trong danh sách.
Lộ trình dựa trên tính năng ("làm X, làm Y, làm Z") tạo ra một động lực nguy hiểm: nhóm phát hành tính năng và coi như xong, kể cả khi các tính năng đó không cải thiện được những chỉ số mà chúng được kỳ vọng sẽ cải thiện. Tính năng đã được giao; vấn đề thì chưa được giải quyết.
Lộ trình dựa trên kết quả diễn đạt lại mỗi mục thành một mục tiêu: "Giảm thời gian để người dùng mới đạt giá trị đầu tiên từ 4 ngày xuống dưới 24 giờ." Khi đó nhóm có thể quyết định — và xem xét lại — cách đạt được kết quả ấy. Cấu trúc này cũng giúp dễ hạ ưu tiên một tính năng hơn nhiều khi bạn tìm ra cách tốt hơn để đạt cùng kết quả.
Product manager là người làm chủ lộ trình. Điều đó nghĩa là họ chịu trách nhiệm về nội dung, các lần cập nhật và việc truyền đạt cho các bên liên quan. Nhưng làm chủ không có nghĩa là một mình viết — những lộ trình tốt nhất được xây dựng cộng tác, với đóng góp từ kỹ thuật (về tính khả thi và khối lượng công việc), thiết kế (về tác động đến trải nghiệm người dùng) và các nhóm tiếp xúc khách hàng (về tín hiệu thị trường).
Điều PM cần tránh là thiết kế lộ trình theo kiểu họp ủy ban. Các bên liên quan có thể đóng góp ý kiến; họ không nên có quyền phủ quyết từng mục. PM tổng hợp ý kiến và đưa ra quyết định. Nếu quy trình đi đến những quyết định đó được tin cậy, thì kết quả cũng sẽ được tin cậy.
Cột Bây giờ nên được xem xét mỗi sprint. Cột Tiếp theo nên được xem xét vào đầu mỗi quý, hoặc bất cứ khi nào có bằng chứng mới đáng kể (một khách hàng lớn churn, đối thủ ra mắt thứ gì đó liên quan, một sprint khám phá cho ra phát hiện bất ngờ). Cột Sau này cần xem lại mỗi quý một lần — không phải để tinh chỉnh, mà để xác nhận rằng các canh bạc định hướng vẫn còn hợp lý.
Mục tiêu là một lộ trình không bao giờ cũ đến mức đáng xấu hổ, nhưng cũng không cập nhật dày đến mức gây lo lắng. Hầu hết các nhóm mắc lỗi cập nhật quá ít — lộ trình phản ánh những quyết định từ sáu tháng trước và chẳng ai nhớ chính xác lần cuối nó được sửa là khi nào.
Lộ trình sẽ được tuân theo nếu — và chỉ khi — nhóm tin tưởng nó. Niềm tin đó đến từ ba điều: lý do của từng mục rõ ràng và vững chắc, nhóm được tham gia xây dựng thay vì bị giao sẵn, và PM cập nhật kịp thời khi hoàn cảnh thay đổi thay vì giả vờ kế hoạch ban đầu vẫn còn nguyên giá trị.
Một lộ trình bị coi là công cụ để thương lượng, hoặc là tài liệu làm ra để làm hài lòng ban điều hành, sẽ bị phớt lờ ở cấp nhóm và bị ác cảm ở cấp các bên liên quan. Một lộ trình phản ánh tư duy thực sự, những đánh đổi có thật và sự không chắc chắn được thừa nhận sẽ trở thành công cụ mà mọi người chủ động tìm đến — vì nó thực sự giúp họ ra quyết định.