Đó là vào năm 2012 và nhóm của chúng tôi vừa mới gia nhập Airbnb. Chúng tôi được yêu cầu xây dựng trải nghiệm “du lịch social” cho các khách hàng của Airbnb. Ý tưởng của trải nghiệm đó là các du khách của Airbnb đang ở cách nhau trên khắp thành phố, và nếu chúng tôi khiến việc gặp gỡ và tham gia các hoạt động cùng nhau trở nên dễ dàng hơn đối với các khách hàng, các chuyến đi của Airbnb sẽ có ý nghĩa hơn rất nhiều. Chúng tôi làm việc chăm chỉ trong một thời gian dài để thiết kế một trải nghiệm tuyệt vời cho du khách, giúp họ khám phá những hoạt động thú vị tại địa phương mà họ có thể tham gia với những du khách khác.

Hãy tua nhanh đến 6 tháng sau khi chúng tôi bắt đầu khởi động phiên bản đầu tiên của trải nghiệm tại San Francisco. Sản phẩm đẹp và trải nghiệm diễn ra suôn sẻ. Vậy nhưng, lượng tiêu thụ lại không lớn. Một phần nhỏ khách hàng thử sử dụng trải nghiệm và nói chung là phản ứng của các khách hàng cũng khá tích cực nhưng những điều này vẫn kém xa so với phản ứng mà chúng tôi mong đợi. We iterate a bit, make some incremental improvements, but a few months later we end it and move on.

Ở đây có ảnh - An early design of the product we launched, giving Airbnb travelers an easy way to find fun things to do with other travelers — designs courtesy of Shaun Modi

I personally took many learnings away from that experience, but most of all it instilled in me the importance of getting the problem statement right. Dù cho có rất nhiều yếu tố có thể góp phần vào sự thất bại của một dự án, không có gì có thể chắc chắn khiến một dự án thất bại hơn là cách hiểu sai về vấn đề cần được giải quyết.  Ở ví dụ bên trên, chúng tôi đã nhận ra rằng vấn đề thực sự chúng tôi cần giải quyết không phải “du khách muốn đi chơi với những du khách khác” mà là “du khách muốn tìm kiếm những hoạt động mới mẻ và có chất lượng cao” quá muộn. Đi chơi với những du khách khác là một giải pháp cho vấn đề này, chứ không phải bản thân vấn đề. May mắn thay, một nhóm khác đã nhận ra điều này và thực hiện được một giải pháp tốt hơn nhiều – Airbnb Experiences vài năm sau đó.

Như tôi đã nhắc tới trong bài viết lần trước, tôi hoàn toàn tin rằng giải quyết the problem statement là bước quan trọng nhất trong việc giải quyết bất cứ vấn đề nào. It’s deceptively easy to get wrong, and when done well it’s a superpower of the best leaders. May mắn là bạn chỉ cần ba bước đơn giản để hoàn thành việc đó:

Step 1: Crystallize the problem you are solving

Bước 2: Thống nhất với nhóm của bạn và các bên liên quan

Step 3: Keep coming back to the problem

“True happiness occurs only when you find the problems you enjoy having and enjoy solving.” — Mark Manson (Nghệ Thuật Tinh Tế Của Việc "Đếch" Quan Tâm)

A little bit of context first

Khung 3 bước này sẽ trở nên hiệu quả nhất khi bạn có ý tưởng về một dự án trong đầu, dù là về một sản phẩm hay một tính năng mới. Trước khi bạn bắt đầu việc thiết kế hay xây dựng, hãy thực hiện những bước này để tạo ra thành công cho dự án.

Nếu nhóm của bạn không có một tầm nhìn rõ ràng (ví dụ như về việc các bạn hướng tới điều gì) hay một chiến lược tổng thể (ví dụ như cách để các bạn có thể đạt tới mục tiêu), hãy dừng việc đọc lại tại đây và tìm ra những điều đó trước.

