Cách package một sản phẩm SaaS mới

1. Hai cách làm packaging cho SaaS

Ulrik Lehrskov-Schmidt mở đầu thẳng vào chủ đề: packaging cho sản phẩm SaaS, và đây là cách làm. Theo Ulrik (video đăng ngày 05/04/2023), có hai cách để làm packaging cho một sản phẩm SaaS. Cách thứ nhất anh gọi là bottom-up và data-driven (đi từ dưới lên, dựa trên dữ liệu). Cách thứ hai anh gọi là top-down và conceptually-driven (đi từ trên xuống, dựa trên khái niệm).

Anh nói sẽ đi qua cả hai cách, ít nhất là theo cách anh làm cho khách hàng của mình, rồi nói một chút về cách anh dùng chúng cùng nhau để có một quy trình còn mạnh hơn (video đăng ngày 05/04/2023).

2. Vì sao làm packaging: price discrimination

Trước khi vào chi tiết, Ulrik dành khoảng 20 giây để nói vì sao chúng ta làm packaging. Theo anh (video đăng ngày 05/04/2023), câu trả lời khá đơn giản: làm để kiếm nhiều tiền hơn. Và cách packaging giúp kiếm nhiều tiền hơn là dùng nó để price discriminate khách hàng: tính các mức giá khác nhau cho các khách hàng khác nhau, vì không phải khách hàng nào cũng muốn mua toàn bộ sản phẩm của bạn.

Anh lấy ví dụ (theo video đăng ngày 05/04/2023): có những khách hàng, nếu phải mua cả sản phẩm, sẽ không biết làm gì với nó, rồi sẽ đòi giảm giá. Họ sẽ nói: "Anh đưa tôi 100 feature, tôi chỉ cần 20, nên tôi muốn được giảm 80%", và cứ thế.

Ulrik so sánh với máy bay (video đăng ngày 05/04/2023): không phải ai cũng được ngồi hạng thương gia. Có người chỉ muốn ngồi hạng phổ thông, vì họ không quan tâm tới champagne và những thứ gì đó được phục vụ ở hạng thương gia. Cũng không sao: bạn có thể có cùng một năng lực bên dưới, nhưng mang tới những trải nghiệm và phiên bản sản phẩm khác nhau cho những khách hàng khác nhau, nhờ đó khai thác được những phân khúc thị trường khác nhau với mức giá phù hợp.

Theo Ulrik (video đăng ngày 05/04/2023), packaging chỉ có vậy. Nó là một cách để bạn tiếp cận khách hàng. Nó không có gì liên quan tới bản chất của sản phẩm hay giải pháp của bạn; nó là cách sản phẩm được giao tới những khách hàng khác nhau.

3. Bottom-up: kiểm kê ba loại feature

Cách thứ nhất là bottom-up, hay data-driven packaging. Theo Ulrik (video đăng ngày 05/04/2023), có rất nhiều cách để làm việc này, nhưng anh sẽ đi qua cách đơn giản nhất, có thể làm chỉ với một cuộc khảo sát, cách mà anh nghĩ phần lớn người xem đều dùng được và phần lớn chưa biết là có tồn tại.

Bước đầu tiên, theo anh (video đăng ngày 05/04/2023), là làm một bản kiểm kê (inventory) tất cả các feature của bạn. Anh chia làm ba loại: functional feature, service feature và commercial feature.

Functional feature, theo Ulrik (video đăng ngày 05/04/2023), không phải là "xuất được CSV, xuất được cái này, xuất được cái kia". Nó là câu trả lời cho một câu hỏi khách hàng sẽ hỏi, kiểu: "Nó có export không?", và bạn đáp: "Có, nó có đủ mọi kiểu export." Nên khi mô tả một feature, hãy nhắm tới một selling point ở mức cao, giống một gạch đầu dòng trên trang pricing, thay vì mô tả 50 hay 100 thành phần chức năng khác nhau của sản phẩm. Anh khuyên nhắm tới khoảng 8 tới 12 functional feature ở mức cao.

Service feature, theo anh (video đăng ngày 05/04/2023), là những thứ như premium onboarding, support, support 24/7, 365 ngày, gì cũng được. Nó cũng có thể là "chúng tôi làm migration giúp bạn". Anh thường nói service feature là những gì bạn làm để giúp khách hàng dùng được các functional feature. Support không phải là thứ khách hàng muốn tự thân nó; nó là một sự bảo đảm, một sự chắc chắn mà khách hàng có được rằng bạn sẽ giúp họ khai thác giá trị từ phần chức năng của giải pháp.

