Tiếp cận để hiểu rõ hơn cam kết với khách hàng
Bài đăng này đã không được cập nhật trong 6 năm
Bài viết sau đây là của Hadrien Raffalli - Labs PM tại Pivotal Tokyo. Ông mô tả cách nhận biết các cam kết khác nhau từ phía khách hàng để làm rõ MVP có thực sự khả thi không.
Tôi rất thích ý tưởng đó. Hãy cho tôi biết khi nào các sản phẩm sẵn sàng được bán ra và tôi sẽ mua chúng.
Với nhiều nhóm sản xuất, câu nói trên có vẻ như rất tuyệt. Mọi người cảm giác rằng những giả thiết của mình đã được thừa nhận, và điều này cho cả nhóm động lực để tiếp tục phát triển sản phẩm.
Tuy nhiên cảm giác đấy có thể chỉ là mơ mộng, vì bạn có quá ít bằng chứng cho thấy đó là sự thật. Bạn không thể biết liệu rằng sản phẩm của mình có tạo ra doanh thu hay không, khách hàng của mình có sử dụng sản phẩm hay không, thậm chí sản phẩm này có thực sự hữu dụng cho họ hay không.
Trong bài viết này, tôi xin được trình bày một phương thức để nhận biết các cam kết khác nhau từ phía khách hàng cùng những thử nghiệm để xác nhận mà bạn cần chạy thử thật sớm để biết Minimum Viable Product (MVP) của bạn có hiệu quả hay không.
Rủi ro cam kết
Trong Lean Startup, Eric Ries định nghĩa một cam kết là một sự trao đổi về mặt giá trị giữa nhóm phát triển sản phẩm và khách hàng. Có được cam kết sớm và đầy đủ là cách lý tưởng để giảm thiểu rủi ro cho sản phẩm, gia tăng cho nhận định rằng khách hàng sẵn lòng chấp nhận sản phẩm của bạn.
Có một rủi ro vốn có trong bất kỳ mối quan hệ thương mại nào, và nó hiếm khi phân tán đồng đều trên phổ cung và cầu. Thuyết phục khách hàng cam kết với sản phẩm từ giai đoạn đầu là một trong những cách hữu hiệu nhất để xác định sớm được công việc bạn đang xây dựng sẽ mang lại lợi nhuận.
Ví dụ, nếu một khách hàng cấp vốn cho bạn khởi nghiệp trước khi bạn xây dựng được giải pháp, rủi ro là tối đa cho khách hàng. Ngược lại, nếu bạn cung cấp một MVP có thể hoạt động trước khi kiếm được tiền, rủi ro lại là tối đa dành cho nhóm phát triển sản phẩm của bạn. Nói một cách khác, bạn chờ đợi việc trao đổi giá trị càng lâu thì rủi ro càng nhiều cho bạn.
Tôi xin được minh hoạ hiện tượng này trong biểu đồ Viability Risk Map bên dưới:
Như đã trình bày ở trên, hình thức cam kết thấp nhất cho một nhóm sản phẩm là nghiên cứu (research) một vấn đề cụ thể. Để tìm phương án kinh doanh phù hợp, bạn nên chạy càng nhiều thử nghiệm chất lượng càng tốt với thời gian triển khai giới bạn. Mỗi thử nghiệm phải rẻ nhất có thể. Hình thức cam kết cao nhất là xây dựng một phần nhỏ (MVP) của phần mềm lớn với các hạ tầng kỹ thuật, pháp lý và thương mại để hỗ trợ nó.
Về phía khách hàng, hình thức cam kết thấp nhất là chấp nhận thảo luận (communication) với nhóm phát triển sản phẩm về các vấn đề và hoàn cảnh của họ. Một trong những loại cam kết cao nhất có thể là mua (purchase) MVP.
Hãy cùng tôi tìm hiểu các loại cam kết bạn có thể yêu cầu khách hàng, tùy thuộc vào độ chín của MVP.
Giảm thiểu rủi ro về tính khả thi
Có một MVP hoặc một prototype hoạt động được không đồng nghĩa với việc bạn có một sản phẩm kinh doanh khả thi trên tay. Ví dụ, nếu MVP của bạn đã có trên thị trường và khách hàng chỉ cam kết chấp nhận việc trao đổi với bạn (nghiên cứu, thông báo, email, v.v.), điều đó không có nghĩa là họ 100% sẽ trở thành người sử dụng cho sản phẩm của bạn. Điều tương tự cũng đúng nếu bạn nghiên cứu mà không thảo luận với người dùng của mình. Mặt khác, nếu bạn thu hút người dùng bằng mẫu thử trước khi phát hành, hoặc thậm chí pre-sale trước khi giải pháp được xây dựng hoàn chỉnh nghĩa là bạn đang giảm đáng kể rủi ro của riêng bạn.
Trong biểu đồ bên dưới, tập hợp các mức độ cam kết được đặt chồng lên trên Viability Risk Map, và tôi sẽ hướng dẫn cho bạn cách đánh giá tính khả thi ở từng giai đoạn
Research stage (Giai đoạn nghiên cứu)
Công việc của bạn đang ở giai đoạn này khi bạn đã có những nhận định về thị trường, sản phẩm và người dùng - nhưng bạn (vẫn) chưa có giải pháp. Việc xác nhận lại những giả thuyết của bạn với người dùng là rất có ích trước khi phát triển bản thử.
Discovery (Tìm hiểu)
Khi bạn tìm hiểu thị trường, sẽ có những khách hàng đã đối mặt với vấn đề mà bạn đang muốn giải quyết. Tại thời điểm này tất cả vẫn chỉ là một dấu hỏi, bạn không thể chắc chắn được họ sẽ sớm là khách hàng tiềm năng của mình hay không. Một khi phân chia được rõ đối tượng, bạn nên sớm đưa thử một phương án, và cố đạt được một cam kết thực sự. Có thể cam kết đó là cùng xây dựng giải pháp, hoặc cấp vốn cho ý tưởng của bạn. Với những khách hàng quyết định không hứa hẹn đi xa hơn, nên được liên lạc lại sau khi hoàn thành prototype. Có thể đối với họ thì thời điểm này là hơi quá sớm.
Partnership (Hợp tác)
Bạn có thể đánh giá sự hợp tác từ phía khách hàng khi thử yêu cầu về sự chia sẻ các dữ liệu quan trọng trong quá trình nghiên cứu. Nếu khách hàng thực sự hứng thú, họ sẽ cung cấp cho bạn thêm thông tin để quan sát xem bạn có thể đưa ra phương án tốt hơn bản demo hay không. Làm được điều này hiệu quả sẽ giúp hình thành một mối quan hệ hợp tác trên cơ sở cùng nhau giải quyết vấn đề đang gặp phải.
Rủi ro về phía khách hàng ở đây là tính cạnh tranh và tính pháp lý. Nếu có thể, hãy đề nghị ký thoả thuận NDA về bảo mật thông tin doanh nghiệp. Rủi ro về phía nhóm phát triển sản phẩm lúc này là việc không hoàn thành được cam kết, do không chắc chắn được phương án đề ra có khả thi với các dữ liệu và ràng buộc thực tế hay không.
Pre-sale (Tiền bán hàng)
Điều tuyệt vời nhất mà bạn có thể nhận được ở giai đoạn nghiên cứu, là được khách hàng đồng ý pre-sale ngay cả khi chưa tồn tại giải pháp. Lúc này, khách hàng sẽ cấp vốn cho bạn trước khi nhận được sản phẩm. Rủi ro của họ là rất lớn, vì ko rõ bạn có thể làm được hay không, thế nên một cam kết thế này thường rất khó để có được vào giai đoạn sớm thế này.
Bạn có thể chia sẻ rủi ro này cùng với khách hàng khi chịu trách nhiệm cam kết tư vấn đưa ra giải pháp cùng khách hàng. Nếu không được thì 2 bên cũng dễ dàng chấm dứt cam kết hơn.
Rủi ro về phía nhóm phát triển sản phẩm là việc không hoàn thành được cam kết đúng hạn cùng các đòi hỏi tuỳ biến (do đã nhận vốn từ khách hàng). Nếu bạn không thể bàn giao nổi sản phẩm ưng ý, uy tín của bạn sẽ bị ảnh hưởng lớn.
Giai đoạn Prototype và MVP sẽ được mô tả tiếp ở phần hai.
All rights reserved