Ở đây có ảnh - This guide is most helpful at the tactics level

Bước 1: Crystallize the problem you are solving

Hãy bắt đầu bằng việc trả lời những câu hỏi sau về dự án của bạn:

Miêu tả: Nó là gì?

Vấn đề: Nó giải quyết vấn đề gì?

Lý do: Làm thế nào để chúng ta biết rằng đây là vấn đề thực sự và cần được giải quyết?

Success: How do we know if we’ve solved this problem?

Đối tượng: Chúng ta xây dựng dự án này cho ai?

Sản phẩm: Dự án này sẽ trông như thế nào khi được xây dựng thành sản phẩm?

You can also use this handy 1-Pager template (copy it here). I find it most effective if a single person takes the first pass (usually the PM, but doesn’t have to be). Bên dưới là một số thông tin chi tiết về các câu hỏi trên.

Miêu tả: Nó là gì?

Đây chỉ là một lời miểu tả ngắn gọn về suy nghĩ của bạn để những người đọc có thể nhanh chóng cảm nhậm được về ý tưởng của dự án. Hãy giữ cho nó thật ngắn gọn.

Vấn đề: Nó giải quyết vấn đề gì?

The problem statement itself is foundational so spend extra time there. Hãy nghĩ về vấn đề đó như một giả thuyết. Bạn tin rằng bạn đang giải quyết vấn đề gì, và tại sao? You’ll add more context later. Key attributes of a strong problem statement include:

Nó cần phải ngắn. Hãy sử dụng một câu duy nhất để miêu tả vấn đề thực sự. Bạn càng giải thích nhiều, vấn đề sẽ càng trở nên mơ hồ.

Nó có tính tập trung cao. Nó gồm chỉ một vấn đề duy nhất có thể được giải quyết bởi một nhóm duy nhất trong một khoảng thời gian hợp lý. Thường thì việc đưa ra ví dụ về những vấn đề bạn không giải quyết rất hữu ích.

Nó cần nói đến một nhu cầu chưa được đáp ứng. Hãy thử tập trung vào nhu cầu của người tiêu dùng, nhưng nếu cần thì bạn cũng có thể tập trung vào nhu cầu của doanh nghiệp. Khung Jobs To Be Done (JTBD) đặc biệt hữu ích trong trường hợp này

Nó trả lời cho câu hỏi “cái gì” và “tại sao”. Cái gì không ổn và tại sao nó lại là một vấn đề? You’ll need to back this up in the next section.

Nó không bao gồm giải pháp. Hãy chống lại sự thôi thúc muốn đi đến giải pháp ngay lập tức.

Examples of good problem statements:

Tài xế Lyft đang hủy các chuyến xe quá thường xuyên vì các hành khách ở quá xa.

Các chủ nhà của Airbnb cảm thấy bực bội vì họ muốn cải thiện nhưng chưa tìm ra cách.

Lượng khách hàng đang giảm ở tỉ lệ quá cao ở bước cuối cùng trong việc đăng ký.

Examples of bad problem statements:

Lượng khách hàng mới đang giảm. [Vấn đề: Quá rộng và không hướng tới lợi ích của khách hàng.]

Xây dựng một chương trình để tạo lượng khách hàng trung thành. [Vấn đề: Hãy đặt ra một biện pháp. Biện pháp này giúp giải quyết vấn đề gì?]

Users are bouncing from the signup flow. [Vấn đề: Không đủ tập trung và chưa trả lời câu hỏi “tại sao”. Hãy đào sâu hơn nữa về vấn đề này.]

Lý do: Làm thế nào để chúng ta biết rằng đây là vấn đề thực sự và cần được giải quyết?

Đây là điểm mà bạn cần thu thập những bằng chứng để củng cổ cho problem statement (hay nói cách khác là giả thuyết) của bạn. Điều gì đã thuyết phục bạn vào ban đầu rằng đây là một vấn đề? Điều gì đã khiến bạn cảm thấy chắc chắn rằng vấn đề này cần được giải quyết?