Cuối cùng là commercial feature (theo Ulrik, video đăng ngày 05/04/2023): điều khoản thanh toán, điều khoản huỷ, mọi thứ nằm trong terms and conditions, tức cách bạn cấu trúc thương vụ quanh những gì khách hàng đang tìm.

4. Cảm xúc tích cực và tiêu cực là hai thang riêng

Có ba loại feature trong tay rồi, Ulrik đề nghị nhận ra điều sau (video đăng ngày 05/04/2023): cảm xúc tiêu cực và cảm xúc tích cực không phải là cùng một thứ nằm trên một thang đi từ 0 lên dương và từ 0 xuống âm. Chúng về bản chất là hai thứ khác nhau. Bạn đang làm việc với hai thang: một thang đi từ trung tính tới hào hứng, tích cực, "tôi muốn cái đó"; và một thang tiêu cực đi từ trung tính tới "tôi thật sự rất ghét cái đó".

Theo Ulrik (video đăng ngày 05/04/2023), nhận thức rằng cảm xúc tiêu cực và tích cực là hai thứ khác nhau, chứ không phải một thứ trên một thang lớn đi từ cộng sang trừ, đã được nhắc đi nhắc lại suốt những năm 1950; anh nói vậy là gần 80 năm trước. Anh nghĩ người đầu tiên làm các nghiên cứu về động lực, xem vì sao nhân viên có động lực, là Herzberg.

5. Herzberg: hygiene factor và động lực

Theo lời Ulrik kể (video đăng ngày 05/04/2023), Herzberg về cơ bản phát hiện ra rằng có những thứ là hygiene factor. Người ta muốn có một môi trường làm việc dễ chịu, nhưng đó là thứ mà nếu có, họ không có động lực hơn, họ chỉ không bị mất động lực. Còn nếu họ có một nhiệm vụ đáng làm, thứ thật sự khiến họ muốn đi làm, như đưa một trạm vũ trụ lên sao Hoả hay đại loại vậy, thì đó mới là thứ tạo động lực thật sự. Và nếu không có một nhiệm vụ đáng làm, họ không thấy bất hạnh, họ chỉ trung tính.

Anh lấy ví dụ công việc ở các tổ chức NGO (theo video đăng ngày 05/04/2023): ở đó có rất nhiều yếu tố tạo động lực mạnh, kiểu "chúng tôi làm vì lý tưởng, vì mục đích, và đó là lý do chúng tôi có mặt". Nhưng cũng thiếu rất nhiều thứ mà Herzberg gọi là hygiene factor: lương thường không tốt lắm, môi trường làm việc không tốt lắm, v.v. Nên cũng có rất nhiều yếu tố gây căng thẳng. Ở những công việc như NGO, ít nhất là kiểu NGO theo khuôn mẫu, bạn có tác động lớn cả ở phía tích cực lẫn phía tiêu cực: thiếu nhiều hygiene factor, lương thì tệ, nhưng nhiều yếu tố tích cực thì thật sự phát huy.

So với một công việc văn phòng nhàm chán, nơi mọi thứ đều ổn (theo Ulrik, video đăng ngày 05/04/2023): "Vì sao mình làm việc này nhỉ? Không biết nữa, nhưng lương tốt và đồ ăn trưa ngon." Ở đó có rất ít tác động ở cả phía tích cực lẫn tiêu cực. Theo anh, việc nhìn vào hai yếu tố này là một phát hiện thật sự của Herzberg.

6. Kano model và hai loại câu hỏi khảo sát

Theo Ulrik (video đăng ngày 05/04/2023), sau đó, anh nghĩ là vào những năm 80, ý tưởng này được một giáo sư trường kinh doanh người Nhật tên là Kano tiếp nhận. Kano đã tạo ra cái gọi là Kano model.

Về cơ bản, theo cách Ulrik thuật lại Kano (video đăng ngày 05/04/2023): bạn lấy tất cả các feature vừa kiểm kê, rồi khảo sát khách hàng tiềm năng, hỏi họ hai loại câu hỏi cho mỗi feature. Anh nói bạn có thể Google "Kano model survey" để xem cách cấu trúc nó.

Loại câu hỏi thứ nhất, theo anh (video đăng ngày 05/04/2023), là: bạn sẽ cảm thấy mạnh tới mức nào nếu feature này có trong sản phẩm? Anh lấy ví dụ một feature như AI data migration; người được hỏi chấm từ 0 tới 5. Đây là câu hỏi cảm xúc tích cực: feature có mặt.

