Những thay đổi về nhu cầu và thói quen tiêu dùng của khách hàng trong và sau đại dịch Covid-19 khiến nhiều doanh nghiệp phải linh hoạt điều chỉnh sản phẩm của mình. Một trong những công cụ được sử dụng phổ biến cho quá trình này là Product Roadmap. Cấu trúc của nó bao gồm những thành tố cần thiết cho quá trình xây dựng và phát triển sản phẩm.

Trong bài viết này, ThinkZone giới thiệu tới các bạn cấu trúc của một Product Roadmap, cũng như các bước cần thiết để xây dựng một Product Roadmap hiệu quả.

1. Product Roadmap là gì?

“Đội ngũ phát triển sản phẩm nên làm gì ngày hôm nay đây?” Câu trả lời thường ở trên chính Product Roadmap – Lộ trình sản phẩm. Đó là một lộ trình bao gồm danh sách các tính năng, ý tưởng, những công việc cần phải làm, từ các dự án nhỏ đến dự án quan trọng và cả những nỗ lực cần phải đạt được. Tất nhiên là tất cả đều phải có thời hạn hoàn thành. Vì thế, mọi người có thể thực hiện công việc của mình theo Lộ trình Sản phẩm và không phải lo lắng điều gì cần làm tiếp theo. Lộ trình sản phẩm là một công cụ mạnh mẽ để mô tả làm thế nào một sản phẩm có thể được phát triển, gắn kết các bên liên quan, và có được một ngân sách cho việc phát triển sản phẩm.

Một lộ trình sản phẩm hiệu quả là cần thiết cho bất kỳ dự án phát triển phần mềm nào. Product Roadmap giúp Product Manager xác định quỹ đạo của một sản phẩm, truyền đạt tiến độ tới bên liên quan, dự kiến những thay đổi về ngân sách… Đó cũng là nơi chiến lược và chiến thuật kết hợp giúp sản phẩm được xây dựng tốt hơn.

Chính vì vậy, Lộ trình Sản phẩm có thể được định nghĩa như sau: Lộ trình Sản phẩm (Product roadmap) là danh sách tính năng và dự án được ưu tiên có thời hạn kết thúc nhất định.

2. Cấu trúc của một product roadmap

  • PRODUCT

Không kể sản phẩm của bạn là phần mềm, phần cứng, hay các thiết bị công nghệ hoặc phi công nghệ, phần này là nơi để bạn miêu tả chính xác sản phẩm mà công ty bạn mang lại là gì.

  • THEME

Trong Project Management, Theme là mục tiêu chiến lược cấp cao và bao quát nhất. Bạn sẽ sử dụng các phần khác của Product Roadmap như Epic và Feature để minh họa chính xác các bước mà bạn cần làm cho mỗi chủ đề.

  • EPICS

Sau khi thiết lập ra được những chủ đề rộng cho các bước riêng lẻ cần thực hiện, thì Epics là nhóm cụ thể nhất sau mỗi chủ đề. Hãy nghĩ về Epics như một công cụ tổ chức: Epic là một nhóm các Feature hay User story có liên quan với nhau. Bạn sẽ có nhiều Epic đơn lẻ trong mỗi chủ đề và nhiều câu chuyện đơn lẻ hoặc Feature trong từng Epic.

  • STORY

Story là một nhóm các bước cụ thể mà bạn sẽ cần phải thực hiện để đạt được mục tiêu của mình hay trong Product Management còn gọi là Theme. Đây là một trong những phần chi tiết nhất trong Product Roadmap của bạn, là nơi để bạn phác thảo chính xác nhất những gì mình sẽ cần phải làm.

  • FEATURE

Feature, hay còn được xem là các nghĩa vụ. Features là các yếu tố cụ thể sẽ đưa bạn đến với Theme mà mình đặt ra. Nếu bạn đi theo định dạng từ trên xuống khi thiết kế một Product Roadmap, thì công việc của bạn ở các bước trước sẽ phải hướng dẫn rõ ràng được cho bạn về các Feature mà mình cần tạo.

  • TIMELINE

Một timeline rõ ràng chính là chìa khóa cốt lõi cho cả Product Roadmap. Không kể timeline đấy bao gồm một vài tuần hay cả một thập kỷ tất cả đều phụ thuộc vào sản phẩm và mục tiêu mà bạn đề ra.

  •  MILESTONE

Thiết lập và thông báo mỗi khi cả nhóm đạt được một Milestone cụ thể là một cách tuyệt vời để đảm bảo rằng bạn không chỉ đang đi đúng lộ trình, mà bản Product Roadmap vẫn tiếp tục là một tài liệu vô cùng hữu ích.

3. Cách xây dựng một product map hiệu quả

  • 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 Product Manager (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.

  • Xây dựng 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 khóa 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. 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 với cách làm được mô tả trong hình ảnh dưới đây:

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ể tùy 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. Một số công cụ có thể kể đến 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à tùy 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 LUẬN

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.

PV