"Em nghĩ sự khác nhau giữa một người Product Manager giỏi và Product Manager bình thường là gì?" - một anh Product Growth ở một tập đoàn công nghệ lớn ở Việt Nam có hỏi mình, trong 1 buổi nch cafe với anh ý tuần trước. Đây là một câu hỏi tưởng dễ, nhưng mà lại khó, vì mỗi người sẽ có góc nhìn khác nhau.

Khi nhận được câu hỏi này, mình có ngập ngừng một chút trước khi quyết định trả lời.

Thật lòng mà nói, mình mới làm Product được 3 năm, không quá ít nhưng cũng chưa phải quá nhiều. Mình chỉ hi vọng góc nhìn này giải quyết được một phần câu hỏi, chứ không thể đại diện được toàn bộ PM ở Việt Nam.

Hiện tại, mình có 6 năm làm trong ngành software, trong đó 3 năm giữ vai trò PM, chủ yếu ở các startup nhỏ và đang grow nhanh, team 7–8 người, sản phẩm tiêu biểu gồm dbdiagram, dbdocs, runsql, và một startup xe cũ.

Góc nhìn cá nhân: PM giỏi là người giỏi mô tả vấn đề

Câu trả lời của mình khi đó là:

Một Product Manager giỏi không chỉ biết build tính năng, mà còn có khả năng nắm bắt, bóc tách và mô tả những vấn đề hiện hữu của công ty, đối thủ và thị trường.

Khi nghe tới chữ "Vấn đề", mọi người thường nghĩ “vấn đề” là cái gì đó đau nhức, gây khó khăn cho user.

Nhưng với mình, việc mô tả vấn đề giống là phác hoạ được một bức tranh toàn cảnh, một "vũ trụ điện ảnh" mà trong đó các nhân vật là users, đối thủ, và sản phẩm và đội ngũ của mình 🤣

Trong đó có:

• User là ai, họ đang làm gì
• Ngữ cảnh, workflow, ràng buộc họ gặp phải
• Những chỗ đang trục trặc, chưa hiệu quả
• Và cả cơ hội tiềm ẩn nếu giải quyết được

Khi mô tả vấn đề, mình đang vẽ lại bức tranh này để cả team cùng nhìn. Từ đó, mọi người có cùng một điểm xuất phát để bàn giải pháp, thay vì mỗi người hình dung một kiểu.

👉 Chính điều này giúp việc alignment và xây dựng sản phẩm trở nên dễ dàng hơn.

Niềm vui thực sự của PM đến từ Giải quyết vấn đề thật sự

Ngày còn là software engineer, mình chỉ trăn trở làm sao build được sản phẩm mà có người dùng mỗi ngày. Đến khi làm PM, cảm giác hạnh phúc nhất không phải là launch xong feature, mà là thấy user giải quyết được vấn đề và đạt mục tiêu nhờ feature đó.

Đây là cảm xúc thoả mãn khi mình có được khi launch feature Schema Changelog của cho dbdocs, nhận được lượng adoption cao (33%) - btw, mình biết đây không chỉ là công sức của riêng mình, mà còn là đóng góp của cả team engineer làm việc ngày đêm để dẫn đến lauching của 2 project này.

Khi thấy có nhiều users dùng tính năng hoặc product mới tạo ra, mình nhận ra cảm giác hạnh phúc nhất của một PM không phải là launch xong một feature, mà là khi thấy user đạt được mục tiêu của họ nhờ feature đó, và giải quyết được vấn đề họ đang gặp phải

Khi mình biết vấn đề mà mình đang giải quyết, mình hình thành được một benchmark, cho cái solution mình sẽ tạo ra:

• Thước đo cho design: Nếu hiểu được vấn đề, mình sẽ thiết kế feature cho khớp vừa khít với vấn đề và ngữ cảnh mà users đang gặp phải.
• Thước đo cho success metrics: Khi hiểu được vấn đề, feature mình sẽ biết sẽ cần track metrics gì để đo lường độ hiệu quả của feature.

Ngược lại, mình sẽ đâm đầu vào triển khai một thứ không ai dùng. Mình còn nhớ khi mình còn làm engineer, mình own việc thiệt một sản phẩm CLI để giúp AI Engineers / AI Research train AI models trên SageMaker. Ngày giới thiệu sản phẩm đến mọi người trong team, mình rất tự tin, interface ngon, trình bày hay - hấp dẫn, đồng nghiệp khen nhiều… nhưng chẳng ai dùng cả.