Loại thứ hai là câu hỏi cảm xúc tiêu cực (theo Ulrik, video đăng ngày 05/04/2023): bạn sẽ cảm thấy thế nào nếu feature này không có trong sản phẩm? Rồi cũng chấm trên một thang. Theo anh, điều Kano muốn làm là hỏi: nếu nó có thì bạn thấy thế nào, so với nếu nó không có? Chính sự tương phản giữa có mặt và không có mặt là thứ chạm tới cảm giác "ồ, tôi thích cái đó và nó có giá trị với tôi", hoặc "tôi không thích, và nó không có giá trị gì với tôi".

7. Ma trận hai chiều và nhóm Doesn't Matter

Theo Ulrik (video đăng ngày 05/04/2023), nếu lấy cảm xúc tích cực, tức khi feature có mặt, đặt lên một trục từ "tôi không quan tâm kiểu nào cũng được" tới "tôi rất quan tâm", và lấy cảm xúc tiêu cực, tức "tôi không quan tâm" tới "tôi rất quan tâm nếu nó không có", rồi vẽ ra, bạn sẽ có một sơ đồ hai nhân hai nhỏ. Sẽ có những feature rơi vào ô "tôi rất quan tâm nếu nó có và nếu nó không có", rồi những ô khác, v.v.

Một trục là độ mạnh của phản ứng trên thang từ một tới năm nếu feature có mặt, trục kia là độ mạnh từ một tới năm nếu feature không có (theo video đăng ngày 05/04/2023). Nếu ai đó chấm năm, năm thì đó là một kiểu. Nếu chấm một, một thì không ai quan tâm gì cả, dù feature có hay không. Bạn cắt ma trận này thành bốn góc phần tư, và ở mỗi góc bạn có thể nói các feature trong đó là gì và chúng nên xuất hiện thế nào trong packaging của bạn.

Ulrik bắt đầu với góc dễ thấy trước (video đăng ngày 05/04/2023): không có phản ứng nào cả. Đó là nơi các feature trở nên vô thưởng vô phạt. Ví dụ trên thang từ một tới năm, với phần lớn khách hàng nó không được chấm cao hơn hai. Không ai thật sự quan tâm nếu nó có, và không ai thật sự quan tâm nếu nó không có.

Vậy thì vì sao bạn lại có feature này? Theo Ulrik (video đăng ngày 05/04/2023), nó đúng nghĩa là bạn có thể bỏ nó đi mà không ai để ý, hay thêm nó vào mà cũng không ai để ý. Nó chỉ chiếm chỗ, và bạn nên bỏ nó đi, hoặc ít nhất đừng quảng cáo là nó có. Nó có thể chìm vào phần chức năng còn lại, và bạn không cần bận tâm về nó nữa.

8. Must-have, differentiator và add-on

Góc tiếp theo, theo Ulrik (video đăng ngày 05/04/2023), là những feature mà người ta nói: nếu nó không có, tôi sẽ phản ứng rất mạnh; nhưng nếu nó có, họ không phản ứng mạnh, kiểu "ừ, cũng được". Anh lấy ví dụ các feature bảo mật. Hỏi: "Bạn có quan tâm không nếu phần mềm này hoàn toàn không an toàn?" Người ta đáp: "Có, tôi rất quan tâm. Tôi cần dữ liệu của mình an toàn trong phần mềm của anh." Ngược lại hỏi: "Bạn có quan tâm không nếu phần mềm này an toàn?" thì họ đáp: "Không hẳn. Tôi cứ mặc định là nó đã có sẵn."

Theo anh (video đăng ngày 05/04/2023), góc này dành cho must-have: tất cả các feature cơ bản phải có trong mọi package. Đó là những feature mà nếu khách hàng không có, họ có phản ứng tiêu cực mạnh, nhưng cũng không có phản ứng tích cực mạnh. Đây là những feature bạn cần cho thấy là mình có, nhưng bạn không bán được chúng. Chúng không tạo ra nhu cầu nào.

Góc trên, nơi người ta có phản ứng mạnh ở cả hai đầu, là premium feature của bạn, theo Ulrik (video đăng ngày 05/04/2023). Chúng là những yếu tố tạo khác biệt (differentiator). Anh nói thêm rằng đó là theo lý thuyết Kano, còn anh thật ra có xu hướng không đồng ý một chút. Đây là những feature mà khi hỏi "nếu chúng tôi không có cái này, bạn có quan tâm không?", người ta nói có; và khi hỏi "nếu chúng tôi có cái này, bạn có quan tâm không?", người ta cũng nói có. Đó là premium feature, những thứ phân biệt gói basic của bạn với gói premium. Vậy là bạn đã có những feature phải nằm trong gói basic, và những feature nên nằm trong gói premium.

