Bài viết được dịch từ “S.I.M.P.L.E. before S.M.A.R.T.” của tác giả Tristan Kromer từ Grasshopper Herder Lean Startup Blog. Nội dung chính sẽ giới thiệu và so sánh 2 hướng tiếp cận trong việc xây dựng và phát triển các công cụ khảo sát khách hàng cho các startup đi theo hướng tinh gọn.
Lưu ý: Các khái niệm sẽ được giữ nguyên gốc bằng tiếng Anh và sẽ được người dịch chú thích bằng mẫu sau “(Tạm dịch: [Tiếng Việt] – ND)”. Mong các bạn thông cảm
1 . Khởi động
Nếu bạn là một bạn đọc quen thuộc của Lean Startup Blog, bạn có thể đã biết rằng chúng tôi có một mẫu (hơi phức tạp) (đây đang nói đến mẫu thiết kế khảo sát dạng S.M.A.R.T – ND) dùng cho việc thiết kế các khảo sát một cách hiệu quả. Và bạn cũng cũng có thể đã biết rằng chúng tôi khuyến cáo bạn bỏ qua nó và tự thiết kế một mẫu cho riêng bạn, 😉
Chúng tôi khá thích mẫu thiết kế khảo sát S.M.A.R.T của chúng tôi vì thế chúng tôi dùng nó khá nhiều, tuy nhiên với các startup mới làm quen với các nguyên tác của Lean, nó (mẫu S.M.A.R.T – ND) hoàn toàn quá mức cần thiết. Thiết kế một mẫu khảo sát (khách hàng) hiệu quả dường như là một quá trình tốn kém thời gian và dễ gây nản chí cho các founder, vì thế chúng tôi thường sẽ thiết kế một khảo sát “tồi” mà không sử dụng mẫu S.M.A.R.T để cho các team khởi đầu.
2. Velocity before Insights – Tay đi nhanh hơn Não
(Về tựa đề “Tay đi nhanh hơn Não” khi được dịch sang tiếng Việt, chúng tôi muốn nhấn mạnh về tầm quan trọng của việc xây dựng một quá trình tinh giản, dễ thực hiện mà tác giả muốn đề cập đến trong chương này.)
Một trong những nguyên tắc chúng tôi tập trung khi hướng dẫn các team mới đó là dựa trên Rudder Fallacy (tạm dịch: Ảo tưởng Bánh lái, đọc thêm bài viết của tác giả). Một các bánh lái không thể đổi hướng con thuyền nếu như con thuyền đó không hề chuyển động. Như vậy muốn điều khiển hướng đi của con thuyền việc đầu tiên là bắt đầu chèo
Với một nhóm đổi mới, hãy bắt đầu chạy thử nghiệm hơn là lo lắng về việc chúng ta có chạy thử nghiệm đúng hay thử nghiệm được thiết kế hoàn hảo hay không.
Chúng tôi luôn khuyến khích các team ra khỏi vùng an toàn, lắng nghe khách hàng và tạo nhanh trang web thử nghiệm – bất cứ điều gì để họ tiến lên phía trước. Chúng tôi khuyến khích các team khởi đầu bằng các buổi phỏng vấn khách hàng tồi, hỏi những câu hỏi sai và trở lại với bộ mặt bối rối hơn là dành cả tuần thiết kế một customer persona “hoàn hảo” cùng một cẩm nang hướng dẫn phỏng vấn và không gặp bất kì một khách hàng nào. Thông thường, ngay cả với các kỹ thuật phỏng vấn khủng khiếp nhất, một vài nhà đổi mới sẽ trở lại với sự tiết lộ rằng họ nên đặt câu hỏi về các giả định của họ. Và đó là cái nhìn mà họ cần: rằng họ có thể sai, rằng họ không biết nhiều như họ nghĩ.
Vì vậy, một MVP với phản hồi của khách hàng có thể có hiệu quả hơn một sản phẩm “hoàn hảo” chưa bao giờ chạm đến người dùng.
3. Bắt đầu từ thứ Đơn Giản
Từ những yếu tố đã bàn luận ở trên, chúng ta thường không nên dùng các phương án phức tạp (S.M.A.R.T) khi hướng dẫn các team mới. Hãy sử dụng vòng lặp Build – Measure – Learn. Nhưng lần này hãy sử dụng theo hướng ngược lại
Learn – Chúng ta đang cố học điều gì? Câu hỏi nào mà câu trả lời của khách hàng sẽ mang lại tiến bộ cho mô hình kinh doanh? Ví dụ như:
- Ai sẽ là khách hàng của chúng ta?
- Họ sẽ trả bao nhiêu cho dịch vụ/sản phẩm của chúng ta?
- Tính năng nào của chúng ta sẽ giải quyết vấn đề của họ?
Measure – Dữ liệu như thế nào, định tính hay định lượng sẽ giúp trả lời các câu hỏi trên? Chúng ta có cần một câu trả lời dạng “Có/Không” cho câu hỏi? Chúng ta có cần phải xem ai đó mua hàng không? Chúng ta có cần phải thấy một biểu hiện thích thú của khách hàng khi sử dụng sản phẩm của chúng ta không? Ví dụ như:
- Tỷ lệ chuyển đổi phần trăm trên landing page
- Những quan sát định tính và video kiểm tra khả năng sản phẩm (video review sản phẩm – ND)
- Dữ liệu nghiên cứu thị trường trên tổng thị trường
Build – Chúng ta cần gì để thu thập được các dữ liệu trên? Đâu là nỗ lực tối thiểu để có thể lấy được câu trả lời cho các câu hỏi của chúng ta? Ví dụ:
- Xây dựng 1 landing page
- Phỏng vấn khách hàng
- Xây dựng giải pháp theo hướng dịch vụ thay vì là sản phẩm
Các công thức đơn giản bên trên có thể nhanh chóng nắm bắt và sử dụng để thiết kế một thí nghiệm với khách hàng, quan trọng hơn là team sẽ không phải lo lắng về khả năng thất bại hay dừng sớm hay bất cứ điều gì cản trở team “get out of the building”.
Learn Simple
Từ các bàn luận bên trên đưa đến một mẫu thiết kế đơn giản hơn – một mô hình chỉ với 4 ô. Một lần nữa chúng ta lại đến với chu trình Build – Measure – Learn cùng với một điểm kết thúc là Result & Insight
- Learn -> Learning Goal – Câu hỏi cụ thể nào về dự án mà câu trả lời sẽ Liên quan đến khả năng tiến bộ của dự án?
- Measure -> Data – Dữ liệu định lượng hoặc định tính nào có thể Đo lường được mà chúng ta sẽ thu thập dữ liệu?
- Build -> Plan – Làm thế nào và khi nào chúng ta sẽ thu thập dữ liệu một cách kịp thời? Dữ liệu đó có thể đạt được?
Và với Result & Insight chúng ta sẽ có kết luận cho thí nghiệm của chúng ta, chu trình Build – Measure – Learn sẽ được thực hiện liên tục và sẽ kết thúc khi chúng ta đã có được dữ liệu cần thiết cho dự án
Simple = S.I.M.P.L.E
Bên cạnh mẫu thí nghiệm S.M.A.R.T (Specific – Cụ thể, Measurable – Đo lường được, Achievable – Có thể đạt được, Relevant – Liên quan, & Timebound – Mốc thời gian). Chúng tôi gọi mẫu thí nghiệm mới này là S.I.M.P.L.E (Small Insights Mean Progress with Lean Experiments – Tạm dịch: Những sự thấu hiểu nhỏ đồng nghĩa với việc tiến bộ thông qua những thử nghiệm tinh gọn – ND)
Bài học ở đây
- “Out of the building” quan trọng hơn là tạo ra một thử nghiệm hoàn hảo nhưng không kiểm chứng nó
- Đừng phụ thuộc hoàn toàn vào các templates – Don’t be a slave to templates
- Bắt đầu với S.I.M.P.L.E. và sau đó hãy tìm cách S.M.A.R.T. – Start S.I.M.P.L.E. and then figure out how to be S.M.A.R.T.
Tristan Kromer – Lean Startup Coach, Dịch bởi ThanhHo từ HCMUT-TBI
