Ghi chép podcast Hiếu TV
Không chính thức

20/04/2020 · 24 phút · Sự nghiệp

The product tower

Bài giảng chuyên môn năm 2020 giới thiệu "product tower", khung tư duy nhiều tầng mà anh Hiếu dùng để đánh giá một sản phẩm hay một doanh nghiệp. Khung đi từ thị trường mục tiêu, phân khúc, persona, nhu cầu, nhu cầu chưa được đáp ứng, tới tuyên bố giá trị, product–market fit, tính năng, rồi UX, UI và kỹ thuật, minh họa bằng Airbnb và ví dụ đóng tàu đánh cá.

Mô hình "product tower" 0:00

Anh Hiếu giới thiệu một mô hình anh gọi là product tower — một khung tư duy (framework) theo thứ tự từng lớp mà anh dùng mỗi khi cần đánh giá (review) một sản phẩm, thậm chí cả một công ty; gọi vậy vì hình dáng giống một tòa tháp xếp chồng. Minh họa bằng Airbnb vì ai cũng biết công ty này hoạt động thế nào — số liệu chỉ để minh họa, có thể không chính xác 100% với mô hình kinh doanh thật của Airbnb. Mô hình có 13 lớp (trước đây 11, gần đây anh thêm hai lớp).

1. Thị trường mục tiêu (target market) — gốc rễ của bất kỳ doanh nghiệp nào. Với Airbnb là ngành du lịch, không phải logistics hay ngân hàng. Hai điều quan trọng nhất khi chọn: hiểu biết chuyên môn của mình về lĩnh vực đó — phải hiểu đúng mới nhận ra vấn đề đang tồn tại và đưa ra được giải pháp; xét cho cùng, một doanh nghiệp là đưa ra giải pháp cho một vấn đề và người dùng trả tiền cho giải pháp đó, còn mọi khía cạnh khác chỉ xoay quanh cốt lõi này — và độ lớn của thị trường, điều nhiều người chỉ chăm chăm vào điểm thứ nhất mà quên mất: thị trường quá nhỏ thì dù thành công chiếm lĩnh được nó vẫn không đủ duy trì doanh nghiệp, lại phải loay hoay tìm thị trường khác. Kể cả thị trường nhỏ, phân tích độ lớn cũng giúp biết giới hạn của mình để chuẩn bị phù hợp.

2. Phân khúc thị trường (market segmentation) — ví dụ năm phân khúc: trẻ em, người trẻ, gia đình, du lịch công tác (business travel), du lịch cao cấp (luxury). Rồi loại bỏ những phân khúc mình không muốn phục vụ — trẻ em thường đi cùng gia đình hay nhà trường, chỗ ăn ở đã được sắp xếp — và không thể phục vụ — khách luxury đòi hỏi rất cao, trong khi mô hình của Airbnb dùng phòng, nhà của người khác, có thể không đáp ứng được, dẫn tới trải nghiệm tệ. Phần còn lại là tập khách hàng tiềm năng.

3. Persona người dùng — hồ sơ đại diện cho những nhóm khách hàng có cùng hành vi và cùng mục tiêu (goal) khi dùng sản phẩm. Thường khoảng 80% persona phản ánh các phân khúc ở bước 2, nhưng không trùng 100%: phân khúc chia theo tiềm năng kinh doanh, còn persona chia theo hành vi và mục đích sử dụng — nghiên cứu một lượng mẫu đủ lớn sẽ hình thành các nhóm hành vi (rành thiết bị số, hay rất kém dùng điện thoại) và các nhóm mục tiêu (đặt phòng càng nhanh càng tốt, hay càng rẻ càng tốt). Có người nằm trong hành trình khách hàng (customer journey) mà không thuộc phân khúc nào: khách công tác có khi tự đặt phòng trên Airbnb, có khi do thư ký hay phòng hành chính đặt giúp — nhóm thư ký, hành chính không phải khách hàng mục tiêu nhưng là đối tượng quan trọng trong hành trình, bắt buộc phải có persona cho họ.

4. Nhu cầu người dùng (user needs). Có bức tranh rõ ràng về người dùng mới bắt tay nghiên cứu: phỏng vấn (interview), quan sát họ trong môi trường thực, rút ra thông tin giá trị — quan trọng nhất là nhu cầu. Khi đi du lịch, khách tiềm năng cần: nơi ở, phương tiện đi lại, bảo hiểm du lịch, thông tin đánh giá về nơi sẽ tới, hoạt động để làm, nơi ăn uống, hướng dẫn viên, vé máy bay, đổi ngoại tệ... rồi xếp theo thứ tự ưu tiên — ở đây nơi ở là quan trọng nhất.

5. Nhu cầu chưa được đáp ứng (underserved needs) — nhu cầu người dùng cần nhưng đang không được dịch vụ hiện có phục vụ tốt; một thuật ngữ rất quan trọng. Cách xác định là đi ngược: loại những nhu cầu đã được phục vụ tốt — đi lại thì Uber đã làm rất tốt, Airbnb không nên nhảy vào; đánh giá điểm đến thì TripAdvisor đã làm quá tốt, muốn thì nên hợp tác — và loại những nhu cầu nằm ngoài năng lực của mình — bảo hiểm dù rất quan trọng nhưng Airbnb không phải công ty bảo hiểm; tương tự vé máy bay, đổi ngoại tệ. Còn lại là nhu cầu chưa được phục vụ tốt và nằm trong khả năng của mình — ta tin có thể phục vụ tốt hơn thị trường — đó là cơ hội kinh doanh.