Góc cuối cùng, theo Ulrik (video đăng ngày 05/04/2023), là những feature mà khi hỏi "nếu feature này không có, bạn có quan tâm không?", người ta nói "không"; nhưng nếu feature có mặt thì họ lại rất quan tâm. Đó là add-on của bạn. Với những feature này, khi hỏi "bạn có muốn cái này không?", câu trả lời là có, nó tạo ra nhiều nhu cầu; nhưng nếu bạn không đưa nó vào bất kỳ gói basic nào, tức phần sản phẩm lõi bạn đang cung cấp, bạn cũng không làm khách hàng nào chùn bước.

Theo anh (video đăng ngày 05/04/2023), đây là công cụ khảo sát chọn feature cơ bản nhất hiện có, và nó gắn rất khớp với cách bạn package một sản phẩm SaaS. Quy trình là: kiểm kê feature, đặt các câu hỏi khảo sát này, gửi cho người trả lời, nhận lại kết quả, rồi vẽ chúng lên sơ đồ về độ mạnh cảm xúc theo hai mặt "nó có" và "nó không có". Từ đó bạn có một ý niệm sơ bộ về những gì không cần bận tâm, đâu là các feature basic lõi, đâu là premium feature, và đâu là add-on.

Ulrik nói (video đăng ngày 05/04/2023) anh sẽ nhận xét một chút về suy nghĩ của mình về Kano model, nhưng là sau khi đi qua cách packaging thứ hai, thứ anh gọi là bản top-down.

9. Top-down: jobs to be done của Clayton Christensen

Theo Ulrik (video đăng ngày 05/04/2023), bản top-down về cơ bản là package quanh jobs to be done. Jobs to be done do Clayton Christensen, một giáo sư ở Harvard Business School, đưa ra. Anh nói Christensen mất cách đây vài năm, nhưng ông là một nguồn ý tưởng rất hay đã thật sự thay đổi cách chúng ta nghĩ về kinh doanh. Ông cũng là cha đẻ của khái niệm disruption, và anh nghĩ disruption là thứ ông được biết tới nhiều hơn cả: ai cũng nói về disruption, và Clayton là người viết cuốn sách và đặt ra lý thuyết đó.

Nhưng theo Ulrik (video đăng ngày 05/04/2023), anh nghĩ đóng góp lớn hơn của Christensen là khái niệm "job". Câu chuyện về cách ông đi tới lý thuyết jobs, theo lời anh kể, là khi ông đang làm việc, anh nghĩ là với vai trò partner ở McKinsey, và nhóm của ông làm một dự án cho McDonald's.

10. Câu chuyện milkshake của McDonald's

Theo câu chuyện Ulrik kể (video đăng ngày 05/04/2023), McDonald's đang cố bán milkshake và đã làm rất nhiều phân tích thống kê về product feature và customer feature. Customer feature, bạn có thể hình dung, là demographics, giới tính, loại thẻ tín dụng họ dùng, loại xe họ lái, tất cả những gì McDonald's biết về khách hàng. Còn ở phía product feature là độ ngọt của milkshake, độ lợn cợn, nhiệt độ, kích cỡ, v.v.

Họ đã làm đủ kiểu phân tích thống kê công phu xem đâu là cấu hình milkshake tối ưu để bán cho kiểu khách hàng tối ưu (theo Ulrik, video đăng ngày 05/04/2023). Nhưng họ chưa thật sự tạo ra đột phá. Họ làm được những tinh chỉnh và cải tiến nhỏ, nhưng chưa tìm ra được thứ gì thật sự chiếm lĩnh thị trường milkshake.

Clayton và nhóm nhận ra điều này, và trong một nỗ lực gần như là cuối cùng, họ nói: thử nói chuyện với khách hàng xem (theo lời Ulrik kể, video đăng ngày 05/04/2023). Thay vì chỉ sắp xếp mọi dữ liệu có được về khách hàng, hãy thật sự nói chuyện với họ: khi họ mua milkshake và bước ra khỏi cửa hàng, chặn họ lại và hỏi vì sao bạn mua milkshake đó, bạn thấy nó thế nào, và bạn còn cân nhắc mua những thứ gì khác.

Họ làm vậy và phát hiện ra rằng nhóm mua milkshake hoá ra là đàn ông ở độ tuổi 30 và 40. "Ai mà ngờ được, đúng không?", Ulrik nói (video đăng ngày 05/04/2023). Và họ thường mua vào buổi sáng và buổi chiều.

