Title: 《Inspired: How to Create Tech Products Customers Love》
Tiếng Việt: Khải Huyền: Cách tạo ra các sản phẩm công nghệ mà khách hàng yêu thích

Sản phẩm thành công tuân theo các quy tắc nhất định

1. Nhiệm vụ của Product Manager là khám phá giá trị, tính khả dụng và tính khả thi của sản phẩm.
2. Define Product – định nghĩa sản phẩm đòi hỏi sự cộng tác của product manager, Interaction Designer và Software Architect.
3. Developer không giỏi thiết kế UX, bởi vì các Developer tập trung vào implement the model, trong khi người dùng nghĩ về các conceptual model (mô hình khái niệm) của sản phẩm.
4. Thiết kế trải nghiệm người dùng là interaction design (thiết kế tương tác), visual design (thiết kế trực quan) (đối với phần cứng, là industrial design – thiết kế công nghiệp).
5. Chức năng và thiết kế UX được liên kết chặt chẽ.
6. Product ideas (ý tưởng sản phẩm) phải được triển khai sớm, không ngừng được người dùng mục tiêu chấp nhận và lặp đi lặp lại để có trải nghiệm người dùng hiệu quả.
7. Sử dụng high-fidelity product prototypes (các nguyên mẫu sản phẩm có độ trung thực cao) là cách hiệu quả nhất để tất cả các thành viên trong nhóm hiểu nhu cầu của người dùng và trải nghiệm người dùng.
8. Mục tiêu của product manager là nắm bắt thị trường phức tạp và nhu cầu của người dùng trong thời gian ngắn nhất, đồng thời xác định giá trị, tính khả dụng và tính khả thi của sản phẩm.
9. Một khi sản phẩm được xác định đáp ứng các yêu cầu trên thì đó là một khái niệm hoàn chỉnh, và không thể đạt được kết quả như mong đợi nếu thiếu bất kỳ yếu tố nào.

Những sai lầm trong cách tiếp cận truyền thống

Theo tác giả của quyển sách, thì so với cách tiếp cận truyền thống, thì đang tồn tại những sai lầm như sau:

Tiếp cận truyền thống	Tác giả cho rằng, vấn đề là: Trong hình thức này, product manager căn bản không phải là product manager, mà thực thất chỉ là người điều phối dự án
Idea (đến từ tầng quản lý nội bộ hoặc từ người dùng hiện tại từ bên ngoài hoặc từ người dùng tương lai)	Idea như vậy sẽ tạo ra các sản phẩm Sales-Driven (thúc đẩy doanh số bán hàng) hoặc Stakeholder-driver (bên liên quan), không phải là tối ưu nhất
Business Cases 1) Giá trị mà sản phẩm có thể mang lại 2) Cần bao nhiêu tiền và thời gian để hiện thực hóa nó	Có quá nhiều biến số, ngay từ khi ở giai đoạn mới bắt đầu thì căn bảng không có phương pháp nào có thể dự đoán giá trị mà nó sẽ mang lại, thuần túy làm chỉ vì cần làm.
Roadmap	Tầng lãnh đạo khả năng cần phải viết, nhưng Roadmap là nguyên nhân chủ yếu dẫn đến sự lãng phí lớn về thời gian và nguồn lực. Lý do là: 1) Thông thường trên 50% sẽ không hiện thực hoặc không cần đến 2) nếu như chức năng có tiềm lực, thông thường sẽ không thể hình thành ngay lập tức được, mà cần tải tiến nhiều lần
Requirement/user stories
To engineers Hình thành Agile, Sprint	Đã quá muộn để sử dụng chúng, càng sớm trao đổi với đội ngũ developers, khả năng có thể đạt được nhiều thông tin hữu dụng, và tránh được nhiều vấn đề sau này. Self Note: Marketing Department cũng cần được đưa vào cuộc thảo luận càng sớm càng tốt, bởi vì bộ phận này có thể đưa ra phản ứng của thị trường cũng như khó khăn khi promote (quảng bá) một cách nhanh chóng cho sản phẩm
QA
Deploy

