Cách tạo một Product Roadmap được người dùng yêu thích

Bài viết được lược dịch từ chia sẻ của Giacomo Lami — General Manager, Product Executive tại Got It

Product Roadmap (lộ trình sản phẩm) là công cụ hiệu quả giúp Product Manager (PM) có thể truyền tải chiến lược sản phẩm, mô tả khả năng phát triển trong tương lai và vạch ra con đường phát triển lâu dài cho sản phẩm ấy.

Tuy vậy, việc xây dựng nên một lộ trình sản phẩm tối ưu là không hề đơn giản, đặc biệt đối với các công ty áp dụng Agile, khi sự thay đổi diễn ra thường xuyên và khó lường trước. Đội ngũ quản trị có tầm nhìn chiến lược của họ, đội ngũ sale và marketing thì muốn ý kiến của mình được lắng nghe, còn các kỹ sư thì luôn phải chờ đợi các yêu cầu chi tiết và các user stories (yêu cầu về sản phẩm dưới góc nhìn người dùng). Là người chịu trách nhiệm cho sự thành công hay thất bại của sản phẩm, việc xây dựng nên một lộ trình sản phẩm rõ ràng là điều đặc biệt quan trọng đối với PM.

Một lộ trình sản phẩm tốt sẽ giúp bạn vạch ra hướng đi của công ty, tạo động lực cho các thành viên trong team, cũng như giúp khách hàng, các đối tác kinh doanh và truyền thông có cái nhìn toàn diện về sản phẩm. Dựa theo kinh nghiệm cá nhân, tôi tin rằng phương pháp tốt nhất để xây dựng một lộ trình sản phẩm là work backwards.

Work backwards nghĩa là bắt đầu từ vạch đích thay vì từ vạch xuất phát. Việc bắt đầu từ mục tiêu của mình sẽ giúp các nhà quản lý sản phẩm có cái nhìn rõ ràng hơn về những tiêu chí cần thực hiện nhằm đạt được mục tiêu đó.

Định hình chiến lược sản phẩm

Để bắt đầu, bạn cần định hình rõ chiến lược sản phẩm, bao gồm 3 nội dung: Tầm nhìn (vision), Mục tiêu (goals) và Sáng kiến (initiatives). Những sáng kiến chủ chốt sẽ giúp định hướng mục tiêu, nên bạn cần biết cách kết nối chúng một cách có hệ thống ngay từ đầu. Một sản phẩm tốt phải được bắt đầu bởi một chiến lược rõ ràng với mục tiêu xây dựng một sản phẩm phù hợp với thị trường. Chiến lược ấy chính là câu trả lời cho câu hỏi “Tại sao” (Why). Đây chính là nền tảng cốt lõi cho vòng đời của một sản phẩm, cũng như kế hoạch phát triển lâu dài.

Tập trung vào các mục tiêu và chỉ số

Trong một chiến lược, các mục tiêu và các chỉ số cần được xác định rõ ràng. Đó có thể là các mục tiêu cụ thể bằng số liệu (ví dụ: tăng gấp đôi conversion rate — tỷ lệ chuyển đổi khách hàng tiềm năng sang khách hàng thực tế), hoặc bao quát hơn (ví dụ: mobile first approach — ưu tiên hướng đến các thiết bị di động). Việc có một lộ trình sản phẩm với các mục tiêu cụ thể như tăng thị phần khách hàng hay loại bỏ được những món nợ kĩ thuật (technical debts) và các chỉ số đo lường giúp PM hiểu được sản phẩm có đang đáp ứng được mục tiêu kinh doanh của công ty không, cũng như chiến lược sản phẩm của mình có hiệu quả không. Nếu không có KPIs, ta chỉ có thể tự suy đoán một cách mơ hồ về cách mà sản phẩm của chúng ta đang hoạt động.

Thu thập các yêu cầu

