Mới đây trên Twitter, anh Jason Levin đã chia sẻ một góc nhìn khá thú vị về lời khuyên "hãy nói chuyện với người dùng của bạn" mà ai cũng hay nghe. Anh bảo, nếu cứ lao vào hỏi han người dùng khi còn chưa biết mình đang xây cái gì thì dễ lạc lối lắm. Thay vào đó, Levin khuyên nên bắt đầu từ chính vấn đề của bản thân: làm phần mềm để giải quyết cái khó của mình trước, rồi sau đó tìm những người cũng đang gặp phải vấn đề tương tự. Nghe hợp lý phết, vừa kết nối được với người dùng, vừa đảm bảo sản phẩm mình làm ra thực sự có giá trị.

Levin còn nói thẳng luôn: nhiều người làm startup mà nhảy vào những lĩnh vực họ chẳng biết gì, thế là sản phẩm làm ra cũng... lạc quẻ. Anh nhấn mạnh, "Đừng làm sản phẩm cho những vấn đề không tồn tại, trong một lĩnh vực bạn chẳng hiểu gì, cho những khách hàng bạn chẳng có tí liên hệ nào." Nghe mà thấm! Ý Levin là, trước khi bắt tay vào làm, phải hiểu rõ đối tượng mình nhắm đến và vấn đề của họ đã, chứ không thì dễ "toang" lắm.

Cái vụ kiểm chứng ý tưởng sản phẩm (product validation) này quan trọng lắm nha. Nó là bước tìm hiểu xem nhóm khách hàng nào đang gặp vấn đề cụ thể, rồi mình mới nghĩ cách giải quyết sao cho đúng. Lời khuyên của Levin hợp lý ở chỗ: bắt đầu từ chính trải nghiệm của mình. Làm vậy thì sản phẩm không chỉ sát thực tế mà còn có sẵn một nhóm người dùng tiềm năng – những người cũng đang đau đầu vì vấn đề giống mình.

Thêm nữa, làm phần mềm thì không thể thiếu chuyện chỉnh sửa, cải tiến liên tục. Joel Spolsky – một "ông trùm" trong làng công nghệ – từng nói, phần mềm tốt có khi mất cả năm trời để mài giũa qua từng phiên bản. Điều này càng củng cố quan điểm của Levin: bắt đầu từ việc dùng sản phẩm của chính mình sẽ giúp mình cải tiến nó dựa trên thực tế sử dụng. Làm vậy thì sản phẩm không chỉ chạy ngon mà còn "chạm" được đến trái tim người dùng.

Nhưng mà, mấy bạn mới vào nghề thì hay bị cái gọi là "hội chứng kẻ mạo danh" (impostor syndrome) với cả cái cảm giác "ngợp" khi học công nghệ mới. Cách tiếp cận của Levin – tập trung vào vấn đề mình quen thuộc – có thể giúp giảm bớt áp lực này. Làm cái mình hiểu thì tự tin hơn, đỡ lo lắng, mà năng suất cũng tăng. Đúng kiểu "quen việc dễ làm", phải không?

Còn chuyện tương tác với người dùng thì khỏi phải bàn, quan trọng lắm luôn. Để tăng tương tác, phải chỉnh sửa liên tục, thử nghiệm A/B, thậm chí dùng mấy công cụ hỗ trợ để hướng dẫn người dùng. Levin bảo, sau khi làm xong sản phẩm để giải quyết vấn đề của mình, bước tiếp theo là mở rộng ra cho nhiều người hơn. Lúc này, phải để ý mấy chỉ số như tỷ lệ thoát (bounce rate), thời gian sử dụng (session duration), hay cách người dùng tương tác để đảm bảo sản phẩm "hợp gu" với họ.

Tóm lại, chia sẻ của Jason Levin là một lời nhắc nhở cực kỳ giá trị về sức mạnh của trải nghiệm cá nhân trong lập trình phần mềm. Làm sản phẩm để giải quyết vấn đề của chính mình không chỉ giúp sản phẩm sát thực tế mà còn tạo được sự kết nối sâu sắc với người dùng. Cách tiếp cận này không chỉ giúp tăng tương tác mà còn đặt nền móng cho việc kiểm chứng sản phẩm và phát triển lâu dài. Trong thời đại công nghệ thay đổi chóng mặt như hiện nay, áp dụng triết lý này có khi lại là chìa khóa để tạo ra những sản phẩm phần mềm ý nghĩa và "chất chơi" đấy!