Sau mới nhận ra: engineers vốn đang train model trên server nội bộ, nên tool của mình chẳng giải quyết vấn đề gì, và thậm chí còn khó dùng hơn là train trực tiếp trên server (vì trên đó có thể dễ dàng tinh chỉnh để experiment hơn). Nếu mình biết trước "vấn đề" này, chắc chắn mình sẽ không làm solution như trên.

4 thành phần trong mô tả bối cảnh vấn đề và cơ hội

Khi mình nhìn lại các dự án từng làm, mình nhận ra một mẫu số chung: một vấn đề được mô tả tốt thường có đủ bốn thành phần sau đây.

• (i) Nhu cầu khách hàng (Customer Needs & Insights)
• (ii) Cục diện cạnh tranh (Competitive Landscape)
• (iii) Năng lực nội bộ (Internal Capability & Operations)
• (iv) Cơ hội kiếm tiền (Monetization & Business Model)

Bài này mình sẽ trước mắt đi qua khai thác 2 ý (i) và (ii), vì nếu viết hết thì sẽ khá dài.

Tìm hiểu vấn đề khách hàng bằng hệ thống bối cảnh, con người, và quy trình đang diễn ra

Khi mô tả về nhu cầu khách hàng, mình thường mắc vào cái bẫy vào việc mô tả vấn đề quá nông, hoặc mô tả một vấn đề không có thật.

Nguyên nhân gốc rễ mình nghĩ là do mình quá tập trung (hoặc bắt đầu từ) khía cạnh kĩ thuật, và không thực sự tập trung nhiều đến việc hiểu user là ai, đang muốn gì và trong bối cảnh như thế nào:

• Họ là ai? Đang giữ vị trí gì?
• Công ty họ là công ty gì? Tại sao họ lại cần dùng tool của mình?
• Workflow của họ thường ngày như thế nào? Mục tiêu là gì?
• Họ đang gặp trở ngại gì khi adopt tool / feature của mình vào workflow của họ?
• Worldview (thế giới quan) của họ là gì?

Một trong những điểm mấu chốt khi hiểu về nhu cầu của khách hàng (đặc biệt với những sản phẩm B2B / Small teams) là cần hiểu rằng con người và process là một trong những mắc xích quan trọng trong việc hình thành nhu cầu hoặc một mục tiêu cụ thể trong một tổ chức.

Đây là vấn đề or nhu cầu mang tính hệ thống, tức là vấn đề xuất phát từ chính cấu trúc, cơ chế hoặc quy trình của công ty đó.

Khi team mình xây dựng feature Whitelabel cho dbdocs (Feature cho phép customize logo của công ty trên app, thay vì hiện logo của dbdocs), bọn mình nhận thấy các công ty có hứng thú cho feature này thường là những công ty DaaS, hoặc consulting firm, khi việc trình bày documentation trở thành "bộ mặt" của công ty, họ cần styling doc cho giống màu của công ty, và sử dụng logo riêng của họ, và nằm trực tiếp trong chuỗi giá trị của công ty. Và có cả công ty còn đòi bọn mình tắt feature Schema Changelog nữa, vì họ không muốn hiển thị cho khách hàng của họ biết những thay đổi trên database.

Mặt khác, với những công ty sử dụng dbdocs như một internal tool, thì những nhu cầu về customize logo là không có. Khi đó, việc đọc doc và chia sẻ internally là nhu cầu chính. Đối với tập này, trái ngược với tập DaaS ở trên về việc public facing, tập này sẽ quan trọng vấn đề security hơn, về muốn chắc chắn rằng doc của họ bảo mật và không bị leak ra ngoài, thì feature về Access Control là feature mà họ quan tâm hơn.

Việc hiểu về con người, động lực, bối cảnh công ty còn giúp mình hiểu hơn về khả năng monetization của sản phẩm đối với công ty đó. Có những công ty mà việc documentation trở thành văn hoá của công ty đó, việc họ adopt và sử dụng dbdocs trở thành điều hiển nhiên. Hoặc ở những data consulting firm, việc trao đổi database schema trở thành một mắt xích trong việc delivery, trao đổi kiến trúc schema với khách hàng, và để trở nên minh bạch và "professional" hơn, thì họ sẽ open hơn với việc trả tiền cho dbdocs.