Vậy khi đạt được sự đồng thuận về mục tiêu của cả team product và các bên liên quan (stakeholders), có phải PM sẽ bắt tay luôn vào công việc thú vị nhất — định hình các tính năng (features) cho sản phẩm?

Từ từ đã! Các tính năng ư? Không hẳn thế! Đừng xây dựng một lộ trình sản phẩm lấy các tính năng làm trung tâm. Lời khuyên của tôi là hãy xây dựng lộ trình sản phẩm theo chủ đề (theme). Bằng cách chia các tính năng thành từng nhóm chủ đề, chúng ta có thể sắp xếp lộ trình sản phẩm đó sao cho các giá trị đối với khách hàng và các bên liên quan được thể hiện rõ. Chủ đề có thể giúp ta tạo ra một lộ trình sản phẩm chứa đựng cả một câu chuyện — câu chuyện về lý do đằng sau những gì ta đưa ra. Chủ đề cũng giúp lộ trình sản phẩm luôn giữ được sự bao quát, đặc biệt là với những sáng kiến dài hạn.

Yêu cầu của sản phẩm có thể đến từ rất nhiều nguồn khác nhau. Vì vậy, việc lắng nghe tất cả mọi người, cởi mở với các yêu cầu và ý tưởng là vô cùng quan trọng. Nhưng đồng thời, bạn cũng cần sẵn sàng nói “không”. Chúng ta luôn muốn nhận được sự đóng góp từ các bên liên quan, song ta không nên đồng ý với tất cả các yêu cầu và ý kiến. Nếu không, lộ trình sản phẩm có thể sẽ trở thành một bộ sưu tập các tính năng một cách rời rạc. Bạn có còn nhớ câu nói của Steve Jobs?

“Sáng tạo không có nghĩa là đồng ý với mọi thứ. Sáng tạo là nói không với gần như tất cả, chỉ trừ những tính năng quan trọng nhất.”

Hãy luôn ghi nhớ tầm nhìn và chiến lược sản phẩm để có thể đưa ra những quyết định đúng đắn.

Bao quát và đơn giản hoá

Lộ trình sản phẩm là kế hoạch tổng quát về điều sản phẩm đang hướng tới. Hãy luôn giữ bức tranh toàn cảnh, và đừng cố gắng tái tạo lại danh sách các tính năng mong muốn của sản phẩm (Agile Product Backlog). Bạn cần chống lại mong muốn đưa thật nhiều thông tin chi tiết vào lộ trình sản phẩm. Hãy giữ nó thật giản đơn và dễ hiểu. Có quá nhiều lộ trình sản phẩm chú trọng vào các tính năng, và điều này dễ khiến cho các bên liên quan cảm thấy mất phương hướng. Thay vào đó, như đã nói ở trên, hãy sử dụng các chủ đề (themes). Các chi tiết, bao gồm câu chuyện của người dùng, kịch bản, hay thiết kế giao diện người dùng (UI) sẽ nằm trong product backlog chứ không phải lộ trình sản phẩm.

Ngoài ra, bạn cần hiểu rõ rằng, lộ trình sản phẩm là để truyền đạt kế hoạch của PM và đạt được sự đồng thuận. Nó nên vẽ ra một câu chuyện mạch lạc về hướng phát triển của sản phẩm. Và một bài thuyết trình trực quan chắc chắn sẽ hiệu quả hơn một bảng tính với các số liệu đơn thuần.

Tạo ra một lộ trình có thể đo lường được

Hãy đảm bảo rằng mọi mục tiêu của lộ trình sản phẩm đều có thể đo lường được. Chúng sẽ cho bạn biết liệu mình có đạt được mục tiêu hay không. Ví dụ, nếu mục tiêu là có được khách hàng, bạn cần chỉ rõ số lượng đó là bao nhiêu; nếu mục tiêu là giảm nợ kĩ thuật (technical debt), hãy xác định có bao nhiêu code xấu (bad code) cần phải được loại trừ hoặc tái cấu trúc. Nếu không có các mục tiêu với sự đo lường cụ thể, sẽ rất khó để xác định liệu ta có đạt được mục tiêu hay không. Tuy nhiên, hãy nhớ lập những mục tiêu thực tế (không quá xa vời).