Vấn đề lớn nhất là: Customer validation happens way too late (kiểm chứng người tiêu dùng quá chậm), như vậy đã để mọi phong hiểm (nguy hiểm, nguy cơ) để đến cuối cùng.

The key principle is Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed The irony is that many teams believe they’re applying Lean principles; yet, they follow this basic process I’ve just described.

(Nguyên tắc quan trọng của phương pháp Lean là giảm thiểu lãng phí, và một trong những hình thức lãng phí lớn nhất là thiết kế, xây dựng, thử nghiệm và triển khai một tính năng hoặc sản phẩm chỉ để phát hiện ra nó không phải là thứ cần thiết. Họ đang áp dụng các nguyên tắc Lean, tuy nhiên, họ tuân theo quy tình cơ bản mà tôi vừa mô tả.)

The traditional approach

3 nguyên tắc

Nguyên tắc 1: Risks are tackled upfront, rather than at the end. (rủi ro phải được giải quyết ngay từ đầu, đừng để đến cuối cùng)

Những loại rủi ro này bao gồm:

• Người tiêu dùng có mua nó không?
• Người tiêu dùng có thể hiểu cách sử dụng?
• Tính khả thi: chúng ta có công nghệ, thời gian, nhân lực và tiền bạc để biến nó thành hiện thực không?
• Với các phòng ban khác (sales, marketing, finance, legal), thì có hợp lý không?

Nguyên tắc 2: Products are defined and designed collaboratively, rather than sequentially. (Các sản phẩm cần được xác định và thiết kế một cách cộng tác, thay vì tuần tự)

Theo cách truyền thống, thì program manager sẽ định ra các yêu cầu, đưa thiết kế để đề ra phương án giải quyết, cuối cùng để developers phát triển. Nhưng ngay từ đầu nên tập hợp mọi người lại, cùng nhau thiết kế → cách này đơn giản và dễ thực hiện.

Nguyên tắc 3: It’s all about solving problems, not implementing features. (Mục đích ban đầu là giải quyết vấn đề, chứ không phải là phát triển tính năng)

Product Discovery (phát hiện/định nghĩa sản phẩm) – có thể đặt 4 loại câu hỏi sau:

1. Will users buy this (or choose to use it)?
2. Can the user figure out how to use this?
3. Can engineers build this?
4. Can our stakeholders support this?

Product Discovery

Product Discovery bao gồm: một loạt các prototypes hoặc thí nghiệm, đa phần đều nhanh, rẻ, cho các rủi ro khác nhau. Thông thường các đội ngũ mạnh (!!!) có thể làm ra khoảng 10-20 cái mỗi tuần.

The Purpose of all these prototypes and experiments in discovery is to quickly come up with something that provides some evidence it is worth building and that we can then deliver to our customers. This means the necessary scale, performance, reliability, fault tolerance, security, privacy, internationalization, and localization have been performed, ad the product works as advertised.

(Mục đích của tất cả các prototypes và thử nghiệm trong khám phá này là nhanh chóng tìm ra thứ gì đó cung cấp một số bằng chứng đáng để xây dựng và sau đó chúng tôi có thể cung cấp cho khách hàng của mình. Điều này có nghĩa là quy mô cần thiết, độ bền, độ tin cậy, khả năng chịu lỗi, bảo mật bảo mật, quốc tế hóa và bản địa hóa đã được thực hiện, quảng cáo sản phẩm hoạt động như được quảng cáo.)

Thành viên trong nhóm: TBU
Thành phần cơ bản: 01 product manager, 01 product designer, và nhiều developers
Nguyên tắc quản lý: (1) đừng bảo mọi người phải làm như thế nào, mà hãy bảo họ làm gì; (2) performance được lo lường bằng kết quả.

Phương án thay thế cho Product Roadmap

Out-come based Roadmap + một thời điểm cực kỳ rõ ràng (một khi đã đưa ra, thì hoặc là deliver, hoặc là không được, không có MVP): liệt kê các vấn đề cần giải quyết mà không phải là các tính năng cần hiện thực. Lợi ích là:

• Nhóm hiểu vấn đề, đồng thời có độ tự do, có thể tự mình quyết định phương án giải quyết phù hợp nhất. Dù gì thì họ cũng là những con người chuyên nghiệp.
• Nhóm sẽ không chỉ vì chỉ hiện thực một tính năng mà có thể vạn sự đại cát được, phải xác định rằng đã giải quyết được vấn đề (Business Problem).

Đồng thời cũng cần cung cấp cho nhóm: Business context.

1. The product vision and strategy: điều này mô tả bức tranh toàn cảnh về những gì tổ chức đang cố gắng hoàn thành và kế hoạch để đật được vision (tầm nhìn) đó là gì. Mỗi nhóm sản phẩm có thể có các lĩnh vực trọng tâm riêng (VD: nhóm người mua và nhóm người bán), nhưng tất cả phải kết hợp với nhau để đạt được product vision (tầm nhìn sản phẩm).
2. The business objectives (mục tiêu kinh doanh): điều này mô tả các mục tiêu kinh doanh cụ thể, ưu tiên cho từng nhóm sản phẩm.

Ví dụ: đó là một ví dụ điển hình về mục tiêu kinh doanh cho một hoặc nhiều nhóm sản phẩm: “Dramatically reduce the time it takes for a new customer to go live”.

Làm thế nào để trở thành một product manager tốt?

• Đừng trở thành một Certified Scrum Product Owner
• Đừng trở thành một Roadmap administrator
• Đừng tự biến mình thành một Project Manager hoặc Program Manager

Trách nhiệm: đánh giá, quyết định những gì cần phải làm, cái gì sẽ hiển thị cho user. Product Backlog, nghe thì có vẻ đơn giản, nhưng điểm khó là: phải đảm bảo rằng những thứ có trong backlogs là đáng để làm, chứ không phải là một cái kho mà mọi thứ đều quăng vào trong đấy (với văn hóa khó nói “không”, đến cuối cùng sẽ biến thành – “đây là một ý tưởng hay, chúng ta đưa vào backlog nhé” → kiên quyết không thể để như vậy!). Vì vậy, người này phải tuyệt đối chịu trách nhiệm.

Khi một product thành công, là tất cả mọi người đều làm việc mình nên làm; khi một product không thành công, thì là lỗi của product manager.

Vì vậy, product manager cần phải Smart, Creative và Persistent:

• Deep Knowledge of the Customer (thấu hiểu sâu sắc về người tiêu dùng) → thực hiện ứng dụng: các loại nghiên cứu user Quantitative (định lượng) và Qualitative (định tính).
• Deep Knowledge of the Data (hiểu biết sâu sắc về dữ liệu) → thực hiện ứng dụng: việc đầu tiên trong ngày là dành nửa giờ để xem dữ liệu của 24 giờ qua, usage analysis – phân tích mức độ sử dụng, sales data – dữ liệu bán hàng, user analysis – phân tích người dùng, A/B testing, v.v…
• Deep Knowledge of Your Business (hiểu biết sâu sắc về business của bạn).
• Deep Knowledge of your Market and Industry (kiến thức sâu về ngành và thị trường của bạn)
• Cần thông minh: ham học hỏi, học nhanh và áp dụng các công nghệ mới để giải quyết các vấn đề cho người dùng, tiếp cận đối tượng mới hoặc kích hạt các mô hình kinh doanh mới (intellectually curious, quickly learning and applying new technologies to solve problems for users, to reach new audiences, or to enable new business models).
• Cần có tính sáng tạo: thinking outside the normal product box of features to solve business problems.
• Cần kiên trì: thúc đẩy công ty vượt ra khỏi vùng an toàn của họ với các bằng chứng thuyết phục (pushing companies way beyond their comfort zone with compelling evidence). → khó!!!

How to be successful / what you want to be

