Friday, November 11, 2016

Từ build sản phẩm đến mang lại giá trị

From building products to solving problems

Nhiều khách hàng đến gặp chúng tôi để được tư vấn về sản phẩm miêu tả rất chi tiết về việc họ muốn một sản phẩm như thế nào, nhưng lại không trả lời được câu hỏi: người dùng có muốn sản phẩm đó hay không, nó giải quyết được vấn đề gì cho người dùng, nó đem đến những trải nghiệm khác biệt như thế nào so với các sản phẩm đối thủ khác.

Nói dễ hiểu hơn, khách hàng đưa ra yêu cầu kiểu như “bên Anh/chị đang muốn làm sản phẩm thế này, có cái này, cái này thị trường không có v.v…” Đủ các loại tính năng nổi bật! Và trong khi nghe một list dài vô tận những yêu cầu đó, chúng tôi nghĩ: Hay đấy, nhưng vì sao người dùng phải quan tâm đến sản phẩm này? Khách hàng tập trung vào feature quá nhiều, nhưng vẫn loay hoay không biết cách tương tác thế nào với người dùng và cũng không biết người dùng tương tác thế nào với sản phẩm. Đối với người làm tư vấn sản phẩm như chúng tôi, đây là một dạng nhiệm vụ bất khả thi (không phải là không làm được, nhưng làm xong không biết ai sẽ xài).
Câu hỏi đặt ra: Nếu không chỉ khách hàng sai lầm, mà các thành viên phát triển sản phẩm cũng tập trung hết mức làm cho ra cái sản phẩm… không biết xài làm sao, thì chuyện gì xảy ra?
Sai lầm chung của chúng ta là: Ta quá chú trọng tới cái ta làm hơn là giá trị thực nó mang lại cho người sử dụng. Là người nghĩ ra sản phẩm, build sản phẩm, ta dễ yêu thương đứa con tinh thần của mình, dễ hứng khởi trong việc kiến tạo nó hoàn hảo như ý ta muốn mà chưa thực sự thấu hiểu đối tượng trực tiếp thụ hưởng: người dùng. Ta quên mất — vì người dùng, vì giải quyết vấn đề của người dùng — sản phẩm của ta mới có lý do ra đời.
Hãy luôn nghĩ về giá trị chúng ta có thể mang lại (impact) hơn là cái chúng ta đã build. Nguyên tắc này chính là User-Centric Design trong “Dev Team’s Bible” :)
Ở Scott, chúng tôi có một format làm việc để đảm bảo rằng team không “phạm quy”. Đó là quy trình để trước hết là tìm đúng vấn đề, sau đó mới đến việc giải quyết vấn đề. (Vì — bạn biết đó, trả lời đúng cho một câu hỏi sai cũng đâu để làm gì).
Để di64n giải dễ hiểu hơn, tôi xin đưa ra một số ví dụ:
Ví dụ như Trello, nếu tiếp cận theo kiểu cũ: chúng tôi là ai, chúng tôi có gì hay v.v… thì trông nó sẽ thế này:
Trello là một công cụ cộng tác, tổ chức dự án dưới dạng bảng, danh sách và thẻ. Mỗi dự án thường được tập hợp trên một bảng, gồm các cột danh sách chủ đề công việc chứa các thẻ nêu lên đầu việc cần làm. Người dùng tương tác với các thẻ và cột thông tin trên Trello chủ yếu thông qua hình thức kéo thả .
Nói thật đi, đọc xong bạn có phản ứng kiểu như “Ừ, rồi sao? Vì sao tôi phải quan tâm? Cái này có giá trị gì với tôi?” không? Vấn đề ở chỗ nó không cho thấy lý do vì sao Trello được ra đời, Trello thì giải quyết được việc gì?
Cũng là sản phẩm đó, thử đặt vấn đề theo kiểu khác xem có khác gì không nhé:
Đối với nhóm những người làm dự án, Trello là công cụ quản lý nhằm phối hợp các công việc một cách hiệu quả để giúp người trong nhóm cần nhìn qua đã biết có các đầu việc nào, ai đang là người chịu trách nhiệm công việc đó, làm tới giai đoạn nào. Khác với JIRA vốn một công cụ quản lý phức tạp và đòi hỏi thời gian học lâu, Trello đơn giản, dễ học và linh hoạt giúp đội nhóm có thể dễ dàng ứng dụng vào nhiều loại hình dự án và tính chất công việc khác nhau.
Cùng một câu chuyện, nếu tâp trung vào vấn đề cần giải quyết (thay vì build cái gì )thì chúng ta có thể thấy được một bức tranh toàn diện hơn:
  • Liệu với mục tiêu đó, giải pháp đó có là đúng hay chưa?
  • Nhu cầu này là có thật không?
  • Với nhu cầu này thì nên build gì là thích hợp….