Đôi khi, ở bước này, bạn nhận ra rằng vấn đề đó không thật sự đáng được ưu tiên ngay bây giờ hoặc bạn cần điều chỉnh cách nhìn của bản thân về vấn đề đó. Đó chính là lý do khiến bạn cần thực hiện những bước này, vậy nên đừng tránh né nó. Có vô vàn những vấn đề - mục tiêu của bạn chính là cảm thấy tự tin về việc vấn đề này xứng đáng với thời gian của nhóm bạn vào lúc này.

Một vài mẹo cho bước này:

Hãy sử dụng nhiều loại dẫn chứng khác nhau và tập hợp tất cả các dữ liệu có thể thuyết phục rằng đây là một vấn đề thực tế và quan trọng.

Chất lượng hơn số lượng. Ba đến năm dữ liệu thuyết phục sẽ tốt hơn nhiều so với một tá những dữ liệu ít liên quan. Bạn càng cố làm cho luận điểm của mình có vẻ có nhiều dẫn chứng với những dữ liệu nhỏ và không liên quan, luận điểm của bạn sẽ càng trở nên thiếu thuyết phục. Luận điểm của bạn không cần phải trở nên hoàn hảo hoặc  air-tight.

Play devil’s advocate with yourself. Hãy thử thuyết phục bản thân bạn rằng vấn đề đó không đủ lớn hay thực tế. Bạn có lỗ hổng nào trong dẫn chứng? Những dẫn chứng bạn đưa ra có thật sự chứng tỏ những gì bạn nghĩ không? Push yourself here.

In the end it’ll be judgement call amongst many tradeoffs. Công việc của bạn là tạo ra luận điểm tốt nhất bạn có thể với những dữ liệu bạn có. Continue refining the problem statement as you learn more.

Success: How do we know if we’ve solved this problem?

Did you achieve what you set out to achieve? How will you know? Answer that question and write it down in this section.

“Did I do that or did I not do that? Yes? No? Simple.” — Andy Grove

This criteria becomes incredibly important throughout the project because it helps you make decisions and prioritize. Does feature X increase the chances of achieving the goal you set? If not, cut it.

Ideally this is a specific metric, with a defined goal, that you can easily measure. Ideally it directly connects to your team’s KPI’s. Ideally it is based on hard data about the opportunity size, investment size, and a heuristic from past experiments. Rarely is it ever ideal. Here is some advice for defining your success criteria:

Try hard to make it a concrete number, e.g., 10% increase in X, 50% decrease in Y, 20% adoption of feature Z within 3 months.

Pick a goal that’s believable, but ambitious. What’s a goal that if you were to hit, your team and your leaders would be excited about?

If you don’t think a metric makes sense for your goal (think long and hard about this), write out what concretely the world would look like if this was a big success. Make that the success criteria.

Đối tượng: Chúng ta xây dựng dự án này cho ai?

Tên của câu hỏi gần như đã thể hiện được nội dung. Một dự án hiếm khi được thiết kế cho tất cả người dùng. Dự án này phục vụ cho khách hàng mới hay cũ? Nó được dùng cho khách hàng thông thường hay khách hàng đặc biệt? Đối tượng khách hàng của nó là khách hàng sử dụng phần mềm hay trang web? …

Sản phẩm: Dự án này sẽ trông như thế nào khi được xây dựng thành sản phẩm?

Đây là điểm mà bạn sẽ đưa ra giải pháp cho vấn đề. Dựa trên cách nhóm của bạn vận hành và những gì các bạn đã chắc chắn, phần này có thể sẽ trở nên vô cùng chi tiết hoặc đầy đủ. Theo kinh nghiệm của tôi, điểm mấu chốt ở đây chính là thống nhất với những người thiết kế của bạn về độ chi tiết họ muốn và những gì sẽ hữu ích trong quá trình thiết kế.

