"Đuối" vì Business Requirements

Làm product một thời gian, em nhận ra phần khó nhất không phải là viết requirement hay prioritise backlog.

Mà là làm việc với business team.

Có những anh chị business nhìn thấy cơ hội là muốn làm ngay.

Hay quá em, mai launch được không?

Làm việc với những người này khá mệt. Backlog chưa kịp nguội thì idea mới đã tới. Nhưng cũng phải thừa nhận là họ tạo ra cảm giác rất nhiều năng lượng. Mình cảm thấy thị trường đang chuyển động và mình đang chạy cùng nó.

Ở chiều ngược lại, cũng có những business stakeholder rất cẩn thận.

Họ muốn phân tích thêm, nghiên cứu thêm, họp thêm một vòng nữa. Làm việc với nhóm này dễ thở hơn rất nhiều. Nhưng đôi khi em lại thấy sản phẩm di chuyển chậm hơn mức cần thiết.

Và product thường là người đứng giữa hai thái cực đó.

Một bên cần hiểu rằng “chỉ sửa một chút thôi” đôi khi là 3 service, 2 database và 4 team cùng tham gia. Bên còn lại cần hiểu rằng việc không thay đổi cũng có chi phí riêng của nó.

Điều thú vị là trong thời đại AI, business giờ hiểu tech nhiều hơn trước rất nhiều. Họ có thể tự viết requirement, tự research, tự brainstorm giải pháp.

Nhưng em thấy vai trò của product vẫn không thay đổi nhiều.

  • Vẫn là người giúp các bên hiểu nhau hơn.

  • Vẫn là người kết nối business context với technical reality.

  • Vẫn là người trả lời câu hỏi: “Chúng ta nên làm gì tiếp theo?”

Mọi người thấy sao?

Business stakeholder khó làm việc nhất mà mọi người từng gặp là kiểu nào?

3 Likes

Ohhh nicee sharing em :clap:

Hầu như chị thấy case 1 (“mai launch được không”) là nhiều, chứ case 2 (“để suy nghĩ cẩn thận”) thì mới bảo bối hiếm có :)))

Một trong những lý do của case 1 thì chị nghĩ vì họ nhìn thấy rõ cơ hội (upside) nhưng bị blindspot về nguồn lực/effort/investment (downside) (kể cả là khách quan không hiểu effort vì thiếu chuyên môn kỹ thuật hoặc cố tình không chịu thông cảm). Dẫn đến quyết định “làm luôn, làm lẹ” nó như kết luận hiển nhiên vì “cái này chỉ thấy upside, không thấy downside” (trong Lesson 4 của BPM về 3-layered architecture mình có bàn).

Vẫn có case 1.2 là họ thực sự nhìn thấy cơ hội chiến lược quan trọng thật nên muốn đẩy nhanh. Nhưng mà case này thì họ chỉ nói câu “mai launch được không” rất ít lần, và nó thực sự quan trọng chứ không phải câu cửa miệng :)))

Case 2 thì hiếm có khó tìm hơn. Chị nghĩ case 2 chỉ xảy ra khi môi trường hoặc cấu trúc đủ incentivized họ làm chuyện đó. Ví dụ công ty có văn hoá “suy nghĩ thận trọng” (thay vì nhắm mắt chạy), họ đủ quan tâm và muốn làm điều đúng đắn, hoặc có dính dáng trách nhiệm nếu có hậu quả xảy ra/làm lãng phí resources (thường có thể xảy ra ở những level đủ cao).

Chị hơi tò mò trường hợp “cũng có những business stakeholder rất cẩn thận” mà em tiếp xúc là họ làm vậy vì lý do gì dạ?

case chị găp thì “khó làm việc” có thể đến từ 2 lý do:

1/ mâu thuẫn về lợi ích giữa các bên/team, KPI của các team bị conflicts nhau hoặc không bổ trợ nhau để đóng góp cho mục tiêu lớn hơn của công ty :))) mình thấy họ “khó” vì họ không làm vậy thì sẽ ảnh hưởng trực tiếp đến họ (đa số).

→ case này thì hít nhiều hơi thật sâu, thiện chí tìm hiểu vấn đề và incentives của họ, chia sẻ vấn đề và incentives của mình; trường hợp thiện chí thì thường hoàn toàn có thể negotiate để đến được common ground; trường hợp hơi ba gai thì chắc phải escalate lên quyền lực cao hơn để phân xử vì vấn đề cấu trúc như KPI choảng nhau mà bên kia không nhượng bộ thì ngoài phạm vi xử lý của mình rồi.

