Tài liệu · Lộ trình tự học
Lộ trình Breaking into
Product Management
Một lộ trình tự học miễn phí, đi từ con số 0 đến lúc hiểu thật sự làm Product là làm gì. Bám sát giáo trình khoá học 7 tuần của tụi mình, đúc kết qua nhiều lần trực tiếp hướng dẫn các bạn fresh, junior PM trong môi trường làm sản phẩm thật.
Đã đăng ký khoá học và đang chờ khai giảng? Đây chính là thứ nên đọc trước. Đi hết lộ trình này, bạn sẽ vào lớp với một nền tảng vững hơn nhiều.
Tổng quan
Tất cả xoay quanh hai không gian: Vấn đề và Giải pháp.
Double Diamond là bản đồ của cả lộ trình: mở rộng rồi tập trung, hai lần, một cho Vấn đề và một cho Giải pháp. Lộ trình bám sát giáo trình khoá học 7 tuần, chia làm hai phần Problem Discovery và Solution Delivery.
Chuẩn bị
Nền tảng tư duy
Không gian Vấn đề
Problem Discovery
45%Bắt đầu từ đâu
Trước tiên: biết mình đang ở đâu.
Đây thường là khó khăn đầu tiên: nếu không biết vị trí hiện tại và mục tiêu kế tiếp, bạn rất dễ chán nản khi ngụp lặn mà không rõ kết quả sẽ thế nào. Một cách hay là tự chấm điểm mình trên bản đồ năng lực PM để thấy đâu là điểm mạnh, đâu là chỗ cần tập trung.
Bản đồ năng lực PM của Ravi Mehta ↗Dành bao nhiêu thời gian?
Trong khoá học, tụi mình hay nói: mỗi 1 tiếng học nên đi kèm 3 tiếng tự luyện để đào sâu và thẩm thấu. Tự học theo lộ trình này cũng vậy, đọc tài liệu chỉ là một nửa, nửa còn lại là thực hành và thu feedback (xem phần Cách luyện tập).
Chuẩn bị
Nền tảng tư duy
Học xong: Phân biệt được không gian Vấn đề và không gian Giải pháp, và thấy nghề PM xoay quanh cả hai.
Trước hết, bạn cần hiểu ngành Product Management khác gì các ngành khác, và thực trạng nghề PM ở Việt Nam.
Cốt lõi của nghề: một PM phải cực kỳ am hiểu cả Vấn đề lẫn Giải pháp. Muốn vậy, bạn phải tách bạch được không gian vấn đề (problem space) và không gian giải pháp (solution space), thứ mà cả lộ trình này xoay quanh.
Tài liệu tham khảo
Jobs to be Done: Theory to Practice
Anthony W. Ulwick
Lý thuyết giải thích vì sao người dùng mua và dùng sản phẩm: họ không muốn cái máy khoan, họ muốn treo bức ảnh gia đình lên tường.
Learning to Build: The 5 Bedrock Skills of Innovators and Entrepreneurs
Bob Moesta
Năm kỹ năng nền: thấu cảm, tìm ra nhu cầu, truy ngược nguyên nhân, dùng nguyên mẫu để tạo thông tin, và đánh đổi khi ra quyết định.
Product Management for Managers
HieuTV
Bài chia sẻ tổng quan rất hay của chú Hiếu về bức tranh Product Management.
Double Diamond Framework
Design Thinking process in Product Management
Tương ứng buổi 01–02 của khoá →Học xong: Biết cách di chuyển có hệ thống giữa hai không gian qua bốn nhịp discover, define, develop, deliver.
Double Diamond là mô hình thiết kế giúp bạn di chuyển giữa problem space và solution space một cách có hệ thống. Bốn giai đoạn (discover, define, develop, deliver) xếp thành hình thoi kép, thể hiện nhịp mở rộng (diverge) rồi tập trung (converge).
Khi gặp một bài toán phức tạp: mở rộng để hiểu hết không gian vấn đề, rồi tập trung chọn ra vấn đề quan trọng nhất. Với vấn đề đã chọn, lại mở rộng để tìm mọi giải pháp khả dĩ, rồi tập trung chọn giải pháp phù hợp với bối cảnh và ràng buộc của bạn.
Tài liệu tham khảo
The Double Diamond Framework
ProductBoard
Giới thiệu framework và giải thích từng bước trong Double Diamond.
core.ac.uk
Analysing the Double Diamond design process
Research paper · CORE
Đi sâu vào thử thách khi áp dụng Double Diamond vào ngữ cảnh startup, và những giới hạn của nó khi va chạm thực tế.
Tư duy giải quyết vấn đề
Mở rộng tự học · Problem Solving
Học xong: Có một bộ công cụ để định hình và mổ xẻ vấn đề trước khi lao vào giải pháp.
Đây là phần tụi mình thêm vào ngoài giáo trình chính, vì giải quyết vấn đề là nền nằm dưới mọi việc một PM làm. Khoá học chạm tới nó ở buổi đầu, còn ở đây bạn được đào sâu tuỳ thích.
Một bộ công cụ tốt giúp bạn dừng lại hỏi “vấn đề thật sự là gì” trước khi vội đề xuất lời giải.
Tài liệu tham khảo
On Problem Solving
Thanh Dinh · Chief Engineer @ Holistics
Tư duy giải quyết vấn đề, nền tảng cho mọi việc một PM làm sau này.
Are Your Lights On?
Donald C. Gause & Gerald M. Weinberg
Cách truy cho ra vấn đề thật sự là gì trước khi vội đi tìm lời giải.
Bulletproof Problem Solving
Charles Conn & Robert McLean
Quy trình bảy bước bóc tách một bài toán phức tạp thành những phần giải được.
Không gian Vấn đề
Problem Discovery
45%Discover — Nghiên cứu & phỏng vấn người dùng
Product Discovery · Research & User Interview
Tương ứng buổi 02–03 của khoá →Học xong: Biết ra ngoài nói chuyện với người dùng, phỏng vấn mà không dẫn dắt, và nghe ra insight thật.
PM không phải người ngồi phòng máy lạnh tưởng tượng ra vấn đề của người dùng. Bạn phải ra ngoài, nói chuyện, và thật sự hiểu vấn đề của họ.
Bạn cần nắm tổng quan về nghiên cứu người dùng: tại sao phải phỏng vấn, phỏng vấn thế nào, và những lỗi cần tránh.
Tài liệu tham khảo
The Mom Test
Rob Fitzpatrick
Cách tìm, phỏng vấn người dùng và tổng hợp thông tin để kiểm chứng ý tưởng, kể cả khi mọi người đang nói dối bạn.
jobs-to-be-done.com
How to get results from JTBD Interviews
Jobs-to-be-Done
Cách phỏng vấn và frame lại thông tin một cách hệ thống theo đúng JTBD framework.
muledesign.com
Research Questions Are Not Interview Questions
Mule Design
Phân biệt thứ bạn muốn biết với thứ bạn thật sự hỏi, một lỗi phỏng vấn rất hay gặp.
Define — Tổng hợp & định nghĩa vấn đề
Product Discovery · Synthesis & Problem Definition
Tương ứng buổi 02–03 của khoá →Học xong: Tổng hợp được thông tin sau phỏng vấn và chốt ra vấn đề đáng giải nhất.
Phỏng vấn xong là một đống thông tin rời rạc. Define là lúc bạn ghép chúng lại, dựng bản đồ công việc người dùng đang cố làm, rồi chọn ra vấn đề đáng giải nhất.
Đây chính là chấm “Problem Definition” ở giữa sơ đồ Double Diamond: điểm bản lề khép lại không gian Vấn đề trước khi mở sang Giải pháp.
Tài liệu tham khảo
jobs-to-be-done.com
Mapping the Job-to-be-Done
Jobs-to-be-Done
Cách bóc tách công việc người dùng đang cố hoàn thành thành từng bước, khung để gắn nhu cầu vào.
delvetool.com
How to Do Thematic Analysis
Delve
Phương pháp rút insight có hệ thống từ dữ liệu định tính, thay vì đọc xong rồi đoán.
ravi-mehta.com
The Three Pillars of Product Decision Making
Ravi Mehta
Ba trụ để quyết định nên giải vấn đề nào: dữ liệu, trực giác đã rèn, và phán đoán bối cảnh.
Không gian Giải pháp
Solution Delivery
55%Develop — Ý tưởng & thiết kế giải pháp
Product Delivery · Ideation & Solution Design
Tương ứng buổi 04–07 của khoá →Học xong: Ideate nhiều giải pháp cho một vấn đề, chọn theo bối cảnh, và phác ra hình hài giải pháp.
Sau khi đã định nghĩa được một vấn đề vừa đủ nhỏ, PM cần ideate nhiều hướng rồi chọn theo bối cảnh và ràng buộc, thay vì bám vào ý tưởng đầu tiên xuất hiện trong đầu.
Tiếp đó là phác hình hài giải pháp: mô hình hoá khái niệm sao cho rõ ràng, và dựng wireframe để hình dung trước khi dồn công sức xây dựng.
Tài liệu tham khảo
longform.asmartbear.com
Rocks, Pebbles, Sand
A Smart Bear
Cách sắp thứ tự ưu tiên để chọn việc đáng làm, và cả khi nào nên bớt tin vào framework ưu tiên.
The Essence of Software
Daniel Jackson
Tư duy khái niệm: mô hình hoá sản phẩm sao cho người dùng dễ hiểu và phần mềm rõ ràng, đáng tin.
checklist.design
Checklist Design
checklist.design
Thư viện thực hành thiết kế để phác giao diện không phải bắt đầu từ con số 0.
Deliver — Làm việc với team & giao hàng
Product Delivery · Artifacts & Project Delivery
Tương ứng buổi 04–07 của khoá →Học xong: Tạo được các tạo vật để dev hiểu và làm đúng, và biết vận hành đội ngũ theo Agile.
Giải pháp dù hay đến đâu cũng vô nghĩa nếu developers không hiểu đủ chi tiết để làm. Bạn cần biết cách tạo ra các tạo vật cần thiết (activity diagram, user stories, mock-up) để làm việc hiệu quả với đội phát triển.
Một PM cũng cần dùng các phương pháp phát triển phần mềm phổ biến như Agile, Scrum để vận hành đội ngũ (developers, QA...). Ngoài ra, nên nắm qua vài khái niệm kỹ thuật nền tảng như Backend, Frontend, API để hiểu rõ hơn không gian giải pháp.
Tài liệu tham khảo
User Story Mapping
Jeff Patton
Cách kể câu chuyện người dùng thành tấm bản đồ, để cả team thấy được bức tranh lớn lẫn từng lát cắt giao hàng.
agilemanifesto.org
Agile Manifesto for Software Development
agilemanifesto.org
Dù ra đời đã lâu, tuyên ngôn Agile vẫn được các đội phát triển phần mềm áp dụng rộng rãi đến hôm nay.
Agile Everywhere
Henrik Kniberg
Ví dụ thực tế khi áp dụng Agile ra ngoài ngữ cảnh phần mềm. Hay cho ai đã biết sơ về Agile nhưng muốn hiểu bản chất.
Xuyên suốt
Kỹ năng & Tư duy
Hai thứ này không nằm ở một chặng riêng, chúng chạy dọc cả lộ trình. Bạn giao tiếp và dùng AI ở mọi bước, từ phỏng vấn người dùng đến làm việc với dev.
Giao tiếp
buổi 08 ↗Giao tiếp không phải kỹ năng phụ, nó quyết định phần lớn việc một PM có làm được việc hay không. Cùng một ý, bạn nói với CEO khác với nói cho engineer.
Dùng AI
buổi 09 ↗Dùng AI như công cụ hỗ trợ tư duy, không thay phán đoán. Và dùng nó để tự học nhanh hơn: tạo đề kiểm tra, ôn theo kiểu spaced retrieval, nhờ chấm và phản biện.
Đào sâu thêm
Muốn đọc rộng hơn?
Anh Anthony Thong Do, một người anh, người "sếp" của tụi mình, có tổng hợp một bản đồ sách Product Management khá đầy đủ, phân theo từng kỹ năng và mức độ ưu tiên.
Bộ sưu tập Product Management Books Collection anthonytd.com/pm-books ↗Cách luyện tập theo lộ trình
Đọc xong rồi, giờ luyện thế nào?
Học, thực hành, rồi thu feedback
Tiếp cận lý thuyết, thực hành liên tục, và quan trọng nhất là tìm cách thu thập feedback. Bạn có thể tự học theo lộ trình trên, rồi tham gia cộng đồng để hỏi đáp và trao đổi. Còn nếu muốn được hướng dẫn sát sao và có người review bài, hãy cân nhắc khoá học của tụi mình.
Dùng AI để học nhanh hơn
Một mẹo tự học hiệu quả: sau mỗi chặng, nhờ AI tạo một bộ câu hỏi kiểm tra từ thứ bạn vừa đọc, tự trả lời trước khi xem đáp án, rồi quay lại ôn sau 2–3 ngày. Ôn ngắt quãng (spaced retrieval) ghi nhớ tốt hơn nhồi nhét nhiều. Bạn cũng có thể nhờ AI chấm bài và phản biện cách tư duy của mình. Xem thêm ở băng Kỹ năng & Tư duy.
Lộ trình này cho bạn bản đồ.
Thứ khó tự học nhất là feedback sát sao và một môi trường luyện tập có người đi cùng. Nếu muốn đi cùng người khác, tụi mình có cộng đồng và khoá học để bạn chọn.