• Trở thành người hiểu rõ người dùng nhất trong công ty. Nếu như có người cần biết người dùng của họ, bạn sẽ trở thành người đầu tiên mà họ nghĩ tới. Và còn phải luôn chia sẻ những gì bạn đã học được, bất kể tốt hoặc xấu.
• Xây dựng mối quan hệ tốt đẹp với các Stakeholders và các đội nhóm hợp tác, đồng thời xây dựng các mối quan hệ một cách có chủ ý (chúng ta đều chú ý đến mối quan hệ hợp tác tốt, và một mối quan hệ tốt có thể giúp công việc của bạn trở nên dễ dàng hơn nhiều! Khi bạn quyết định trở thành một người influencer và học hỏi từ sếp cũ).
  1) Bạn hiểu rõ những hạn chế trong công việc của họ;
  2) Bạn chỉ cung cấp cho họ những giải pháp mà bạn cho là có khả thi (trong phạm vi hạn chế của công việc thực tế của họ).
• Hãy suy nghĩ như một CEO. Cần phải hiểu rõ mọi khía cạnh: Financial, marketing, sales, legal, Partnership, service, the customer environment, the technical capabilities, the user’s experience. → điều đó không nhất thiết có nghĩa là bạn phải có bằng MBA.
• Ở những Product Managers thành công, winning solutions không đến từ users hoặc sales, mà đến từ Intense Collaboration with design and engineering to solve real problems for users.
• True leadership is a big part of what separates the great product people from the merely good ones. So no matter what your title or level may be, if you aspire to be great, don’t be afraid to lead. (Leadership chân chính là chìa khóa để phân biệt product manager giỏi với product manager thông thường. Nếu bạn muốn trở thành product manager giỏi, đừng ngại lãnh đạo – lead).

How to Sell the Dream/Product

• Use a prototype → có những so sánh đồ thị cần được hiểu.
• Share the pain → để đoàn đội có thể cảm nhận được pain point của user, cho họ cùng tham gia nghiên cứu về user là một giải pháp tốt.
• Share the vision.
• Share learnings generously → dù tốt hay xấu, hãy thường xuyên chia sẻ. Hãy để mình trở thành một Go-to Person, người hiểu rõ vấn đề của users.
• Share the credit → khi thành công là công lao của mọi người, khi có vấn đề, thì phải đứng ra chịu trách nhiệm.
• Learn how to give a great demo → lưu ý rằng bản demo ở đây không phải là một bài kiểm tra, mà nó là một công cụ để minh họa cho sếp. Vì vậy cần làm thật tốt thật tốt!!!
• Do your homework.
• Cần tràn đầy nhiệt tình, hoặc bất kỳ tình huống nào cũng phải tỏ ra tràn đầy nhiệt tình, như vậy mới có thể lan tỏa cho cả đội nhóm.

How to work with product design?

Trong giai đoạn Product Discovery, có thể có những vấn đề sau:

• How will consumers first learn about the product?
• How will we onboard a first-time user and reveal new functionality?
• How might users interact at different times during their day?
• What other things are competing for the user’s attention?
• How might things be different for a one-month-old user versus a one-year-old user?
• How will we motivate a user to a higher level of commitment to the product?
• How will we create moments of gratification?
• How will a user share his experience with others?
• How will customers receive an offline service?
• What is the perceived responsiveness of the product?

Sau đó làm Prototyping → User Testing.

Cần phải có một Trained Product Designer, nếu không, tốt nhất nên yêu cầu phía công ty. Và bạn không phải một in-house agency, mà là can discover the right product.

Trong thực tế:

• Do whatever you need to do to have your designers sit next to you → làm bất kỳ điều gì bạn cần làm để các designers ngồi bên cạnh bạn.
• Include your designer from the very inception of every idea → cần có designer ở ngay thời điểm mới bắt đầu ý tưởng.
• Include your design in as many consumer and user interactions as possible learn about users and consumers together → đưa thiết kế của bạn cho càng nhiều người dùng và người dùng tương tác càng nhiều càng tốt, cùng nhau tìm hiểu về người user và consumers.
• Fight your temptation to provide your designer with your own design idea give your designer as much room as possible to solve the design challenges him or herself → không cung cấp cho designer của bạn ý tưởng thiết kế của bạn, cung cấp cho designer càng nhiều không gian nhất để có thể giải quyết những thách thức thiết kế của họ.