Bước 2: Thống nhất với nhóm của bạn và các bên liên quan

Bạn đã bao giờ nhìn thấy những biển quảng cáo của hãng Chipotle (ảnh ở bên dưới) dọc những con đường cao tốc chưa? Nhiều năm trước Peter – đồng nghiệp của tôi đã chỉ ra mưu mẹo đằng sau những quảng cáo đó – mọi người trong số chúng ta đều tưởng tượng ra món burrito lý tưởng và ngon lành nhất đối với bản thân ở bên trong lớp giấy bạc. Chúng ta đều thấy những gì chúng ta muốn thấy.

 Ở đây có ảnh

Problem statements are like silver burritos. Mọi người trong nhóm của bạn đều có một phiên bản độc nhất về vấn đề trong đầu mình. Đôi lúc những phiên bản đó gần như giống hệt nhau. Đôi lúc những phiên bản đó vô cùng khác biệt. Dự án càng lớn và phức tạp, khả năng các phiên bản khác nhau càng cao. Nhiệm vụ của bạn là “tiêu diệt” triệt để sự không thống nhất này sớm và thường xuyên. Hãy “mở lớp giấy bạc” và đảm bảo rằng tất cả mọi người đều đồng ý với “món burrito” ở bên trong. May mắn là chúng tôi có một tài liệu tuyệt vời từ Bước 1 mà sẽ giúp cho công việc của bạn trở nên dễ hơn 10 lần.

 Tôi thường tiếp cận bước này theo cách sau:

Tôi thử thực hiện Bước 1 (tất nhiên, người làm việc này có thể là bất cứ ai có hứng thú với một vấn đề cụ thể trong nhóm của bạn)

Chia sẻ bản nháp với toàn bộ nhóm sẽ tham gia vào dự án này. Xin ý kiến (qua bình luận, email hoặc trực tiếp). Hãy trân trọng những đóng góp đó, chỉnh sửa và sau đó chia sẻ lại bản nháp của bạn.

Nếu những phản hồi đồng nhất với nhau và cả nhóm có vẻ thống nhất thì tuyệt. Còn nếu không thì hãy tìm cách để khiến mọi người thống nhất và nói chuyện về các sự bất đồng với từng người.

Một khi nhóm của bạn đã thống nhất, hãy chia sẻ về ý tưởng với những bên liên quan. Việc nhóm của bạn và những người đánh giá về sự thành công của bạn có cùng ý kiến về vấn đề mà bạn đang giải quyết trước khi bạn bắt tay quá sâu vào việc thiết kế/xây dựng là vô cùng quan trọng.

Bring the team together for an in-person kickoff where you again review the problem statement, answer any outstanding questions, and make sure your team has everything they need to get rolling.

Bước 3: Keep coming back to the problem

Chúng ta thường bắt đầu với những dự định và sự thống nhất tuyệt vời, nhưng vào lúc quan trọng nhất – trong quá trình làm việc, chúng ta thường không tiếp tục giải quyết được vấn đề đã đặt ra. Và đó chính là phần quan trọng nhất của vấn đề.

Một vài năm trước, tôi đã làm một dựa án về xây dựng bảng điều khiển cho các chủ nhà của Airbnb. Vấn đề ban đầu chúng tôi xác định và thống nhất là giảm thời gian chủ nhà cần để trả lời – giảm lượng thời gian trung bình một chủ nhà cần dùng để trả lời tin nhắn của một khách hàng. Giả thuyết của chúng tôi là các chủ nhà sẽ trả lời nhanh hơn nếu các tin nhắn chưa đọc được đẩy lên trên và tốc độ trả lời tin nhắn ảnh hưởng tới vị trí của họ trên trang kết quả tìm kiếm. Chúng tôi đã đúng, nhưng trong suốt cả dự án, khi phạm vi và sự phức tạp dần tăng lên (mẹo chuyên nghiệp: xây dựng bảng điều khiển là một vấn đề theo kiểu “món burrito trên gói giấy bạc” điển hình), tôi đã liên tục phải nhắc nhở cả nhóm về vấn đề chúng tôi thật sự cần giải quyết. Không có gì có thể giúp giảm sự mở rộng phạm vi hơn là việc quay trở về  the problem statement và những tiêu chuẩn thành công. Bạn có thể giải quyết rất nhiều vấn đề bằng rất nhiều cách, nhưng bạn cũng có thể tạo nên một sản phẩm đẹp đẽ nhưng không giải quyết được vấn đề gì.

