Làm Sao Để Xây Dựng 1 MVP Trong 3 Tháng Bằng JTBD?
Xây dựng tinh gọn và nhanh chọn 1 MVP trong 3 tháng nhưng vẫn Customer Centric
Hello anh em! Lại mình đây. Đây sẽ là bài viết số 2 của mình về đề tài Product. Trước đấy mình có 1 bài viết về nhu cầu khách hàng: Unlocking Customer Needs
Sau 3 ngày mình đăng bài thì cũng tiếp cận được khoảng 500 lượt xem và nhận được nhiều feedback từ bạn bè trong cộng đồng. Ở bài viết này mình cũng sẽ viết ngắn gọn và súc tích hơn để anh em có thể có hứng thú đọc. Okay, vào bài viết thôi.
Lưu ý: bài viết này được dựa trên phiên bản gốc tháp Product-Market Fit của tác giả Dan Olsen trong quyển The Lean Product Playbook và mốc thời gian “3 tháng” cho 1 MVP (Minimum Viable Product) là được các tác giả Product nổi tiếng khác gợi ý là tốt nhất. Dĩ nhiên, có vài công ty sẽ hoàn thành sớm hơn như 2 tháng hoặc lâu hơn là 6 tháng. Nhưng các dự án trước đây của mình từng làm qua thì không quá 3 tháng. Vì việc build 1 MVP quá dẫn tới chi phí cơ hội sẽ mất đi rất cao (Cost of Delay theo WSJF). Với việc launch 1 MVP sớm giúp mình nhận feedback sớm của Customer từ đấy giúp chúng ta có sự cải thiện sớm hơn để có thể tiến tới Product-Market Fit. Các sách các bạn có thể tham khảo để build 1 MVP mình để cuối bài viết cho anh em nhé!!!
Trước hết cần hiểu MVP là gì đã nhé! Theo Eric Ries định nghĩa MVP là:
“It is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least amount of effort.”
“Đây là phiên bản của một sản phẩm mới cho phép một nhóm thu thập được lượng thông tin tìm hiểu đã được xác thực tối đa về khách hàng với ít nỗ lực nhất.”
Tại sao lại cần 1 MVP để thu thập lượng thông tin tối đa từ khách hàng các bạn PO PM hoặc Product Designer đã tự hỏi chưa? Nếu chúng ta xem việc xây dựng 1 sản phẩm để kiếm tiền như là 1 trò chơi. Chúng ta nghĩ rằng đi từ điểm A (ý tưởng) đến điểm B (sản phẩm kiếm được nhiều tiền) là 1 đường thẳng thì đấy chỉ là mơ mộng và lý thuyết. Còn thực tế chúng ta gặp rất nhiều các ma sát về khó khăn trong việc cạnh tranh ở thị trường cũng như nhu cầu của khách hàng thay đổi liên tục theo thời gian. Nên điểm A để đến điểm B chúng ta cần sẽ phải điều chỉnh liên tục trong ngắn hạn thay vì cứ nghĩ rằng đi 1 mạch thẳng và chúng ta đi lạc khỏi điểm B lúc nào không hay.
Làm sao để xây dựng 1 MVP một cách tinh gọn?
Đây là câu hỏi khi mình mới bắt đầu vào 1 dự án mới toanh thời ở Onpoint. Lúc đấy các sếp giao cho mình 1 dự án mới toanh và chưa có trên thị trường quá nhiều. Dự án đấy khá là khó và to vì nó không chỉ liên quan tới Digital Product mà còn liên quan tới Physcial Product, Service Product, Logistic, Operation,… Dĩ nhiên, dự án đó cũng fail vì thời điểm đó mình chưa có kinh nghiệm xây bài bản cũng như đo lường và xác định Unmet Needs của khách hàng. Nên hy vọng bài viết này sẽ giúp các bạn phần nào.
Mình vô tình biết tới tháp Product-Market Fit do Dan Olsen khi đọc quyền The Lean Product Playbook. Và mình ước mình có thể apply nó “chuẩn” nó hơn. Vì hồi đấy tập tành apply cho dự án nhưng vẫn fail nhiều lắm. Nhất là tầng 2 là tầng mình gặp khó khăn nhiều. Vì thời điểm đấy khái niệm Job To Be Done chưa quá thịnh hành ở Việt Nam hoặc có thịnh hành mà mình chưa được tiếp cận tới. Hãy đến ý nghĩa của từng tầng (mình hay gọi là layer)
Target Customer: khách hàng tiềm năng của bạn là ai?
Underserved Needs: Nhu cầu chưa được phục vụ của tệp khách hàng tiềm năng là gì?
Value Proposition: Giá trị đề xuất mà công ty bạn tạo và cung cấp cho khách hàng là gì?
Feature Set: Bộ tính năng nào bạn cần ưu tiền để bạn có thể xây dựng trong MVP là gì?
UX: Làm sao bạn giúp cho user trải nghiệm tốt hơn trên sản phẩm của bạn là gì?
Launch MVP: sau khi xây dựng thì launch sản phẩm và lấy feedback sớm để cải thiện liên tục
Ví dụ đơn giản cho các bạn về MVP của Grab khi mới launch tại Việt Nam đi.
Target Customer: Grab thấy rằng tệp khách hàng chấp nhận sớm (Early Adopter) là dân văn phòng có nhu cầu đi lại nhiều. Họ có thu nhập vừa phải nhưng lại cũng có nhu cầu đi lại thường xuyên hơn.
Underserved Needs: Tệp văn phòng thường hay di chuyển từ điểm ở nhà tới công ty. Vì họ cảm thấy khá lười khi phải di chuyển bằng xe máy riêng. Nên họ hay bắt taxi hoặc xe ôm để di chuyển. Nhưng ngoài chi phí cao của các phương tiện truyền thống ra thì họ phải đứng chờ rất lâu để vẫy taxi hoặc gọi điện lên tổng đài. Các bác tài xế xe ôm thì hay hét giá cũng như lai lịch không rõ ràng nên sẽ nguy hiểm cho các khách hàng nữ.
Value Proposition: Grab mới thấy vậy nên muốn tạo giá trị cho khách hàng là giúp khách hàng giảm thời gian phải đứng bắt taxi cũng như giảm khả năng không rõ lai lịch của người tài xế. Đồng thời Grab minh bạch về giá giúp khách hàng an tâm không bị lo lắng về việc chém giá.
Feature Set: Grab thấy rằng tính năng mới đầu để test xem nhu cầu của tệp khách hàng này có thực sự giống như đưa từ giả thuyết (value proposition) phía trên không?
Grab tiến hành xây dựng các tính must have như đăng nhập vào app
Tính năng nổi trội hơn đối thủ (performance) như giá tiền và đường đi từ điểm A tới điểm B
Tính năng có hay không có cũng được (delighter) thêm tiền tips cho tài xế (cái này mình đang ví dụ nên có thể tính năng này hồi ms launch MVP chưa có đâu.
UX: Grab thấy rằng khi dân văn phòng đặt app là đang đứng ở ngoài đường hoặc văn phòng khi chuẩn bị có nhu cầu di chuyển. Họ cần một trải nghiệm đơn giản nhất có thể và thấy chắc rằng tài xế đã nhận được cuốc của họ. Như vậy Grab quyết định xây dựng một app có thể giúp tệp user này có thể dễ dàng đặt được xe và hiển thị đoạn đường của họ đặt.
Grab launching và thu thập feedback và thấy rằng việc tài xế di chuyển tới không biết còn bao lâu để họ có thể canh di chuyển khi đang ở trên văn phòng công ty. Như vậy ở phase sau Grab tiến hành xây dựng tính năng này.
Nhưng vấn đề khi mình làm theo mô hình tháp này thì trở ngại đầu tiên là làm sau tôi xác định được Underserved Needs khi mà sản phẩm quá mới hoặc có quá nhiều sản phẩm trên thị trường. Trở ngại thứ 2 là làm sao mapping được từ Needs của khách hàng để đề xuất giá trị cho khách. Trở ngại cuối cùng khi xây dựng Product Backlog để chạy Agile thì làm sao xác định được tính năng nào nên cho vào và không nên cho vào để run MVP.
Ở dưới có 1 case study của bọn mình apply trong cuộc thi Hackathon của Zalo tổ chức 1 cuộc thi là hoàn thiện 1 sản phẩm có thể sử dụng trên app mô phỏng đơn giản là code xong rồi, nhưng chỉ trong 24 tiếng mà thôi. Đề tài của bọn mình chọn là app: “Kết nối những người có nhu cầu đặt sân tập thể thao và kết nối thành viên khi bị thiếu thành viên trong đội” Ví dụ mọi người muốn đá bóng mà thiếu 1-2 ông thì khó có thể đá nên kiếm người đá chung. Business Model này thật ra mình thấy không ổn nhưng do các members trong team mình vote nên mình follow theo thôi 😊))) Anh em tham khảo cách trình bày thôi.
Bọn mình sử dụng phiên bản Lean Job To Be Done cho phần tìm Underserved Needs
Bọn mình sử dụng Value Proposition Canvas đề xác định giá trị đề xuất cho khách hàng
Để thiết lập backlog bọn mình sử dụng Kano Model và Value / Effort (cái này phù hợp MVP chứ ở làm các tập đoàn mình hay dùng công thức khác)
Và bọn mình xem 24 tiếng như là 3 tháng để launch sản phẩm (~ 6 Sprints trong đấy 1 Sprint làm Product Discovery và 5 Sprints để release sản phẩm). Bọn mình cũng tiến hành tạo Sprint Backlog và Sprint Review, Sprint Retrospective. Thay vì có Daily Meeting thì tụi mình có Hourly Meeting 😊))))
Ở phần giải pháp thì Brainstorm và Sketch cũng như dot voting để chọn cho lẹ
😊)) Mình cũng sử dụng BPMN 2.0 để thiết kế user flow để cover nhiều flow của user trải nghiệm hơn
Và dĩ nhiên còn hàng chục bước nữa nhưng mình chỉ show cơ bản cho mọi người thôi. Ở dưới là bản final của tụi mình
Bài viết tới đây là hết rùi. :D Nhớ chia sẻ cho bạn bè vào để mình có động lực viết các bài viết mới nữa
Mình có 2 công ty: 1 công ty về Education, 1 công ty về cửa hàng đồ ăn. Bạn nào ở HCM có thể qua ăn ủng hộ :D
Cộng Đồng Job To Be Done:
Các kênh và group có tên “Job To Be Done Viet Nam” hoặc Job To Be Done VN” hầu như là của mình nên mọi người search là ra.