6. Tuyên bố giá trị (value proposition) — giá trị ta mang tới để giải quyết vấn đề người dùng đang gặp. Khớp được value proposition với nhu cầu chưa được đáp ứng dẫn tới một khái niệm cực kỳ quan trọng, không chỉ trong làm sản phẩm mà cả điều hành doanh nghiệp: product–market fit. Đó là tín hiệu cho rất nhiều quyết định chiến lược — tới lúc phải quyết định công ty có nên bước vào giai đoạn tăng trưởng mạnh (growth) không, câu trả lời phụ thuộc vào việc đã tìm ra product–market fit chưa; chưa có mà dồn sức vào tăng trưởng thì "càng tăng càng chết".

7. Sản phẩm và bộ tính năng (feature set). Có value proposition rồi mới nghĩ cần sản phẩm gì, tính năng gì. Ví dụ Airbnb quyết định có hai sản phẩm: Airbnb cho gia đình, và Airbnb mảng trải nghiệm (Experiences), với các tính năng như danh sách chỗ ở (listing), nổi bật, đặt phòng...

8. Thiết kế trải nghiệm (UX) — nhờ đi qua những tầng nền vững chắc, UX lúc này phục vụ một mục đích lớn hơn: giải quyết một vấn đề cụ thể cho người dùng, chứ không chỉ làm ra một trải nghiệm đẹp. Tiếp đó là thiết kế giao diện (UI), rồi front-end, back-end và các phạm trù kỹ thuật.

Ai phụ trách tầng nào

  • Bộ phận kinh doanh (business) quyết định các tầng móng: thị trường nào, phân khúc nào, khách hàng nào — trả lời câu hỏi why: vì sao làm việc này (thị trường tiềm năng, đủ lớn, mình có khả năng chiếm lĩnh).
  • Quản lý sản phẩm (product management) phụ trách từ khoảng tầng nhu cầu tới tầng tính năng — trả lời câu hỏi what: làm gì để chiếm lĩnh thị trường đó. Mô tả công việc của họ: nắm sâu người dùng, nhu cầu và nỗi đau (pain points) của họ, cộng hiểu biết về đối thủ và năng lực của chính doanh nghiệp, để quyết định xây chức năng, sản phẩm nào có xác suất thành công cao nhất.
  • UX, UI, kỹ sư trả lời câu hỏi how: làm ra nó như thế nào.

Mỗi đội có tầng trách nhiệm chính, nhưng nên hiểu càng sâu xuống bên dưới càng tốt, và biết một phần tầng trên — product manager không trực tiếp làm UX nhưng nên hiểu UX; UX designer cần hiểu vấn đề mình đang giải quyết và mô hình kinh doanh của công ty, đồng thời hiểu UI để chắc thiết kế của mình hiện thực hóa được; UI designer cần hiểu UX và lập trình front-end để thiết kế có thể xây được — hiểu để hỗ trợ đội khác, không phải để giẫm chân lên chuyên môn của họ. Suốt quá trình phải liên tục quay lại kiểm chứng giả thuyết (validate hypotheses) với người dùng — không đợi tới khi có wireframe hay giao diện mới thử, mà thử được từ tầng sâu bên dưới, như kiểm chứng value proposition khi chưa có sản phẩm. Vì vậy nghiên cứu người dùng (user research) là đội chạy dọc cả tòa tháp để phối hợp với các đội — đó mới là cách làm user-centred development.

Ví dụ đóng tàu

Làm một sản phẩm mới giống đóng một con tàu: chủ hãng tàu là hội đồng quản trị, người điều hành hãng là CEO, đội vận hành sản phẩm sau khi xây xong là thuyền trưởng và thủy thủ đoàn. Product manager am hiểu việc đóng tàu đi bắt cá: nhận chiến lược "năm nay đi bắt cá ở vùng Nam Cực" thì đưa ra yêu cầu — tàu phải phá được băng, giữ ấm cho thủy thủ, có thiết bị đánh bắt chuyên dụng cho vùng biển đó, đủ bao nhiêu xuồng cứu hộ. UX designer phân tích yêu cầu đó để thiết kế cấu trúc, bố cục con tàu dễ điều khiển, dễ vận hành, giúp thủy thủ làm việc hiệu quả nhất — ví dụ kéo một mẻ cá lên trước phải qua bốn công đoạn, giờ chỉ còn hai; đồng thời đưa yêu cầu xuống bộ phận kỹ thuật — như tốc độ tàu phải đạt bao nhiêu hải lý mỗi giờ (chỉ nói tốc độ cần đạt, không chỉ định gắn loại máy nào — đó là chuyên môn của đội kỹ thuật — nhưng phải giải thích vì sao, chẳng hạn muốn bắt một loại cá nhất định thì cần đạt tốc độ đó). UI designer trực tiếp thiết kế bảng điều khiển: hình dạng cần gạt, cách bố trí, nút bấm sao cho dễ bấm, dễ hiểu, dễ dùng. Trong suốt quá trình đóng tàu phải liên tục mời những người sẽ sử dụng con tàu tới trải nghiệm thử và ghi nhận phản hồi — trách nhiệm của đội user research và phân tích dữ liệu. Tất cả xoay quanh nhu cầu của người sử dụng.