Chỉ là cách đặt vấn đề khác, cùng một lúc, mọi thông tin được kiểm tra chéo, rõ ràng hiệu quả hơn nói đơn thuần về giải pháp. Chúng tôi gọi đó là “problem statement” (tự hào bổ sung thêm: hàng tự thiết kế cho team nhà xài trước, nay chia sẻ với anh em) — Để viết được một problem statement như trên, thật ra vô cùng đơn giản, nó như thế này:

Dễ ợt, chỉ cần dựa theo format này, điền các yếu tố cần thiết vào chỗ trống là đã tạo được một problem statement. Problem statement được thiết kế để cùng lúc nêu lên: đối tượng sử dụng, phân khúc thị trường, đặc điểm nhận diện và lợi thế cạnh tranh độc nhất (USP), những thông tin này có phù hợp với nhau hay không (cross check).




Cũng là câu chuyện của Trello lúc nãy, so sánh trực tiếp với format của problem statement
Một ví dụ khác từ Amazon




Chúng ta thấy tuy Trello là một công cụ digital, và Amazon dash button là một nút vật lý, cách tiếp cận vấn đề đều giống nhau. Điều này làm tôi nhớ lại một câu hỏi của khán giả trong Product meetup #4: “Product mindset của các bạn đang nói tới có thể dùng cho những sản phẩm vật lý/cho ngành sản xuất phần cứng không?” Ví dụ này là một minh chứng cho tính tổng quát của các công cụ mà Scott đang xây dựng.
Hai ví dụ vừa rồi là những cách sử dụng căn bản của problem statement.
Câu hỏi tiếp theo là: “Tôi sẽ phải viết problem statement thế nào nếu tôi có một sản phẩm có nhiều đối tượng người dùng khác nhau, hay giải pháp của chúng tôi giải quyết cùng lúc nhiều vấn đề, lợi thế cạnh tranh của chúng tôi là thứ không ai trong thị trường thực sự giải quyết được tốt?”
Problem statement này có thể ứng dụng cho các trường hợp phức tạp hơn không? Hãy cùng xem ví dụ dưới đây (của một sản phẩm trông quen quen).