Hãy tránh cái bẫy này với một vài những thói quen tốt:

Trong mọi buổi duyệt thiết kế, hãy đảm bảo rằng các nhà thiết kế bắt đầu bằng việc nhắc lại the problem statement. Nếu như vậy chưa đủ rõ ràng, hãy hỏi họ rằng “Chúng ta đang cố gắng giải quyết vấn đề gì?”.

Trong mọi cập nhật về tiến trình với các bên liên quan, hãy nhắc lại the problem statement để đảm bảo rằng mọi người tiếp tục thống nhất về sản phẩm đầu ra.

Trước khi hoàn thành việc thiết kế hãy đảm bảo rằng bạn hỏi bản thân rằng: “Mình có tự tin rằng sản phẩm này sẽ giải quyết được vấn đề chúng ta đặt ra không?”

Một ghi chú cuối cùng

Chúng ta đều là những người giải quyết vấn đề (vấn đề kỹ thuật, vấn đề giữa người với người, vấn đề của tổ chức,…) chuyên nghiệp. Bạn sẽ không thể thoát khỏi việc giải quyết các vấn đề.

“Các vấn đề xuất hiện liên tiếp trong cuộc sống. Khi bạn giải quyết vấn đề sức khỏe của mình bằng cách mua một thẻ tập gym, bạn tạo ra những vấn đề mới, ví dụ như bạn sẽ bắt buộc phải thức dậy sớm để đi tập gym đúng giờ, chảy mồ hôi nhiều như một người nghiện ma túy đá trong vòng ba mươi phút trên máy elliptical, và sau đó tắm rửa, thay quần áo đi làm để bạn không bốc mùi khắp phòng làm việc. Khi bạn giải quyết việc không dành đủ thời gian cho người yêu bằng cách thiết kế một “buổi tối hẹn hò” vào ngày thứ tư, bạn tạo ra những vấn đề mới, ví dụ như tìm ra việc mà cả hai bạn không ghét để làm vào mỗi thứ tư… Các vấn đề không dừng lại, chúng sẽ chỉ được thay đổi và/hoặc nâng cấp.”

— Mark Manson (Nghệ Thuật Tinh Tế Của Việc "Đếch" Quan Tâm)

Bất cứ khoảng thời gian nào bạn dành cho việc củng cố kỹ năng giải quyết vấn đề của mình, trong những vấn đề của bản thân lẫn những vấn đề của nhóm, là khoảng thời gian xứng đáng. Nếu bạn muốn tìm hiểu thêm nữa về chủ đề này thì đây là năm quyển sách tôi đặc biệt giới thiệu:

Làm Ra Làm Chơi Ra Chơi

Nghệ Thuật Tinh Tế Của Việc "Đếch" Quan Tâm

Chiến Lược Tốt & Chiến Lược Tồi

Làm Điều Quan Trọng

Phân Tích Dữ Liệu Tinh Gọn

Nếu bạn tìm thấy những thói quen, công cụ hoặc tài liệu khác giúp bạn giải quyết các vấn đề một cách hiệu quả hơn, tôi sẽ rất vui lòng được biết – hãy đăng bài tweet trên trang cá nhân của tôi.

Trân trọng,

Lenny

Chân thành cảm ơn Sean, Brett và Yelena vì đã cho tôi ý kiến về những bản nháp ban đầu.