2/ không có vấn đề nào ở tầng cấu trúc, chỉ đơn giản là tính cách họ vậy =))) thường là các bác ở vị trí có quyền lực và có tiếng nói thì thích là khó thui chứ không cần lý do (thiểu số).

-> case này ráng né được thì né, bớt va chạm vì không có logic nào apply được ở đây cả :)))

1 Like

Phần này khá thú vị, vì thay vì họ push product, thì họ làm việc giống như kiểu “KPI là 3 chữ cái” =))) do em có đi nghe tin hành lang được thì có 1 vài project nó đã thật sự được kickoff ở phía biz từ những năm trước, commitment vẫn mong muốn rất cao, nhưng đến khi có product involve vào để planning và clearing business requirements thì vẫn có mặt em lol. Nhưng chỗ này em thấy hay vì nếu product có thật sự challenge thì biz đã thủ sẵn và “táp” lại product về bất cứ những edge case nào đó hay cần đưa ra rõ ràng business value cho những câu hỏi thách đố là vẫn okela luôn ạ. Mà làm vậy thì tech và product lại thật sự được aligned nhanh hơn và có nhiều sự ưu tiên từ team hehe

1 Like

Giờ mới có time ngồi reflect suy nghĩ thử về chuyện làm việc với business team. Thú thật là anh cũng không có quá nhiều pain point chỗ này, chắc do trước giờ khi làm B2B SaaS products thì đa số các công ty anh làm đều đặt trọng số cho product ngang hoặc hơn business.

Ở Katalon thì cả chiến lược GTM hay là pricing unit như thế nào thì thời anh làm cũng lean on PMs để frame và lead conversations đó. Khi có customer request thì nó đều phải đi qua triage process được xem như interface giữa product & business team, với SLA về chuyện phản hồi chứ không phải là giải quyết. Sẽ có một cuộc meeting hàng quý hay tháng giữa business và product để review về lost deals + churn, đào ra lý do để có thể bàn luận, và thường CEO/CPO + PM sẽ là người pick ra một số capabilities từ lost deals + churned customers đó để cân nhắc đưa vào roadmap.

Về sau lúc anh gần rời khỏi công ty thì anh thấy process đó bắt đầu chuyển dịch sang SLA là resolution, thì anh thấy khá bất hợp lý bởi lẽ nó đặt product vào một vị thế phải resolve tất cả customer requests và được track performance theo metrics đấy, trong khi có những thứ nó trông có vẻ quick win nhưng sẽ ảnh hưởng tới product roadmap về long-term. Đây là một trong nhiều tín hiệu khác chỉ dấu chuyện công ty đã bắt đầu prioritize short-term business values over long-term strategic values.

Theo anh quan sát thì việc debate và defend against business requests nếu thực hiện trên mỗi ad-hoc request nó rất tốn thời gian cũng như khó cho team product, vì business họ thường có thể kể câu chuyện đẹp đẽ như “Nếu mày làm feature này thì sẽ close được contracts”, còn ở phía Product phải cân bằng bài toán long-term hơn, mà long-term thì khó để giải thích bằng con số.

Vì vậy, nếu công ty nó không position team Product ở vị thế ngang hoặc hơn để đối trọng lại business, thì rất dễ để chạy theo quick win hoặc tiếp tục vắt cash cow, dẫn đến chuyện sự sống lâu dài của sản phẩm bị ảnh hưởng. Chuyện positioning của team product trong một công ty nó sẽ được chi phối bởi Head of Product hay VP of Product có define product development process theo một cách holistic không, CEO có mandate nhiều quick wins so với chuyện đầu tư long-term strategy không, cũng như tình trạng của công ty (nếu đang thiếu tiền thì phải ưu tiên có tiền chứ cũng không ăn mày đòi xôi gấc được).

Gần đây anh cũng đã quan sát được một vài data points bổ trợ cho narrative prefer quick win over sustainability thì sẽ phải trả giá, khi thấy công ty cũ của anh layoff >=40% và nhìn vào product innovation của họ từ góc độ customers. Tuy có nhiều nguyên do, nhưng chuyện dần dần chuyển dịch theo hướng team product phải chạy theo business short-term chắc hẳn đóng góp cũng nhiều cho trạng thái hiện tại của công ty.

P/S: cơ mà khả năng cao a bị biased bởi kinh nghiệm làm B2B =))) chứ có khi ở B2C thì ngược lại nó mới là norm, cũng ko có đúng sai tốt xấu mà chắc tùy tính chất của domain

2 Likes