Khi được hỏi vì sao mua milkshake, vào buổi sáng những người này nói (theo lời Ulrik kể, video đăng ngày 05/04/2023): "Tôi có một quãng đường dài đi làm, và tôi chán vì nó mất nhiều thời gian, có lẽ tôi cũng hơi đói, nên tôi cần một món ăn vặt. Vậy là tôi ghé McDonald's. Tôi có thể lấy cà phê, hay một quả chuối, hay thứ gì khác, nhưng tôi chọn milkshake, vì nó kéo dài được lâu và tôi thấy hơi no. Sau khi ăn hay uống xong milkshake, nó cho tôi một thứ để ăn và giữ tôi không chán suốt một tiếng lái xe. Đó là điều tôi đang cố giải quyết."

Cà phê thì kéo dài được một tiếng, nhưng không no, tới chỗ làm vẫn đói; còn quả chuối thì ăn trong xe dễ bẩn, và hết trong hai phút (theo lời kể trong video đăng ngày 05/04/2023). Nên milkshake là thứ anh ta chọn để giải quyết job này. Theo Ulrik, đó chính là ý tưởng về một job: có một ý định rõ ràng về một việc tôi đang cố làm xong trong một tình huống.

Tua nhanh tám hay chín tiếng sau, cùng buổi chiều đó, cùng người đàn ông ấy bước vào cùng cửa hàng McDonald's (theo lời Ulrik kể, video đăng ngày 05/04/2023). Giờ anh ta có hai đứa con ở ghế sau. Anh vừa đón chúng và đang trên đường về nhà, và trẻ con thì là trẻ con, chúng nghịch khắp nơi. Anh ta đang cố "mua chuộc" chúng bằng McDonald's: "Được rồi các con, bố mua cho mỗi đứa một ly milkshake, rồi các con cho bố khoảng 20 phút để gọi một cuộc điện thoại, hay xong nốt việc trong ngày, hay gì cũng được, cho bố yên một chút." Đó là cuộc trao đổi anh ta định làm với lũ trẻ.

Ý ở đây, theo Ulrik (video đăng ngày 05/04/2023), là người đàn ông đó không cần cùng một ly milkshake trong cả hai tình huống, vì anh ta đang giải quyết một job khác. Buổi sáng anh muốn milkshake lạnh, đặc, cỡ lớn, có khi còn lợn cợn, và có lẽ thật ra cũng không ngọt lắm. Đó là lựa chọn sản phẩm, lựa chọn feature ngược hẳn với thứ anh muốn vào buổi chiều. Vì nếu bạn đưa cho một đứa trẻ năm tuổi một ly milkshake cỡ lớn, rất lạnh, rất lợn cợn, không ngọt lắm, nó sẽ ngồi đó cả tiếng đồng hồ cố uống cho hết. Thứ bạn muốn là nó không bẩn, và xong trong khoảng 10 phút, vì đó là khoảng nghỉ bạn cần.

Theo lời Ulrik kể (video đăng ngày 05/04/2023), nhóm đã bỏ hẳn toàn bộ phân tích về khách hàng là ai và họ sẽ nói gì. Họ nhận ra rằng khách hàng cũng sẽ trả lời khảo sát khác đi tuỳ theo job mà họ đang "thuê" milkshake làm cho mình, tuỳ theo tình huống họ đang ở.

Ulrik gọi đó là một câu chuyện dài, và rút ra (video đăng ngày 05/04/2023): đôi khi việc phân tích product feature, customer attribute và câu trả lời khảo sát chỉ kéo chúng ta sa vào chi tiết vụn vặt, vì ta quên hỏi câu hỏi lõi: khách hàng đang cố giải quyết điều gì? Vì sao họ ở đây, họ đang mua gì? Họ mua một khoảng nghỉ, như buổi sáng, hay mua một kiểu nghỉ khác cho con mình, vốn là một kiểu sản phẩm khác?

11. Đóng gói quanh point of first demand

Ulrik kể cách anh thường áp dụng điều này vào packaging (video đăng ngày 05/04/2023): ta đã có tất cả các feature, vì ta vẫn làm cùng bản kiểm kê commercial feature, service feature và functional feature như trước, và như vậy là ổn, cứ làm. Ta vẫn cần đóng chúng thành package hay module hay gì đó, nhưng tạm để sang một bên. Rồi tự hỏi: đâu là động lực nhu cầu lõi (core demand driver) đang đưa khách hàng tới cửa? Họ đang cố làm xong việc gì?

