Mình đã thành lập 1 team sẽ viết các bài viết phân tích về Product và công nghệ cho anh em. Vì đây là chuỗi các bài viết hoàn toàn miễn phí nên hãy like và ăn ủng hộ nhà hàng mình tại HCM để có chi phí mời các tác giả ăn uống nhé!!!! (Có tất cả trên các app)
Like và ăn ủng hộ nhà hàng tại đây
Xin chào mọi người, mình là tác giả Ngọc Mai mình hiện là Product Manager/Product Owner làm việc với nhiều dự án ở các domain khác nhau y tế, AI, E-commerce, Fintech….Các bạn có thể kết nối với mình qua thông tin mà mình để ở cuối bài nhé.
Thuở chân ướt chân ráo mới vào nghề các sếp cứ bảo mình “em đi Discovery đi", “ Em làm Discovery tới đâu rồi?" lúc đấy non choẹt không hiểu “Discovery" là gì; làm những gì; đi “Discovery" để làm gì?. Nên bài viết sau đây mình sẽ chia sẻ cụ thể về Product Discovery được tổng hợp trong quá trình làm việc và các tài liệu mình đã đọc. Trong bài viết này mình sẽ dùng các cụm từ Product Discovery (khám phá sản phẩm) và Product Delivery (tạm dịch: chuyển giao sản phẩm), mà mình sẽ không dùng cụm từ “gathering and defining requirements” vì nhiệm vụ của Product Manager là tạo ra giá trị “create value" chứ không dừng lại ở việc thu thập và phân tích yêu cầu.
Product Discovery là gì?
Đầu tiên về khái niệm “Product Discovery" đã tồn tại song song với sự phát triển của phần mềm. Và hai vấn đề lớn nhất mà các bạn làm sản phẩm luôn gặp đó là: Tìm sản phẩm đúng để xây - Build the right thing (Product Discovery) và Xây sản phẩm cho đúng - Build the thing right (Product Delivery), Product Discovery được sử dụng để mô tả quá trình ra quyết định về việc xây dựng sản phẩm gì, trong khi Product Delivery là quá trình xây dựng, triển khai và duy trì một sản phẩm chất lượng. Cả hai vấn đề trên đều quan trọng như nhau, tuy nhiên đối với mình việc "Discovery" (khám phá) mới là khía cạnh khó khăn hơn, và cũng chính là nơi diễn ra hầu hết các hoạt động sáng tạo. Do đó, đây là lĩnh vực mình dành nhiều sự chú ý.
Vậy có những kĩ thuật nào để thực hiện Product Discovery?
Customer Interviews
Usability Tests
A/B Tests
Demand Tests
Assumption Tests
Customer Journey Mapping
Experience Mapping
Story Mapping
Assumption Mapping
Opportunity Solution Trees
Jobs-To-Be-Done
Ethnographic Studies
Customer Visits
Và danh sách còn rất rất nhiều. Chúng ta rất dễ bị ngộp trong các cách thức sử dụng trong Product Discovery (các bạn yên tâm là nhóm chúng mình sẽ có một chuỗi bài viết về các cách thức trên). Nhưng thật ra nguyên tắc để làm Product Discovery là sự tìm tòi, tò mò về thị trường, về khách hàng, về nhu cầu và nỗi đau của họ. Một quá trình Product Discovery tốt sẽ bao gồm tiếng nói khách hàng trong xuyên suốt quá trình.
Đọc tới đây chắc mọi người đã hòm hòm hiểu được mindset của Product Discovery. Mình hy vọng vậy 😂
Thế làm Product Discovery để làm gì?
Quá trình Product Discovery sẽ giúp mọi người giảm rủi ro và tiết kiệm nguồn lực khi xây dựng sản phẩm. Song song đó, quá trình này sẽ giúp mọi người trả lời được 4 câu hỏi về 4 khía cạnh quan trọng trong khi xây dựng sản phẩm:
Giá trị (Desirability)
Liệu người dùng có dùng sản phẩm của tôi không?/Tại sao tôi phải dùng sản phẩm của bạn?
Mức độ dễ sử dụng (Usability)
Người dùng có thể độc lập sử dụng sản phẩm khi không được hướng dẫn không?
Tính khả thi (Feasibility)
Đội ngũ chúng ta có xây được sản phẩm đó không?
Khả năng sống sót (Viability)
Sản phẩm này có thể nuôi sống/duy trì công ty không?/Sản phẩm này có tuân thủ quy định, luật không? Các stakeholder có ủng hộ sản phẩm này không?
Các câu hỏi trên cần được trả lời bằng dẫn chứng thực tế “evidence". Sau đó, đội phát triển sản phẩm cần mô tả các giải pháp sẽ thực hiện trong giai đoạn Delivery.
Các lỗi sai thường gặp trong Product Discovery :
Giai đoạn Discovery nghe có vẻ nhẹ nhàng đơn giản nhưng rất dễ làm sai cụ thể là mình hồi xưa, sai bét cả ra 🙂. Do là sai quá sai nên mình mò lại và mình biết đến bác Marty Cagan - Founder SVPG nói về 6 lỗi sai thường gặp trong Product Discovery, để đảm bảo thông tin được chính xác nhất mình xin phép giữ nguyên gốc tiếng Anh đối với các thuật ngữ:
Confirmation-biased Discovery: Product Discovery là một quá trình khai phá khách quan nhằm xác định các giải pháp giải quyết hiệu quả vấn đề của người dùng. Tuy nhiên, nhiều đội ngũ thực hiện Discovery chỉ để xác nhận (validate) ý tưởng đã có sẵn, thay vì tìm giải pháp hiệu quả cho vấn đề - hồi trước mình cũng đã như vậy.
Product-as-prototype Discovery: Các đội sản phẩm bị hiểu lầm "prototype"- phiên bản đầu tiên của sản phẩm để test hay thường được gọi là "MVP" (Sản phẩm tối thiểu có thể bán được) là các đoạn code hoạt động được, được viết ngay từ đầu để sử dụng trong sản phẩm cuối cùng. Điều này dẫn tới việc lãng phí nguồn lực, công sức cả đội, khiến cho việc test thị trường bị chậm trễ.
Partial-Team Discovery: Quá trình Discovery cần sự tham gia tích cực của nhiều bộ phận: quản lý sản phẩm, thiết kế sản phẩm và các kỹ sư (cùng các bộ phận khác - tuỳ sản phẩm). Chúng ta thường thấy các kiểu hình Discovery chỉ có mỗi Product Manager hoặc Product Manager và UX thực hiện. Điều này dẫn đến:
Bỏ lỡ ý tưởng hay từ kỹ sư - những người hiểu khả năng triển khai.
Mất kết nối với mục tiêu kinh doanh và bối cảnh đưa sản phẩm ra thị trường.
Kết quả nghiên cứu quá thiên về chiến thuật hoặc xa rời thực tế kinh doanh.
Ít khi đưa ra những thông tin sâu sắc thúc đẩy sản phẩm phát triển.
Giao đoạn bàn giao từ "Discovery" sang "Delivey" thiếu hụt thông tin và kinh nghiệm thực tế.
Phụ thuộc nhiều vào tài liệu văn bản.
Bỏ qua chuyên môn của kỹ sư trong thiết kế và đánh giá thử nghiệm.
One-Dimensional Discovery: Nhiều đội sản phẩm có xu hướng chỉ sử dụng một kỹ thuật Discovery quen thuộc hoặc họ cảm thấy đơn giản mà bỏ qua các phương pháp khác. Điều này dẫn đến việc quá trình Discovery chỉ giải quyết được một phần rủi ro của sản phẩm. Nên kết hợp nhiều kỹ thuật Discovery khác nhau để tận dụng ưu điểm của từng phương pháp và có được kết quả toàn diện nhất.
Big-Bang Discovery: Loại Discovery này xảy ra khi các đội sản phẩm dành nhiều thời gian để lên kế hoạch và thiết kế một số lượng rất ít thí nghiệm (thường chỉ 1 thí nghiệm). Nếu một nhóm mất nhiều tuần để chuẩn bị và đánh bóng thí nghiệm, thì đó chính là "Big-Event Discovery". Dĩ nhiên, mức độ trưởng thành của sản phẩm cũng sẽ ảnh hưởng đến độ chi tiết thực hiện Discovery, nhưng về bản chất Discovery là một quá trình liên tục (Continuos Discovery) và để tối ưu các đội sản phẩm nên thực hiện test mỗi 1 tuần hoặc 1 test mỗi 2 tuần.
Outsourced Discovery: Nhiều đội sản phẩm giao phó việc Discovery cho các bên tư vấn hoặc agency bên ngoài. Nếu các nhóm luôn dựa vào nguồn lực bên ngoài, kiến thức về khách hàng có được từ Discovery sẽ không được tích lũy. Học hỏi hiệu quả nhất đến từ tương tác trực tiếp với khách hàng, không phải qua báo cáo từ các bên thứ ba.
Tổng hợp từ nhiều nguồn tài liệu của SVPG
Thế nào là Product Discovey hiệu quả?
Để làm tốt trong giai đoạn Product Discovery là việc không dễ nhưng tìm ra giải pháp thật sự để giải quyết vấn đề cho khách hàng và doanh nghiệp của bạn là một việc cực kỳ quan trọng. Do vậy, mọi người có thể sử dụng các ý dưới đây như một checklist khi Discovery:
● Việc khám phá sản phẩm yêu cầu một mindset cởi mở
● Việc khám phá sản phẩm giải quyết rủi ro khi xây dựng sản phẩm
● Việc khám phá sản phẩm cần được thực hiện bởi tất cả phòng ban (cross-functional)
● Việc khám phá sản phẩm yêu cầu sự đánh giá (judgment)
● Việc khám phá sản phẩm ưu tiên sự học hỏi nhanh chóng
● Việc khám phá sản phẩm cần phối hợp dùng nhiều kỹ thuật khác nhau
● Việc khám phá sản phẩm là một quá trình lặp lại liên tục (continuous discovery)
Tổng hợp từ nhiều nguồn tài liệu của SVPG
Bạn muốn thảo luận thêm?
Bạn có câu hỏi hoặc muốn đóng góp thêm ý kiến về Product Discovery hay đơn giản chỉ muốn kết nối có thể liên hệ với mình qua email eileen.ngocmai@gmail.com 😀
Hãy like và ăn ủng hộ nhà hàng mình để có tiền mời các tác giả ăn uống nhé
Cộng Đồng Job To Be Done:
Bùi Thị Ngọc Mai (Eileen)
Hay quá
cám ơn tác giả đã chia sẻ