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,chúng tôi sẽ 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ả.
Product Roadmap là gì?
Product roadmap là một bản thông tin chỉ dẫn tầm nhìn, hướng đi, ưu tiên của sản phẩm theo thời gian.
Product roadmap cũng dùng để truyền đạt định hướng, và tiến độ phát triển sản phẩm tới đội nhóm bên trong tổ chức lẫn các stakeholders ở bên ngoài.
Mối liên hệ giữa Product Roadmap, Product Vision, Product Strategy
Hình trên thể hiện mối quan hệ giữa tầm nhìn của doanh nghiệp, chiến lược sản phẩm (Product Strategy), Product Roadmap và Business Model.
Từ tầm nhìn của công ty, chiến lược sản phẩm trong dài-trung hạn sẽ được xây dựng để từ đó thiết kế ra Product roadmap và Business Model.
Các yếu tố cần có của 1 Product Roadmap
Product strategy & goals
Product roadmap cần chỉ ra được vì sao các tính năng cần được xây dựng, chúng nhằm phục vụ mục đích gì. Chúng có liên hệ mật thiết với chiến lược phát triển sản phẩm của doanh nghiệp hay không.
Mục tiêu đưa ra trong Product roadmap cũng cần đo lường được để biết khi nào thì hoàn thành mục tiêu.
Các tính năng sẽ được xây dựng (Epic, Features, User story)
Epic là một nhóm gộp các tính năng hoặc user stories có chung 1 mục tiêu. User Story là một câu chuyện người dùng, bản tóm tắt nhu cầu của họ, giúp họ đạt được 1 mục tiêu cụ thể. Story là mức dưới cấp của epic. Tính năng là 1 thứ đã được cụ thể hóa, được phát triển để đáp ứng được user story, epic, và mục đích đề ra của sản phẩm.
Khi nào các tính năng này được hoàn thành (timeframe)
Một product roadmap cần có các mốc thời gian, deadline hoàn thành cho các epic, User Story, feature.
Ai phụ trách phát triển các tính năng này
Theme/nhóm các tính năng, high-level priorities (Release).
Xây dựng Product Roadmap dành cho ai?
Product Owner sẽ sử dụng roadmap để cộng tác với các team khác đồng thời đạt được sự đồng thuận về cách thức sản phẩm sẽ phát triển và được chuyển giao tới tay khách hàng.
Đặc biệt trong các tổ chức Agile, thì product roadmap khi được chia sẻ và minh bạch giúp giữ mọi người có cùng 1 cách hiểu thống nhất và nắm được bối cảnh để đưa ra những quyết định trong công việc hàng ngày.
Một số đối tượng cần xem Product Roadmap:
Các đội phát triển nội bộ (internal development team): Họ chính là những người phát triển tính năng cho sản phẩm nên rất quan tâm đến cấp độ chi tiết của bản roadmap.
Đội ngũ executives, C-level: Đây là những người thường tập hợp lại hàng tháng, hàng quý để nhìn vào bức tranh tổng thể về tốc độ phát triển của công ty, tiến độ hướng tới mục tiêu đã đề ra, họ ít khi nhìn vào chi tiết các stories và tasks.
Đội Sales, marketing: Roadmap giúp đội ngũ sales tư vấn và trò chuyện với khách hàng về những lợi ích, và hứa hẹn từ phía doanh nghiệp. Còn đối với đội marketing, nó giúp họ dễ dàng hơn trong việc giới thiệu các tính năng mới, và lợi ích để thu hút sự chú ý của khách hàng đăng ký dùng thử hoặc để lại thông tin liên lạc.
Khách hàng: chính là những người háo hức về điều gì sẽ diễn ra tiếp theo. Họ chỉ cần một cái nhìn tổng thể về các tính năng mới, các mảng ưu tiên tiếp theo trong định hướng sản phẩm
Làm thế nào để xây dựng Product Roadmap?
Bước 1. Bắt đầu với customer-focused vision
Doanh nghiệp nào cũng sẽ có sứ mệnh, tầm nhìn (vision) khi mới thành lập. Từ đây, các nhà sáng lập sẽ phát triển các sản phẩm để đạt được sứ mệnh, tầm nhìn đó.
Ví dụ:
Sứ mệnh của Magestore là giúp doanh nghiệp kinh doanh thảnh thơi bằng giải pháp công nghệ của Magestore. Tầm nhìn của Magestore là Tạo ra trải nghiệm trơn mượt cho tương lai của ngành bán lẻ (Seamless Experience Creator for the Future of Retail).
Magestore đang phát triển các sản phẩm công nghệ khác nhau. Mỗi sản phẩm lại có 1 tầm nhìn, sứ mệnh riêng.
Về giải pháp POS cho nhà bán lẻ, chúng tôi đang giúp khách hàng vận hành doanh nghiệp với ít công sức bằng hệ thống Magento POS native.
Để đạt được tầm nhìn này, Magestore xây dựng chiến lược cho sản phẩm POS như sau:
- Magento Native: Magestore ứng dụng công nghệ, UX của Magento để làm sản phẩm
- Easy to customize: sản phẩm dễ tùy chỉnh so với các đối thủ khác trên thị trường POS phát triển trên nền tảng Magento dành cho nhà bán lẻ
Bước 2. Tổng hợp thông tin từ các key Stakeholders
Không thể có được 1 Product Roadmap hoàn chỉnh, nếu bạn không có những bước nghiên cứu thị trường, tổng hợp thông tin từ khách hàng, các kỹ sư trong các nhóm phát triển, từ đội sales, marketing, những người thuộc nhóm C-level,và cả những partner của bạn
Hãy đối chiếu lại với bức tranh lớn hơn như mục tiêu của công ty trong từng giai đoạn (OKR), chiến lược phát triển của toàn công ty cũng như của sản phẩm.
Tại Magestore, chúng tôi luôn tận dụng sức mạnh của trí tuệ tập thể từ tất cả các team trong công ty để thu thập được những sáng kiến phát triển tính năng mới mang lại giá trị cho khách hàng. Vì vậy chúng tôi thường tổ chức các buổi Product Planning với những format được chuẩn bị và điều phối để giúp các ý tưởng lớn tìm đến với nhau và nảy nở.
Bước 3. Chọn những điều quan trọng để thực hiện
Tiếp theo hãy chọn ra 3 thứ (theme) mà bạn muốn hoàn thành trong quý tới dựa trên giá trị hướng tới khách hàng. Thiết lập ưu tiên quan trọng trong khoảng thời gian 3 tháng là vừa đủ.
Và Product Owner sẽ là người quyết định cuối cùng trong việc ưu tiên những thứ gì sẽ làm trước, sau khi đã thu thập ý kiến từ đội phát triển, từ các stakeholder trong và ngoài công ty.
Bước 4. Lên timeframe cho các initiative
Sau khi có được những tính năng ưu tiên sẽ đưa vào triển khai, bạn hãy lên 1 action plan với 1 số initiative – hành động chính để đạt được những điều quan trọng đó, gán chúng vào 1 lịch trình để thực hiện.
Bước 5. Tạo các bản roadmap phù hợp với từng loại stakeholders
Không phải ai cũng hiểu Product roadmap của bạn đang nói về điều gì. Và mỗi phòng ban, mỗi nhóm người lại có những mối quan tâm khác nhau khi họ tiếp cận Product Roadmap. Vì vậy, để giúp họ hiểu nhanh hơn Product Roadmap, hãy tạo các bản view nhìn phù hợp theo nhu cầu và mối quan tâm của họ.
Nhóm C-level: quan tâm việc Product roadmap liên hệ như thế nào với tầm nhìn, chiến lược của công ty, chiến lược về sản phẩm. Họ cũng muốn biết các đợt phát hành sẽ tác động ra sao đến các chỉ số doanh thu, lợi nhuận của công ty.
Marketing: quan tâm đến tính năng sản phẩm, so sánh với các sản phẩm tương tự và tiềm năng của sản phẩm có thể tạo ra doanh thu.
Sales: sẽ quan tâm đến các tính năng mà khách hàng sẽ nhận được, ngày release, chi tiết về lợi ích mà sản phẩm mang lại cho khách hàng. Tránh hứa 1 ngày release cụ thể xác định, mà chỉ nên đưa ra timeline
Engineers & developers: quan tâm đến chiến lược sản phẩm, cho đến các requirements, deadlines, sprints và các task chi tiết.
Lợi ích của việc tạo ra các bản roadmap với view nhìn khác nhau nằm ở chỗ bạn có thể phát hiện ra roadmap sản phẩm của bạn còn thiếu sót điều gì, và cần hiệu chỉnh ra sao.
Bước 6. Chia sẻ Product roadmap
Khi đã giới thiệu và chia sẻ Product Roadmap với những phòng ban liên quan nhất, bạn có thể tiếp tục chia sẻ rộng rãi trong toàn công ty.
Việc chia sẻ Product roadmap sẽ thúc đẩy tinh thần gắn kết trong team, và nhờ đó team cũng được sự quan tâm ủng hộ từ đội ngũ quản lý. Roadmap cũng được coi là cách giao tiếp về tiến độ của sản phẩm và set expectation cho giai đoạn tiếp theo.
Cách để xây dựng Product Roadmap 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.
Trên đây là những thông tin liên quan đến Product roadmap do dean2020.edu.vn đã tổng hợp và chia sẻ đến các bạn. Hy vọng rằng với những chia sẻ trên đây sẽ giúp bạn có thêm những kiến thức bổ ích, và đừng quên theo dõi bài viết của chúng tôi để cập nhật những kiến thức mới bạn nhé!