Ước tính chi phí

Dù sản phẩm có mới, non trẻ và luôn thay đổi, thì ta vẫn nên thực hiện việc ước tính chi phí sản xuất theo hướng top-down (từ trên xuống). Hãy xác định ta sẽ cần bao nhiêu người với những kỹ năng nào để có thể cho ra các lần phát hành (releases) như mong muốn trong lộ trình sản phẩm. Sau đó, dựa vào kinh nghiệm cá nhân trong việc phát triển những sản phẩm tương tự hoặc các phiên bản trước của sản phẩm đang có, hãy cân nhắc xem liệu công ty bạn đã có đủ nhân lực với chuyên môn phù hợp chưa, liệu có cần tuyển thêm người không. Qua đó, bạn có thể ước tính được thời gian và chi phí lao động cần thiết.

Tạo niềm tin nội bộ

Một lộ trình sản phẩm tốt đến mấy cũng sẽ trở nên vô giá trị nếu như những người tham gia phát triển, tiếp thị và bán sản phẩm của bạn không thực sự tin vào nó. Cách tốt nhất để tạo nên sự đồng thuận chính là sự hợp tác với các bên liên quan trong quá trình xây dựng và cập nhật lộ trình sản phẩm. Việc này cho phép PM tận dụng được các ý tưởng, kiến thức của họ, cũng như tạo nên niềm tin vững chắc trong nội bộ team. Tổ chức các workshop để cùng nhau xây dựng lộ trình sản phẩm là một lựa chọn yêu thích của tôi để gắn kết với mọi người.

Làm việc cùng các kỹ sư để đưa ra dự đoán

Hãy lên kế hoạch cho các lần phát hành (releases) và tạo danh sách các tính năng mong muốn của sản phẩm (backlog) — đây là thời điểm để sử dụng ngày tháng và xem lại các mốc thời gian trong lộ trình sản phẩm. Hãy tập hợp các lần phát hành và các tính năng trong một cái nhìn tổng quan. Hãy đảm bảo mọi thông số, cấu trúc dây (wireframes), cũng như các giao diện người dùng (UIs) được định nghĩa rõ ràng và được lưu trữ trong một công cụ quản lý backlog như JIRA. Việc trao đổi với các kỹ sư phần mềm là vô cùng quan trọng ở thời điểm này. Hãy thực sự làm việc như một team để có thể xác định tất cả các trường hợp có thể xảy ra để chắc chắn rằng các tính năng được xác định rõ ràng và thân thiện với người dùng. Đặc biệt, hãy ghi nhớ việc phải luôn chú trọng đến từng chi tiết.

PM nên tập trung vào các trường hợp sử dụng (use cases) và các vấn đề mà tính năng sản phẩm có thể giải quyết và để các engineers đưa ra giải pháp. Sự phản hồi của họ sẽ là chìa khoá quan trọng trong giai đoạn xác định thứ tự ưu tiên (Prioritization phase).

Việc ước tính và xác định thứ tự ưu tiên nên được diễn ra cùng một lúc. Đây chính là một trường hợp catch-22 điển hình. Một mặt, PM phải biết kỹ sư cần bỏ ra bao nhiêu nỗ lực cho một tính năng để có thể tạo ra một sprint hiệu quả; mặt khác, PM lại không được để bị ảnh hưởng bởi các nỗ lực phát triển sản phẩm đó và phải chú trọng vào các tính năng quan trọng nhất. Việc tìm được sự cân bằng là vô cùng thiết yếu ở đây.

Xác định thứ tự ưu tiên