Có những công ty văn hoá documentation không quá mạnh, thì sẽ rất khó để monetize. Mình còn nhớ có lúc mình nói chuyện với anh Dev ở 1 công ty nọ, ảnh bảo ảnh phải dùng chui dbdocs (để sếp không biết ảnh tốn thời gian vào documentation), và không thể nào xin tiền công ty để mua dbdocs.

Như vậy, để hiểu đủ sâu không gian vấn đề của khách hàng, cần hiểu được thế giới quan (world view), mục tiêu (goal), và hệ thống xung quanh user đó (hệ thống con người, hệ thống quy định, etc.).

Ví dụ về mô tả bối cảnh

Đây là ví dụ mình hay dùng để mô tả bối cảnh: bắt đầu từ user nào, họ đang ở trong quy trình / workflow nào, rồi đi tới use case cụ thể mà họ cần, đương nhiên là kèm dẫn chứng (bằng tên khách hàng / or quote) để không bị bẻ nhé mn :))

Sau đó mình note lại mục tiêu của use case đó, và cuối cùng là bối cảnh & vấn đề hiện tại mà họ đang gặp.

Trình bày như vậy giúp cả team dễ hình dung bức tranh chung và nói cùng một ngôn ngữ.

Sử dụng hình ảnh để mô tả Problem Space về UX

Khi mô tả 1 vấn đề về trải nghiệm user, đôi khi bằng con chữ thôi chưa đủ, mình phải dùng hình.

Đặc biệt là trong những buổi họp sync với team, 1 tấm hình thôi là đủ giải thích cho vấn đề đó. Đôi khi nói dài dòng không ai hiểu, đưa 1 cái hình là cả làng hiểu luôn :)) Đỡ lòng vòng, mà team nhìn vào thấy được vấn đề và nỗi đau của user luôn.

Ví dụ 1: Feature "Diagram View" cho dbdiagram

Context:

• Khi sử dụng dbdiagram, một trong những nỗi đau lớn của user khi quản lý schema phức tạp là: tất cả bảng đều render chung một chỗ.
• Với vài chục bảng thì còn tạm, nhưng với vài trăm bảng trở lên thì diagram trở nên ngợp, rối, và gần như không thể dùng.

Khi mô tả vấn đề này, mình đưa ngay cho team mình 1 bức hình sau:

Nhìn hình dưới đây thì hiểu ngay, hàng trăm bảng trải dài, dày đặc, không ai có thể đọc hay trao đổi ý nghĩa gì từ bức tranh này cả.

Vấn đề là:

• User cần diagram nhỏ gọn, có mục đích rõ ràng, ví dụ chỉ show domain “Customer” hoặc “Order Processing”.
• Nhưng đồng thời họ cũng cần giữ một source of truth duy nhất, để nếu sửa bảng ở view này thì các view khác cũng cập nhật theo.
• Giải pháp thủ công hiện tại (tạo nhiều project riêng) thì lại gây lệch version, mất đồng bộ.

Rất nhiều user đã than phiền về chuyện này, nhưng trong team thì ít người thực sự cảm được vì trải nghiệm với database của tụi mình chủ yếu là OLTP nhỏ gọn, chứ chưa từng đụng database khổng lồ kiểu OLAP.

Cho tới khi mình đưa tấm hình này ra, cả team mới “ồ” lên và hiểu ngay vấn đề. Và từ đó, bức hình này trở thành một mấu chốt quan trọng để cả team align và bắt tay vào design giải pháp “Diagram View”.

Ví dụ 2: Feature "Version Merge" cho dbdocs

Context: Nhiều team build dbdocs tự động qua CI/CD. Kết quả là changelog sinh ra liên tục, nhưng phần lớn là empty changes (do chỉ đổi metadata/formatting) hoặc thay đổi rất nhỏ, rải rác (1–2 bảng/field) nên thiếu bối cảnh.

Khi cần xem lại lịch sử để viết release note, trả lời khách hàng/audit, hay truy vết sự cố, mọi người gặp các đau đầu sau:

Thay vì giải thích dài dòng, mình thường đưa ra một tấm hình như như trên. Chỉ một cái screenshot thôi là team hiểu ngay: “À, changelog hiện tại bị rác (empty), bị rời rạc (small incremental), và bị thiếu context (large changes with no context)”.