• Encourage your designer to iterate early and often. Don’t get all nitpicky about design details with the very early iterations. Encourage your designer to feel free not just to iterate on the particular design approach but to explore alternative solutions to the problem → khuyến khích designer của bạn sớm tiến hành iterate và thường xuyên. Đừng hiểu quá nhiều về các chi tiết thiết kế với những lần lặp lại sớm. Khuyến khích nhà thiết kế của bạn cảm thấy tự do không chỉ lặp lại cách tiếp cận thiết kế mà còn khám phá các giải pháp thay thế cho vấn đề.

How to work with development – Engineers, Developers and Programmers

Học Computer Science, Computer Programming hoặc các công việc khác liên quan đến Developer.

Trọng điểm là: mục đích chỉ là để hiểu, đừng cầm tay chỉ việc người ta, đừng múa rìu qua mắt thợ, đừng trực tiếp nói với họ là nên làm như thế nào hay cần phải làm gì.

Chúng ta cần đội ngũ developers tham gia vào thời gian đầu của Discovery, nhưng không phải tất cả developers đều đồng ý, điều này không có vấn đề gì cả. Nhưng nếu không ai trong nhóm developers sẵn sàng tham gia vào quá trình phát triển, vậy thì điều đó nhất định phải được giải quyết.

* Cần chú ý đến cách giao tiếp với developer và designer, hãy giao tiếp theo thói quen quen thuộc của họ.

The Right Process

Product Discovery Phương thức: a high-fidelity user prototype and a story map as their go-to technique. Customer Discovery: "happy reference customers."	Đầu tiên, xác định phương án giải quyết cho users là gì, bao gồm: ít nhất là có đủ users cần đến phương án giải quyết này. Sau đó, có một phương án giải quyết, và thử áp dụng cho một tập users lớn. Vì vậy, chúng ta cần thực hiện thực nghiệm một cách nhanh chóng và ít tốn kém. Cuối cùng, cung cấp một giải pháp bền vững, có thể mở rộng và mạnh mẽ. We need to learn fast, yet also release with confidence → mục đích quan trọng nhất là: tìm ra bằng chứng cho thấy product chúng ta muốn làm ra là đáng giá và sẽ không lãng phí công sức và thời gian của mọi người.
Phỏng vấn người dùng Tác giả tin rằng những điểm chính khi phỏng vấn người dùng là: 1. Tần suất: 2-3 giờ/tuần, hàng tuần. 2. Mục đích: phải rõ ràng, không phải chứng để chứng minh điều gì đó, mà là để hiểu và học tập nhanh chóng. 3. Tìm người có mục tiêu tiếp cận: phải tìm người có trong thị trường mà mình muốn nhắm đến 4. Chuẩn bị: hãy nói rõ ngay từ đầu những gì mà bạn cho rằng người dùng của mình gặp vấn đề. 5. Thành phần tham gia: Product Manager, Designer và Developer, ít nhất 3 người. 6. Trong cuộc phỏng vấn: những câu hỏi mở, thử hỏi xem người tiêu dùng bây giờ như thế nào? hơn là đàm phán về tương lai. 7. Theo dõi: kiểm tra với đội nhóm, xem thử những gì bạn nghe nó nhất quán không. Bởi vì đôi khi đáp án khác nhau ở những người khác nhau lại có thể hiểu một cách khác nhau. * Sau khi phỏng vấn xong, bạn có thể theo dõi thử nghiệm người dùng (user test) và thử nghiệm ý tưởng sản phẩm - product idea test.	Những gì bạn cần biết: - Are your customers who you think they are? - Do they really have the problems you think they have? - How does the customer solve this problem today? - What would be required for them to switch?
Concierge Test: Yêu cầu người dùng thành thật cho bạn thấy cách họ làm việc / yêu cầu người dùng dạy cho bạn cách họ làm việc để bạn có thể cung cấp cho họ các giải pháp tốt hơn.

FAQ

1. Có bị mâu thuẫn với ý “build fast fail fast” không?
2. …. TBU …

More Resources:

1. Slide: here