Anh lấy ví dụ (theo video đăng ngày 05/04/2023): có thể ai cũng muốn nói chuyện với bạn về predictive maintenance, vì đó là một thành phần rất lớn trong sản phẩm của bạn. Tuyệt. Vậy hãy tạo package đầu tiên và gọi nó là predictive maintenance. Rồi nhìn vào tất cả product feature, functional feature, service feature, v.v., và hỏi: đâu là tập feature tối ưu để giải quyết predictive maintenance? Lấy những feature đó vào, và đó là package đầu tiên của bạn. Anh gọi nó là point of first demand.

Theo Ulrik (video đăng ngày 05/04/2023), điều bạn đang thật sự làm là dựng một offering cộng hưởng với demand generation, với marketing và với các lead bạn có, để có thể chốt được thương vụ. Và điều xảy ra ở đây là bạn có thể lấy job, giải pháp và vấn đề mà bạn đã package quanh nó, rồi bắt đầu tự hỏi: thứ này đáng giá bao nhiêu với khách hàng?

12. Vì sao cách chia theo feature khó trả lời câu hỏi giá

Đây là chỗ Ulrik bắt đầu so sánh hai mô hình (video đăng ngày 05/04/2023). Theo anh, câu hỏi "thứ này đáng giá bao nhiêu" rất khó trả lời bên phía Kano model và việc chia nhỏ feature. Ở đó bạn nói: ta có tất cả những must-have feature rơi vào góc này của khảo sát; bạn kéo chúng ra rồi hỏi khách hàng muốn trả bao nhiêu cho chúng. Và bạn không biết, vì đây là cách nhìn lấy sản phẩm làm trung tâm. "Giờ tôi có bảy feature nằm trong góc này. Chúng đáng giá bao nhiêu với ai đó?" Bạn không biết, vì bạn không biết họ dùng chúng vào việc gì, không biết vì sao họ mua những feature đó.

Theo Ulrik (video đăng ngày 05/04/2023), thiếu mối liên hệ đó, điều bạn đang làm là cố định giá sản phẩm, thay vì định giá khách hàng, vốn là điều ta đang làm. Toàn bộ ý nghĩa của packaging là price discrimination giữa các khách hàng: cố tìm ra họ muốn mua gì. Nên cách làm data-driven, survey-driven, preference-driven hay usage-based cho packaging cũng ổn, nếu bạn còn nhớ hỏi: vì sao họ làm vậy?

13. Job tiếp theo và trục mở rộng

Điều Ulrik thường làm (video đăng ngày 05/04/2023) là chạy quy trình jobs trước: tìm ra job to be done lõi, đó là point of first demand, và package quanh nó cho tốt. Theo anh, đừng bận tâm nếu bạn kéo cả những feature cao cấp và premium nhất của mình vào package cơ bản nhất này. Như vậy là ổn, nó sẽ giúp bạn, vì người ta thật sự muốn thứ này, và bạn có thể tạo ra giá trị trong offer đó.

Rồi bạn tự hỏi (theo Ulrik, video đăng ngày 05/04/2023): nếu tôi giải quyết cho khách hàng job đầu tiên mà họ mang tới cửa, ví dụ predictive maintenance, thì job tiếp theo của họ sẽ là gì? Bạn có thể nói: nếu giải quyết xong predictive maintenance, job tiếp theo sẽ là kiểu đi vào vận hành và tối ưu vận hành. Tuyệt. Giờ ta đã gỡ được, có thể nói, chướng ngại lớn nhất cho hiệu quả của khách hàng, thứ họ đang tìm: mọi thứ đều hỏng hóc, nên họ muốn predictive maintenance. Khi đã giải quyết và giảm thiểu vấn đề đó, vấn đề tiếp theo trong danh sách việc của họ, theo ta nghĩ, là operations management.

Vậy ta có thể làm gì với operations management từ chồng feature của mình để tạo thành một package xây tiếp trên package đầu (theo Ulrik, video đăng ngày 05/04/2023)? Có thể ta cần nghĩ ra feature mới: nếu phải giải quyết operations management, ta cần làm một dashboard thế này, hay một chức năng làm việc kia. Tuyệt. Theo anh, giờ bạn đang đổi mới sản phẩm, chính là vậy. Nhưng mỗi lần đổi mới, bạn đổi mới quanh các nguồn nhu cầu: khách hàng đang cố làm xong việc gì, và tôi đáp ứng điều đó thế nào?