Và cũng từ ảnh này, hướng giải pháp bật ra rất tự nhiên:

• Squash versions để gom các thay đổi nhỏ/empty thành một mốc có ý nghĩa.
• Remove versions khi lỡ tạo ra các phiên bản rác.
• Tag & Release để tạo ngữ cảnh: mỗi release là một “câu chuyện” các thay đổi kể từ lần phát hành trước.

Nói ngắn gọn: một tấm hình mô tả đúng “bề mặt” của nỗi đau sẽ rút ngắn nửa buổi họp.

Team nhìn vào là hiểu vấn đề nằm ở đâu, vì sao user than phiền, và mình nên đi theo hướng cleanup + contextualize bằng title thay vì làm entity search.

Luôn luôn giữ lại raw customer requests

Mình nghĩ mình không phải là một người giỏi “frame problems” ngay từ đầu, do đó mình luôn giữ lại raw customer requests, tức là những ghi chú nguyên bản từ user, chưa qua xử lý hay diễn giải.

Lý do là:

1. Tránh mất thông tin gốc
   • Nếu chỉ ghi lại phần mình hiểu, có thể mình vô tình làm méo mó vấn đề.
   • Raw request giúp mình quay lại xem chính xác user đã nói gì, trong ngữ cảnh nào.
2. Tách biệt giữa “signal” và “interpretation”
   • Request thô là signal.
   • Cách mình hiểu, phân tích, và frame thành vấn đề là interpretation.
   • Giữ lại raw request giúp mình sau này có thể kiểm chứng lại: mình frame có đúng không? hay mình đã áp đặt suy nghĩ của mình vào?
3. Giúp team có common ground
   • Khi chia sẻ với team, raw request tạo ra sự minh bạch: mọi người đều thấy “người dùng nói như thế này”.
   • Sau đó cả team mới cùng bàn xem: nhu cầu thật sự là gì, vấn đề nằm ở đâu.
4. Nguyên liệu để tìm pattern
   • Một request thì có thể mang tính cá nhân, nhưng khi gom nhiều raw requests, mình sẽ bắt đầu thấy pattern lặp lại.
   • Chính pattern này mới chỉ ra đâu là vấn đề thực sự, đủ lớn để giải quyết.

👉 Vì vậy, mình coi việc giữ lại raw requests như một “kho dữ liệu gốc” để đối chiếu, thay vì chỉ dựa vào trí nhớ hay diễn giải một chiều. Từ đó, framing problem trở thành một quá trình dần dần tinh chỉnh, thay vì quyết định ngay từ đầu.

Mô tả bối cảnh thị trường bằng cách nghiên cứu các giải pháp có sẵn

Để mô tả vấn đề đủ sâu, chỉ hiểu khách hàng thôi là chưa đủ. Một PM giỏi còn cần hiểu bức tranh cạnh tranh (competitive landscape): ai đang chơi trong sân này, họ đang giải quyết vấn đề ra sao, và tại sao giải pháp của họ vẫn chưa “trọn vẹn”.

Nhiều người nghĩ rằng khi đã nhắc đến đối thủ hay giải pháp thì tức là đang bước sang solution space, và làm “bẩn” không gian vấn đề.

Nhưng với đối với mình thì khác, mọi thứ đều là remix, người tìm ra problem hay solution đầu tiên khả năng không phải là mình. Việc nhìn vào giải pháp hiện tại thực chất cũng là một cách bóc tách vấn đề, vì nó cho thấy:

• Thị trường đang công nhận những phần nào của vấn đề là quan trọng.
• Các giải pháp phổ biến thường bỏ qua hoặc xử lý hời hợt ở đâu.
• Cái “gap” nằm chính ở khoảng trống giữa nhu cầu thực sự và cách giải quyết hiện tại.

Nói cách khác, khi nghiên cứu các giải pháp đã có, mình không tìm “ý tưởng copy”, mà tìm hiểu vì sao khoảng trống vẫn tồn tại. Có khi là do giới hạn kỹ thuật, có khi là do workflow chưa khớp với user, hoặc đơn giản là chưa ai thực sự đặt câu hỏi từ góc nhìn của user.