Instagram đưa ra một giải pháp mà hai đối thủ của họ không giải quyết được rốt ráo. Lợi thế cạnh tranh của họ là độc nhất vì họ là bên có thể giải quyết được cả một chuỗi hành vi từ A đến Z.
Họ ứng dụng problem statement này thế nào? Rất đơn giản: phần nào cần mở rộng thì họ sẽ viết thêm phần đó, đương nhiên vẫn bám theo sát format. Đã nói về đối thủ thì phải nói rõ về lợi thế cạnh tranh của họ, sau đó mới nói về lợi thế cạnh tranh tổng hợp của mình.
Tương tự, nếu sản phẩm của bạn giải quyết vấn đề cho 2 nhóm đối tượng khác nhau (chẳng hạn như giải quyết vấn đề cho cả người bán và người mua và bạn là platform), thì bạn chỉ cần viết vế đầu hai lần, cứ như vậy mà nhân lên cho đến khi chúng ta đảm bảo được mình nêu ra được đúng vấn đề mình cần giải quyết.
Có thể thấy, các team với các sản phẩm thành công đều tiếp cận theo hướng “giải quyết vấn đề” chứ không cố gắng “build sản phẩm” và hướng người dùng theo đó. Với những kinh nghiệm build sản phẩm tương tự cách đặt vấn đề này, Scott tổng hợp lại và xây dựng ra bộ công cụ của riêng mình để giúp việc nắm bắt các phương pháp này được dễ dàng và nhanh nhất để mọi team đều có thể dùng được, tập trung giải quyết đúng vấn đề của người dùng (lại là nguyên tắc User-centric design).
Trước khi đi tiếp, chúng ta hãy so sánh before/after một lần nữa câu chuyện product statement và problem statement




Quảng cáo: nếu bạn thích bài viết này thì ngoài bấm like ra bạn cũng có thể đăng ký để nhận những bài viết tương tự của Scott đến tận hộp mail cá nhân tại đây

Nâng cao lên chút xíu

Nếu gặp phải những sản phẩm ra đời để giải quyết những vấn đề rất khác nhau cho những nhóm đối tượng khác nhau, và cũng có những lợi thế cạnh tranh khác nhau cho từng nhóm đó thì sao? Phần này thì team Scott chờ comment của anh em, có ai đang phát triển sản phẩm gặp vấn đề tương tự không, mọi người định giải quyết nó thế nào, gặp khó khăn gì?

Một số lưu ý với problem statement:

  1. Problem statement không phải là thứ để viết 1 lần, bạn có thể phải viết và chỉnh sửa phần này nhiều lần trong quá trình làm sản phẩm. Cũng có thể chỉ đơn giản vì problem statement đầu tiên của chúng ta chưa có đủ thông tin và cần chỉnh sửa thêm
  2. Để viết được problem statement tốt, chúng ta cần phải có đủ các nguyên liệu cần có trước khi bắt tay vào viết. Cẩu thả đưa ra những giả định cho phần quan trọng bậc nhất này không phải là một ý hay.
  3. Đánh giá problem statement không dựa vào độ hay ho, độ “kêu” của nó mà độ xác thực. Hãy mang PS của bạn tham khảo với nhiều góc nhìn để ngày càng hoàn thiện nó.
  4. Problem statement không chỉ dành cho cả sản phẩm, mà có thể áp dụng cho từng dự án bên trong sản phẩm. Cách tiếp cận cũng tương tự cho problem statement của sản phẩm nhưng hãy để PS của dự án cùng với sản phẩm để đảm bảo dự án của bạn sẽ góp phần giải quyết vấn đề chung của sản phẩm.
Chốt lại (cho dễ nhớ), đây là một công cụ giúp người làm sản phẩm nhìn thấy những yếu tố quan trọng nhất của một vấn đề cần giải quyết, và nhờ vậy giải quyết đúng trọng tâm — hiệu quả nhất. Điểm đặc biệt nữa là Proble Statement của Scott được cố tình thiết kế sao cho đơn giản dễ xài nhất — ngay trong lần đầu tiên. Giống như đạp xe đạp vậy, đã biết cách rồi thì từ đó về sau không sợ quên nữa. Đây cũng là tiêu chí quan trọng mà chúng tôi đặt ra khi thiết kế mọi công cụ làm việc cho Dev team, và những công cụ quan trọng nhất sẽ được chia sẻ trong THE SHIFT. Đây là một chương trình mà Mos và Trevoe Wettman cùng xây dựng với mục tiêu phát triển tư duy sản phẩm cho các Dev Team nhanh nhất (tức là học nhanh, áp dụng nhanh, giỏi nhanh).
Nguồn :  từ đây

Buy me a coffee