Theo Ulrik (video đăng ngày 05/04/2023), khi bắt đầu đặt một chuỗi những câu hỏi như vậy, bạn sẽ thấy đây là một nhiệm vụ thiết kế, không phải một bài phân tích dữ liệu định lượng. Đây là công việc thiết kế: bạn cố hiểu khách hàng và việc họ làm, rồi cố làm ra thứ vừa với họ. Nó giống thiết kế một cái ghế. Khi người ta ngồi vào, họ sẽ biết nó tốt hay tệ. Và bạn có thể có ý niệm, nhờ hiểu khách hàng và cách họ ngồi, xem nó tốt hay không. Nhưng không có thứ gọi là một cái ghế tối ưu, "cái đó là cái quái gì chứ?", anh nói. Chỉ có ghế tốt và ghế tệ, và với mục đích của ta thì thế là đủ.

Theo anh (video đăng ngày 05/04/2023), thường thì các package sẽ hình thành một trục phát triển (development axis). Ulrik nghĩ ra một phần mềm ngay lúc đó để làm ví dụ: point of first demand là "chúng tôi muốn có dữ liệu này". Tiếp theo: "thường khi giải quyết được cái này, chúng tôi muốn làm advanced modeling với dữ liệu". Và khi giải quyết được cái đó: "chúng tôi muốn làm advanced modeling trong các team lớn hơn, chia sẻ mọi model và cộng tác". Vậy là ta có một trục dọc theo sản phẩm, một trục mở rộng (expansion axis) đi theo độ tinh thông và độ trưởng thành của khách hàng.

Theo Ulrik (video đăng ngày 05/04/2023), đó thường là cách những thứ này diễn ra: nếu bạn bắt đầu với point of first demand, khách hàng tìm gì khi bước qua cửa của tôi, rồi vấn đề tiếp theo, vấn đề tiếp theo nữa, thì đó thường là nơi bạn có expansion. Khách hàng sẽ lớn dần dọc theo trục này theo một cách có logic về khái niệm khi bạn giải quyết từng vấn đề cho họ. Và có những khách hàng bước vào khi đã ở cao hơn trên chuỗi đó: họ đã tinh thông rồi, nên họ cần kiểu vấn đề này.

14. Giới hạn của việc định lượng jobs to be done

Theo Ulrik (video đăng ngày 05/04/2023), vấn đề của jobs to be done là nó mơ hồ. Nếu Google "jobs to be done theory", bạn sẽ thấy nhiều người sau Clayton Christensen đã cố chia nó thành một bài tập data-driven. Họ nói đã làm các phương pháp khảo sát, phương pháp phỏng vấn, và cố biến tất cả thành những phép đo jobs to be done có thể tính toán, định lượng được. Anh nói bạn có thể làm vậy ở một mức nào đó. Nhưng nếu bạn bị lạc, thấy cây mà không thấy rừng, thì bạn đang bỏ lỡ điểm chính.

Ulrik cũng nêu một điểm (video đăng ngày 05/04/2023): anh nghĩ Christensen đã có 10, 15 năm trước khi mất làm việc với lý thuyết jobs to be done, cùng rất nhiều nghiên cứu sinh tiến sĩ, học viên cao học và các giáo sư khác, và ông chưa bao giờ thật sự phát triển một framework định lượng cho lý thuyết jobs. Anh nghĩ đó là vì ở một mức độ nào đó, làm vậy thật ra không phù hợp.

Theo anh (video đăng ngày 05/04/2023), có một xu hướng rất mạnh là lấy cách tiếp cận data-driven rồi dựa vào nó quá nhiều. Vì con số không nói dối, đúng không? Ý tưởng là nếu ta làm hết mọi việc thì sẽ có câu trả lời, và điều đó gỡ bớt nỗi lo và trách nhiệm khỏi ta, những người ra quyết định và thiết kế sản phẩm, vì ta có thể dựa vào dữ liệu.

Ulrik nói đó cũng là lý do giới tư vấn rất thích cách này (video đăng ngày 05/04/2023): họ có thể nói "chúng tôi đã chạy đủ mọi phân tích, có hàng đống dữ liệu, đã làm đủ mọi thứ, đã làm khoảng 200 cuộc phỏng vấn jobs to be done, đây là kết quả định lượng và bạn xem tất cả các biểu đồ này". Theo anh, điều đó rất tốt để bán các dự án tư vấn quy mô lớn, nhưng chưa chắc tốt cho việc tạo ra những sản phẩm SaaS bán được.