👉 Vì vậy, với mình: nghiên cứu giải pháp hiện có không phải là đi vào solution space quá sớm, mà là mở rộng problem space đến tận ranh giới của nó, để hiểu rằng vấn đề này đang được theo đuổi tới đâu, giải quyết như thế nào, và tại sao vẫn chưa được giải quyết triệt để.

(a) Cách tiếp cận khi phân tích thị trường

Mình thường phân tích theo ba lớp:

1. Các giải pháp hiện có: Ai đang cung cấp sản phẩm / feature tương tự? Họ tiếp cận bằng công nghệ hay workflow nào?
2. Điểm mạnh / điểm yếu của họ: Giải pháp của họ đáp ứng tốt ở đâu, nhưng thiếu sót ở đâu? Những thiếu sót này đến từ yếu tố kỹ thuật, trải nghiệm người dùng, hay mô hình kinh doanh?
3. Khoảng trống (the gap): Tồn tại nhu cầu nào mà các đối thủ chưa chạm đến, hoặc chạm chưa đúng cách? Nhu cầu đó có đủ lớn, đủ “painful” để người dùng sẵn sàng thay đổi hành vi và trả tiền không?

Mình thường gom các feature vào từng nhóm (feature group), rồi so sánh xem mỗi tool đang giải quyết đến đâu. Từ đó sẽ thấy được theme chính của những solution sẵn có, đối chiếu với nhu cầu/ bối cảnh thực tế của user xem đã khớp hay chưa.

Nếu thị trường đã có common solution + giải quyết được vấn đề mà user mình đang gặp phải, và mình chưa có ý tưởng gì mới, mình sẽ "chôm" nó làm baseline cho nhanh, sau đó bổ sung thêm những improvement riêng để cải tiến gỉai pháp của mình.

(b) Case: Schema Changelog trong dbdocs

Khi nghiên cứu thị trường, mình nhận ra:

• Hầu hết các công cụ quản lý schema đều dừng lại ở mức version control text-based.
• Cách phổ biến là user lưu lại database dump hoặc migration script theo thời gian.

Điều đó giúp user biết: “À, mình có version A, version B, version C”.

Nhưng có hai vấn đề:

1. Granularity chỉ ở mức file/database dump → user chỉ thấy “version khác nhau”, chứ không biết cụ thể thay đổi nằm ở đâu.
2. Thiếu insight ở entity-level → không trả lời được những câu hỏi cực kỳ thực tế:
   • Cột nào vừa bị xoá?
   • Bảng nào vừa được thêm vào?
   • Ai là người thực hiện thay đổi này, và khi nào?

👉 Đây chính là khoảng trống.

dbdocs quyết định đi sâu hơn, làm entity-level tracking. Tức là không chỉ biết có version mới, mà biết chính xác cột nào thay đổi, thay đổi kiểu gì, khi nào.

Khi thêm “một chiều thông tin” này, trải nghiệm của user thay đổi hẳn:

• Data engineer không cần so từng file dump để đoán ra khác biệt.
• Khi có sự cố (xoá nhầm cột, mất quan hệ), họ tra thẳng changelog với entity cụ thể để khoanh vùng nguyên nhân.
• Các team compliance/audit có thể chứng minh rõ lịch sử thay đổi schema cho khách hàng hoặc regulators.

Và đây cũng chính là lý do feature Schema Changelog được adopt cao: nó giải quyết một pain còn trống trên thị trường, chứ không chỉ bắt chước tính năng của đối thủ.

Kết

Trở lại câu hỏi ban đầu:

“Sự khác nhau giữa một PM giỏi và một PM bình thường là gì?”

Một điều mình nhận ra: mô tả vấn đề không chỉ để tìm giải pháp, mà còn để alignment.

Khi problem được viết rõ ràng, cả team: từ engineer, designer, đến business, đều có cùng một điểm xuất phát. Ai cũng hiểu mình đang giải quyết cái gì, vì sao nó quan trọng, và khi nào thì coi là thành công.

Ngược lại, nếu problem mơ hồ, mỗi người sẽ tự suy diễn theo cách khác nhau → dẫn tới làm nhiều nhưng không chạm đúng nhu cầu user.

👉 Vậy nên, với mình: PM giỏi là người mô tả vấn đề đủ rõ để thiết kế được giải pháp vừa khít với bối cảnh và vấn đề mà user đang gặp phải, và sử dụng vấn đề như một công cụ alignment để kéo team cùng nhau về một hướng.