Hãy sử dụng thứ tự ưu tiên hoặc một thang điểm để định hướng các cuộc trò chuyện. Hiển nhiên, ta không thể quy mọi quyết định về sản phẩm thành một con số, nhưng ta hoàn toàn có thể dùng công cụ này để cho mọi người thấy sự minh bạch trong việc đánh giá các cơ hội khác nhau, từ đó cho họ một cái nhìn sâu hơn về các quyết định của chúng ta. Có rất nhiều phương pháp để xác định thứ tự ưu tiên. Cá nhân tôi đánh giá cao và thường sử dụng phương pháp Theme Scoring.

Bước đầu tiên của mô hình này là định nghĩa các tiêu chí lựa chọn (selection criteria) và trọng số (weight) của nó, sau đó tạo ra các chủ đề (themes). Sau khi chọn ra một chủ đề tham khảo (theme reference — một ứng cử viên nặng ký cho phiên bản tiếp theo), hãy so sánh tất cả các chủ đề đó với chủ đề tham khảo và tính điểm. Thứ tự của các chủ đề được sắp xếp theo thang điểm từ cao xuống thấp về cơ bản chính là lộ trình cho sản phẩm của bạn.

Chia sẻ lộ trình sản phẩm

Có lẽ phương án tốt nhất với PM là tạo ra 2 lộ trình sản phẩm — 1 bản lưu hành nội bộ và 1 bản có thể công bố rộng rãi. Hãy đảm bảo sự thống nhất giữa chúng, dù bạn có thể tuỳ chỉnh một chút cho hợp với từng đối tượng sử dụng. Với khách hàng, hãy cho họ thấy chủ đề chính của lần phát hành đó và các tính năng quan trọng mà họ sẽ quan tâm. Còn các bên liên quan trong nội bộ công ty sẽ muốn hiểu được những điểm mấu chốt mang tính chiến lược, được thể hiện qua các mục tiêu và sáng kiến.

Hãy sử dụng một công cụ để minh hoạ (visualize) lộ trình sản phẩm của mình. Có rất nhiều công cụ như vậy và tất nhiên, chúng đều có những ưu và nhược điểm. Tôi đã tìm hiểu và sử dụng các công cụ như Roadmunk, Product Plan, Aha! và Jira. Một khi đã có một bản minh hoạ như ý muốn, ta hoàn toàn có thể tự tin chia sẻ nó với những người liên quan chủ chốt và dễ dàng cập nhật tin tức đến mọi người.

Thường xuyên xem lại và tuỳ chỉnh

Cuối cùng nhưng không kém phần quan trọng, hãy thường xuyên xem lại và cập nhật lộ trình sản phẩm của bạn. Nếu môi trường kiểu agile thì thường cũng kéo theo nhiều thay đổi. Bởi vậy việc thường xuyên xem lại và cập nhật là vô cùng cần thiết. Tôi khuyên bạn nên làm việc này mỗi 4 tuần đến 3 tháng một lần, tuỳ theo tuổi đời của sản phẩm cũng như sự năng động của thị trường.

Để kết lại, việc tạo ra lộ trình sản phẩm là thử thách lớn nhất mà các PM phải đối mặt. Tuy vậy cho đến hôm nay, vẫn có rất nhiều lộ trình sản phẩm được tạo ra một cách viển vông do áp lực của việc bán hàng hoặc các yêu cầu khẩn cấp vào phút cuối của lãnh đạo công ty. Tuy nhiên chính chúng ta, những nhà quản lý sản phẩm, mới là người quyết định có thay đổi xu hướng này và tiếp cận nó một cách cứng rắn, khoa học hơn hay không.

Hy vọng bài viết này có thể đi theo hướng nhìn đó và cho các bạn một vài gợi ý trong việc tạo ra lộ trình sản phẩm của riêng mình.

Happy roadmapping!

Nếu bạn muốn theo con đường product và muốn được đào tạo trong môi trường rất khốc liệt xây dựng sản phẩm toàn cầu thì nhanh tay ứng tuyển vào vị trí Technical Product Manager tại Got It nhé!