Anh gợi ý đọc cuốn sách gốc, anh nghĩ tên là Competing Against Luck (theo video đăng ngày 05/04/2023). Theo Ulrik, cuốn sách thật ra hoàn toàn là về việc hiểu mặt khái niệm của chuyện này, và anh nghĩ trong đó không có phép đo định lượng nào. Không phải vì các tác giả không giỏi những thứ đó, mà vì họ nghĩ đó là cách tiếp cận sai để chạm tới một thứ như thế này.

15. Kết hợp hai phương pháp khi làm cho khách hàng

Ulrik kể cách anh thường kết hợp hai phương pháp trong công việc thực tế với khách hàng (video đăng ngày 05/04/2023). Anh và nhóm làm bản kiểm kê feature để hiểu mình đang làm việc với cái gì. Rồi làm quy trình jobs: khách hàng đang mua gì? Theo anh, đôi khi nó đơn giản vậy thôi: hai tiếng trò chuyện ở mức tổng quát với đúng người trong tổ chức có thể làm rõ: ta đang mua gì ở đây, ta đang bán gì, vì sao khách hàng tìm tới ta? Rồi anh và nhóm làm point of first demand, rồi nguồn nhu cầu tiếp theo, nguồn nhu cầu tiếp theo nữa, làm rõ và xác định một trục. Sau đó mới nhìn vào feature, chọn chúng vào, có khi nghĩ ra vài feature mới, và thế là tốt.

Theo Ulrik (video đăng ngày 05/04/2023), đôi khi, nếu có năng lực để làm, hay có đủ lượng phản hồi khảo sát tốt, anh và nhóm cũng chạy một Kano survey, hoặc những loại khác như conjoint survey, hay loại gì đó, "gọi là gì cũng được", để nắm sở thích về feature và độ mạnh của chúng. Nhưng thực tế thì hiếm khi nó quan trọng tới vậy, vì nó gần như tách rời khỏi phía marketing, phía nhu cầu, phía câu chuyện (narrative), v.v.

Nên thường thì, theo Ulrik (video đăng ngày 05/04/2023), thứ bạn có được là sanity check phần jobs, tức phần định tính, bằng phần định lượng. Ví dụ bạn đã nghĩ ra một packaging dựa trên jobs, rồi chạy một Kano survey, và không thể làm hai thứ khớp với nhau: vậy là bạn có vấn đề. Thông thường điều nên xảy ra là những feature bạn đưa vào cũng được dữ liệu khảo sát ủng hộ. Rồi bạn có thể đi làm các cuộc phỏng vấn kiểm chứng (validation interview) và những việc khác để hiểu vì sao. Anh nói trong thực tế anh dùng cách data-driven chủ yếu để kiểm chứng packaging dựa trên jobs ở một bước nhất định.

Theo Ulrik (video đăng ngày 05/04/2023), một cách dùng khác là cách data-driven có thể khá tốt trong việc tìm ra roadmap feature. Nếu ta có 10 feature chưa biết xử lý ra sao, kiểu ta có thể làm một tính năng sign-on cho enterprise, hay cái tính năng encryption kia, hay một widget feature nào khác đang cân nhắc, thì chạy Kano survey để thật sự làm rõ: đây là thứ người ta mặc định ta đã có, hay là thứ thật sự thúc đẩy nhu cầu premium, hay là thứ hợp làm add-on hơn, tức có khách hàng rất thích nhưng sẽ không bận tâm nếu ta không có nó. Rồi ta có thể dùng phương pháp khảo sát làm đầu vào cho roadmap.

Nhưng theo anh (video đăng ngày 05/04/2023), sẽ không hợp lý nếu bạn không có packaging dựa trên jobs làm nền bên dưới để trả lời: vì sao ta phát triển những feature này? Ta đang cố giúp khách hàng làm xong việc gì với chúng? Ulrik nói đó thường là cách anh chạy packaging.

16. Khác với các hãng tư vấn lớn

Theo Ulrik (video đăng ngày 05/04/2023), cách này khác với khi bạn tìm tới Simon-Kucher, McKinsey, Bain hay bất kỳ hãng tư vấn nào kiểu đó, vì, như anh đã nói, họ được trả tiền theo giờ. Nên nếu họ có thể đưa một team vào xây những bộ dữ liệu lớn, làm thật nhiều phân tích trên đó và cho bạn xem kết quả, thì cách đó được coi là best practice: dữ liệu nằm ngay đó, và cứ thế.

Và bạn có cảm giác như mình đang làm rất nhiều việc. Nhưng Ulrik lập luận (video đăng ngày 05/04/2023) rằng bạn vẫn chưa làm phần việc khái niệm thật sự: tìm ra khách hàng muốn gì. Anh nói: hãy bắt đầu từ đó, rồi dùng cách kia như một add-on.