Chủ đề chính của bài này là hai từ khóa Py góp nhặt từ môn MIS trong chương trình MBA: spreadsheet mindset vs data modeling mindset. Không chỉ dùng để giải thích sự khác nhau giữa hai cách tổ chức dữ liệu, theo Py, việc hiểu và thực hành “được” hai loại mindset này còn có thể giúp các bạn junior tăng tốc nhanh hơn trên con đường làm sản phẩm.

Định nghĩa
(Phần này được tổng hợp với sự hỗ trợ của AI)

Spreadsheet mindset, nói theo kiểu học thuật, là cách tiếp cận vấn đề theo mô hình bảng phẳng — flat table. Dữ liệu được sắp xếp tuyến tính: mỗi hàng là một bản ghi, mỗi cột là một thuộc tính. Người dùng tương tác với dữ liệu bằng cách lọc, tổng hợp, kéo công thức. Theo cách định nghĩa của Humanizing Work¹, đây là tư duy phù hợp với những bài toán mà dữ liệu đã có sẵn và công cụ phân tích có thể cho ra một câu trả lời rõ ràng. Còn nói theo cách đời thường hơn, đây là tư duy của người quen xử lý từng case một — bài toán đến thì giải, giải xong thì thôi, hướng đến việc deliver kết quả nhanh trong thời gian ngắn. Những vị trí như CS hay performance marketing, nơi phản ứng nhanh là yêu cầu sống còn, thường rất thành thạo kiểu tư duy này.

Data modeling mindset thì không nhìn vào nội dung của bảng — mà nhìn vào cấu trúc của hệ thống. Theo cách diễn đạt của Joe Reis trong newsletter Practical Data Modeling², “data modeling trước hết là một bài tập tư duy — bạn đang ánh xạ các khái niệm kinh doanh vào dữ liệu.” Cốt lõi của cách tiếp cận này xoay quanh ba câu hỏi: entity (đối tượng trong hệ thống là gì?), attribute (thuộc tính của nó là gì?), và relationship (các đối tượng liên kết với nhau như thế nào?). Quan hệ đó là one-to-one, one-to-many, hay many-to-many — câu trả lời sẽ quyết định cách hệ thống vận hành, không chỉ hôm nay mà còn khi mọi thứ bắt đầu phức tạp hơn.

Lấy ví dụ đơn giản: cùng là bài toán phân tích lợi nhuận. Người có spreadsheet mindset sẽ mở bảng tính, lấy doanh thu trừ chi phí . Người có data modeling mindset sẽ dừng lại và hỏi thêm: một đơn có thể áp nhiều mã giảm giá không? Một sản phẩm có thể thuộc nhiều danh mục không? Nếu có, khi tính lợi nhuận theo danh mục, đơn đó sẽ được đếm mấy lần?

PO cần loại mindset nào?

Với Py, mindset không phải thứ chọn một lần rồi dùng mãi — mà là thứ cần biết chuyển đổi tùy tình huống. Và ở góc độ đó, tinh thần của data modeling mindset không chỉ dừng lại ở dữ liệu — mà còn có thể áp dụng vào cả cách thiết kế giải pháp nói chung.

Và chắc chắn, PO cần cả hai, và đồng thời cần tự build bộ filter để có thể chọn nhanh mindset nào khi cần sử dụng. Chẳng hạn có thể dựa vào mức độ gấp, mức độ impact của request để chọn cách tiếp cận phù hợp:

• Nếu là hot fix, quick win, những thứ cần lên nhanh trong giai đoạn vận hành — spreadsheet mindset là đủ, tập trung quan sát những gì đang hiện hữu rồi đưa ra quyết định. 
• Còn nếu là build hệ thống, cụm tính năng lớn, hay toàn bộ sản phẩm mới — data modeling mindset giúp bạn vừa define được big picture, vừa không bỏ qua small steps, tức là ước tính được scope và đồng thời xác định được làm gì trước.

Suy cho cùng, cả hai mindset đều phục vụ cho cùng một việc: giúp PO phân tích vấn đề qua nhiều layer, đưa ra giải pháp đáp ứng được nhiều tiêu chí cùng lúc — thường là impact, thời gian, và trong giới hạn nguồn lực đang có. Ở góc độ nào đó, data modeling mindset khá tương đồng với system thinking. Khi quen với việc đặt câu hỏi về entity, attribute, relationship, bạn sẽ tập được cách nhìn một hệ thống theo từng lớp, tìm mấu chốt thay vì xử lý triệu chứng.

Với junior PO, theo Py thì data modeling mindset còn quan trọng hơn nữa. Việc chẻ nhỏ và tìm mối liên hệ không chỉ giúp học nhanh, mà còn giúp các bạn quen với việc xử lý rất nhiều rule chằng chịt, hay thậm chí là những bài toán chồng chéo khi dự án cần phối hợp giữa nhiều bên, nhiều stakeholder cùng lúc. Dĩ nhiên, để thuần thục mindset này cần không ít công sức. Nhưng theo Py, đây là khoản đầu tư xứng đáng để đi sâu và xa hơn trong nghề.

Ở level cá nhân, Py hay tự thách thức bản thân bằng cách add thêm một vài câu hỏi khi phân tích vấn đề và đưa giải pháp: “Nếu bên kia đổi thì có cách nào đó để bên mình không cần đổi hay không?” hay “Cái này có thể làm theo kiểu config được không?” Không phải lúc nào cũng cần nghĩ sâu đến vậy — nhưng chính những lần nghĩ thêm đó, theo thời gian, là thứ khiến cách tư duy trở nên linh hoạt hơn.

Nói thêm, “đi sâu và xa hơn” ở đây không chỉ là chuyện thăng tiến trong một vai trò cố định — vì bản thân vai trò đó đang thay đổi. AI đang phát triển rất nhanh, ranh giới giữa BA, PO, PM ngày càng mờ — BA phải làm nhiều hơn trước, PO cũng không còn chỉ là PO theo nghĩa cũ. Trong môi trường mà scope liên tục thay đổi, công cụ liên tục thay đổi, thứ giúp bạn đứng vững không phải là biết nhiều tool — mà là có một cách tư duy đủ linh hoạt để chia nhỏ bất kỳ bài toán mới nào thành những phần có thể xử lý được. Kiến thức về tool có thể lỗi thời. Cấu trúc tư duy thì không.

Spreadsheet giúp bạn xử lý nhanh. Data modeling giúp bạn chậm lại đúng chỗ. Với PO, cả hai đều là công cụ tư duy — một cái để deliver, một cái để thiết kế. Và thứ tạo ra sự khác biệt không phải là giỏi cái nào hơn, mà là biết tình huống nào cần cái nào.

¹ Richard Lawrence & Peter Green, Spreadsheet Problems. Link.
(Py chỉ mượn 1 quan điểm nhỏ trong bài viết này, nhưng thông điệp chính của toàn bài thì nhiều hơn thế: spreadsheet tốt, nhưng đừng lạm dụng.)

² Joe Reis, The Relational Model, Part 3. Link.

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.

Chúc bạn nhiều may mắn và bình an.

Anpy